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
They don't have the same purpose. to/from are a simplification/thin layer over
> 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;
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.
That seems neat. Even more reason for me not to re-invent the wheel.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk