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

Subject: Re: [boost] [boost::endian] Summary of discussion #1
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2010-06-03 06:49:18

vicente.botet wrote:
> Tomas Puverle wrote:
>
> >> I dont find swap is correct (maybe due to my poor English),
> >> as there is no swap at all .
> >
> > Sorry, I don't understand what you mean by "there is no
> > swap at all".  Can you please expand on this?
> >
> >> In addition we have already swap that takes always two arguments.
> >
> > Again, I don't know what you're referring to - are you
> > referring to std::swap()?
>
> Yes, it was std::swap. From my understanding swap concerns
> the exchange of two parts. In the your swap function that
> returns the result there are no two parts.

The bytes are swapped within the multi-byte value, just as values are swapped between objects using std::swap().  The behavior is quite similar.  The word applies equally well.

> >> Do you plan to define the typed version independently of
> >> Boost.Endian?
> >
> > They will be part of the Boost.Endian library I am proposing.
>
> I was talking of  Beman's Boost.Endian.

Tomas intends to supply his own version in his library.  There is no Boost.Endian library as yet.  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.

> >> But I find much more clear the typed version than the swap
> >> interface when
> >> copy is used.
> >> int j;
> >> int i = endian::swap<endian::host_to_big>(j);
> >> --- versus ---
> >> int j;
> >> endian<big,int> i = j;
> >
> > Sorry but I can't figure out if you're pointing out a
> > design problem or simply stating your interface preference.
>
> I'm stating that your UNTYPED swap_in_place could be more
> efficient than the the TYPED one. But that there is no reason
> that the UNTYPED swap<> be more efficient than the TYPED
> assignation. And that the TYPED assignation is endian-safe.
> So yes I was stating my preference.

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?

There are, yet, use cases in which the function-based design is more efficient, I think, but we should explore ways to ensure both are as efficient as possible.  Regardless, it is clear that there are prejudices in favor of one approach or the other in various contexts and for various users, hence Tomas has agreed to include *both* in his proposal.

> > I agreed to implement the typed interface (even though I
> > don't personally endorse it), so you are free to choose
> > your preferred implementation.
>
> The typed interface exists already on the Beman's library.
> Thus I don't see any need to reimplement it. Do you?

It very likely should be reimplemented on the function-based interface so that there is just one implementation of a given swap routine.  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, but there is already sufficient reason to create a new set of endian types, if only to compare and contrast with Beman's.

> >> There is also another feature the endian class provides
> >> and is the ability to work with integers with an arbitrary
> >> number of bytes.
> >
> > Sorry I am having trouble envisioning a use case for this.
> > Do you have a scenario you can share?

I can imagine any packed byte protocol requiring this.  Indeed, there are packed bit protocols, too, to justify the bitfield endian handling mentioned previously.  These do seem worth consideration.

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