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.
> 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.
> 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?
> 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.
> 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.
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk