The file boost/detail/endian.hpp needs to be set up for your CPU type
I saw this error and was wondering, can the endianness of a compiler not be
determined through templates instead of using
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? -- 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 Wed, May 8, 2013 at 9:51 AM, Adrian_H
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?
I don't think there is a way of deducing endianness through templates since templates deal with integer values and not their binary representation. Through constexpr maybe?.. I can't speak for the committee, but my understanding is that C++ Standard tries to avoid dealing with binary representation of data to not limit implementations. Things started to change though with adding <cstdint> types.
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.
On 05/08/2013 08:26 AM, Adrian_H wrote:
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.
This usually involves a lot more than endianness (e.g. floating point representation, container representations) and is usually handled by other standardization bodies such as IETF, OMG, and OASIS. However, regarding endianness, you may want to have a look at: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3620.pdf
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.
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.
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.
Adrian_H skrev 2013-05-08 09:53:
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.
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?! Bo Persson
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 05/08/2013 11:57 PM, Adrian_H wrote:
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.
If I interpret your proposal correctly, then you seem to aim for interoperability between C++ applications only. Interoperability is not restricted to C++ applications, so the C++ standard is not the best place to standardize it. There are plenty of standards for binary wire protocols, that works regardless which language the application is written in. The following is just a small sample: http://en.wikipedia.org/wiki/Comparison_of_data_serialization_formats http://en.wikipedia.org/wiki/Binary_xml http://en.wikipedia.org/wiki/List_of_automation_protocols Anyways, the Boost community does not decide what is standardized, so this discussion is perhaps better carried out on isocpp.org.
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.
Jonathan Wakely-2 wrote
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.
How does one write a proposal to the C++ committee? I'll do it. This is a problem that probably comes up a lot, people then figure out some clumsy workaround and then forget about it. These workarounds are just that, and they impact the bottom line as programmers try and figure out some way of figuring them out. This should be standard. No workaround required. -- 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 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
On Wed, May 8, 2013 at 3:57 AM, Adrian_H
Jonathan Wakely-2 wrote
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.
How does one write a proposal to the C++ committee?
http://isocpp.org/std/submit-a-proposal
I'll do it. This is a problem that probably comes up a lot, people then figure out some clumsy workaround and then forget about it. These workarounds are just that, and they impact the bottom line as programmers try and figure out some way of figuring them out.
This should be standard. No workaround required.
Jonathan hit the nail on the head.The C++ standard is essentially an open source software project staffed entirely by volunteers. There is no such thing as something that "should be standard" - there are only things that someone has written a proposal for, and then gone to the trouble of shepherding through the standardization process. --Beman
participants (7)
-
Adrian_H -
Andrey Semashev -
Beman Dawes -
Bjorn Reese -
Bo Persson -
Jonathan Wakely -
Marc Glisse