$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
Subject: Re: [boost] [boost::endian] Request for comments/interest
From: Tomas Puverle (tomas.puverle_at_[hidden])
Date: 2010-06-02 09:53:23
> swap_in_place<big>(data);
>
> This swap_in_place is a no-op if native is big.
A no-op in what respect? I (might) give you that there will be no observable
state change. But from a runtime perspective, I don't agree.
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