Re: [boost] [Endian] Review

Subject: Re: [boost] [Endian] Review
From: Beman Dawes (bdawes_at_[hidden])
Date: 2011-09-08 15:23:21

On Thu, Sep 8, 2011 at 1:18 PM, Tomas Puverle <
Tomas.Puverle_at_[hidden]> wrote:

> Hi Beman,
>
> >      - What is your evaluation of the design?
>
> The design of the integer types seems reasonable to me, even though I would
> prefer not to have the overloaded operators on them.  I feel that having
> the
> operators has the potential to break the boundary between program input and
> the program's processing.  What do you I mean by that?  Typically, I try to
> structure my programs as follows:
>
>        1) Read input data
>        2) Verify input invariants, construct internal representation
>        3) Process internal representation
>        4) Output result
>

> The problem with having operators in the endian types is that they
> encourage
> the user to continue using them past the point 2).
>

I'm in complete agreement with you for large and/or performance critical
programs need careful structuring. But not all programs are large and/or
performance critical, so the convenience of having the full range of
operations triumphs over other considerations. The conversion functions are
available where the "input the data, do all the incoming byte reordering, do
all the processing, do all the outgoing byte reordering, output the data"
model is desired.

But there can be other considerations. Program flow is sometimes chaotic,
and then it become easy to become confused over which variables need to be
reordered and which don't. The endian integer approach is much less
error-prone in such situations.

>
> However, as I said, that's my personal preference and last year plenty of
> people wanted to see the operators included.  Perhaps they could be a
> policy?
>
> endian<..., bool EnableOperators_ > ?
>

I'll give it some thought, but my initial reaction is that endian is already
more complex than I like, so I'm leery of adding yet more complexity.

>
> As for the rest of the library, I have the following comments:
>
> - As many other people have mentioned, floating point support and user
> defined
> types are a must.
>

I think floating point is easily doable, although details haven't been
worked out yet.

Do you have an example of a UDT that you would like to see work? And what do
you want it to work for? Both class endian and the conversion functions?

> - I am happy that the "conversion functions" have been added,
> Unfortunately,
> I find them lacking in several departments:
>        - (Note: I am going to try very hard not to get drawn into another
> naming
>                discussion.  That's pretty much what ended my efforts last
> year -
>                50 people commenting, each proposing a different set of
> names :D )
>

Understood:-)

       - While the endian types support unaligned data, the endian functions
>                don't appear to do so.  I don't see how the endian types
> could be
>                implemented using them.
>

Right. That would be a highly desirable addition.

>        - No support for user defined types, arrays/ranges of user defined
> types
>          etc.  This is extremely useful.  A frequent example I come across
> is
>          the following (using our syntax):
>                        //load a file into memory
>                        //...
>                        swapInPlace<BigToNative>(data.begin(), data.end());
>
>          Depending on the platform, that last statement may get compiled
> out
>          to a no-op.  This is also the big reason why our version of
> "reorder()"
>          is not unconditional but depends on the "swap type".
>

Yep, that's why the conditional reodering functions are provided. The names
are a serious impediment to understanding. Maybe they all should include
"reorder" and "conditional" in the names for clarity.

The other issue that has come up is the interface. A pure function (i.e.
returning the new value) interface would allow use of std::transform. Not
sure how that would play out with unaligned or unusual sized types, however.

I'm glazing over, so will wait to reply to the rest of your comments. I'll
also dig out your previous proposal and review the floating point issues you
mention.

Thanks!

--Beman