[boost::endian] Summary of discussion #1
Thank you everyone for your contributions. It seems the activity is dying down a little and some consensus has been reached, so I decided to summarize the thread here for my and other people's benefit. Unanswered question: One question which I posed in the original thread and didn't get picked up by anyone was to do with the metafunction is_mutable_range<T>. I use it to determine whether T is a range as opposed to just a value. I was suggesting is_mutable_range<> and is_const_range<> could be added to Boost.Range but nobody had any opinions. Basic interface: There were many suggestions for changes/improvements but in the end, it seemed that the proposed functional interface was generally ok. Beside the two functions swap<>() and swap_in_place<>(), there was a desire for two simpler alternatives, to<>() and from<>(), which would imply the "host" portion, i.e. swap<host_to_{little/big}>() would be equivalent to to<{little/big}>() and swap<{little/big}_to_host>() would be equivalent to from<{little/big}>(). The idea of "network" being a synonym for "big" was raised but ultimately rejected, due to the fact that the library shouldn't be tied to any particular device/protocol. Floating point values: There is a potential issue with swapping floating point values. This will be resolved by limiting the contexts in which swap<>, from<> and to<> can be used. Typed vs untyped: One of the most contentious issues of the whole thread, I think both sides have accepted that there is value in the other side's approach (or, at the very least, I don't see how my library is going to make it through the review unless I implement it :) Having said that, as the typed interface ultimately relies on copying of data, there may have to be some limitations on floating point values. Bitfields: There was some desire for generic bit swapping/bit fields. I have some ideas on this but for now I would prefer to concentrate on the byte-swapping issues and revisit this in the future. This seems like a reasonable plan for implementation. Thanks again for all the input. Tom
On 2 June 2010 11:37, Tomas Puverle <tomas.puverle@morganstanley.com> wrote:
Having said that, as the typed interface ultimately relies on copying of data,
I think the summary here is that the typed approach requires copying while using members, and that the untyped approach may require swapping before and after use. Thinking about that, I believe I've come up with a situation in which the typed approach is more efficient than the swapping one. Suppose you want to know the width and height of a BMP image on a big-endian machine. If you have a way to get around aliasing issues, then memory-mapping the beginning of the file, type punning to the typed header type, and reading out the 2 values you care about is faster than swapping everything in the header. (Yes, you could just swap the two fields you care about, for equivalent performance, but that's an operation at a different granularity.) Hoping that makes sense, ~ Scott McMurray
Scott McMurray wrote:
On 2 June 2010 11:37, Tomas Puverle wrote:
Having said that, as the typed interface ultimately relies on copying of data,
I think the summary here is that the typed approach requires copying while using members, and that the untyped approach may require swapping before and after use.
Not unreasonable, except the former doesn't imply less swapping than the latter as your phrasing suggests.
Thinking about that, I believe I've come up with a situation in which the typed approach is more efficient than the swapping one. Suppose you want to know the width and height of a BMP image on a big-endian machine. If you have a way to get around aliasing issues, then memory-mapping the beginning of the file, type punning to the typed header type, and reading out the 2 values you care about is faster than swapping everything in the header. (Yes, you could just swap the two fields you care about, for equivalent performance, but that's an operation at a different granularity.)
If all I wanted was two values, I wouldn't swap the entire header. I would do exactly what you discounted parenthetically, so the typed approach is not more efficient, it's overkill in your example. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
On 2 June 2010 13:25, Stewart, Robert <Robert.Stewart@sig.com> wrote:
If all I wanted was two values, I wouldn't swap the entire header. I would do exactly what you discounted parenthetically, so the typed approach is not more efficient, it's overkill in your example.
The difference is in the error-prone-ness. With the typed one, it's free for me to type pun it, and then I pay for what I actually read. With swapping, I have a choice of swapping everything, and paying for the ones I don't use, or of only swapping the ones I do use, and risk either forgetting to swap before reading or accidentally swapping twice if I read it twice.
The difference is in the error-prone-ness.
With the typed one, it's free for me to type pun it, and then I pay for what I actually read. With swapping, I have a choice of swapping everything, and paying for the ones I don't use, or of only swapping the ones I do use, and risk either forgetting to swap before reading or accidentally swapping twice if I read it twice.
Disagree. It's akin to saying that since some programmers misuse pointers, they should not exist. The interface is just as dangerous as forgetting to use the "typed" endian types in the definition of the structure. I don't see anything error-prone or bad about the following: struct ImgHdr; ... ImgHdr hdr; std::size_t width = swap<big_to_host>(hdr.width); std::size_t height = swap<big_to_host>(hdr.height); In fact, it's probably more efficient from the point of the view of the programmer, since if the structure is large (and with images it frequently is!), they don't have to go and define an entire endian-enabled structure elsewhere. The code is concise and well-encapsulated. Second, and more importantly - a lot of the times, the structures which need to be endian swapped are defined elsewhere, not by you. They are defined in the OS headers or in the headers of an image library or what not. With the typed approach, you will need to maintain a parallel structure with the same fields and layout - now talk to me about error prone! Finally - I don't see what your point is. I agreed to provide the typed interface, so feel free to use it. Are you arguing against the inclusion of the functional approach? Tom
Tomas Puverle wrote:
Unanswered question:
No opinion.
Beside the two functions swap<>() and swap_in_place<>(),
Your swap<>() takes a value and converts it to another of the same type, but endian swapped. That looks a lot like a cast, though the type doesn't change in your design, so naming it something like "endian_cast" is not unreasonable. If you pick up my ideas for allowing the input and output types to change, within limits, then it looks even more like a cast. I still dislike the name "swap_in_place." If you agree to "endian_cast," then this is easy: rename swap_in_place<>() to "swap." Otherwise, swap_in_place<>() could be named "swap" while your swap<>() could be named something like "swapped_copy." IOW, the more efficient function should be the one to encourage and the other should emphasize the casting or copying nature of the operation in its longer name.
Floating point values: There is a potential issue with swapping floating point values. This will be resolved by limiting the contexts in which swap<>, from<> and to<> can be used.
That's certainly the easiest solution. I wonder if there are papers on this subject. According to Wikipedia: "On some machines, while integers were represented in little-endian form, floating point numbers were represented in big-endian form. Because there are many floating point formats, and a lack of a standard "network" representation, no standard for transferring floating point values has been made. This means that floating point data written on one machine may not be readable on another, and this is the case even if both use IEEE 754 floating point arithmetic since the endianness of the memory representation is not part of the IEEE specification." An interesting discussion of some points raised here, but has merit for deciding whether and how to support floating point swapping: <http://www.dmh2000.com/cpp/dswap.shtml>.
From the latter, there is room to consider using a class template to manage an appropriate integer type to hold a swapped floating point value and have the swap functions return that when swapping floating point values. The reverse is also possible if the swapping functions recognize the intermediate swapped type on input and return the corresponding floating point type.
That is, something like the following might be possible: template <class E, class T> typename swapped_floating_point<T> endian_cast(T); template <class E, class T> T endian_cast(typename swapped_floating_point<T>); (with suitable additional line noise to ensure that T is a floating point type.) _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
That looks a lot like a cast, though the type doesn't change in your design, > so naming it something like "endian_cast" is not unreasonable.
Since the type isn't supposed to change, I don't like the cast<> idea too much. But let me sit on it.
Otherwise, swap_in_place<>() could be named "swap" while your swap<>() could be named something like "swapped_copy."
These are good names - I might steal them ;) <snip> I'll look at the link but I can't access the site from work - I'll look when I get home. <snip>
That is, something like the following might be possible:
template <class E, class T> typename swapped_floating_point<T> endian_cast(T);
template <class E, class T> T endian_cast(typename swapped_floating_point<T>);
I suggested this in the earlier thread but no one took the bait. However, I think it's not a panacea. We can restrict the interface as discussed to begin with; this functionality can be added later, since it won't break anything. Tom
At Wed, 2 Jun 2010 18:06:19 +0000 (UTC), Tomas Puverle wrote:
That looks a lot like a cast, though the type doesn't change in your design, > so naming it something like "endian_cast" is not unreasonable.
Since the type isn't supposed to change, I don't like the cast<> idea too much. But let me sit on it.
Otherwise, swap_in_place<>() could be named "swap" while your swap<>() could be named something like "swapped_copy."
These are good names - I might steal them ;)
I'd go with “swap” and “swapped.” My 2c -- Dave Abrahams BoostPro Computing http://www.boostpro.com
At Wed, 02 Jun 2010 17:31:48 -0400, David Abrahams wrote:
At Wed, 2 Jun 2010 18:06:19 +0000 (UTC), Tomas Puverle wrote:
That looks a lot like a cast, though the type doesn't change in your design, > so naming it something like "endian_cast" is not unreasonable.
Since the type isn't supposed to change, I don't like the cast<> idea too much. But let me sit on it.
Otherwise, swap_in_place<>() could be named "swap" while your swap<>() could be named something like "swapped_copy."
These are good names - I might steal them ;)
I'd go with “swap” and “swapped.”
Amending that: watch out for unintended ADL effects with “swap.” It's one of those globally claimed names whose meaning (at least with two arguments) is fixed for all time w.r.t. unqualified calls. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
I'd go with “swap” and “swapped.”
Amending that: watch out for unintended ADL effects with “swap.” It's one of those globally claimed names whose meaning (at least with two arguments) is fixed for all time w.r.t. unqualified calls.
I think the consensus was to use "endian_cast" for the function which returns a swapped copy of the underlying data and "endian_swap" for the function which performs the swapping in place (Rob's suggestions). This is so that people can do using namespace boost::endian; int i = endian_cast<from_big>(j); which seems pretty readable. The only thing remaining for me to decide whether "endian_cast" and "endian_swap" should live in the endian namespace (as I indicated above) or in the boost namespace, as others have suggested. Even though I dislike the endian::endian_cast<> syntax, my personal preference would be to have endian_cast in the endian namespace for "cleanliness" issues - I may well be ok with using namespace boost::endian; in my local scope to but I will not be ok with doing using namespace boost; Tom
Tomas Puverle wrote:
Dave Abrahams wrote:
I'd go with "swap" and "swapped."
Amending that: watch out for unintended ADL effects with "swap." It's one of those globally claimed names whose meaning (at least with two arguments) is fixed for all time w.r.t. unqualified calls.
Yeah, it's probably best that we not risk such problems.
I think the consensus was to use "endian_cast" for the function which returns a swapped copy of the underlying data and "endian_swap" for the function which performs the swapping in place (Rob's suggestions).
"endian_swap" was, I think, your suggestion. I'm not sure I like it. How about "reorder?"
Even though I dislike the endian::endian_cast<> syntax, my personal preference would be to have endian_cast in the endian namespace for "cleanliness" issues - I may well be ok with
using namespace boost::endian;
in my local scope to but I will not be ok with doing
using namespace boost;
using boost::endian_cast; _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
At Thu, 3 Jun 2010 16:36:29 +0000 (UTC), Tomas Puverle wrote:
I'd go with “swap” and “swapped.”
Amending that: watch out for unintended ADL effects with “swap.” It's one of those globally claimed names whose meaning (at least with two arguments) is fixed for all time w.r.t. unqualified calls.
I think the consensus was to use "endian_cast" for the function which returns a swapped copy of the underlying data and "endian_swap" for the function which performs the swapping in place (Rob's suggestions).
This is so that people can do
using namespace boost::endian;
int i = endian_cast<from_big>(j);
which seems pretty readable.
Ouch. Normally the destination type is in the <>s of a cast. Why not just two functions: boost::endian::from_big( x ) boost::endian::from_little( x ) ? -- Dave Abrahams BoostPro Computing http://www.boostpro.com
David Abrahams wrote:
Tomas Puverle wrote:
using namespace boost::endian; int i = endian_cast<from_big>(j);
Ouch. Normally the destination type is in the <>s of a cast. Why not just two functions:
boost::endian::from_big( x ) boost::endian::from_little( x )
I had proposed boost::endian::from<big_endian>() and boost::endian::to<big_endian>(), but I thought the copying and transformational aspects of these functions was highlighted a bit better by the new-style cast notation. That the current and target endiannesses could be specified similar was a nice consistency: endian_cast<big_to_little>(); endian_cast<to_little>(); endian_cast<from_big>(); Using distinct functions means something like this: from<little_endian>(); to<little_endian>(); reorder<little_to_big>(); There's nothing wrong with that approach, but we thought the cast notation was clean. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
----- Original Message ----- From: "Tomas Puverle" <tomas.puverle@morganstanley.com> To: <boost@lists.boost.org> Sent: Wednesday, June 02, 2010 5:37 PM Subject: [boost] [boost::endian] Summary of discussion #1
Thank you everyone for your contributions. It seems the activity is dying down a little and some consensus has been reached, so I decided to summarize the thread here for my and other people's benefit.
Unanswered question: One question which I posed in the original thread and didn't get picked up by anyone was to do with the metafunction is_mutable_range<T>. I use it to determine whether T is a range as opposed to just a value. I was suggesting is_mutable_range<> and is_const_range<> could be added to Boost.Range but nobody had any opinions.
This could be the best option. What about creating a ticket?
Basic interface: There were many suggestions for changes/improvements but in the end, it seemed that the proposed functional interface was generally ok. Beside the two functions swap<>() and swap_in_place<>(), there was a desire for two simpler alternatives, to<>() and from<>(), which would imply the "host" portion, i.e. swap<host_to_{little/big}>() would be equivalent to to<{little/big}>() and swap<{little/big}_to_host>() would be equivalent to from<{little/big}>().
I don't think having several names for the same purpose is a good idea. We need to choose between swap and /to/from. Given that both will be used on the endian namespace we have endian::swap<endian::host_to_{little/big}>() endian::from<{endian::little/big}>() endian::swap<endian::host_to_{little/big}>() endian::swap<endian::{little/big}>() While I find the name swap_in_place apropiated, I dont find swap is correct (maybe due to my poor English), as there is no swap at all . In addition we have already swap that takes always two arguments. What about to "convert_to" "convert_from" endian::convert_from<{endian::little/big}>() endian::convert_to<{endian::little/big}>()
The idea of "network" being a synonym for "big" was raised but ultimately rejected, due to the fact that the library shouldn't be tied to any particular device/protocol.
I agree. I don't see any added value to name big as network. In the same way the library defines a typedef for native, the user can define its own typedef for network.
Floating point values: There is a potential issue with swapping floating point values. This will be resolved by limiting the contexts in which swap<>, from<> and to<> can be used.
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?
Typed vs untyped: One of the most contentious issues of the whole thread, I think both sides have accepted that there is value in the other side's approach (or, at the very least, I don't see how my library is going to make it through the review unless I implement it :) Having said that, as the typed interface ultimately relies on copying of data, there may have to be some limitations on floating point values.
Do you plan to define the typed version independently of Boost.Endian? 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. 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; or int j; int i = endian::swap<endian::big_to_host>(j); --- versus --- endian<big,int> j; int i = j; There is also another feature the endian class provides and is the ability to work with integers with an arbitrary number of bytes. For example we can have a physical structure such as struct X { endian<big, int, 24> i; endian<big, int, 16> j; endian<big, int, 24> j; };
Bitfields: There was some desire for generic bit swapping/bit fields. I have some ideas on this but for now I would prefer to concentrate on the byte-swapping issues and revisit this in the future.
There is already a GSoC project (Brian Bartman) that is working on an extension of Boost.Bitfield. The idea is to a have a kind of fusion sequence adaptor on top of Boost.Bitfield. Used to easily manipulate groups of bitfields the same way as does C bitfields, but in a portable manner. Example declaration: struct Rgb565 { struct red {}; struct green {}; struct blue {}; typedef bitfields< endianess<big> bitfield<unsigned char, red, 5>, bitfield<unsigned char, green, 6>, bitfield<unsigned char, blue, 5> > type; }; Example usage: Rgb565::type r = make_bitfields<Rgb565::type, 1,2,3>; // Write to a bitfield. r.get<Rgb565::red>() = 23; //or r.set<Rgb565::red>(23); // Read from a bitfield Rgb565::at<Rgb565::blue>::value_type b = r.get<Rgb565::blue>(); Other posibility could be to use unamed bitfields whic are accessed as tuples. typedef bitfields<big, 5,6,5> Rgb565; Rgb565 r; r.get<0>() = 23; // or r.set<0>(23); // Read from a bitfield Rgb565::at<2>::value_type b = r.get<2>(); If you have other ideas for a Bitfield library, we are open to any suggestion. Best, Vicente
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
----- Original Message ----- From: "Tomas Puverle" <tomas.puverle@morganstanley.com> To: <boost@lists.boost.org> Sent: Wednesday, June 02, 2010 8:30 PM Subject: Re: [boost] [boost::endian] Summary of discussion #1
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()?
Yes, it was std::swap. From my understanding swap concerns the exchange of two parts. In the your swap function that returns the result there are no two parts.
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 was talking of Beman's Boost.Endian.
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?
I was referring to the TYPED version I proposed in a preceding post.
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'm stating that your UNTYPED swap_in_place could be more efficient than the the TYPED one. But that there is no reason that the UNTYPED swap<> be more efficient than the TYPED assignation. And that the TYPED assignation is endian-safe. So yes I was stating my 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?
The typed interface exists already on the Beman's library. Thus I don't see any need to reimplement it. Do you?
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?
I work for a telecomunication company, and I have used a lot of standard protocols that reserved 3 bytes for an int. Theese protocols were defined a long time ago, but we need to work yet with them. I have not an example at hands, but you can belive me that these cases exists. Of course for propietaty protocols this could be avoided, and now we have less problem with the size of the messages. Vicente
vicente.botet wrote:
Tomas Puverle wrote:
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()?
Yes, it was std::swap. From my understanding swap concerns the exchange of two parts. In the your swap function that returns the result there are no two parts.
The bytes are swapped within the multi-byte value, just as values are swapped between objects using std::swap(). The behavior is quite similar. The word applies equally well.
Do you plan to define the typed version independently of Boost.Endian?
They will be part of the Boost.Endian library I am proposing.
I was talking of Beman's Boost.Endian.
Tomas intends to supply his own version in his library. There is no Boost.Endian library as yet. I'm quite certain, however, that Tomas would model his version on Beman's and give credit or would work with Beman to create a modified, joint submission.
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'm stating that your UNTYPED swap_in_place could be more efficient than the the TYPED one. But that there is no reason that the UNTYPED swap<> be more efficient than the TYPED assignation. And that the TYPED assignation is endian-safe. So yes I was stating my preference.
I dislike referring to the function-based interface as "untyped" and the higher level interface as "typed." Perhaps we could use "function-based" and "object-based" as the adjectives? There are, yet, use cases in which the function-based design is more efficient, I think, but we should explore ways to ensure both are as efficient as possible. Regardless, it is clear that there are prejudices in favor of one approach or the other in various contexts and for various users, hence Tomas has agreed to include *both* in his proposal.
I agreed to implement the typed interface (even though I don't personally endorse it), so you are free to choose your preferred implementation.
The typed interface exists already on the Beman's library. Thus I don't see any need to reimplement it. Do you?
It very likely should be reimplemented on the function-based interface so that there is just one implementation of a given swap routine. Several of us have agreed that including support for arithmetic operators is misleading. Whether Tomas or others have still different ideas on the interface remains to be seen, but there is already sufficient reason to create a new set of endian types, if only to compare and contrast with Beman's.
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?
I can imagine any packed byte protocol requiring this. Indeed, there are packed bit protocols, too, to justify the bitfield endian handling mentioned previously. These do seem worth consideration. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
----- Original Message ----- From: "Stewart, Robert" <Robert.Stewart@sig.com> To: <boost@lists.boost.org> Sent: Thursday, June 03, 2010 12:49 PM Subject: Re: [boost] [boost::endian] Summary of discussion #1 > > vicente.botet wrote: >> Tomas Puverle wrote: >> I'm stating that your UNTYPED swap_in_place could be more >> efficient than the the TYPED one. But that there is no reason >> that the UNTYPED swap<> be more efficient than the TYPED >> assignation. And that the TYPED assignation is endian-safe. >> So yes I was stating my preference. > > I dislike referring to the function-based interface as "untyped" and the higher level interface as "typed." Perhaps we could use "function-based" and "object-based" as the adjectives? My typed/untyped was respect to endianess. With the Beman's approach the type know its endianess, with the Tom approach it doesn't. I don't find the function/object naming appropiated, I consider the Beman's endian classes as types not as objects, and the conversion from atype to another is clearly a functional concept not an object concept. I don't consider the swap_in_place belongs to the functional programming paradigm, at least not to the pure one. > There are, yet, use cases in which the function-based design is more efficient, I think, but we should explore ways to ensure both are as efficient as possible. Regardless, it is clear that there are prejudices in favor of one approach or the other in various contexts and for various users, hence Tomas has agreed to include *both* in his proposal. > >> > I agreed to implement the typed interface (even though I >> > don't personally endorse it), so you are free to choose >> > your preferred implementation. >> >> The typed interface exists already on the Beman's library. >> Thus I don't see any need to reimplement it. Do you? > > It very likely should be reimplemented on the function-based interface so that there is just one implementation of a given swap routine. OK, if the performance of the Beman's library are not degraded and all the features are preserved. For the moment, the figures Terry has provided show that the swap copy takes more time than the assignation between typed endian variables. I will let Beman's to decide if the reuse the Tom library is benefical for his library. > Several of us have agreed that including support for arithmetic operators is misleading. I agree for the kind of applications I'have done. This doens't mean that nobody will take advantage of this transparent interface. Not all the applications have the same performances constraints. >From my point of view we need just to split the interface of the endian class in two: * packets: endian packets without arithmetic operators. * integer: endian integers with all the arithmetic operators. Tom can always reimplement the Beman's library using its library, but I don't consider this necessary. > Whether Tomas or others have still different ideas on the interface remains to be seen, but there is already sufficient reason to create a new set of endian types, if only to compare and contrast with Beman's. I agree, but I dont see why the Tom library should include the packet interface. >> >> 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? > > I can imagine any packed byte protocol requiring this. Indeed, there are packed bit protocols, too, to justify the bitfield endian handling mentioned previously. These do seem worth consideration. The Bitfield library doesn't take care of bitfields that are between two words. This was already managed correctly by the Beman's library. Would the Tom library take care of this cases, e.g. endian<big, int, 3>? Best, Vicente
vicente.botet wrote: > Stewart, Robert wrote: > > > I dislike referring to the function-based interface as > > "untyped" and the higher level interface as "typed." > > Perhaps we could use "function-based" and "object-based" > > as the adjectives? > > My typed/untyped was respect to endianess. With the Beman's > approach the type know its endianess, with the Tom approach > it doesn't. Of Beman's library provides types. int and double are types, too. I understand that Beman's types know their endianness, insofar as it is supplied by a template argument. Endianness, however, is not a type. > I don't find the function/object naming appropiated, I > consider the Beman's endian classes as types not as objects, > and the conversion from atype to another is clearly a > functional concept not an object concept. I don't consider > the swap_in_place belongs to the functional programming > paradigm, at least not to the pure one. I didn't use the word "functional" but "function-based." Tomas' approach uses functions. Beman's approach uses objects of type boost::endian, hence "object-based." Tomas' functions are not typeless. They operate upon a specific type T. To call them "untyped" is misleading, hence my desire to use "function-based" and "object-based" as the means to reference the different approaches. > > Several of us have agreed that including support for > > arithmetic operators is misleading. > > I agree for the kind of applications I'have done. This > doens't mean that nobody will take advantage of this > transparent interface. Not all the applications have the same > performances constraints. The standard library usually refrains from providing what is inherently inefficient. That is a good idea for Boost libraries, too. At the very least, I think there should be separate types with and without the operators so the distinction can be made very clear. > > From my point of view we need just to split the interface > > of the endian class in two: > * packets: endian packets without arithmetic operators. > * integer: endian integers with all the arithmetic operators. I guess your "packets" are simply what Beman provides now minus the arithmetic operators. The name isn't helpful, but we can work on that. > Tom can always reimplement the Beman's library using its > library, but I don't consider this necessary. I wasn't suggesting it was necessary, but Tomas may well have ideas of his own and we don't know yet how Beman will receive the new ideas. > > Whether Tomas or others have still different ideas on the > > interface remains to be seen, but there is already sufficient > > reason to create a new set of endian types, if only to > > compare and contrast with Beman's. > > I agree, but I dont see why the Tom library should include > the packet interface. You're assuming that Beman's library will be accepted and that Tomas' library should be proposed as a complement to it. I'm assuming the possibility that Tomas' will produce a library that subsumes Beman's. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
Tomas intends to supply his own version in his library.
Correct.
There is no Boost.Endian library as yet.
That is true. However, there is one in the review queue which is the main reason for my trying to write one, as I explained in my original RFC post, as I am sure you recall.
I'm quite certain, however, that Tomas would model his version on Beman's and give credit or would work with Beman to create a modified, joint submission.
Of course.
I dislike referring to the function-based interface as "untyped" and the higher level interface as "typed." Perhaps we could use "function-based" and "object-based" as the adjectives?
Thank you.
It very likely should be reimplemented on the function-based interface so that there is just one implementation of a given swap routine.
Absolutely. The main reason for this, as I've already mentioned, that I intend to implement the swapping using machine instructions, where available.
Several of us have agreed that including support for arithmetic operators is misleading.
Agreed completely.
Whether Tomas or others have still different ideas on the interface remains to be seen,
Not really. The endian objects should be pretty trivial to write once the function-based machinery is done.
I can imagine any packed byte protocol requiring this.
Ahh... When I saw Vincent's post, he wrote "another feature the endian class provides and is the ability to work with integers with an arbitrary number of bytes" endian<big, int, 24> i; endian<big, int, 16> j; endian<big, int, 24> j; Hence I was reading the above as three integers 24, 16, 24 bytes long, which is why my eyebrows were raised. But I think the correct reading would be "an integer type with 24, 16 and 24 *bits*" respectively, no? If that's the case, I don't really see a problem. If we are, however, talking about arbitrary precision integers, I might be more twitchy. Tom
Tomas Puverle wrote:
I can imagine any packed byte protocol requiring this.
When I saw Vincent's post, he wrote "another feature the endian class provides and is the ability to work with integers with an arbitrary number of bytes"
endian<big, int, 24> i; endian<big, int, 16> j; endian<big, int, 24> j;
Hence I was reading the above as three integers 24, 16, 24 bytes long, which is why my eyebrows were raised. But I think the correct reading would be "an integer type with 24, 16 and 24 *bits*" respectively, no?
Exactly. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
Vicente wrote:
The typed interface exists already on the Beman's library. Thus I don't see any need to reimplement it. Do you?
Beman's approach is integer centric and combines the use of non-natively-sized integers and endianness. I would like to see Beman's library split into two parts: the integer part and the endian-part. I have shown that implementing the object-based approach that Beman's uses does not benefit from a swap-based implemention (at least on my machine).
I work for a telecomunication company, and I have used a lot of standard protocols that reserved 3 bytes for an int. Theese protocols were defined a long time ago, but we need to work yet with them. I have not an example at hands, but you can belive me that these cases exists. Of course for propietaty protocols this could be avoided, and now we have less problem with the size of the messages.
Absolutely! For over-the-air (wireless) protocols, conservation of bits in messages is extremely important due to limited bandwidth. terry
----- Original Message ----- From: "Terry Golubiewski" <tjgolubi@netins.net> To: <boost@lists.boost.org> Sent: Thursday, June 03, 2010 6:17 PM Subject: Re: [boost] [boost::endian] Summary of discussion #1
Vicente wrote:
The typed interface exists already on the Beman's library. Thus I don't see any need to reimplement it. Do you?
Beman's approach is integer centric and combines the use of non-natively-sized integers and endianness. I would like to see Beman's library split into two parts: the integer part and the endian-part.
I agree. Beman, what do you think about this split? Best, Vicente
Beman's approach is integer centric and combines the use of non-natively-sized integers and endianness. I would like to see Beman's library split into two parts: the integer part and the endian-part.
It's easy for me to suggest that someone else should change. But what would such a change look like. How about this... (I've ignored alignment) namespace boost { namespace interface { template<size_t Bits, endian_t Endian=native> class PackedInteger { public: typedef typename boost::int_t<Bits>::least value_type; static const endian_t endianness = Endian; private: boost::array<char, (Bits+CHAR_BITS-1)/CHAR_BITS> m_storage; void store(value_type x); // depends on Endian choice value_type retrieve() const; // depends on Endian choice public: PackedInteger(): { m_storage.fill('\0'); } explicit PackedInteger(value_type x) { store(x); } operator value_type() const { return retrieve(); } PackedInteger& operator=(value_type x) { store(x); } // All the usual integer operations go here. }; // PackedInteger } } // boost::interface My point is that one must consider "how" the compact integer will be stored in memory, so endianness is important to an implementation of PackedInteger<Bits>. PackedInteger<> must provide for all possible native endiannesses, so why not make it a template parameter that defaults to "native"? So Beman's "endian" survives almost intact with just a name change from "endian" to "PackedInteger" and a reordering of the template parameters. Then I suppose endian<E, T> should be specialized to support a PackedInteger<Bits, Endian>, but I can't think of what it would be used for, since in a message specification it would be easier to just use "PackedInteger<24, big>" instead of "endian<big, PackedInteger<24>>". Still, either should work, so here it is... template<endian_t E1, size_t Bits, endian_t E2> class endian<E1, PackedInteger<Bits, E2>> { public: typedef PackedInteger<Bits, E2> value_type; private: typedef PackedInteger<Bits, E1> Storage; Storage m_storage; public: endian() : m_storage() { } endian(value_type x) : m_storage(typename Storage::value_type(x)) { } operator value_type() const { return value_type(typename Storage::value_type(m_storage)); } endian& operator=(value_type x) { m_storage = typename Storage::value_type(x); } }; Well, thats my 5000 cents. terry
----- Original Message ----- From: "Terry Golubiewski" <tjgolubi@netins.net> To: <boost@lists.boost.org> Sent: Thursday, June 03, 2010 10:27 PM Subject: Re: [boost] [boost::endian] Summary of discussion #1
Beman's approach is integer centric and combines the use of non-natively-sized integers and endianness. I would like to see Beman's library split into two parts: the integer part and the endian-part.
It's easy for me to suggest that someone else should change. But what would such a change look like. How about this... (I've ignored alignment)
namespace boost { namespace interface {
template<size_t Bits, endian_t Endian=native> class PackedInteger {
<snip> I think that the packed class should take the same template parameters as the original endian class, as this packed class is able to manage integer endian. template <BOOST_SCOPED_ENUM(endianness) E, typename T, std::size_t n_bits, BOOST_SCOPED_ENUM(alignment) A = alignment::unaligned> class endian_pack; The single difference between endian_pack and the original endian is that it don't inherits from cover_operators.
My point is that one must consider "how" the compact integer will be stored in memory, so endianness is important to an implementation of PackedInteger<Bits>. PackedInteger<> must provide for all possible native endiannesses, so why not make it a template parameter that defaults to "native"? So Beman's "endian" survives almost intact with just a name change from "endian" to "PackedInteger" and a reordering of the template parameters.
Then I suppose endian<E, T> should be specialized to support a PackedInteger<Bits, Endian>, but I can't think of what it would be used for, since in a message specification it would be easier to just use "PackedInteger<24, big>" instead of "endian<big, PackedInteger<24>>". Still, either should work, so here it is...
template<endian_t E1, size_t Bits, endian_t E2> class endian<E1, PackedInteger<Bits, E2>> {
The original endian class could be declared as template <BOOST_SCOPED_ENUM(endianness) E, typename T, std::size_t n_bits, BOOST_SCOPED_ENUM(alignment) A = alignment::unaligned> class endian; template <typename T, std::size_t n_bits> class endian< endianness::big, T, n_bits, alignment::unaligned > : cover_operators< endian< endianness::big, T, n_bits >, T > { typedef endian_pack<E,T,n_bits,A> pack_type; pack_type pack_; // change every access to the value_type original m_value by pack_.m_value. This seems simple. Isn't it? Best, Vicente
----- Original Message ----- From: "Terry Golubiewski" <tjgolubi@netins.net> To: <boost@lists.boost.org> Sent: Thursday, June 03, 2010 10:27 PM Subject: Re: [boost] [boost::endian] Summary of discussion #1
Beman's approach is integer centric and combines the use of non-natively-sized integers and endianness. I would like to see Beman's library split into two parts: the integer part and the endian-part.
I have split the Beman endian implementation in two classes/files endian.hpp as before and endian_pack.hpp. The split has been straightforward. All the test passes on cygwin gcc-3.4, mingw gcc 4.4 and MSVC 9.0Express (all Little endian). I have added a endian_pack_test.cpp file which is based on the endian_test.cpp file (just changing endian by endian_pack and removing operator ++ test). In order to make the test as transparent as possible I have defined also the corresponing types to big32_t as big32_pt (for pack type). The attached patch contains the new and modified files. Beman, could you take a look to see if this changes can be incorporated in your library? If this is the case, I can work on the documentation. Can someone test other platforms, compilers? Best, Vicente
Hi, for those that can not apply the tack I have attached the split of the files. Best, Vicente _____________________ Vicente Juan Botet Escribá http://viboes.blogspot.com/
vicente.botet wrote:
Terry Golubiewski wrote:
template<size_t Bits, endian_t Endian=native> class PackedInteger { <snip>
template <BOOST_SCOPED_ENUM(endianness) E, typename T, std::size_t n_bits, BOOST_SCOPED_ENUM(alignment) A = alignment::unaligned> class endian_pack;
The single difference between endian_pack and the original endian is that it don't inherits from cover_operators.
That should be the primary interface because it doesn't encourage using inefficient arithmetic operators, so that should be named boost::endian.
template<endian_t E1, size_t Bits, endian_t E2> class endian<E1, PackedInteger<Bits, E2>> {
The original endian class could be declared as
template <BOOST_SCOPED_ENUM(endianness) E, typename T, std::size_t n_bits, BOOST_SCOPED_ENUM(alignment) A = alignment::unaligned> class endian;
template <typename T, std::size_t n_bits> class endian< endianness::big, T, n_bits, alignment::unaligned > : cover_operators< endian< endianness::big, T, n_bits >, T > {
The class with operators should be named in such a way to indicate that it manages endianness and provides the arithmetic operators, so I suggest boost::endian_integer. Given those names, why wouldn't endian_integer inherit from endian? _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
----- Original Message ----- From: "Stewart, Robert" <Robert.Stewart@sig.com> To: <boost@lists.boost.org> Sent: Friday, June 04, 2010 12:54 PM Subject: Re: [boost] [boost::endian] Summary of discussion #1
vicente.botet wrote:
The single difference between endian_pack and the original endian is that it don't inherits from cover_operators.
That should be the primary interface because it doesn't encourage using inefficient arithmetic operators, so that should be named boost::endian.
First, currently is boost::integer::endian_pack and not boost::endian_pack, as it works only with integers. Well, I have no other problem than preserving the current interface. We can discuss of course of better names.
The original endian class could be declared as
template <BOOST_SCOPED_ENUM(endianness) E, typename T, std::size_t n_bits, BOOST_SCOPED_ENUM(alignment) A = alignment::unaligned> class endian : cover_operators< endian< E, T, n_bits, A >, T > {
The class with operators should be named in such a way to indicate that it manages endianness and provides the arithmetic operators, so I suggest boost::endian_integer.
As I said above I was just preserving the current interface. As for now endian is in the namespace interger, it is clear for me that we are working with endian integers. If we can put names in the boost namespace then the names need to be reconsidered. As the classes works only with integers I see the following possibilities boost::interger::endian_pack boost::interger::endian --- boost::interger_endian_pack boost::interger_endian --- boost::endian_interger_pack boost::endian_interger But no boost::endian. Have you other proposition that respect the fact that these classes works only with integers?
Given those names, why wouldn't endian_integer inherit from endian?
I was sure someone will ask this. We can inherit, but this introduce multiple inheritance, which I wanted to avoid. Could you describes the advantages to inherit? Best, Vicente
vicente.botet wrote:
Stewart, Robert wrote:
vicente.botet wrote:
The single difference between endian_pack and the original endian is that it don't inherits from cover_operators.
That should be the primary interface because it doesn't encourage using inefficient arithmetic operators, so that should be named boost::endian.
First, currently is boost::integer::endian_pack and not boost::endian_pack, as it works only with integers.
I didn't notice the "integer" namespace.
Well, I have no other problem than preserving the current interface. We can discuss of course of better names.
"endian_pack" doesn't suggest the class' actual purpose, so a different name is in order (no pun intended). A "pack" of integers, as "integer::*_pack" indicates, is a collection, a set of integers, which is not the case here. The class also doesn't contain a collection or set of "endians." Even if you use "packed" as did Terry, the term is misleading because there aren't multiple integers packed into the object. You're designing a specifically-sized integer type with implicit endianness conversion, right? Given that boost::endian<T> creates an implicit endianness converting wrapper around T, where T is an integer type (at least presently), it is probably not appropriate to call this class "endian_integer." Would "compressed_endian_integer" or "boost::integer::compressed::endian" do? That leaves room for "endian_integer" to be the variant of "boost::endian" that includes arithmetic operators.
The original endian class could be declared as
template <BOOST_SCOPED_ENUM(endianness) E, typename T, std::size_t n_bits, BOOST_SCOPED_ENUM(alignment) A = alignment::unaligned> class endian : cover_operators< endian< E, T, n_bits, A >, T > {
The class with operators should be named in such a way to indicate that it manages endianness and provides the arithmetic operators, so I suggest boost::endian_integer.
As I said above I was just preserving the current interface. As for now endian is in the namespace interger, it is clear for me that we are working with endian integers.
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. 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. Thus, boost::endian could be like Beman's without the operators and boost::endian_integer could be like Beman's boost::endian.
If we can put names in the boost namespace then the names need to be reconsidered. As the classes works only with integers I see the following possibilities
I'm not certain we should assume the class will never support anything besides integers. That's certainly the case for Beman's library, but Tomas has implied the possibility for floating point support in his.
boost::interger::endian_pack boost::interger::endian --- boost::interger_endian_pack boost::interger_endian --- boost::endian_interger_pack boost::endian_interger
But no boost::endian.
Beman's library provides boost::endian, so I have been assuming the likelihood of adding a little more to the boost namespace: boost::endian boost::endian_integer boost::compressed_endian_integer
Given those names, why wouldn't endian_integer inherit from endian?
I was sure someone will ask this. We can inherit, but this introduce multiple inheritance, which I wanted to avoid. Could you describes the advantages to inherit?
That's merely a side effect of providing the operator support via inheritance from cover_operators. That isn't the only way to provide operators, however. If one doesn't inherit from cover_operators, then I think inheritance makes sense and would be useful to clients. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
On 4 June 2010 09:20, Stewart, Robert <Robert.Stewart@sig.com> wrote:
"endian_pack" doesn't suggest the class' actual purpose, so a different name is in order (no pun intended). A "pack" of integers, as "integer::*_pack" indicates, is a collection, a set of integers, which is not the case here. The class also doesn't contain a collection or set of "endians." Even if you use "packed" as did Terry, the term is misleading because there aren't multiple integers packed into the object.
I'd guess that pack was chosen thinking of the verb, like the perl function pack: <http://perldoc.perl.org/functions/pack.html>.
Scott McMurray wrote:
On 4 June 2010 09:20, Stewart, Robert <Robert.Stewart@sig.com> wrote:
"endian_pack" doesn't suggest the class' actual purpose
I'd guess that pack was chosen thinking of the verb, like the perl function pack: <http://perldoc.perl.org/functions/pack.html>.
Perhaps, but while function names are rightly verbs, type names should be nouns. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
----- Original Message ----- From: "Stewart, Robert" <Robert.Stewart@sig.com> To: <boost@lists.boost.org> Sent: Friday, June 04, 2010 3:29 PM Subject: Re: [boost] [boost::endian] Summary of discussion #1
Scott McMurray wrote:
On 4 June 2010 09:20, Stewart, Robert <Robert.Stewart@sig.com> wrote:
"endian_pack" doesn't suggest the class' actual purpose
I'd guess that pack was chosen thinking of the verb, like the perl function pack: <http://perldoc.perl.org/functions/pack.html>.
Perhaps, but while function names are rightly verbs, type names should be nouns.
So the noum shoud be? Vicente
Vicente Botet wrote:
Rob Stewart wrote:
Scott McMurray wrote:
On 4 June 2010 09:20, Stewart, Robert <Robert.Stewart@sig.com> wrote:
"endian_pack" doesn't suggest the class' actual purpose
I'd guess that pack was chosen thinking of the verb, like the perl function pack: <http://perldoc.perl.org/functions/pack.html>.
Perhaps, but while function names are rightly verbs, type names should be nouns.
So the noum shoud be?
I suggested some in another reply. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
----- Original Message ----- From: "Stewart, Robert" <Robert.Stewart@sig.com> To: <boost@lists.boost.org> Sent: Friday, June 04, 2010 4:02 PM Subject: Re: [boost] [boost::endian] Summary of discussion #1
Vicente Botet wrote:
Rob Stewart wrote:
Scott McMurray wrote:
On 4 June 2010 09:20, Stewart, Robert <Robert.Stewart@sig.com> wrote:
"endian_pack" doesn't suggest the class' actual purpose
I'd guess that pack was chosen thinking of the verb, like the perl function pack: <http://perldoc.perl.org/functions/pack.html>.
Perhaps, but while function names are rightly verbs, type names should be nouns.
So the noum shoud be?
I suggested some in another reply.
Please could you repeate it here, I don't remember which one of your suggestion used the noum for pack. Vicente
vicente.botet wrote:
Rob Stewart wrote:
Vicente Botet wrote:
Rob Stewart wrote:
Scott McMurray wrote:
Rob Stewart wrote:
"endian_pack" doesn't suggest the class' actual purpose
I'd guess that pack was chosen thinking of the verb, like the perl function pack: <http://perldoc.perl.org/functions/pack.html>.
Perhaps, but while function names are rightly verbs, type names should be nouns.
So the noum shoud be?
I suggested some in another reply.
Please could you repeate it here, I don't remember which one of your suggestion used the noum for pack.
I suggested compressed_endian_integer. See my reply in that other part of the thread for subsequent discussion of such names. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
I suggested compressed_endian_integer. See my reply in that other part of the thread for subsequent discussion of such names.
I think the "endian" parameter is of secondary importance and should be removed from the name: compressed_integer, packed_int, etc. The type should still have an endianness template paramenter, but it should default to "native". Of my implementation, all that ever actually gets used is int24_t and uint24_t. They are implemented as typedefs of packed_int which is similar to Beman's, something like this. typedef packed_int<3, signed, native> int24_t; typedef packed_int<3, unsigned, native> uint24_t; I don't specify mine in terms of "bits", the "3" represents the number of bytes (which I assume are octets). The "signed" and "unsigned" types are strictly tags and have nothing to do with the actual implementation (other than to indicate sign). If boost::integer is going to be a namespace, then I suppose these belong there. terry
Terry Golubiewski wrote:
Rob Stewart wrote:
I suggested compressed_endian_integer. See my reply in that other part of the thread for subsequent discussion of such names.
I think the "endian" parameter is of secondary importance and should be removed from the name: compressed_integer, packed_int, etc. The type should still have an endianness template paramenter, but it should default to "native".
If the type is in a namespace that indicates the handling of endianness, I'd agree. Otherwise, I think "endian" necessary in the name. If it is hoisted into the boost namespace, for example, "compressed_integer" is less useful.
typedef packed_int<3, signed, native> int24_t; typedef packed_int<3, unsigned, native> uint24_t;
Using "int" in the name is short, but misleading. The underlying type may be char, short, int, long, etc., I imagine. At the least, "int" should be spelled "integer." I still don't like "packed" for reasons I've outlined elsewhere. Vicente disliked my "reduced" suggestion (and I now recognize the mathematical connotation that might be problematic in it), so I'm not sure what else to use yet. I think in another chain of replies there was progress in another direction, so I won't pursue names further here (especially as this reply is being sent so much later than originally intended!). _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
From: "Stewart, Robert" <Robert.Stewart@sig.com> To: <boost@lists.boost.org> Sent: Monday, June 14, 2010 1:47 PM Subject: Re: [boost] [boost::endian] Summary of discussion #1
Terry Golubiewski wrote:
Rob Stewart wrote:
I suggested compressed_endian_integer. See my reply in that other part of the thread for subsequent discussion of such names.
I think the "endian" parameter is of secondary importance and should be removed from the name: compressed_integer, packed_int, etc. The type should still have an endianness template paramenter, but it should default to "native".
If the type is in a namespace that indicates the handling of endianness, I'd agree. Otherwise, I think "endian" necessary in the name. If it is hoisted into the boost namespace, for example, "compressed_integer" is less useful.
typedef packed_int<3, signed, native> int24_t; typedef packed_int<3, unsigned, native> uint24_t;
Using "int" in the name is short, but misleading. The underlying type may be char, short, int, long, etc., I imagine. At the least, "int" should be spelled "integer."
I still don't like "packed" for reasons I've outlined elsewhere. Vicente disliked my "reduced" suggestion (and I now recognize the mathematical connotation that might be problematic in it), so I'm not sure what else to use yet. I think in another chain of replies there was progress in another direction, so I won't pursue names further here (especially as this reply is being sent so much later than originally intended!).
Even if we don't have yet a clear vision of what is the endianness of a floating point and that we are reduced to interger types, I propose we name it boost::endian_holder as it is aware of the endianess and can contain UDT, as time_point, quantity::si::length .... template <typename Endian, typename T, std::size_t n_bytes=8*sizeof(T), typename Alignment = alignment::aligned> class endian_holder; I will let the name boost::endian_integer or boost::integer::endian for the class providing also the arithmetic operations. Best, Vicente
template <typename Endian, typename T, std::size_t n_bytes=8*sizeof(T), typename Alignment = alignment::aligned> n_bits? 2010/6/14 vicente.botet <vicente.botet@wanadoo.fr>
From: "Stewart, Robert" <Robert.Stewart@sig.com> To: <boost@lists.boost.org> Sent: Monday, June 14, 2010 1:47 PM Subject: Re: [boost] [boost::endian] Summary of discussion #1
Terry Golubiewski wrote:
Rob Stewart wrote:
I suggested compressed_endian_integer. See my reply in that other part of the thread for subsequent discussion of such names.
I think the "endian" parameter is of secondary importance and should be removed from the name: compressed_integer, packed_int, etc. The type should still have an endianness template paramenter, but it should default to "native".
If the type is in a namespace that indicates the handling of endianness,
I'd agree. Otherwise, I think "endian" necessary in the name. If it is hoisted into the boost namespace, for example, "compressed_integer" is less useful.
typedef packed_int<3, signed, native> int24_t; typedef packed_int<3, unsigned, native> uint24_t;
Using "int" in the name is short, but misleading. The underlying type
may be char, short, int, long, etc., I imagine. At the least, "int" should be spelled "integer."
I still don't like "packed" for reasons I've outlined elsewhere. Vicente
disliked my "reduced" suggestion (and I now recognize the mathematical connotation that might be problematic in it), so I'm not sure what else to use yet. I think in another chain of replies there was progress in another direction, so I won't pursue names further here (especially as this reply is being sent so much later than originally intended!).
Even if we don't have yet a clear vision of what is the endianness of a floating point and that we are reduced to interger types, I propose we name it boost::endian_holder as it is aware of the endianess and can contain UDT, as time_point, quantity::si::length ....
template <typename Endian, typename T, std::size_t n_bytes=8*sizeof(T), typename Alignment = alignment::aligned> class endian_holder;
I will let the name boost::endian_integer or boost::integer::endian for the class providing also the arithmetic operations.
Best, Vicente
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- Murilo Adriano Vasconcelos http://murilo.wordpress.com
vicente.botet wrote:
Even if we don't have yet a clear vision of what is the endianness of a floating point and that we are reduced to interger types, I propose we name it boost::endian_holder as it is aware of the endianess and can contain UDT, as time_point, quantity::si::length ....
That's an excellent argument in favor of keeping the name generic.
template <typename Endian, typename T, std::size_t n_bytes=8*sizeof(T), typename Alignment = alignment::aligned> class endian_holder;
I will let the name boost::endian_integer or boost::integer::endian for the class providing also the arithmetic operations.
"endian_integer" is fine for the type with arithmetic operations, but "endian_holder" seems more circumspect that necessary. It begs questions like, "What's an 'endian' that you need a holder?" I'd prefer to call it "endian" but you can't have a boost::endian namespace, too. Is boost::endianness a good namespace name? What about boost::order/ordering/ordered? boost::order::endian (boost::endianness::endian) provides the basic facilities. boost::order::endian_integer (boost::endianness::endian_integer) derives from endian and provides arithmetic operators. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
----- Original Message ----- From: "Stewart, Robert" <Robert.Stewart@sig.com> To: <boost@lists.boost.org> Sent: Friday, June 04, 2010 3:20 PM Subject: Re: [boost] [boost::endian] Summary of discussion #1
vicente.botet wrote:
Stewart, Robert wrote:
vicente.botet wrote:
should be named boost::endian.
First, currently is boost::integer::endian_pack and not boost::endian_pack, as it works only with integers.
I didn't notice the "integer" namespace.
I saw that.
Well, I have no other problem than preserving the current interface. We can discuss of course of better names.
"endian_pack" doesn't suggest the class' actual purpose, so a different name is in order (no pun intended). A "pack" of integers, as "integer::*_pack" indicates, is a collection, a set of integers, which is not the case here. The class also doesn't contain a collection or set of "endians." Even if you use "packed" as did Terry, the term is misleading because there aren't multiple integers packed into the object.
You're designing a specifically-sized integer type with implicit endianness conversion, right? Given that boost::endian<T> creates an implicit endianness converting wrapper around T, where T is an integer type (at least presently), it is probably not appropriate to call this class "endian_integer." Would "compressed_endian_integer" or "boost::integer::compressed::endian" do? That leaves room for "endian_integer" to be the variant of "boost::endian" that includes arithmetic operators.
For me compressed and packed are not the same. The name pack comes from the fact the integer bytes are packed. We can talk of compression of un integer that can takes values from 0 and 10000 for example. But what we say here is that we need a integer represented with 24 bits, as this is the constraint. packed is the word I have always see in this context, not compressed. Other language procide this king of packed integers. I have no trouble with endian_pack, but don't know all the English subtilities to affirm this is a correct or wrong name.
The original endian class could be declared as
template <BOOST_SCOPED_ENUM(endianness) E, typename T, std::size_t n_bits, BOOST_SCOPED_ENUM(alignment) A = alignment::unaligned> class endian : cover_operators< endian< E, T, n_bits, A >, T > {
The class with operators should be named in such a way to indicate that it manages endianness and provides the arithmetic operators, so I suggest boost::endian_integer.
As I said above I was just preserving the current interface. As for now endian is in the namespace interger, it is clear for me that we are working with endian integers.
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.
It is to me that I'm already using the Boost.Endian library. Of course I'm open to changes in Boost.Endian as the library has not ben accepted, and I will adapt my code to the new one.
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. Thus, boost::endian could be like Beman's without the operators and boost::endian_integer could be like Beman's boost::endian.
I have no problem if Beman changes.
If we can put names in the boost namespace then the names need to be reconsidered. As the classes works only with integers I see the following possibilities
I'm not certain we should assume the class will never support anything besides integers. That's certainly the case for Beman's library, but Tomas has implied the possibility for floating point support in his.
I will see when this is provided. Until now we are limited to integers, and I remeber that Tom said that the first release will be limited to integers.
boost::interger::endian_pack boost::interger::endian --- boost::interger_endian_pack boost::interger_endian --- boost::endian_interger_pack boost::endian_interger
But no boost::endian.
Beman's library provides boost::endian, so I have been assuming the likelihood of adding a little more to the boost namespace:
Sorry. I miss it. Could you point me to the file and the line, or in the documentation? From what I can see everything is inside namespace boost { namespace integer { ...}}
boost::endian boost::endian_integer boost::compressed_endian_integer
We need to names not three. What is your concrete proposal? Are other booster ready to add new names as these ones on the namespace boost?
Given those names, why wouldn't endian_integer inherit from endian?
I was sure someone will ask this. We can inherit, but this introduce multiple inheritance, which I wanted to avoid. Could you describes the advantages to inherit?
That's merely a side effect of providing the operator support via inheritance from cover_operators. That isn't the only way to provide operators, however. If one doesn't inherit from cover_operators, then I think inheritance makes sense and would be useful to clients.
I have no problem with the design you propose, even if I don't see yet concrete use cases where the inheritance from endian to endian_pack is useful. Could you made a concrete proposal that doesn't inherits from cover_operators? Best, Vicente
vicente.botet wrote:
Stewart, Robert wrote:
vicente.botet wrote:
"endian_pack" doesn't suggest the class' actual purpose, so a different name is in order (no pun intended). A "pack" of integers, as "integer::*_pack" indicates, is a collection, a set of integers, which is not the case here. The class also doesn't contain a collection or set of "endians." Even if you use "packed" as did Terry, the term is misleading because there aren't multiple integers packed into the object.
You're designing a specifically-sized integer type with implicit endianness conversion, right? Given that boost::endian<T> creates an implicit endianness converting wrapper around T, where T is an integer type (at least presently), it is probably not appropriate to call this class "endian_integer." Would "compressed_endian_integer" or "boost::integer::compressed::endian" do? That leaves room for "endian_integer" to be the variant of "boost::endian" that includes arithmetic operators.
For me compressed and packed are not the same. The name pack comes from the fact the integer bytes are packed. We can talk of compression of un integer that can takes values from 0 and 10000 for example. But what we say here is that we need a integer represented with 24 bits, as this is the constraint. packed is the word I have always see in this context, not compressed. Other language procide this king of packed integers.
I see your concern with the term "compressed." Packing implies reduction of space, certainly. Thus, "packed" does imply the right idea, but only in the context of multiple integers being packed into a structure. The individual, smaller-than-normal integer type isn't packed to my mind. It is reduced or shrunk from its normal size, hence my use of "compressed."
I have no trouble with endian_pack, but don't know all the English subtilities to affirm this is a correct or wrong name.
Would "reduced_endian_integer" satisfy?
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.
It is to me that I'm already using the Boost.Endian library. Of course I'm open to changes in Boost.Endian as the library has not ben accepted, and I will adapt my code to the new one.
Understood. I wouldn't want to introduce gratuitous changes, but I think we're discussing changes of merit.
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. Thus, boost::endian could be like Beman's without the operators and boost::endian_integer could be like Beman's boost::endian.
I have no problem if Beman changes.
What if he simply hands off his effort to Tomas?
If we can put names in the boost namespace then the names need to be reconsidered. As the classes works only with integers I see the following possibilities
I'm not certain we should assume the class will never support anything besides integers. That's certainly the case for Beman's library, but Tomas has implied the possibility for floating point support in his.
I will see when this is provided. Until now we are limited to integers, and I remeber that Tom said that the first release will be limited to integers.
Granted, but putting the names in the "integer" namespace means floating point cannot be added later without undue confusion.
boost::interger::endian_pack boost::interger::endian --- boost::interger_endian_pack boost::interger_endian --- boost::endian_interger_pack boost::endian_interger
I assumed the above were all your invention.
But no boost::endian.
Beman's library provides boost::endian, so I have been assuming the likelihood of adding a little more to the boost namespace:
Sorry. I miss it. Could you point me to the file and the line, or in the documentation? From what I can see everything is inside namespace boost { namespace integer { ...}}
Is it? I must have missed it in my scans of his documentation and I've always seen it referenced as "boost::endian" on the list.
boost::endian boost::endian_integer boost::compressed_endian_integer
We need to names not three. What is your concrete proposal?
Hmmm. Maybe I'm inventing more than I need to, but I'm not convinced. Beman's endian is already compressed/packed/reduced, right? Is your idea simply to create a version with and without operators? My thinking was that we need the following: 1) A class template that uses an appropriate (currently built-in integer) type and applies implicit endianness conversions 2) A class template that extends 1 to include arithmetic operators 3) A class template that determines the smallest integer type to support a requested number of bits and applies implicit endianness conversions to it (could derive from an instantiation of 1) 4) A class template that extends 3 to include arithmetic operators That implies four names, not two or three.
Are other booster ready to add new names as these ones on the namespace boost?
It is good to avoid polluting the boost namespace, but all of the names I suggested begin with or contain "endian" so they're fairly unique. I don't mind putting them in some nested namespace, but I don't think "integer" is appropriate.
I was sure someone will ask this. We can inherit, but this introduce multiple inheritance, which I wanted to avoid. Could you describes the advantages to inherit?
That's merely a side effect of providing the operator support via inheritance from cover_operators. That isn't the only way to provide operators, however. If one doesn't inherit from cover_operators, then I think inheritance makes sense and would be useful to clients.
I have no problem with the design you propose, even if I don't see yet concrete use cases where the inheritance from endian to endian_pack is useful. Could you made a concrete proposal that doesn't inherits from cover_operators?
I think that's premature, but if we get far enough along, I'll consider doing so. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
----- Original Message ----- From: "Stewart, Robert" <Robert.Stewart@sig.com> To: <boost@lists.boost.org> Sent: Friday, June 04, 2010 4:20 PM Subject: Re: [boost] [boost::endian] Summary of discussion #1
vicente.botet wrote:
For me compressed and packed are not the same. The name pack comes from the fact the integer bytes are packed. We can talk of compression of un integer that can takes values from 0 and 10000 for example. But what we say here is that we need a integer represented with 24 bits, as this is the constraint. packed is the word I have always see in this context, not compressed. Other language procide this king of packed integers.
I see your concern with the term "compressed." Packing implies reduction of space, certainly. Thus, "packed" does imply the right idea, but only in the context of multiple integers being packed into a structure. The individual, smaller-than-normal integer type isn't packed to my mind. It is reduced or shrunk from its normal size, hence my use of "compressed."
I can understand your concern. But I will reserv compressed integers for classes that have the range of possible values as parameters, and that deduce the number of needed bytes. Thinking more on, pack will not be appropiated, as it is used for unaligned integers. I have found this Octet-packed integers.
I have no trouble with endian_pack, but don't know all the English subtilities to affirm this is a correct or wrong name.
Would "reduced_endian_integer" satisfy?
Not for me. Do others like?
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.
It is to me that I'm already using the Boost.Endian library. Of course I'm open to changes in Boost.Endian as the library has not ben accepted, and I will adapt my code to the new one.
Understood. I wouldn't want to introduce gratuitous changes, but I think we're discussing changes of merit.
Don't worry, if we find a better design, I will the first to request the change ;-)
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. Thus, boost::endian could be like Beman's without the operators and boost::endian_integer could be like Beman's boost::endian.
I have no problem if Beman changes.
What if he simply hands off his effort to Tomas?
For the moment Beman has not abandoned his library :)
If we can put names in the boost namespace then the names need to be reconsidered. As the classes works only with integers I see the following possibilities
I'm not certain we should assume the class will never support anything besides integers. That's certainly the case for Beman's library, but Tomas has implied the possibility for floating point support in his.
I will see when this is provided. Until now we are limited to integers, and I remeber that Tom said that the first release will be limited to integers.
Granted, but putting the names in the "integer" namespace means floating point cannot be added later without undue confusion.
Once we will have a floating point implementation, we could add someting that works for both. But if you insists, you can put it in namepace boost.
boost::interger::endian_pack boost::interger::endian --- boost::interger_endian_pack boost::interger_endian --- boost::endian_interger_pack boost::endian_interger
I assumed the above were all your invention.
The first choice is what I was proposed in the post. The others were propositions at the boost namespace level.
But no boost::endian.
Beman's library provides boost::endian, so I have been assuming the likelihood of adding a little more to the boost namespace:
Sorry. I miss it. Could you point me to the file and the line, or in the documentation? From what I can see everything is inside namespace boost { namespace integer { ...}}
Is it? I must have missed it in my scans of his documentation and I've always seen it referenced as "boost::endian" on the list.
I think people use sometimes boost::endian to refer to Boost.Endian :)
boost::endian boost::endian_integer boost::compressed_endian_integer
We need to names not three. What is your concrete proposal?
Hmmm. Maybe I'm inventing more than I need to, but I'm not convinced. Beman's endian is already compressed/packed/reduced, right? Is your idea simply to create a version with and without operators? My thinking was that we need the following:
1) A class template that uses an appropriate (currently built-in integer) type and applies implicit endianness conversions
2) A class template that extends 1 to include arithmetic operators
3) A class template that determines the smallest integer type to support a requested number of bits and applies implicit endianness conversions to it (could derive from an instantiation of 1)
4) A class template that extends 3 to include arithmetic operators
That implies four names, not two or three.
Bemans class has an aligned/unaliged parameter that reduce the names to two.
Are other booster ready to add new names as these ones on the namespace boost?
It is good to avoid polluting the boost namespace, but all of the names I suggested begin with or contain "endian" so they're fairly unique. I don't mind putting them in some nested namespace, but I don't think "integer" is appropriate.
Do you have a concrete suggestion? Best, Vicente
Perhaps "odd_int" or "irregular_int" then? Beman's approach is not "the" boost approach yet, (but its the only one in the sandbox, though I expect that's going to change soon). terry
On Fri, Jun 4, 2010 at 7:57 AM, vicente.botet <vicente.botet@wanadoo.fr> wrote:
For me compressed and packed are not the same. The name pack comes from the fact the integer bytes are packed. We can talk of compression of un integer that can takes values from 0 and 10000 for example. But what we say here is that we need a integer represented with 24 bits, as this is the constraint. packed is the word I have always see in this context, not compressed. Other language procide this king of packed integers.
To whit, GCC supports struct packing via the __packed__ attribute: http://gcc.gnu.org/onlinedocs/gcc/Type-Attributes.html I'm not a linguist, but I use pack as a noun all the time. Whenever I feel like rock climbing, I grab my gear pack and head for the crag. Jon
Jonathan Franklin wrote:
On Fri, Jun 4, 2010 at 7:57 AM, vicente.botet <vicente.botet@wanadoo.fr> wrote:
For me compressed and packed are not the same. The name pack comes from the fact the integer bytes are packed. We can talk of compression of un integer that can takes values from 0 and 10000 for example. But what we say here is that we need a integer represented with 24 bits, as this is the constraint. packed is the word I have always see in this context, not compressed. Other language procide this king of packed integers.
To whit, GCC supports struct packing via the __packed__ attribute: http://gcc.gnu.org/onlinedocs/gcc/Type-Attributes.html
That's for a UDT, not for an int.
I'm not a linguist, but I use pack as a noun all the time. Whenever I feel like rock climbing, I grab my gear pack and head for the crag.
Of course "pack" can be a noun. I didn't say otherwise (presuming that your reference to nouns versus verbs was in reference to one of my posts on that point). However, just as you've used it, a "pack" is a collection or holder of things. Hence, it doesn't work in this context because the type in question holds a single integer type of some number of bits/octets. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
On Fri, Jun 4, 2010 at 10:33 AM, Stewart, Robert <Robert.Stewart@sig.com> wrote:
Jonathan Franklin wrote:
To whit, GCC supports struct packing via the __packed__ attribute: http://gcc.gnu.org/onlinedocs/gcc/Type-Attributes.html
That's for a UDT, not for an int.
Of course. The point is that packing has a well-known meaning. If you rethink your concept of packing in terms of bits in an int representation, you can reword the verbiage in the link like so: This attribute, attached to an *integral type* definition, specifies that each *bit* of the *integral type* is placed to minimize the memory required.
I'm not a linguist, but I use pack as a noun all the time. Whenever I feel like rock climbing, I grab my gear pack and head for the crag.
Of course "pack" can be a noun. I didn't say otherwise (presuming that your reference to nouns versus verbs was in reference to one of my posts on that point).
Perhaps I misread. My recollection is that it was claimed the "pack" label was no good because it is a verb, not a noun. I'm sure I'm remembering this wrong, and it isn't worth looking up or revisiting. Sorry for bringing it up.
However, just as you've used it, a "pack" is a collection or holder of things. Hence, it doesn't work in this context because the type in question holds a single integer type of some number of bits/octets.
Again, an integral type is a collection of bits, which some people, other than yourself, might like to pack into a... pack. ;-) And this is purely a semantic discussion now, so I'm exiting post-haste. Jon
----- Original Message ----- From: "Stewart, Robert" <Robert.Stewart@sig.com> To: <boost@lists.boost.org> Sent: Friday, June 04, 2010 6:33 PM Subject: Re: [boost] [boost::endian] Summary of discussion #1
Of course "pack" can be a noun. I didn't say otherwise (presuming that your reference to nouns versus verbs was in reference to one of my posts on that point). However, just as you've used it, a "pack" is a collection or holder of things. Hence, it doesn't work in this context because the type in question holds a single integer type of some number of bits/octets.
The Beman's unaligned version contains a number of octes not an integer. char m_value[n_bits/8]; best, Vicente
vicente.botet wrote:
Rob Stewart wrote:
as you've used it, a "pack" is a collection or holder of things. Hence, it doesn't work in this context because the type in question holds a single integer type of some number of bits/octets.
The Beman's unaligned version contains a number of octes not an integer.
char m_value[n_bits/8];
Hmmm. "octet_pack" could work; that fits my notion of a "pack." I'd still like "endian" to be part of the name or namespace if it does the implicit endianness conversions; boost::endian::octet_pack, for example. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
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 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. 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 Vincente fails to see this.
On 4 June 2010 10:29, Tomas Puverle <tomas.puverle@morganstanley.com> wrote:
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 disagree. The endian types provide different storage policies for integral types. Comparing them, which provide much stronger invariants than swapping-based approaches, to untyped void* code is unfair.
----- Original Message ----- From: "Tomas Puverle" <tomas.puverle@morganstanley.com> To: <boost@lists.boost.org> 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
Terry Golubiewski wrote:
It's easy for me to suggest that someone else should change. But what would such a change look like. How about this... (I've ignored alignment)
namespace boost { namespace interface {
boost::interface strikes me as a meaningless namespace.
template<size_t Bits, endian_t Endian=native> class PackedInteger { public: typedef typename boost::int_t<Bits>::least value_type; static const endian_t endianness = Endian; [snip] PackedInteger(): { m_storage.fill('\0'); } explicit PackedInteger(value_type x) { store(x); }
Why explicit?
operator value_type() const { return retrieve(); } PackedInteger& operator=(value_type x) { store(x); } // All the usual integer operations go here. }; // PackedInteger
} } // boost::interface
I don't understand the point of "packed" in the name. I'd have expected boost::endian to be what Beman has now minus arithmetic operators and then boost::endian_integer to be derived from boost::endian with the arithmetic operators. That seems simple and obvious. Have I missed something? _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
Robert Stewart wrote:
Terry Golubiewski wrote:
It's easy for me to suggest that someone else should change. But what would such a change look like. How about this... (I've ignored alignment)
namespace boost { namespace interface {
boost::interface strikes me as a meaningless namespace.
I see several classes as having to do with message passing and communication interfaces. endian, packed_int, bitfield, dispatcher, etc. Perhaps just "comm" would be better?
template<size_t Bits, endian_t Endian=native> class PackedInteger { public: typedef typename boost::int_t<Bits>::least value_type; static const endian_t endianness = Endian; [snip] PackedInteger(): { m_storage.fill('\0'); } explicit PackedInteger(value_type x) { store(x); }
Why explicit?
Without the explicit, operations on PackedInteger, such as comparison, will have ambiguity.
operator value_type() const { return retrieve(); } PackedInteger& operator=(value_type x) { store(x); } // All the usual integer operations go here. }; // PackedInteger
} } // boost::interface
The point of PackedInteger is to provide 3-, 5-, 6-, 7-byte integers. It really doesn't have anything to do with endianess in intention. However, when storing the values into memory, you have to decided which endian to use, of course. I hastily picked the "PackedInteger" name because I believe it will be used by users that want the smallest integer that will meet their needs because they are space constrained, such as in messages.
I don't understand the point of "packed" in the name. I'd have expected boost::endian to be what Beman has now minus arithmetic operators and then boost::endian_integer to be derived from boost::endian with the arithmetic operators. That seems simple and obvious. Have I missed something?
Terry Golubiewski wrote:
Robert Stewart wrote:
Terry Golubiewski wrote:
namespace boost { namespace interface {
boost::interface strikes me as a meaningless namespace.
I see several classes as having to do with message passing and communication interfaces. endian, packed_int, bitfield, dispatcher, etc. Perhaps just "comm" would be better?
I see. "comm" is certainly better than "interface" which can apply to nearly anything. Note that the Boost way would spell out the word. Having said that, I question tying endianness with communications. In the general sense, it does work, but one usually thinks of networking, telephony, etc. when using the word "communications." Tomas has rightly kept endianness from networking because it can be used for graphics, market data, etc. In my own code, I used "byte_order" as the namespace.
template<size_t Bits, endian_t Endian=native> class PackedInteger { public: typedef typename boost::int_t<Bits>::least value_type; static const endian_t endianness = Endian; [snip] PackedInteger(): { m_storage.fill('\0'); } explicit PackedInteger(value_type x) { store(x); }
Why explicit?
Without the explicit, operations on PackedInteger, such as comparison, will have ambiguity.
I haven't looked into it, so I'll take your word for it. I thought it was to prevent implicit construction from native types on general principles.
The point of PackedInteger is to provide 3-, 5-, 6-, 7-byte integers. It really doesn't have anything to do with endianess in intention. However, when storing the values into memory, you have to decided which endian to use, of course. I hastily picked the "PackedInteger" name because I believe it will be used by users that want the smallest integer that will meet their needs because they are space constrained, such as in messages.
Given the context, the sudden introduction of PackedInteger surprised me. That you say it "really doesn't have anything to do with endianness" explains it. "Packed integer" suggests a type that selects the smallest representation to hold the current value, though that would be largely impractical. Perhaps "sized_integer," "integer_field" (following "bit field"), or something of that sort would be more to the point. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
Tomas has rightly kept endianness from networking because it can be used for > graphics, market data, etc. In my own code, I used "byte_order" as the namespace.
Without the explicit, operations on PackedInteger, such as comparison, will have ambiguity.
I haven't looked into it, so I'll take your word for it. I thought it was to
Agreed. Endianness simply applies to converting data from one byte/bit orientation to another. prevent implicit construction
from native types on general principles.
Which is one the problems having the "object-based" interface with automatic conversion operators on types. And from there is just keeps getting uglier.
On 02/06/10 16:37, Tomas Puverle wrote:
Beside the two functions swap<>() and swap_in_place<>(),
On the naming issue: We already have a widely used and understood meaning for two-argument swap which performs the swap in-place. For that reason I would expect in-place semantics from your one-argument swap too. More subjectively, I prefer Rob's suggested endian_cast to swap. I don't associate this operation with swapping, and indeed in some cases there is no swapping involved. John Bytheway
More subjectively, I prefer Rob's suggested endian_cast to swap. I don't associate this operation with swapping, and indeed in some cases there is no swapping involved.
Thanks John. I am not married to the names in the current version of the code. I liked the earlier suggestion to rename "swap_in_place" to "swap" and the current "swap" to "swap_copy". But I am not totally opposed to endian::cast<> either. Names are a very subjective thing and I think it will become clearer which ones are preferable as I/others write/use the library. I will also be the first to admit that even though I try and come up with descriptive names, they are usually far from perfect, so this feedback is useful. Actually, now that I think about it, the cast<> notation may allow me to unify the swap/to/from functions into a single form: endian::cast<big_to_host>() //explicit direction endian::cast<from_litle>() //"to_host" is implicit endian::cast<to_big>() //"from_host" is implicit I actually really like that. What do you think? Tom
Tomas Puverle wrote:
John Bytheway wrote:
More subjectively, I prefer Rob's suggested endian_cast to swap. I don't associate this operation with swapping, and indeed in some cases there is no swapping involved.
I liked the earlier suggestion to rename "swap_in_place" to "swap" and the current "swap" to "swap_copy".
Actually, I used "swapped_copy" rather than "swap_copy" intentionally, but it isn't a big deal.
Actually, now that I think about it, the cast<> notation may allow me to unify the swap/to/from functions into a single form:
endian::cast<big_to_host>() //explicit direction endian::cast<from_litle>() //"to_host" is implicit endian::cast<to_big>() //"from_host" is implicit
Where did "big_to_host" come from in your example? Shouldn't that be "big_to_little?" The "from_*" and "to_*" names lose value if you introduce "big_to_host" and friends. "from_big" is little better than "big_to_host," for example. The template arguments in your example assume the endian namespace, while the casts do not. Real code would need to be like the following: endian::cast<endian::big_to_little>(); endian::cast<endian::from_little>(); endian::cast<endian::to_big>(); or this: using namespace boost::endian; cast<big_to_little>(); cast<from_little>(); cast<to_big>(); As you can see, "cast" is not so good in the latter; it is vague and harder to distinguish via textual search. I named it "endian_cast" for those reasons and to make it more like the new-style casts. How about putting "endian_cast" in the boost namespace and the other names in the boost::endian namespace, providing for the following usage? using namespace boost::endian; endian_cast<big_to_little>(); endian_cast<from_little>(); endian_cast<to_big>(); _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
How about putting "endian_cast" in the boost namespace and the other names in the boost::endian namespace, providing for the following usage?
using namespace boost::endian; endian_cast<big_to_little>(); endian_cast<from_little>(); endian_cast<to_big>();
Sure. Looks good. By the same reasoning, we should also have a boost::endian_swap<>(), no? (Which would be the 'in-place' version)
Tomas Puverle wrote:
Rob Stewart wrote:
How about putting "endian_cast" in the boost namespace and the other names in the boost::endian namespace, providing for the following usage?
using namespace boost::endian; endian_cast<big_to_little>(); endian_cast<from_little>(); endian_cast<to_big>();
Sure. Looks good.
By the same reasoning, we should also have a boost::endian_swap<>(), no? (Which would be the 'in-place' version)
I disagree. "swap" alone has meaning, even if somewhat different from that of std::swap. There is no "*_swap" prior art to follow. Thus: using namespace boost::endian; swap<big_to_little>(); and: endian::swap<endian::big_to_little>(); and, in cases of ambiguity: endian::swap<big_to_little>(); _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
----- Original Message ----- From: "Tomas Puverle" <tomas.puverle@morganstanley.com> To: <boost@lists.boost.org> Sent: Wednesday, June 02, 2010 9:34 PM Subject: Re: [boost] [boost::endian] Summary of discussion #1
By the same reasoning, we should also have a boost::endian_swap<>(), no? (Which would be the 'in-place' version)
Are you using the word swap because the bytes are swaped in the implementation? Vicente
How about this... template<endian_t From, class T> T convert_to_host(void* buf); // Coverts/copies a physical format into a big-/little-endian physical format. and template<endian_t To, class T> void convert_from_host(const T& x, void* buf); // Converts/copies a T into a big-/little-endian physical format. and template<endian_t From, endian_t To, class T> void convert_in_place(T& x); // Convert an object supposedly in 'From' endian format to an object in 'To' endian format in place. terry
On 02/06/10 20:01, Tomas Puverle wrote:
I am not married to the names in the current version of the code.
I liked the earlier suggestion to rename "swap_in_place" to "swap" and the current "swap" to "swap_copy".
Indeed that's better, but I'm still not enamoured with it. At the risk of confusing the issue, another possibility would be "swapped" for the out-of-place version.
But I am not totally opposed to endian::cast<> either. Names are a very subjective thing and I think it will become clearer which ones are preferable as I/others write/use the library. I will also be the first to admit that even though I try and come up with descriptive names, they are usually far from perfect, so this feedback is useful.
Actually, now that I think about it, the cast<> notation may allow me to unify the swap/to/from functions into a single form:
endian::cast<big_to_host>() //explicit direction endian::cast<from_litle>() //"to_host" is implicit endian::cast<to_big>() //"from_host" is implicit
I actually really like that. What do you think?
Yes! I do like that. For the out-of-place version, I think this is definitely better than the swap-based names. John
John Bytheway wrote:
endian::cast<big_to_host>() //explicit direction endian::cast<from_litle>() //"to_host" is implicit endian::cast<to_big>() //"from_host" is implicit
I actually really like that. What do you think?
Yes! I do like that. For the out-of-place version, I think this is definitely better than the swap-based names.
I don't think the function should use "cast" because the return type and parameter type are the same. I don't think the function name should use "swap" either because that is an implementation detail. Perhaps endian_transform or endian_convert instead? terry
Tom wrote:
endian::cast<big_to_host>() //explicit direction endian::cast<from_litle>() //"to_host" is implicit endian::cast<to_big>() //"from_host" is implicit
I actually really like that. What do you think?
Is it imporant that these names are templated? What are the advantages of this templated-tagged design over.. endian::cast_big_to_host() endian::cast_from_little() endian::cast_to_big() where the functions are only templated on the object type. template<class T> T cast_big_to_host(const T& x); template<class T> T cast_from_big(const T& x) { return cast_bit_to_host(x); } Although, I strongly disagree with T both as an argument and as a return value of a "cast". terry
On 3 June 2010 12:30, Terry Golubiewski <tjgolubi@netins.net> wrote:
Tom wrote:
endian::cast<big_to_host>() //explicit direction endian::cast<from_litle>() //"to_host" is implicit endian::cast<to_big>() //"from_host" is implicit
Is it imporant that these names are templated? What are the advantages of this templated-tagged design over..
I also find it odd that the direction is mixed in with the endianness. I'd expect something like to_host_endian and from_host_endian, with a policy type for the endianness. (Perhaps the big and little types could be formalized policies, in a way that there could be a custom<1,3,0,4> endian type for very strange endians, with big and little just being instances thereof, perhaps with specializations for speed if needed.) The only advantage I see of the explicit one is that it theoretically allows cast<big_to_little>, but that would mean defining a number of types quadratic in the number of endiannesses. It clearly has no speed benefit over to_host then from_host on typical machines. I'm also not certain that it's even a useful operation.
Scott McMurray wrote:
On 3 June 2010 12:30, Terry Golubiewski <tjgolubi@netins.net> wrote:
Tom wrote:
endian::cast<big_to_host>() //explicit direction endian::cast<from_litle>() //"to_host" is implicit endian::cast<to_big>() //"from_host" is implicit
Is it imporant that these names are templated? What are the advantages of this templated-tagged design over..
I also find it odd that the direction is mixed in with the endianness.
We discussed this previously. I had suggested to<>() and from<>() as well as endian_cast<>. Tomas noted the symmetry of the cast notation for all three cases, but that necessarily requires the direction in the template argument.
I'd expect something like to_host_endian and from_host_endian, with a policy type for the endianness.
to_host_endian<little>() just barely implies conversion from little endian to host endianness to my mind. endian_cast<from_little>() is clearer to me. from<little>() is perfectly clear, but doesn't express that a copy is returned (versus in-place reordering) while the new-style cast syntax more readily implies it.
The only advantage I see of the explicit one is that it theoretically allows cast<big_to_little>, but that would mean defining a number of types quadratic in the number of endiannesses. It clearly has no speed benefit over to_host then from_host on typical machines. I'm also not certain that it's even a useful operation.
As discussed previously, there are occasions when the reordering is for translation without the need to modify or inspect the data in the process. For those cases, going from a specific endianness to a specific endianness is appropriate. I don't imagine those uses are frequent, but it is rather nice that they can use the same syntax as the others. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
participants (10)
-
David Abrahams -
John Bytheway -
Jonathan Franklin -
Murilo Adriano Vasconcelos -
Scott McMurray -
Stewart, Robert -
Terry Golubiewski -
Tomas Puverle -
Vicente Botet -
vicente.botet