Re: What's the summary of N2855 - Rvalue References and Exception Safety?
On 2 Mai, 14:58, DeMarcus <use_my_alias_h...@hotmail.com> wrote:
I find the paper N2855 - Rvalue References and Exception Safety very promising.
http://www.open-std.org/Jtc1/sc22/WG21/docs/papers/2009/n2855.html
In the introduction of N2855 they deal with the problem that
the move operation may throw due to invocation of the copy
constructor when the move constructor T(T&&) is absent. In
the paper they locate such problems with Concepts, but now
in the absence of Concepts (that won't make it into C++0x),
Note that the follow-up paper
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3050.html
accepted for the current FCD can be considered
as the concept-free successor of n2855 (and going
even further).
what are the guidelines writing classes with
strong exception guarantee?
As of the current wording for e.g. std::vector you
will always get the strong guarantee unless the
value type has a potentially throwing move-constructor
and *no* copy-constructor. While the wording does not
require an implementation to use the new library
component std::move_if_noexcept to detect this
situation, it has to behave "as-if" doing so.
There is an additional situation, involved with
allocators in case of a swap function of the
container, see [container.requirements.general]/8+9,
e.g.
"The behavior of a call to a container?s swap
function is undefined unless the objects being
swapped have allocators that compare equal or
allocator_traits<allocator_type
>::propagate_on_container_swap::value is true."
and some similar situations, but I ignore this
for your thread, because it seems you are
discussion value types of containers.
If I make sure that I always provide the move
constructor along with the copy constructor,
will I be safe then?
You don't need a move constructor to realize
the strong exception guarantee. But if the
implementation cannot detect that your move
constructor is nothrow, it will use the
copy-constructor.
E.g.
class SomeClass
{
public:
SomeClass( const SomeClass& sc );
noexcept SomeClass( SomeClass&& sc );
Note that you are mis-positioning the noexcept
specification here, it must be added at the end
of the function declaration like so:
SomeClass( SomeClass&& sc ) noexcept;
[It follows the same rules as the dynamic
exception-specification]
};
This declaration helps an implementation
to use the move-constructor for even those
functions where otherwise the strong guarantee
would be critical. Thus, it doesn't help
or harm to violate the strong guarantee but
it ensures that the implementation can take
advantage of the move operation.
or
class SomeClass
{
public:
SomeClass( const SomeClass& sc ) = delete;
SomeClass( SomeClass&& sc ) = delete;
};
This type is basically unusable for most container
operations.
or
class SomeClass
{
public:
SomeClass( const SomeClass& sc ) = delete;
noexcept SomeClass( SomeClass&& sc );
};
or (will be caught by the compiler during move)
class SomeClass
{
public:
SomeClass( const SomeClass& sc );
SomeClass( SomeClass&& sc ) = delete;
};
but definitely *not* the following that would be easy to do by mistake
None of the deleted functions does help
to realize the strong guarantee, because
the corresponding function would not be
implicitly declared anyway in above
scenarios according to the core rules
defined in clause 12 [special].
class SomeClass
{
public:
SomeClass( const SomeClass& sc );
};
There is nothing wrong with this type, because
it does not have a move constructor (but a move
assignment operator), so it has the same strong
guarantee as a C++03 type.
Am I guaranteed to be safe if I always provide the move
constructor along with the copy constructor?
Speaking of value types, I believe yes, because
the implementation is required to use the copy
constructor, if the move constructor might
throw.
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! ]