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