On Wed, May 8, 2013 at 10:38 AM, Adrian_H
Even if templates or optimizers are not capable of stating this. The COMPILERS should have something EMBEDDED to state this. It is, after all, generating the code. And there are constants that are lying about in memory too that it has to create. So logically, it knows what endianness of the target binary is going to be, even if it doesn't know what it is outside the data segment that the constants are stored in. I only know a little about multi-endian architectures, but IIRC, they have a way to automagicaly transfer data from different endian segments correctly.
Still, with cloud computing and other interoperable computing models, COMPILERS need to take responsibility to make it possible for programmers to make sane code without such clumsy methods as an endian.h header file.
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.