Re: [boost] [interprocess] default constructors

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.