Andrey Semashev-2 wrote
When you care for endianness, you either program for a specific target (e.g. some low level code to speed up processing) or you're implementing some sort of binary (de)serialization. The first case is best covered with preprocessor macros, since target-specific code typically should not be compiled for other targets. The second case is what the C++ Standard is severely lacking, IMHO, but a third party library solution based on (non-portable) macros is still possible.
I think your first case is not really hugely relevant as the compiler is already fairly competent in that area. I think it is the 2nd case that really makes the discussion important, and interoperability shouldn't be left to something as clumsy as macros. What we need is a real solution. I think instead of trying to figure out what endianness the system is (and systems can have a split personality like that of a PowerPC), I think it should be the compiler's responsibility to enforce interoperability when it is needed. This goes the same for alignment/padding as well. What we really need is a way to force the compiler to do a specific endianness of types and to set the padding/alignment of structures. Some type of modifier that when not used will allow the compiler to optimize as it sees fit, but if used, states that the type MUST BE this way, that the alignment MUST BE this way. WHY are programmers trying to programme assembler like routines to try and figure out the endianness by using tricks that aren't portable across compilers and setting alignment in a similar fashion? This should NOT be in the domain of the C++ programmer! This should be PART of the language! This ridiculous problem has been around for so long, and it is going to get worse as we have the compiler try and optimize things away and have strict aliasing that make old tricks fail. I say NO MORE! MAKE IT PART OF THE LANGUAGE! This will then allow for optimizations to work across platforms, and developers don't have to go crazy trying to make it work. And for those who don't need it, don't have to worry about it. It'll make code cleaner, more maintainable and reduce development costs. This is something that should have been done years ago. -- View this message in context: http://boost.2283326.n4.nabble.com/boost-The-file-boost-detail-endian-hpp-ne... Sent from the Boost - Dev mailing list archive at Nabble.com.