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 09:57:07

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

> 
> vicente.botet wrote:
>> Stewart, Robert wrote:
>> > vicente.botet wrote:
>>
>> > 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.

I saw that.
 
>> 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.

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 have no trouble with endian_pack, but don't know all the English subtilities to affirm this is a correct or wrong name.
 
>> >> 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.

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.

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

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 {
...}} 
> boost::endian
> boost::endian_integer
> boost::compressed_endian_integer

We need to names not three. What is your concrete proposal?
Are other booster ready to add new names as these ones on the namespace boost?

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

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?

Best,
Vicente