Re: [boost] [boost::endian] Request for comments/interest

Subject: Re: [boost] [boost::endian] Request for comments/interest
From: Terry Golubiewski (tjgolubi_at_[hidden])
Date: 2010-06-03 01:21:15

> However, there is a much bigger problem with all of the examples using 
> copy,
> please see point 25.2.1 bullet 3 below from the C++ standard:
>
> 25.2.1 Copy [lib.alg.copy]
> template<class InputIterator, class OutputIterator>
> OutputIterator copy(InputIterator first, InputIterator last,
> OutputIterator result);
> 1 Effects: Copies elements in the range [first, last) into the range 
> [result,
> result + (last
> - first)) starting from first and proceeding to last. For each 
> non-negative
> integer n <
> (last-first), performs *(result + n) = *(first + n).
> 2 Returns: result + (last - first).
> *3 Requires: result shall not be in the range [first, last).*
>
> Unless I am missing something, I don't see why you are implementing
> swap_in_place *on top* of the endian types. That just seems backwards to 
> me
> (other than being illegal)
>
> Is there a fundamental design issue you can see by implementing the endian 
> types
> on top of the functional primitives?
>
> Tom

I'm implementing swap-in-place on top of endian types to compare that 
approach to yours.
I would **never** do that in practice (unless I really need to ;o) ).

I had to make special versions of copy that allowed the destination to be 
the same as the source.

Yes, I think swapping the bytes underneath an object in place is a very bad 
design practice.
You can get some performance gain by doing it though, as I recently found 
out.  I was unable to match the swap-in-place performance using my typed 
approach.
I'm not really sure why not though.
But my experiments suggest that if you try to implement a typed-endian 
interface on top of a swapping one, then you suffer an even worse 
performance penalty.

terry