Re: [boost] [boost::endian] Request for comments/interest

Subject: Re: [boost] [boost::endian] Request for comments/interest
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2010-06-01 11:40:20

Tomas Puverle wrote:
> Rob Stewart wrote:

Don't drop attributions.  Things can get confusing otherwise.

> > Note that it seems rare indeed to have a utility that
> > does nothing but endianness conversion rather than needing
> > to do something to the data during the conversion.
>
> I think what you describe is pretty close to what I had in mind.
>
> And while the utility which does nothing but endian
> conversion does seem a bit far fetched (perhaps some sort of
> network bridge which translates between two different
> network layers?), I think a far more likely scenario is a
> program that examines and modifies a portion of the data
> while performing "regularization" on the rest of it.
>
> I certainly didn't want to preclude that use case.

An API with only from and to functions doesn't preclude it, but it does make it less efficient.

> > Assuming an API like Tomas suggested, the utility can do
> > all conversions with at most one swap.  That efficiency is
> > only possible, however, if the utility does nothing to the
> > data during the conversion.
>
> Agreed.  Still, there seems no good reason to preclude it.

No argument.

> >    enum host_relative_byte_order { big_endian, little_endian };
>
> I prefer to use types to enums for the tags.

I have no problem with either.

> >    template <host_relative_byte_order, class T>
> >    T
> >    from(T);
> <snip code>
>
> I just want to make sure - your only issue right now is with
> the function names, is that correct?

No.  I object to forcing specifying both the source and target endianness in the interface when the usual need is between the host and the external endianness.  With your syntax, the two are always specified in the call swap<source_to_target>().  With mine, the words "from" and "to" are relative to the host order, so you get from<big_endian> and to<little_endian>.

> Please don't take this the wrong way, as this is just a
> matter of taste, but I find your interface worse than mine.
> It seems that you've gone from the two functions to seven or
> eight.

There's no reason for me to be troubled by your thinking your interface better than mine.  After all, I'm suggesting the reverse!

Indeed, I'm suggesting a larger interface because I'm including your interface and adding more.  The result is three categories of functions, ignoring overloads:

   from<X>()
   to<X>()
   swap<X_to_Y>()

That's not complicated or confusing, is it?

> As for the type conversions, I don't see why you need the
> endian swapper to do them.  Would you be perhaps able to
> share a use case for this?

There are various cases in which the external format uses a type that isn't what the class that will ultimately consume the data prefers -- perhaps for compatibility or sizing reasons.  If the client's type is large enough to handle the value, but different from, the external type, the client must swap, check the range, and then copy.  I like doing that in one place.  Clearly, there must be a copy to effect that, so such functionality can be layered atop the single-type functions, but I think they are highly useful nonetheless and should be considered for inclusion in such a general purpose library.

> >    template
> >    <
> >       host_relative_byte_order From
> >       , host_relative_byte_order To
> >       , class T
> >    >
> >    T
> >    swap(T);
>
> Finally, I have tried and rejected the approach which
> includes the "from" and "to" endianness.  The main reason
> is that I've found that I, myself, and other developer
> using the library, had trouble remembering which
> parameter was "from" and which was the "to", leading to
> bugs.  Hence the "machine_to_big" tag, which is
> completely unambiguous.

I agree that is a better approach.  You might consider adding the reverse choices for completeness: "Y_from_X."

_____
Rob Stewart                           robert.stewart_at_[hidden]
Software Engineer, Core Software      using std::disclaimer;
Susquehanna International Group, LLP  http://www.sig.com

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.