Re: [boost] [boost::endian] Summary of discussion #1

Subject: Re: [boost] [boost::endian] Summary of discussion #1
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2010-06-04 09:20:29

vicente.botet wrote:
> Stewart, Robert wrote:
> > vicente.botet wrote:
>
> >> The single difference between endian_pack and the original
> >> endian is that it  don't inherits from cover_operators.
> >
> > That should be the primary interface because it doesn't
> > encourage using inefficient arithmetic operators, so that
> > should be named boost::endian.
>
> First, currently is boost::integer::endian_pack and not
> boost::endian_pack, as it works only with integers.

I didn't notice the "integer" namespace.

> Well, I have no other problem than preserving the current
> interface. We can discuss of course of better names.

"endian_pack" doesn't suggest the class' actual purpose, so a different name is in order (no pun intended).  A "pack" of integers, as "integer::*_pack" indicates, is a collection, a set of integers, which is not the case here.  The class also doesn't contain a collection or set of "endians."  Even if you use "packed" as did Terry, the term is misleading because there aren't multiple integers packed into the object.

You're designing a specifically-sized integer type with implicit endianness conversion, right?  Given that boost::endian<T> creates an implicit endianness converting wrapper around T, where T is an integer type (at least presently), it is probably not appropriate to call this class "endian_integer."  Would "compressed_endian_integer" or "boost::integer::compressed::endian" do?  That leaves room for "endian_integer" to be the variant of "boost::endian" that includes arithmetic operators.

> >> The original endian class could be declared as
> >>
> >>   template <BOOST_SCOPED_ENUM(endianness) E, typename T,
> >> std::size_t n_bits,
> >>     BOOST_SCOPED_ENUM(alignment) A = alignment::unaligned>
> >>     class endian : cover_operators< endian< E, T, n_bits, A >, T >
> >>     {
> >
> > The class with operators should be named in such a way to
> > indicate that it manages endianness and provides the
> > arithmetic operators, so I suggest boost::endian_integer.
>
> As I said above I was just preserving the current interface.
> As for now endian is in the namespace interger, it is clear
> for me that we are working with endian integers.

Remember that this thread has been about Tomas' proposal, which might be merged with Beman's library or might be proposed as an alternative.  The current interface isn't critical to that discussion.

I'm trying to accommodate the discussion, in this and related threads, in which many of us noted the inefficiency of the arithmetic operators and hence the need for something like Beman's boost::endian without those operators.  Thus, boost::endian could be like Beman's without the operators and boost::endian_integer could be like Beman's boost::endian.

> If we can put names in the boost namespace then the names
> need to be reconsidered. As the classes works only with
> integers I see the following possibilities

I'm not certain we should assume the class will never support anything besides integers.  That's certainly the case for Beman's library, but Tomas has implied the possibility for floating point support in his.

> boost::interger::endian_pack
> boost::interger::endian
> ---
> boost::interger_endian_pack
> boost::interger_endian
> ---
> boost::endian_interger_pack
> boost::endian_interger
>
> But no boost::endian.

Beman's library provides boost::endian, so I have been assuming the likelihood of adding a little more to the boost namespace:

boost::endian
boost::endian_integer
boost::compressed_endian_integer

> > Given those names, why wouldn't endian_integer inherit from endian?
>
> I was sure someone will ask this. We can inherit, but this
> introduce multiple inheritance, which I wanted to avoid.
> Could you describes the advantages to inherit?

That's merely a side effect of providing the operator support via inheritance from cover_operators.  That isn't the only way to provide operators, however.  If one doesn't inherit from cover_operators, then I think inheritance makes sense and would be useful to clients.

_____
Rob Stewart                           robert.stewart_at_[hidden]
Software Engineer, Core Software      using std::disclaimer;
Susquehanna International Group, LLP  http://www.sig.com

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.