Re: [boost] [endian] endian flip and endian domain

Subject: Re: [boost] [endian] endian flip and endian domain
From: Dave Handley (Dave.Handley_at_[hidden])
Date: 2010-06-08 13:28:04

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