|
Boost : |
From: David Abrahams (dave_at_[hidden])
Date: 2003-10-28 21:10:38
Eric Friedman <ebf_at_[hidden]> writes:
> Eugene,
>
> E. Gladyshev wrote:
>> Also, I mentioned it to Eric that the current implementation doesn't
>> actually provide basic guarantees. He was going to look into that.
>
> Are you referring to the following problem?
>
> T f();
>
> class my_type
> {
> T t_;
> public:
> my_type() { }
> my_type(const my_type& other)
> : t_( f() )
> {
> }
> };
>
> variant< int, my_type > v;
>
> int main()
> {
> my_type m1;
>
> my_type m2 = m1; // ok
> v = m1; // potentially undefined: does f visit v?
> }
This case is a red herring. This is why:
std::vector<char> storage;
void* operator new(size_t x);
int main()
{
std::vector<char> storage2(10,'a');
storage = storage2; // potentially undefined: does my custom
// operator new try to use storage?
};
This problem doesn't change the fact that std::vector assignment gives
the basic guarantee. Any class is allowed to break its own invariants
temporarily during the execution of its member functions. You can
always arrange for the broken state to be exposed to a component which
is invoked from that member function as long as the invoked component
has another reference to the object being modified.
This is not a problem which needs to be solved.
-- Dave Abrahams Boost Consulting www.boost-consulting.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk