Boost logo

Boost :

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

> 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, gregod at, cpdaniel at, john at