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.