const QPointF points[] =
{
QPointF(r.left() - i, r.top() - i),
QPointF(r.right() + i, r.top() - i),
QPointF(r.right() + i, r.bottom() + i),
QPointF(r.left() - i, r.bottom() + i),
points[0] // is this line valid (according to the C++ standard)?
};
While this compiles with the MS Visual Studio Compiler, i am not sure if this is valid code according to the C++ Standard.
Quotes from the Standard would be highly appreciated.
Since there is no sequence point in the statement, the result is undefined, much like for the
i=i++
example quoted at that wikipedia page.Otherwise said, nothing specifies, whether the compiler should first evaluate everything, then assign, or do evaluate-assign for each element separately and in which order.
C++03/C++11 answer
No, it's not.
On the right-hand side of the
=
,points
does exist1 but the initialiser is only applied after all its operands have been evaluated.If
points
is at namespace scope (and thus has static storage duration and has been zero-initialized2), then this is "safe" but your use ofpoints[0]
there is going to give you0
, rather thanQPointF(r.left() - i, r.top() - i)
again.If
points
has automatic storage duration — it has not yet been initialised so your use ofpoints[0]
is attempting to use an uninitialised variable, wherepoints[0]
has an indeterminate value... which is bad3.It's difficult to provide standard references for this, other than to say that there is nothing in
8.5 "Initializers"
that explicitly makes this possible, and rules elsewhere fill in the rest.from http://www.comeaucomputing.com/pcgi-bin/compiler.cgi:
Old Answer (misses the point):
I checked the current C++0x draft, and there i found the sentence 8.5.1.17 which says:
So while this sentence is not part of the C++ Standard from 2003, im quite sure that this should be working in any up to date compiler, if this is part of C++0x.
Edit:
The comments made me rethink this matter. This line only ensures that the
QPointF
objects are created in the order in which they occur in the array initialization (relevant if the element constructors have observable side-effects). The problem is, the value ofpoints
is indeterminate during its array initialization. So there cant be a guarantee for a valid value ofpoints[0]
either, at least not if you rely on the standard.