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

Subject: Re: [boost] [boost::endian] Summary of discussion #1
From: Tomas Puverle (tomas.puverle_at_[hidden])
Date: 2010-06-02 14:30:06

> This could be the best option. What about creating a ticket?

Ok, will do.

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

> What about to "convert_to" "convert_from"

I will consider these, but I prefer Robert's names, endian::swap<>() and
endian::swap_copy<>(), endian::from<>() and endian::to<>().

> Does it means that swap_in_place on a structure containing a  floating point 
will be undefined, or that the
> library will fail to compile or throw an exception in this case?

Neither.  swap_in_place will always work.

However, swap<>(), to<>() and from<>() may fail to compile when used in cases
deemed "dangerous" for floating point swapping.

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

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

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

> There is already a GSoC project (Brian Bartman) that is working on an 
> extension of Boost.Bitfield. 
<snip>

That seems neat.  Even more reason for me not to re-invent the wheel.  

Tom