Saturday, September 3, 2016

Digest for comp.lang.c++@googlegroups.com - 25 updates in 8 topics

Jerry Stuckle <jstucklex@attglobal.net>: Sep 02 07:58PM -0400

On 9/2/2016 4:51 PM, me wrote:
>> I'm not even going to bother with you any more.
 
> Classic! I'm sure that will convince readers who can go back and look at
> the history ...
 
They sure can. And they will see what you really are.
 
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
Richard Damon <Richard@Damon-Family.org>: Sep 02 09:48PM -0400

On 9/2/16 8:51 AM, BartC wrote:
> uint32_t a;
> uint32_t b;
> etc.
 
Since the pragma doesn't begin with STDC it is implementation defined,
so does nothing as far as what the standard says must happen. Once you
are willing to depend on implementation defined behavior,you don't need
the pragma, as the implementation can document their padding rules and
define that padding won't be added in this case (the standard doesn't
require this to be documented, but it can be).
David Brown <david.brown@hesbynett.no>: Sep 03 05:58PM +0200

On 02/09/16 22:56, Paavo Helde wrote:
> with a struct is that the compiler decides to place it into registers
> altogether and there is no layout to speak of (what is the padding
> between EAX and EBX?).
 
Certainly when you have small structs declared locally, you can expect
that some or all of the parts will be placed in registers. Other bits
might go onto the stack, or be removed entirely if they are not actually
needed.
 
> registers (except for the common initial sequence, if any). Using
> different registers might make a lot of sense if one member is holding
> integers and the other floating-point numbers, for example.
 
Yes, that sounds reasonable.
 
> I guess the
> only thing which might hold the compiler developers back here is that
> the union has a long tradition of being illegally abused for type-punning.
 
Note that this is only "illegal abuse" for C++ compilers that don't
allow it as an implementation-dependent feature. C compilers (from C99
onwards) have it as part of the standards, and C++ compilers such as gcc
allow it as implementation-dependent behaviour. Since all, or at least
almost all, C++ compilers are also C compilers, it would surprise me if
such type-punning unions work did not work correctly - at least in
simple cases. (Relying on this behaviour, unless it is documented by
your compiler, is of course a bad idea.)
David Brown <david.brown@hesbynett.no>: Sep 03 06:08PM +0200

On 02/09/16 22:32, Jerry Stuckle wrote:
 
<snip>
 
Jerry, you are wrong. You are talking absolute nonsense. You are
talking such complete and utter rubbish, that I suspect you actually
/do/ know a little about how compilers work - it would be hard to get so
many things wrong in so many ways by sheer idiocy and ignorance, so at
least part of what you write must be intentionally wrong.
 
I can only suppose you think it is fun to post this sort of stuff to
wind people up. Certainly that seems to be the only motivation for the
extraordinary levels of hatred and bile you pour out at people on
Usenet, and the totally unjustified insults you come out with. What a
sad, lonely little life you must lead when you gain pleasure from trying
to push other people down.
Jerry Stuckle <jstucklex@attglobal.net>: Sep 03 06:25PM -0400

On 9/3/2016 12:08 PM, David Brown wrote:
> Usenet, and the totally unjustified insults you come out with. What a
> sad, lonely little life you must lead when you gain pleasure from trying
> to push other people down.
 
Sorry, David. Once again you are throwing out the standards, based on
your incorrect assumptions. But such is the life of language lawyers
who think they know what is going on - but have absolutely no clue.
 
And those aren't insults. They are only the truth. Stoopid is as
stoopid does. And you have proven yourself time and time again to be
one of the worst. Starting when you claimed you couldn't determine
whether a machine was big endian or little endian at compiler time, and
I showed you wrong there, also.
 
The bottom line is - you don't know 10% of what you think you know. And
you never will until you humble up and figure out a lot of people know
more than you do - most of the world, in fact.
 
But then it seems many of the people in this newsgroup are in the same boat.
 
And FYI - the first compiler I wrote was a FORTRAN compiler in the early
70's in IBM 360 assembler. It was a side project since I had access to
a mainframe at the time.
 
One other thing - I lead a very happy life. One thing I have learned
over the years. I don't have to put up with stoopid idiots or trolls.
Life is too short to worry about what they think of me. When you start
paying me what my clients do or otherwise make a positive difference in
my life, I will start to care. Until then, you're not worth my worrying
about.
 
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
ram@zedat.fu-berlin.de (Stefan Ram): Sep 03 09:43PM

I wanted to run clang-tidy using my MinGW headers. I had
no prior experience with LLVM/clang. I understand it that
clang will not work freestanding but needs header files
from a C++ implementation.
 
First, I used »cc1plus.exe -v« to get the header directories
from MinGW and then I supplied them to clang-tidy after »--«
(like all other options following) with »-I« options.
 
clang-tidy did not accept »-std=c++17«, but then »-std=c++1z«
worked.
 
However, the MinGW/gcc header files contained lines like:
 
const char * __restrict__ , ...) __MINGW_NOTHROW;
 
, and clang-tidy reported an error on such lines (due to
»__MINGW_NOTHROW« and such, I suppose). I was able to reduce the
number of errors slightly using »-fms-compatibility-version=19.00«.
 
clang-tidy stopped after 20 errors, so I used »-ferror-limit=9999«.
Now it reports »3332 errors«, all in the MinGW header files.
 
I use »| tail -99« to only see the diagnostics for the code
that I have written, and it works in this way. For example, I
write »a[ i ]« and it recommends to use »::gsl::at«.
 
It seems that they have invested more effort to make it play
nice with MSVC.
 
I am using relatively recent versions of both MinGW and clang,
so maybe it would work better if I had used more stable versions,
but I want C++17/C++1z. While it feels bad to ignore 3332 error
messages, it then also works to give me the diagnostics that I want,
as far as I can understand what is happening.
 
I even tried to
 
#define __MINGW_NOTHROW /**/
 
at the very top of my file, before #including, but this had
no effect on the error messages.
ram@zedat.fu-berlin.de (Stefan Ram): Sep 03 10:17PM

>but I want C++17/C++1z. While it feels bad to ignore 3332 error
>messages, it then also works to give me the diagnostics that I want,
>as far as I can understand what is happening.
 
I want to suppress the errors from headers. So, of course, the
first thing I did was to use this option directly on »clang-tidy«:
 
-header-filter=abcdefg
 
. It should only show errors from headers matching
»abcdefg«, and since there are no such headers, I was
hoping not to see such errors. But it had no effect.
 
Without the include directories, my command line now looks like:
 
clang-tidy -header-filter=abcdefg -checks=* main.cpp
-- -std=c++1z -ferror-limit=9999 -fms-compatibility-version=19.00
 
.
Vir Campestris <vir.campestris@invalid.invalid>: Sep 03 09:02PM +0100

On 01/09/2016 21:41, David Brown wrote:
> Actually, Jerry has been correct in this thread - and he has not been
> the rudest and most unpleasant poster here either (that "honour" goes to
> the OP himself). Credit where credit is due.
 
I don't see Jerry's stuff, except where other's post it on. He may have
improved.
 
Andy
Gareth Owen <gwowen@gmail.com>: Sep 03 09:06PM +0100

>> the OP himself). Credit where credit is due.
 
> I don't see Jerry's stuff, except where other's post it on. He may
> have improved.
 
He hasn't.
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Sep 03 09:36PM +0100

On 03/09/2016 21:06, Gareth Owen wrote:
 
>> I don't see Jerry's stuff, except where other's post it on. He may
>> have improved.
 
> He hasn't.
 
I think it's time I also plonked Stuckle as life's too short to have to
read his consistently egregious posts.
 
/Flibble
Jerry Stuckle <jstucklex@attglobal.net>: Sep 02 07:57PM -0400

On 9/2/2016 4:45 PM, Mr Flibble wrote:
> job in my entire life and my current job is certainly "decent".
 
> So how many of your consultancy companies when bankrupt again?
 
> /Flibble
 
Nope, you didn't. The only one you could have possibly had you got
fired. And you just proved it.
 
Just like a troll.
 
And none of my consultancy companies have gone bankrupt. I probably
make more in a day than you do in a week.
 
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
raltbos@xs4all.nl (Richard Bos): Sep 03 08:00AM

> > engineers try to steer a river using traffic signs."
 
> > As usual, Randall Munroe nails it.
 
> Unicode is simple in C++: just use std::string and UTF-8.
 
You... do not understand Unicode.
 
If you think the problem is just one of choosing one correct charset,
you're very naive. The problems are much hairier than that, and much
more detailed.
 
Richard
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Sep 03 02:10PM -0500


> If you think the problem is just one of choosing one correct charset,
> you're very naive. The problems are much hairier than that, and much
> more detailed.
 
Of course I understand Unicode: I am designing a compliant text editor
widget as I write this. As far as C++ is concerned it really is that
simple.
 
/Flibble
"Öö Tiib" <ootiib@hot.ee>: Sep 03 07:39AM -0700

On Saturday, 3 September 2016 00:57:02 UTC+3, Mr Flibble wrote:
> with random access like vector or deque. Also std::map is a single
> container whilst this is a solution that allows us to have multiple
> foreign containers.
 
Logic of the idexitor feels like that of somewhat constrained multimap
to references or map to pairs of references. IOW it can hold one-to-many
relations under certain constraints. Does indexitor achieve that it is
cheaper to update the innuendoes to other container when needed? Are there
other positive effects?
 
When I need to reduce the cost of updating references or iterators in
"indexing containers" of elements of "other container" then I typically
use containers with stable references (huge variety std:: [forward_]list
/ [multi]set / [multi]map, boost::intrusive:: [s]list / [multi]set)
as that "other container" or use boost::multiindex::multi_index_container
for the whole problem. What is indexitor's benefit compared to those
approaches?
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Sep 03 02:05PM -0500

> as that "other container" or use boost::multiindex::multi_index_container
> for the whole problem. What is indexitor's benefit compared to those
> approaches?
 
The benefit is that you don't have to use containers with stable
references.
 
/Flibble
Gareth Owen <gwowen@gmail.com>: Sep 03 07:27AM +0100


> This provokes an error in the second line.
 
> This asymetric behavior is somehow surprising.
 
Isn't the difference that you return a temporary object, and then
attempt to to pass a non-const reference to that temporary?
And in the other you have a legitimate non-const reference?
jacobnavia <jacob@jacob.remcomp.fr>: Sep 03 10:02AM +0200

Le 03/09/2016 à 08:27, Gareth Owen a écrit :
 
> Isn't the difference that you return a temporary object, and then
> attempt to to pass a non-const reference to that temporary?
> And in the other you have a legitimate non-const reference?
 
Well, shouldn't any references be ignored also in the return value of
the template and the template made to return the temporary object and
note a reference to it?
 
But if we would do that we would forbid returning a reference at all
from a template what would have another (surely worst) implications.
Gareth Owen <gwowen@gmail.com>: Sep 03 04:45PM +0100


> Well, shouldn't any references be ignored also in the return value of
> the template and the template made to return the temporary object and
> note a reference to it?
 
I don't see anything in the description that suggests. The reference is
only removed for the purpose of type deduction.
"Chris M. Thomasson" <invalid@invalid.invalid>: Sep 02 06:56PM -0700

For fun, I was thinking about the effect of certain race-conditions, and
decided to see what happens if I made a random bit generator based on
multi-threading race-conditions alone. Here is a little program I wrote
that generates random 1024-bit numbers, and a busted fetch-and-add impl...:
____________________________________________
#include <thread>
#include <atomic>
#include <cstdio>
 
#define THREADS 7
 
static std::atomic<unsigned int> g_racer(0);
 
 
void racer(unsigned int n)
{
for (unsigned int i = 0; i < n; ++i)
{
// Race infested fetch-and-add op
unsigned int r = g_racer.load(std::memory_order_relaxed);
r = r + 1;
g_racer.store(r, std::memory_order_relaxed);
}
}
 
 
unsigned int get_rand_bit(unsigned int n)
{
std::thread t[THREADS];
 
for (unsigned int i = 0; i < THREADS; ++i)
{
t[i] = std::thread(racer, n);
}
 
for (unsigned int i = 0; i < THREADS; ++i)
{
t[i].join();
}
 
unsigned int r = g_racer.load(std::memory_order_relaxed);
 
return r & 1;
}
 
 
void display_rand_bits(unsigned int n)
{
std::printf("%u Race-Condition Bits\n"
"____________________________________________\n",
n
);
 
for (unsigned int i = 0; i < n; ++i)
{
unsigned int r = get_rand_bit(1000000);
std::printf("%u", r);
if (! ((i + 1) % 64)) std::printf("\n");
std::this_thread::yield();
}
 
std::printf("\n____________________________________________\n");
}
 
 
int main()
{
display_rand_bits(1024);
 
return 0;
}
____________________________________________
 
 
Does this program work for you? If so, can you please show me some of
the outputs you get? Thanks. FWIW, I notice I seem to get better results
when the system is busy doing something else...
 
 
 
FWIW, here are a couple of outputs I get:
 
 
1024 Race-Condition Bits
____________________________________________
0111111111110111000011101111001100101011010111111011101001100010
0010100110111111010110101100100111010101110111000110110000111110
0110011111101100001010000101111110001101000110101000010101000001
1110010101011100111101100001000001101011111100101100101110001101
0100011000000110011011101100011000000001110110011111010001001000
1001111011111100000011100011101000011101010010111111011110010001
1101101100010011110001110010010111000111110101110110100000001101
0100111110100101100101000010011010100011011010001010110001101011
1001110001000111011100001101011001100101100010010011000011001010
1001000101000110011100000111010011010111001110010101000011000001
0001111100000011100000001100100111000000010100101110000111001011
0000101001100010011010010110001000011111110000101100110100101000
1100101111010011000010100101010000000011000000000011101001111001
1001001011110101001000110010010101010111011010000000000110100110
0110100110001000111011101000110001011010011110000111010111111111
1000010111000011011010111000111000011000001010101111100110111000
 
____________________________________________
 
 
 
1024 Race-Condition Bits
____________________________________________
1101011000111010011001110000000110000000111011100110010111110011
0001110010100010111101101100101001100001100001111110110011111101
1000111100010001100001111011010100111000000101101101110101010111
0111001011000111101101001110010111010000111110100111000110001111
0110011111111011111011000100010010110000100100111110001010100000
0110101101100101110100000111001000110101110000010100001000100000
1000111100101111100110101001000010010011011100001010000101110011
0001000001000010010110111101000011000010110001010101111110010011
0111011000111000111011111000110100001101110000010100010101110001
0001111110110000110111001010111111101111010011001111100111001101
1111000000100000110000001100001000111011000010101111110010000001
0000101101101100100010010001000101011111000011001101000110010111
0110000100010111111101001110111101111100101000111101101101111000
0100100100111011001000010100111100011111100000101001110011010100
1010011000101010101010111010000110100101110001100010010110101000
0111011011000100111000101010101111010110110010101111010110000000
 
____________________________________________
 
 
 
1024 Race-Condition Bits
____________________________________________
1011101010101011101010100000011110001010011010000001110101101000
1000110111100111100000110111000011101000000111001010111111111000
0000100110110010111110100111110001110010110100111000011110000101
1110110010111001100010000100011011001111101010010111011111000010
0001010010100010010110110100010000110110101010110100101001111010
0101011101111010101100101111110110000011101001110010110100111010
1000101011111111100011111110001010010000101110011111101001100010
1110111110001011000011000110100110110101100110000001101100001000
0101110100001001010111110001110110110000110101101101100101110101
0011101000110010001000010000111110011100000011010101001110010011
0100010000101000101001000000100110100001000000111100111010101001
0100101011110010010101011010111100000011100111010100110001101111
1100010000010000001001110010110100110110110001010100011100011101
1110110101111100101011001111100111011001111110111100011101100011
0111100000111010101110111110001000100111101010010100011110101100
0000011110101000110010110001000101010111100110001011011000100011
 
____________________________________________
 
 
;^D
Brett Dong <brett.browning.dong@gmail.com>: Sep 03 03:41PM +0800

On 9/3/16 9:56 AM, Chris M. Thomasson wrote:
> multi-threading race-conditions alone. Here is a little program I wrote
> that generates random 1024-bit numbers, and a busted fetch-and-add impl...:
> ____________________________________________
 
On my machine:
 
1024 Race-Condition Bits
____________________________________________
1101110000110101000000001010000101011100001010001100011110001111
1011000100101010001000101001100100011001110111100110010010000111
0011101011000010010100001011010101111001111101100110101000110100
1110101011001101100001010111011000101001100110001001110101001100
1000000100011010100111011111100000010000111011100011110111110110
0101110001111010010011010101001000111111110010101100110111000011
1001101111000010000101010010111101110101111100001011110101111011
0011010101010000011010010110100001100110111010100010011101000011
1000011001011101100101001000100100001000001111111010001101010000
1011000000111011011111111111110010110110011000010001111011010000
1000010111110011001111010111111011000010100100011100100111110010
0011100001011001101110010010101010101111100010110100001111000011
0110111101001010101100011110001011011101110110000101100110111001
1010011010110101101011110010100011001001100110000110000010000000
1011001010100000100010000011101010111000011100100011010001011011
0100111101101110100010110010011111110101100000011011100100111011
 
____________________________________________
Brett Dong <brett.browning.dong@gmail.com>: Sep 03 04:17PM +0800

I modified the implementation a little bit:
 
1. Create the same amount of threads to the number of physical threads
local hardware actually has. This makes the program run much faster on
my dual core 4-thread CPU.
 
2. Measure the time elapsed to calculate how many bits are generated per
second.
 
______________________________________________________________________
#include <iostream>
#include <thread>
#include <atomic>
#include <time.h>
 
#ifdef __MACH__
#include <sys/time.h>
/* clock_gettime is not implemented on OSX
http://stackoverflow.com/questions/5167269/clock-gettime-alternative-in-mac-os-x
*/
#define CLOCK_REALTIME 0
int clock_gettime(int /*clk_id*/, timespec* t)
{
timeval now;
int rv = gettimeofday(&now, NULL);
if (rv)
return rv;
t->tv_sec = now.tv_sec;
t->tv_nsec = now.tv_usec * 1000;
return 0;
}
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)