[Beman's endian] explicit native endianes
Hi Beman, I see that there are specific classes for native endian, endian<endianness::native, ...>. I was wondering if instead of defining a separated class we can not define endianness::native depending on the ENDIAN of the host and remove the explicit definition. # ifdef BOOST_BIG_ENDIAN BOOST_SCOPED_ENUM_START(endianness) { big, little, native=big }; BOOST_SCOPED_ENUM_END #else BOOST_SCOPED_ENUM_START(endianness) { big, little, native=little }; BOOST_SCOPED_ENUM_END #endif Will this break the design? Best, _____________________ Vicente Juan Botet Escribá http://viboes.blogspot.com/
On 4 June 2010 08:04, vicente.botet <vicente.botet@wanadoo.fr> wrote:
I was wondering if instead of defining a separated class we can not define endianness::native depending on the ENDIAN of the host and remove the explicit definition.
I would have expected that the other way around would be better. The native endian would be implemented with memcpy, the big and little portably, and as an optimization big or little would be = native, based on the defines.
----- Original Message ----- From: "vicente.botet" <vicente.botet@wanadoo.fr> To: <boost@lists.boost.org> Sent: Friday, June 04, 2010 2:04 PM Subject: [boost] [Beman's endian] explicit native endianes
Hi Beman,
I see that there are specific classes for native endian, endian<endianness::native, ...>.
I see that there is a specilization for native unaligned template <typename T, std::size_t n_bits> class endian< endianness::native, T, n_bits, alignment::unaligned > but not for native aligned. template <typename T, std::size_t n_bits> class endian< endianness::native, T, n_bits, alignment::aligned > Is this is not an error what is the rationale? Best, Vicente
I see that there are specific classes for native endian, endian<endianness::native, ...>. I was wondering if instead of defining a separated class we can not define endianness::native depending on the ENDIAN of the host and remove the explicit definition.
That's what my design does. I've been using it for several years. I don't know if it would break Beman's though. terry
----- Original Message ----- From: "Terry Golubiewski" <tjgolubi@netins.net> To: <boost@lists.boost.org> Sent: Friday, June 04, 2010 2:41 PM Subject: Re: [boost] [Beman's endian] explicit native endianes
I see that there are specific classes for native endian, endian<endianness::native, ...>. I was wondering if instead of defining a separated class we can not define endianness::native depending on the ENDIAN of the host and remove the explicit definition.
That's what my design does. I've been using it for several years. I don't know if it would break Beman's though.
I had made the change and every thing works well :) Best, Vicente
Hi Vicente,
I see that there are specific classes for native endian, endian<endianness::native, ...>.
I was wondering if instead of defining a separated class we can not define endianness::native depending on the ENDIAN of the host and remove the explicit definition.
# ifdef BOOST_BIG_ENDIAN BOOST_SCOPED_ENUM_START(endianness) { big, little, native=big }; BOOST_SCOPED_ENUM_END #else BOOST_SCOPED_ENUM_START(endianness) { big, little, native=little }; BOOST_SCOPED_ENUM_END #endif
Interesting. Seems like a good idea!
Will this break the design?
Off-hand, I can't think of any reason. I've been very tied up with other projects. I'll try to look at this in more detail over the next few days. Thanks, --Beman
participants (4)
-
Beman Dawes -
Scott McMurray -
Terry Golubiewski -
vicente.botet