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