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-03 07:48:52

----- Original Message ----- 
From: "Stewart, Robert" <Robert.Stewart_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Thursday, June 03, 2010 12:49 PM
Subject: Re: [boost] [boost::endian] Summary of discussion #1

> 
> vicente.botet wrote:
>> Tomas Puverle wrote:

>> 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?

My typed/untyped was respect to endianess. With the Beman's approach the type know its endianess, with the Tom approach it doesn't. 
I don't find the function/object naming appropiated, I consider the Beman's endian classes as types not as objects, and the conversion from atype to another is clearly a functional concept not an object concept. I don't consider the swap_in_place belongs to the functional programming paradigm, at least not to the pure one.

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

OK, if the performance of the Beman's library are not degraded and all the features are preserved. For the moment, the figures Terry has provided show that the swap copy takes more time than the assignation between typed endian variables. I will let Beman's to decide if the reuse the Tom library is benefical for his library.

> Several of us have agreed that including support for arithmetic operators is misleading.  

I agree for the kind of applications I'have done. This doens't mean that nobody will take advantage of this transparent interface. Not all the applications have the same performances constraints. 

>From my point of view we need just to split the interface of the endian class in two:
* packets: endian packets without arithmetic operators.
* integer: endian integers with all the arithmetic operators. 

Tom can always reimplement the Beman's library using its library, but I don't consider this necessary.

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

I agree, but I dont see why the Tom library should include the packet interface.
 
>> >> 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.

The Bitfield library doesn't take care of bitfields that are between two words. This was already managed correctly by the Beman's library.

Would the Tom library take care of this cases, e.g. endian<big, int, 3>?

Best,
Vicente