Re: [boost] [endian] endian flip and endian domain
Gottlob Frege wrote:
I think what I am saying is that, conceptually at least, the
endian-types come first, and the straight functions are built on top
of that (instead of the other way around as most are suggested).
Now, I wouldn't want that to impact performance, which is why I say
'conceptually'. We can specialize the heck out of everything so that
performance wins, but I think the conceptual foundation is important.
I disagree. If you have an endian type then I think you are coding in from the beginning a need for a copy in order to endian swap - even if the endian swap is a no-operation. Unless I'm missing something here. I also don't think this is bad. Remember that endian swapping happens once at the boundary of the code. It isn't something that is constantly changing type and we shouldn't be worried about the programmer losing track of what type the data is in imho. Of course, if someone can come up with a typed interface which doesn't enforce a copy then I may change my mind. Next, on naming, I think we should be very careful that we don't over-think the naming question. I'll ask a general question. What term does everyone use when talking about endian swapping? Certainly in my programming career I've never heard it called anything other than endian swapping. Also (and I know this shouldn't be taken as a definitive source) Wikipedia refers to the process of changing endianness as a byte swap. Shouldn't we use swap because that is what everyone knows the process of changing endianness as? That's my 2d, but I'm not wholly against another naming option. Dave
Dave Handley wrote:
Gottlob Frege wrote:
I think what I am saying is that, conceptually at least, the endian-types come first, and the straight functions are built on top of that (instead of the other way around as most are suggested). Now, I wouldn't want that to impact performance, which is why I say 'conceptually'. We can specialize the heck out of everything so that performance wins, but I think the conceptual foundation is important.
I disagree. If you have an endian type then I think you are coding in from the beginning a need for a copy in order to endian swap - even if the endian swap is a no-operation.
This discussion isn't necessarily intended to account for swap in place, which all have agreed is necessary. Rather, I at least am thinking of this discussion as applying to the object-based approach and to the copy-based conversion functions.
Unless I'm missing something here. I also don't think this is bad. Remember that endian swapping happens once at the boundary of the code. It isn't something that is constantly changing type and we shouldn't be worried about the programmer losing track of what type the data is in imho.
This has been discussed repeatedly and there remain several in this discussion committed to the usefulness of the object-based approach, so you'll not convince them otherwise. Instead, keep the two approaches distinctly in scope as you read the discussions.
Of course, if someone can come up with a typed interface which doesn't enforce a copy then I may change my mind.
+1
Next, on naming, I think we should be very careful that we don't over-think the naming question. I'll ask a general question. What term does everyone use when talking about endian swapping? Certainly in my programming career I've never heard it called anything other than endian swapping. Also (and I know this shouldn't be taken as a definitive source) Wikipedia refers to the process of changing endianness as a byte swap. Shouldn't we use swap because that is what everyone knows the process of changing endianness as? That's my 2d, but I'm not wholly against another naming option.
While I sympathize with your position, it has been noted that "swap" is a very bad choice because of std::swap(), boost::swap(), etc. Those functions have a distinct behavior and purpose that endianness conversion does not satisfy. Considering that our work could be standardized in the future, can you imagine the committee accepting "swap" as the name? I can't. That implies the need to find another name. _____ 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 Tue, Jun 8, 2010 at 1:05 PM, Dave Handley <Dave.Handley@morganstanley.com> wrote:
Gottlob Frege wrote:
I think what I am saying is that, conceptually at least, the
endian-types come first, and the straight functions are built on top
of that (instead of the other way around as most are suggested).
Now, I wouldn't want that to impact performance, which is why I say
'conceptually'. We can specialize the heck out of everything so that
performance wins, but I think the conceptual foundation is important.
I disagree. If you have an endian type then I think you are coding in from the beginning a need for a copy in order to endian swap - even if the endian swap is a no-operation. Unless I'm missing something here. I also don't think this is bad. Remember that endian swapping happens once at the boundary of the code. It isn't something that is constantly changing type and we shouldn't be worried about the programmer losing track of what type the data is in imho. Of course, if someone can come up with a typed interface which doesn't enforce a copy then I may change my mind.
I'm thinking that we can do a typed interface that doesn't enforce a copy. Of course, I haven't written the templates yet to prove that. It may just come down to the 'tags' used in swap_in_place<big_tag, little_tag>() are also the types we are talking about. so swap_in_place<big_type>(k); is fine if k is a big_type or little_type (or other endian type). But fails to compile if k is an int. swap_in_place<big_type, little_type>(k); would be required for k of type int. Of course then the order of types is somewhat confusing. cast_in_place<big_type, little_type>(k); is,... well at least the orde *might* be less unexpected. Tony
On Tue, Jun 8, 2010 at 1:05 PM, Dave Handley <Dave.Handley@morganstanley.com> wrote:
Next, on naming, I think we should be very careful that we don't over-think the naming question. I'll ask a general question. What term does everyone use when talking about endian swapping? Certainly in my programming career I've never heard it called anything other than endian swapping. Also (and I know this shouldn't be taken as a definitive source) Wikipedia refers to the process of changing endianness as a byte swap. Shouldn't we use swap because that is what everyone knows the process of changing endianness as? That's my 2d, but I'm not wholly against another naming option.
I'll admit to having a habit of over-thinking on names. But they are important. I agree that swap is often used, but it has 2 strikes against it: - doesn't always swap - std::swap To me that was enough to look further. Doesn't mean swap is out of the running, but the above are solid points against it in my mind. The first more than the second, actually. So I tried to take the practical approach, which I think is along the same lines as what you are thinking. To me that means: - "cast" if the syntax matches. - "convert" otherwise "convert", to me, matches most closely with what you express - ie, "What term does everyone use..." Yes, 'swap' might be the first term, but I think, by re-reading the emails, that "convert" comes in second, clearly ahead of the rest. That's actually why I suggested it - it was the term everyone was using. And without the problems swap has. Tony
Gottlob Frege wrote:
On Tue, Jun 8, 2010 at 1:05 PM, Dave Handley <Dave.Handley@morganstanley.com> wrote:
I'll admit to having a habit of over-thinking on names. But they are important.
Ditto.
- "cast" if the syntax matches. - "convert" otherwise
That's a reasonable taxonomy and one that can be explained readily. "cast" should be named "endian_cast" based upon earlier discussion, even if it lives in a boost::endian namespace. The word "endian" need not be added to "convert" as it is obviated by template argument(s) and the namespace name.
"convert", to me, matches most closely with what you express - ie, "What term does everyone use..." Yes, 'swap' might be the first term, but I think, by re-reading the emails, that "convert" comes in second, clearly ahead of the rest. That's actually why I suggested it - it was the term everyone was using. And without the problems swap has.
I adopted "convert" specifically because I tried to stop using "swap," so yes, it is a suitable word for the purpose and a reasonable second choice. _____ 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 (3)
-
Dave Handley -
Gottlob Frege -
Stewart, Robert