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

Subject: Re: [boost] [boost::endian] Summary of discussion #1
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2010-06-02 16:47:14

----- Original Message ----- 
From: "Tomas Puverle" <tomas.puverle_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Wednesday, June 02, 2010 8:30 PM
Subject: Re: [boost] [boost::endian] Summary of discussion #1

 
>> I don't think having several names for the same purpose is a good idea. We
> need to choose between swap and
>> /to/from. 
> 
> They don't have the same purpose.  to/from are a simplification/thin layer over
> swap<>().
> 
>> 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.

>> Do you plan to define the typed version independently of Boost.Endian?
> 
> I don't understand the question.  The endian types are supposed to be a thin
> interface on top of the functional part of the library.   They will be part of
> the Boost.Endian library I am proposing.

I was talking of  Beman's Boost.Endian.

>> I'm not yet sure we can have a typed version for swap_in_place that has no 
>> execution cost when the endianess are equal. 
> 
> What then, in particular, is the question?  The implementation is right there in
> swap_impl.hpp.  Have you looked at it yet, as Dave Handley suggested?

I was referring to the TYPED version I proposed in a preceding post.
 
>> 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;
> <snip>
> 
> 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 agreed to implement the typed interface (even though I don't personally
> endorse it), so you are free to choose your preferred implementation.  Does that
> not satisfy your needs?

The typed interface exists already on the Beman's library. Thus I don't see any need to reimplement it. Do you?
 
>> 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 work for a telecomunication company, and I have used a lot of standard protocols that reserved 3 bytes for an int. Theese protocols were defined a long time ago, but we need to work yet with them. I have not an example at hands, but you can belive me that these cases exists. Of course for propietaty protocols this could be avoided, and now we have less problem with the size of the messages.
 

Vicente