Lee Rhodes writes: > Andrew Haley wrote: > > > It would work on gcc, because gcc allows members of a union to be > > written as one type and read as a different incompatible type. > > Other C compilers allow this too. However, it's is not guaranteed by > > the language standards, so it doesn't much help you with truly > > portable code. > > Stroustrup in his "C++ Programming Language, 3rd Ed." doesn't say > that using a union in this way is forbidden, he just feels > (strongly) that the use of unions for type conversion is a misuse > of unions and that it is "cheating". OK, but it doesn't matter what Stroustrup thinks about this because his opinion is not normative: language implementations follow the standards. All that the standard defines is that a pointer to a union, suitably converted, points to each of its members and vice versa: that doesn't mean that you can write an int and read a float. However, most if not all compilers will allow unions to be used to access incompatible types in this way. > So how "implementation-dependent and dangerous" is this conversion? I've already explained this. It's not defined by the standard, but it is defined by gcc as an extension. We need this extension in order to be able to write parts of the C library. > 2) unsigned long long (ULL): now this may be dangerous. I have not > figured out a way to define an integral type that is EXACTLY 64 > bits ...Other than using <limits> and testing to see if, in fact, > that ULL has that number of bits and then if it doesn't, throw an > error. GCC provides ULL at 64 bits, but my understanding is that > "it is not guaranteed by the language standards" either (it isn't > even mentioned!). Sure it is. int64_t, ISO/IEC 9899:1999 Section 7.18.1.1. Of course, it isn't guaranteed that your target machine even has a 64-bit type, but if it has then it must define the int64_t typedef. Andrew.
