Re: assignment of std::valarray
On 25 Aug., 19:28, backminator <backmina...@gmail.com> wrote:
Hi all.
Im trying to parse the C++0x documentation related to the assignment
of std::valarray.
This code is tested under g++ 4.4.3, VisualStudio2008 and finally
VS2010.
Three examples of assigning one valarray to another:
1. Pure assignment
std::valarray<int> a(2), b(2);
std::cerr << &(a[0]) << std::endl;
a = b;
std::cerr << &(a[0]) << std::endl;
2. Negation + assignment
std::cerr << &(a[0]) << std::endl;
a = -b;
std::cerr << &(a[0]) << std::endl;
3. Computed assignment:
std::cerr << &(a[0]) << std::endl;
a -= b;
std::cerr << &(a[0]) << std::endl;
g++: same pointer adress for &(a[0]) is reported before and after in
all the above examples.
vs2008: dito
vs2010: Example 2 (Negation+assignment), results in a different adress
before and after the assignment.
Now to my question, what does the standard say about this?
26.6.2.6:
"The appearance of an array on the left-hand side of a computed
assignment does not invalidate references or pointers."
Yes, this is 26.6.2.6/4 in the FCD and 26.3.2.6/8 in
the 2003 C++ Standard.
Does not invalidate, does that mean change?
The way you ask causes a knot in my brain, therefore:
Your above quoted paragraph guarantees that your test
program should return equal addresses before and after
the computed assignment, but that would only hold for
your example 3, which seems not to be affected by the
change.
Example 1 belongs clearly to the domain of 26.6.2.2,
valarray<T>& operator=(const valarray<T>& v);
and no such guarantee is given, i.e. your assumptions
may break for any new version of your library.
Assuming that vs2010 has already made valarray
rvalue-capable, the compiler should either select
valarray<T>& operator=(valarray<T>&&);
or another overload as of the anti-aliasing guarantees
given in 26.6.1/3+4, but with equivalent semantics
[In fact the standard does not really say that, but
that is the most reasonable ad-hoc interpretation].
The standard does not require that the copy/move
assignment operator will guarantee that your test
case holds. In fact, for a move operation it is
rather probable, that the operation is simply
a swap between the internal pointers of source
and target, which would have the observed effects.
Side note: We should be rather thankful, that C++03
did *not* guarantee that an assignment without reason
for a resize does not invalidate pointers and
references: This ensured that the introduction of
move semantics as of C++0x did not silently break these
guarantees.
HTH & Greetings from Bremen,
Daniel Kr?gler
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]