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 10:20:30

vicente.botet wrote:
> Stewart, Robert wrote:
> > vicente.botet wrote:
>
> > "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.
>
> For me compressed and packed are not the same. The name pack
> comes from the fact the integer bytes are packed. We can talk
> of compression of un integer that can takes values from 0 and
> 10000 for example. But what we say here is that we need a
> integer represented with 24 bits, as this is the constraint.
> packed is the word I have always see in this context, not
> compressed. Other language procide this king of packed integers.

I see your concern with the term "compressed."  Packing implies reduction of space, certainly.  Thus, "packed" does imply the right idea, but only in the context of multiple integers being packed into a structure.  The individual, smaller-than-normal integer type isn't packed to my mind.  It is reduced or shrunk from its normal size, hence my use of "compressed."

> I have no trouble with endian_pack, but don't know all the
> English subtilities to affirm this is a correct or wrong name.

Would "reduced_endian_integer" satisfy?

> > 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.
>
> It is to me that I'm already using the Boost.Endian library.
> Of course I'm open to changes in Boost.Endian as the library
> has not ben accepted, and I will adapt my code to the new one.

Understood.  I wouldn't want to introduce gratuitous changes, but I think we're discussing changes of merit.

> > 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.
>
> I have no problem if  Beman changes.

What if he simply hands off his effort to Tomas?

> >> 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.
>
> I will see when this is provided. Until now we are limited to
> integers, and I remeber that Tom said that the first release
> will be limited to integers.

Granted, but putting the names in the "integer" namespace means floating point cannot be added later without undue confusion.

> >> boost::interger::endian_pack
> >> boost::interger::endian
> >> ---
> >> boost::interger_endian_pack
> >> boost::interger_endian
> >> ---
> >> boost::endian_interger_pack
> >> boost::endian_interger

I assumed the above were all your invention.

> >> 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:
>
> Sorry. I miss it. Could you point me to the file and the
> line, or in the documentation? From what I can see everything
> is inside
> namespace boost { namespace integer {
> ...}}

Is it?  I must have missed it in my scans of his documentation and I've always seen it referenced as "boost::endian" on the list.

> > boost::endian
> > boost::endian_integer
> > boost::compressed_endian_integer
>
> We need to names not three. What is your concrete proposal?

Hmmm.  Maybe I'm inventing more than I need to, but I'm not convinced.  Beman's endian is already compressed/packed/reduced, right?  Is your idea simply to create a version with and without operators?  My thinking was that we need the following:

 1) A class template that uses an appropriate (currently built-in integer) type and applies implicit endianness conversions

 2) A class template that extends 1 to include arithmetic operators

 3) A class template that determines the smallest integer type to support a requested number of bits and applies implicit endianness conversions to it (could derive from an instantiation of 1)

 4) A class template that extends 3 to include arithmetic operators

That implies four names, not two or three.

> Are other booster ready to add new names as these ones on the
> namespace boost?

It is good to avoid polluting the boost namespace, but all of the names I suggested begin with or contain "endian" so they're fairly unique.  I don't mind putting them in some nested namespace, but I don't think "integer" is appropriate.

> >> 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.
>
> I have no problem with the design you propose, even if I
> don't see yet concrete use cases where the inheritance from
> endian to endian_pack is useful. Could you made a concrete
> proposal that doesn't inherits from cover_operators?

I think that's premature, but if we get far enough along, I'll consider doing so.

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