Re: [Algorithms] How to get 3dvector largest coordinate index?
Brought to you by:
vexxed72
From: Gino v. d. B. <gin...@gm...> - 2009-03-06 09:48:21
|
I tend to agree. When replacing a float compare by an integer compare on the bit representation of the floats, strict-aliasing is the least of your problems. (Other assumptions: sizeof(int32_t) == sizeof(float), floats are IEEE754-ish (PS2 included), floats are non-negative and finite) I don't see why the type-pun through a union is discredited so badly. I have yet to be bitten by a union type pun. To turn the argument around: Does anyone here know of a compiler for which type punning through a union does not give the proper result? The whole "union is considered harmful" debate seems to be a mostly religious one. In any way, how hard is it to create a rule in autoconf or cmake (build tools you would use in cross-platform projects) that checks whether the used compiler exploits strict-aliasing in unions and set a define accordingly? Matt J wrote: > > I do not think that is the point Christer is making. On P. 438 of his > book he has an example of code that removes an explicit check for > divide by zero (by assuming the behavior of IEEE and the behavior of > NaN, which could be a trap representation), and he suggests is not > portable but can be used as a 'quick and dirty' solution, because you > can check for an error using exception handling and fall back to a > more robust version. So why can't that exact same argument be made > with a union cast? Also, if that is legal code, why isn't a union > cast? To me it seems like when you are trying to optimize something > for fun and by definition it is machine specific because your > interpreting an IEEE float as a series of bits, beating someone over > the head with a standards book is a little bit of a cheap shot - > especially when it is legal by the latest C99 TC3 standards and works > on a wide range of compilers including, but not limited to, GCC w/ > strict aliasing > > > The point more is that just because it works some of the time as > an artefact of a "correct" implementation (on most platforms, ints > and floats being the same size etc), it doesn't mean that it will > work everytime (and it isn't portable). One of the more important > points is that (for example) in C++98 compilers, there is no > guarantee on the number of bits for most of the integral data > types other than a minimal possible size and representable range. > > http://en.wikibooks.org/wiki/C%2B%2B_Programming/Data_Types_Reference > > Cheers, > Conor > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------------ > 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 |