Le 10/09/11 14:05, Beman Dawes a écrit :
On Fri, Sep 9, 2011 at 3:20 PM, Vicente J. Botet Escriba <vicente.botet@wanadoo.fr> wrote:
Le 09/09/11 15:05, Beman Dawes a écrit :
On Fri, Sep 9, 2011 at 2:32 AM, Vicente Botet<vicente.botet@wanadoo.fr>wrote:
Hi,
I have separated the endian class into a endian_pack that is integer agnostic and an endian class that behaves as an integer (You could see the details in the Sandbox under endian_ext).
Reference docs:
http://svn.boost.org/svn/boost/sandbox/endian_ext/libs/integer/endian/doc/ht...
http://svn.boost.org/svn/boost/sandbox/endian_ext/libs/integer/endian/doc/ht...
(Sorry but there is a bad link to the reference)
This is not complex Complexity is in the eye of the beholder. To me, that approach was markedly more complex and confusing.
What do you find complex in separating the classes endian_pack and endian? That particular approached seemed to markedly increase surface area. It might be a good thing to provide the basic endian buffer facility in addition to the full endian integer facility, but not at the cost of doubling the surface area.
Next follows the definition of the endian class using endian_pack. template <typename E, typename T, std::size_t n_bits=sizeof(T)*8, BOOST_SCOPED_ENUM(alignment) A = alignment::aligned
class endian : cover_operators< endian< E, T, n_bits, A>, T > { endian_pack<E, T, n_bits, A> pack_; public: typedef E endian_type; typedef T value_type; BOOST_STATIC_CONSTEXPR std::size_t width = n_bits; BOOST_STATIC_CONSTEXPR BOOST_SCOPED_ENUM(alignment) alignment_value = A;
# ifndef BOOST_ENDIAN_NO_CTORS endian() BOOST_ENDIAN_DEFAULT_CONSTRUCT template <typename T2> explicit endian(T2 val) : pack_(val) { } # endif endian & operator=(T val) { pack_=val; return *this; } operator T() const { return T(pack_); } const char* data() const { return pack_.data(); } }; I don't think this could be considered to double the surface. Best, Vicente