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

Subject: Re: [boost] [boost::endian] Summary of discussion #1
From: Tomas Puverle (tomas.puverle_at_[hidden])
Date: 2010-06-03 10:11:22

> Tomas intends to supply his own version in his library.  

Correct.

> There is no Boost.Endian library as yet.  

That is true.  However, there is one in the review queue which is the main
reason for my trying to write one, as I explained in my original RFC post, as I
am sure you recall.

> I'm quite certain, however, that Tomas would model his version on Beman's and 
> give credit or would work with Beman to create a modified, joint submission.

Of course.

> I dislike referring to the function-based interface as "untyped" and the 
> higher level interface as "typed."  Perhaps we could use "function-based" 
> and "object-based" as the adjectives?

Thank you.

> It very likely should be reimplemented on the function-based interface so 
> that there is just one implementation of a given swap routine.  

Absolutely.  The main reason for this, as I've already mentioned, that I intend
to implement the swapping using machine instructions, where available.

> Several of us have agreed that including support for arithmetic
> operators is misleading.  

Agreed completely.

> Whether Tomas or others have still different ideas on the interface remains 
> to be seen, 

Not really.  The endian objects should be pretty trivial to write once the
function-based machinery is done.

> I can imagine any packed byte protocol requiring this.  

Ahh...

When I saw Vincent's post, he wrote "another feature the endian class provides
and is the ability to work with integers with an arbitrary number of bytes"

  endian<big, int, 24> i;
  endian<big, int, 16> j;
  endian<big, int, 24> j;

Hence I was reading the above as three integers 24, 16, 24 bytes long, which is
why my eyebrows were raised.  But I think the correct reading would be "an
integer type with 24, 16 and 24 *bits*" respectively, no?

If that's the case, I don't really see a problem.  If we are, however, talking
about arbitrary precision integers, I might be more twitchy.

Tom