Re: [boost] [endian] endian flip and endian domain
Robert Stewart wrote:
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.
The problem is with the initial statement above which says "the endian-types come first, and the straight functions are built on top of that". This is what I fundamentally disagree with. IMHO, you have to write the straight functions (in Tom's terminology, swap and swap_in_place), then implement the endian-types on top of that interface. If you do it the other way around you enforce a copy on the function based interface. At least as far as I can see. I don't disagree that many people want and might well heavily use an object-based interface. Robert Stewart 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.
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.
I agree that the existence of std::swap() is an issue. In that context I would argue for something more like boost::endian_swap. I think changing the verb used is an obfuscation and not necessarily helpful. Dave
Dave Handley wrote:
Robert Stewart wrote:
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.
The problem is with the initial statement above which says "the endian-types come first, and the straight functions are built on top of that".
Agreed, but note the qualifications that followed. I took Tony's statement as wishful thinking that might be proven justified, but very likely won't. Furthermore, I noted that the discussion applied to the copy-based conversion functions. Since those involve a copy, they could just as easily be built atop the object-based approach as not. I don't think that dictates a loss of efficiency, but must be proven.
I agree that the existence of std::swap() is an issue. In that context I would argue for something more like boost::endian_swap. I think changing the verb used is an obfuscation and not necessarily helpful.
I don't mind boost::endian_swap but boost::endian::endian_swap might be a bit much. However, "endian_swap" doesn't connote the copying overhead so I see that as suitable to the in-place operation, and "endian_cast" as more appropriate to convey the copying operations. _____ 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:39 PM, Stewart, Robert <Robert.Stewart@sig.com> wrote:
Dave Handley wrote:
The problem is with the initial statement above which says "the endian-types come first, and the straight functions are built on top of that".
Agreed, but note the qualifications that followed. I took Tony's statement as wishful thinking that might be proven justified, but very likely won't. Furthermore, I noted that the discussion applied to the copy-based conversion functions. Since those involve a copy, they could just as easily be built atop the object-based approach as not. I don't think that dictates a loss of efficiency, but must be proven.
Indeed, it is wishful thinking, yet it may be possible. And indeed I'm wondering if it can be applied to the non-copy case, where as mentioned, the endian-types are used as the swap 'direction tags'. Maybe this is the only worthwhile thing that survives the discussion. Too early to tell, but worth exploring, I think. I suspect the template madness might get too ugly to implement so of this, hard to tell at this point. And yes, at the end of the day, actual swap functions need to exist, and they will probably need to work on raw ints. Or take endian-types that are immediately reinterpreted as raw ints. In fact, swap_in_place can only take a raw int (or raw_int/indeterminate_endian :-) as it doesn't make sense for it to be either endian - it is one endian on the way in, another on the way out! So the question may just be how much we should expose with a raw-int interface vs endian-typed, and/or to what degree. If we could expose more strongly typed versions *without additional overhead*, I'd prefer that. And actually, it is simple to convince yourself that we could. The problem would be the amount of reinterpret_casts that would be required by clients. They would instead resort to boost::endian::detail... pretty quickly. So the only question is how to pretty-up the interface, while keeping it consistent. Tony ** And actually, I'm starting to think of other uses of indeterminate_endian... Maybe it implicitly converts to/from an int (without any swapping of course) and thus is primarily useful as a documentation tool. ie indeterminate_endian convert_to_big(indeterminate_endian); is clear about its intent. The fact that it can take and return ints without additional casts just makes it useful.
Gottlob Frege wrote:
On Tue, Jun 8, 2010 at 1:39 PM, Stewart, Robert <Robert.Stewart@sig.com> wrote:
Dave Handley wrote:
So the question may just be how much we should expose with a raw-int interface vs endian-typed, and/or to what degree. If we could expose more strongly typed versions *without additional overhead*, I'd prefer that.
+1
And actually, it is simple to convince yourself that we could. The problem would be the amount of reinterpret_casts that would be required by clients. They would instead resort to boost::endian::detail... pretty quickly.
I would not want to impose any additional casts on client code. I'd want the endian library to do all of that sort of thing by a nice, convenient, obvious, self-documenting syntax.
indeterminate_endian convert_to_big(indeterminate_endian);
is clear about its intent. The fact that it can take and return ints without additional casts just makes it useful.
I suspect I missed a message in which you previously suggested indeterminate_endian. If that type converts to and from integer types, convert_to_big() would create ambiguities and allow unsafe conversions. Perhaps your signature has just mislead me. Did you mean something like the following? template <class T> indeterminate_endian<T> convert_to_big(indeterminate_endian<T>); Given that, and assuming that indeterminate_endian<T> will only construct from and convert to T, it may be workable. Syntax that clearly declares that the input is, or is assumed to be, of a certain endianness and that the output is to be another is certainly important. Whether that requires an object-based approach or just reasonably named function templates with suitable template arguments is still at issue, I think. Why don't you try to piece together all of your current ideas into a coherent collection that covers the bases of casting, swap-in-place, endian types, etc. To many of those are vague in my mind from what you've been suggesting and its good to step back to see the effect of tangents on the whole periodically. _____ 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.
Stewart, Robert <Robert.Stewart <at> sig.com> writes:
"endian_swap" doesn't connote the copying overhead so I see that as suitable to the in-place operation, and "endian_cast" as more appropriate to convey the copying operations.
I've been more or less neutral throughout this discussion -- it seems a bit bikeshedish in that as long as the semantics are correct, the naming doesn't warrant so much discussion. However, this is the first naming proposal I've seen suggested that I *really* like, so +1 from me on this. FWIW, as far as the namespace is concerned, I think the entirety of the library should reside in the boost::endian namespace, and these two function templates should be brought into the boost namespace via using declarations.
Adam Merz wrote:
Stewart, Robert <Robert.Stewart <at> sig.com> writes:
"endian_swap" doesn't connote the copying overhead so I see that as suitable to the in-place operation, and "endian_cast" as more appropriate to convey the copying operations.
I've been more or less neutral throughout this discussion -- it seems a bit bikeshedish in that as long as the semantics are correct, the naming doesn't warrant so much discussion.
I understand that much attention has been drawn to something so apparently simple as naming, and yet we'll be stuck with the names for a long time, if things go as intended. How many have been annoyed by the "empty" member function's not emptying but indicating whether a container is empty? Similar mischances are likewise awkward, so it is not without value to consider names carefully. Furthermore, when names are not counter-intuitive to semantics, they assist in forming associations with actual semantics. We have discussed a great many other aspects along the way, so we're not entirely distracted by names, but it is worth settling soon to avoid further distraction.
However, this is the first naming proposal I've seen suggested that I *really* like, so +1 from me on this.
I'm please to get another opinion on the matter, if for no other reason than you agree with me!
FWIW, as far as the namespace is concerned, I think the entirety of the library should reside in the boost::endian namespace, and these two function templates should be brought into the boost namespace via using declarations.
That really is what I have meant, though I've expressed it as those names being in the boost namespace. Thanks for the clarification. _____ 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 (4)
-
Adam Merz -
Dave Handley -
Gottlob Frege -
Stewart, Robert