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

Subject: Re: [boost] [boost::endian] Summary of discussion #1
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2010-06-04 11:27:24

----- Original Message ----- 
From: "Stewart, Robert" <Robert.Stewart_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Friday, June 04, 2010 4:20 PM
Subject: Re: [boost] [boost::endian] Summary of discussion #1

> 
> vicente.botet wrote:
>>
>> 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 can understand your concern. But I will reserv compressed integers for classes that have the range of possible values as parameters, and that deduce the number of needed bytes.

Thinking more on, pack will not be appropiated, as it is used for unaligned integers. 
I have found this Octet-packed integers. 
 
>> 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?

Not for me. Do others like?
 
>> > 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.

Don't worry, if we find a better design, I will the first to request the change ;-)

>> > 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?

For the moment Beman has not abandoned his library :)
 
>> >> 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.

Once we will have a floating point implementation, we could add someting that works for both. But if you insists, you can put it in namepace boost. 

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

The first choice is what I was proposed in the post.
The others were propositions at the boost namespace level.
 
>> >> 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.

I think people use sometimes boost::endian to refer to Boost.Endian :)
 
>> > 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.

Bemans class has an aligned/unaliged parameter that reduce the names to two.
 
>> 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.

Do you have a concrete suggestion?
 
Best,
Vicente