On 05/10/15 10:49, Dmitry Olshansky wrote:
Yes and no, if your type is movable in C++ you have to have a T.init
equivalent to leave something behind after move (oops!).
No, under C++ you can choose whether it makes sense for your type to be
movable or not. No oops at all.
C++ does not make any attempt to protect you from your own incompetence.
Within that assumption (which some people accept as reasonable and
others don't), C++ does the right thing.
Now if the type is not movable it doesn't really burden much to have an
invalid state and trigger an assert in dtor to make sure the type is
properly initialized. Then:
T a; // would trigger assert on dtor
T a = T(...); // shouldn't
But how will you detect whether the type has been properly constructed
or not?
If all states are valid and you still want to guarantee construction
that gets tricky. For example for "seconds" struct if we allow negative
seconds as in diff of time. (Though I'd just use long.min for the
"wrong" flag in this case).
But that is a very strong aspect of the C++ paradigm. Saying "you can
engineer a type that is valid at any point it is in scope, enforced by
the compiler". In fact, it was such a fundamental part of the C++ design
that Strastrup had to change a long standing C constraint (variables are
only defined at the start of the scope) in order to support it. That
change, like many others, has found its way back into C99, so many
people today don't even realize it was ever there.
Shachar
