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