Re: [Algorithms] How to get 3dvector largest coordinate index?
Brought to you by:
vexxed72
From: Glenn F. <ga...@ga...> - 2009-03-07 05:41:18
|
wow great post jim :) On Fri, Mar 6, 2009 at 9:28 PM, Jim Tilander <jim...@gm...> wrote: > It's sad to see that so many people have no knowledge of the C++ > language, or even worse, disdain for that knowledge and taking the > attitude that it doesn't matter. Yes, the standard is pretty nasty, > long and full of language that takes way too long to interpret. But > it's *the* only source of authoritative answers to many of the > questions we can encounter while coding. It's like a workman who > doesn't like or want to understand his tools. Oh, wait -- it's exactly > like that. > > Now don't get me wrong, I've by no means an expert at the language, > but I've tried to preach 3.10.15 over the years (I saw that Charles > beat me to it posting it). The very first reaction to the paragraph > should be to read it again. Here it is: > > 3.10.15: > If a program attempts to access the stored value of an object through > an lvalue of other than one of the following > types the behavior is undefined: > — the dynamic type of the object, > — a cv-qualified version of the dynamic type of the object, > — a type that is the signed or unsigned type corresponding to the > dynamic type of the object, > — a type that is the signed or unsigned type corresponding to a > cv-qualified version of the dynamic type of > the object, > — an aggregate or union type that includes one of the aforementioned > types among its members (including, > recursively, a member of a subaggregate or contained union), > — a type that is a (possibly cv-qualified) base class type of the > dynamic type of the object, > — a char or unsigned char type. > > Note the wording of the first sentence (read it again, how many of you > guys did read it the time Charles posted it? :). *Any other* access > than the ones listed are invalid (actually undefined behavior, which > in standard speak is run away and hide). Actually, Philip Taylor wrote > an earlier email explaining most of this in plain talk, read his post > again :) People try to get around this and read the following very > liberally, but it turns out that no, the way you can access memory is > very limited. The above can be summarize in short as: > > "Only one type can ever live at one memory address at the same time" > > Now, as many noted, char* are intentionally left there as a loophole. > You can always access things through a char* and it will be fine. But > you need to treat it as char, and not go around doing things like: > > float f; > int* bad = (int*)(char*)(float*)&f; // this is bad. > > If you want an integer representing your IEEE 754 number, you need to > do (assuming a long is 32 bits of course and endianess): > > float f; > unsigned char* p = (unsigned char*)&f; > long i = p[0] << 24 | p[1] << 16 | p[2] << 8 | p[3]; > > The union trick does not work. No really, it doesn't. It's undefined > behavior meaning that the compiler is free to do whatever it likes. > Even erase your hard drive or start tetris. It so happens that the gcc > guys usually doesn't want people to hunt them down and strangle them > so in this case they are trying to do the right thing, through turning > off most of the optimizations. > > Another point to make is that the bit_cast that Pal mentioned (I think > it has been mentioned before as union_cast) has one terrible flaw > apart from the obvious that it's undefined since it uses the union > trick: it works by copying r-values. It can thus be abused like this: > > int* i = union_cast<float*>( &f ); > > Which will just yield the original error while optimizing since it > copies the r-value of the pointer, but not that of the value itself. I > think I saw this usage on the thread as well, stay away from it -- > pain an misery will ensue. > > Now some people question the need to actually bother with stuff like > this, and continue on casting like we programmed in C89. They will get > bitten by the decent compilers that does perform the most basic > optimizations. They will be very slow on in-order processor by nature > of the compiler having no chance to figure out aliasing. Aliasing btw > is the big reason why FORTRAN is 2x as fast as regular C89 in most of > the cases. Aliasing a large reason why C99 came about and why C++ has > the draconian rule 3.10.15. There is a *reason* why this all matters > and that is speed. > > Why would we bother with the whole union-type punning illegalities? > Because it breaks the standard! That's why we are in this whole mess > to start with, remember we broke the standard by casting float* to > int* and then using it? The proposed solution was a bug in the > compiler that could be exploited by using unions. It just seems > incredibly shortsighted to me, to go and break the same rule again and > then stick the head in the sand pretending that it's not a problem. > It's a fundamental problem with how we write code if we can not follow > something that's in the basics of the language (oh, god don't bring > templates into this if we can't even handle the basics like using > r-values and l-values). > > Note that the TBAA (Type Based Alias Analysis) have been present in > gcc for a long time, it's only recently (ok, really not so recently) > that they decided to make it default in -O2, even though it would > break a lot of code. The fact that people think that they can break > the standard and be safe just because nobody will want to break their > code is just naive. Compiler vendors will "break" your code, and if > you turn around and complain I bet the answer will be "turn off > optimizations to fix it". Which I bet those people will not be willing > to do and then will turn to scramble to fix their code. Only, we are > talking about basic assumptions here. All the l-value accesses. Those > are a ton of accesses. It could potentially be a complete rewrite of a > major part of the codebase. That's what we've faced on the current > platforms and it just burned everybody badly. Why would you after this > advocate breaking the same rule again? > > /j > > > ------------------------------------------------------------------------------ > Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, > CA > -OSBC tackles the biggest issue in open source: Open Sourcing the > Enterprise > -Strategies to boost innovation and cut costs with open source > participation > -Receive a $600 discount off the registration fee with the source code: > SFAD > http://p.sf.net/sfu/XcvMzF8H > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list > |