Boost logo

Boost :

Subject: Re: [boost] [interprocess] default constructors
From: Mathias Gaunard (mathias.gaunard_at_[hidden])
Date: 2008-11-30 14:14:58


Ion Gaztañaga wrote :

> I don't think move should be implemented as swap, because the resource
> (shared memory) is still there floating around:

Indeed, but that is the only way to really keep the strong invariant of
one-way construction (which certainly is useful, since it allows optimal
object performance by avoiding tests for "emptiness" and leads to safer
code since operations on empty objects may not happen).
Using swap however may lead to delayed resource reclamation in
expressions introducing a lot of temporaries, which is the problem
you're refering to (albeit you're using casting to turn named variables
into temporaries, meaning the expression is their whole scope). I'm not
so sure it is that big an issue however, but your opinion may differ on
that subject, hence the alternative solution below.

Ideally, we would want destructive move semantics (move semantics where
the moved-from object is destructed when move is performed) but those
are not what C++0x provides, unfortunately.

> //other_shm will be in default-constructed state
> shm = move(other_shm)

Why must that state be the default-constructed one?
It could just be an unspecified private state than can only be reached
from a move, and where only the minimum required operations, such as
destruction, are valid.

However, that means potential overhead for those operations. And I
personally still do not know what operations are required to be valid on
moved-from objects, since that is badly specified, which means in the
worst case you have to support all assignment and copying scenarios
from/to moved-from objects.

That still provides all the safety of the original not move-aware
solution, but only if the user is careful about what he does to named
variables he has casted to temporaries once they have been moved,; seems
safe enough.
There is overhead, but only less than with allowing two-phase
construction, unless the rollback semantics are hard to maintain on
assignment due to exception safety issues (you might also choose not to
support them here and fall back to the moved state on failure).

You talked of containers; but since those are dynamically-sized
sequences of elements, it makes sense for them to be empty, i.e. to be a
sequence of 0 element. On the other hand, for a lot of other things,
being empty doesn't make much sense.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk