I've look and constexpr seems to not be able to do this either. For a language that was/(is?) touted for being able to port an application written in it to any machine, I think interoperability between machines is just as big an issue. -- 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.

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. -- 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.

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.

Bo Persson wrote

The problem is that C and C++ doesn't enforce any specific implementation of data in the underlying hardware. For example, a byte (char) isn't required to be 8 bits. Not all bits in a word are required to take part of the value. The word size isn't given by standard either.

*IF* the language standard was to let you specify 42 bit padding and 17 bit alignment on any data type, that would disqualify some hardware up front. It would just be impossible to implement this on some systems that have compilers right now.

How is that an improvement? Less portability because there will be fewer compilers?!

Yeah, I've heard this excuse before, and it doesn't fly. If a vender chooses not to be able to do generic things, such as reading a binary file or stream of types that are not native, then that is the choice of the vender to not make a compatible compiler. It can have a lesser compliance standard attached to it if need be. But to hurt the interoperability of the rest of the community is hurting the progress of the community, and that is not good. A standard needs to be created for binary interoperability, for speed, size, and genericity. Xml is ok for certain usages where resources are plentiful, but is too bloated for other things like micro controllers where resources are scarce. Communication is key for a thriving community. -- 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.

On 8 May 2013 06:51, Adrian_H wrote:

I've been looking around and am just shocked that there doesn't seem to be any way of using the optimizer or templating system in any consistent way across compilers to generate a compile time endinness value. Does anyone know why the C++ committee has steered clear of this?

Noone has written a proposal suggesting that it be standardised. Unless someone does that it ain't gonna happen. If noone's bothered yet it suggests to me that it isn't all that important to that many people.

On Wed, 8 May 2013, Adrian_H wrote:

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 don't know, to do something as simple as extracting the exponent and mantissa of an IEEE float/double, using bitfields is significantly faster (and actually easier, since there is no standard function that does exactly that).

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.

That could indeed be convenient when ease and compatibility are more important than speed, but it means you need to standardize very precisely the layout of classes in that mode, which is a significant amount of work. On Wed, 8 May 2013, Adrian_H wrote:

How does one write a proposal to the C++ committee?

http://isocpp.org/std/submit-a-proposal -- Marc Glisse