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-04 11:52:53

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

> 
>> Remember that this thread has been about Tomas' proposal, which might be
> merged with Beman's library or
>> might be proposed as an alternative.  The current interface isn't critical to
> that discussion.
> 
> Which is why I've effectively withdrawn from the discussion now, as this thread
> was hijacked.

I'm sorry if I  hijacked this thread. I will jump on a specific one for Beman's library.

>> I'm trying to accommodate the discussion, in this and related threads, in
> which many of us noted the
>> inefficiency of the arithmetic operators and hence the need for something like
> Beman's boost::endian
>> without those operators.  
> 
> Code which encourages bad coding habits/inefficient code shouldn't be in boost,
> full stop.

I don't find the endian class design a bad one. It is just not enough efficient for most of the applications, but not all of them.
You know OO languages on  the 60 were not popular because the implementation was not enough efficient. Now most of the languages are OO.
 
> Having the arithmetic operators on endian types is a completely wrong separation
> of concerns - it's akin to throwing away types and writing all code just using
> void pointers.
> 
> I don't see how Vicente fails to see this.

You know Vicente has a 'contradiction mind' ;-) As I said already, not all the applications need the same performances. Do you will use the arithmetic operations on the Beman's endian class if the performances responded to your expectations? I guess the answerr is yes. I have used them on some application that don't have performances contraits and its transparency makes the application very elegant. I'm just saying that the expectations can vary, so no need to drop these classes if the author want to maintain them, and there are enough reviewers that request to maitain them.

The fact I 'm for an interface without arithmetic operators (because I need it for some applications), doesn't means that I want to drop the one with, just separate them.

Best,
Vicente