|
Boost : |
From: David Abrahams (dave_at_[hidden])
Date: 2003-10-08 19:36:56
"E. Gladyshev" <egladysh_at_[hidden]> writes:
> --- Brock Peabody <brock.peabody_at_[hidden]> wrote:
>
>> > Good summary. I would prefer the second option.
>> > I think it should be possible to implement basic
>> > guarantees without the backup heap.
>> > The requirement says that variant should
>> > contain *a* value, so why do we need
>> > a backup heap. If we don't need a backup heap
>> > we don't have an issues with the first-type switch.
>>
>> I may be wrong, but I think they had already determined that there was no
>> way to get the basic guarantee for classes without no-throw copy
>> constructors unless they used the backup heap. I bet they would be thrilled
>> if you could prove them wrong :)
>
> I have to check the links that Dave pointed me to
> and think about it some more.
> But intuitevely the backup heap requirement doesn't seem
> to be necessary for the basic safety.
> If you have any references on why I am wrong, please
> let me know.
variant<std::vector<int>, std::string> v("hello");
v = std::vector<int>(3);
First you destroy the contained string, then you try to construct the
vector and it throws. The invariant says you have to contain either
a vector or a string, but you can't get the string back; it's likely
to throw on construction too.
The only way to maintain the basic guarantee in this case, with this
invariant, is to construct the vector, somewhere else, before
destroying the string... which means on the heap or in duplicate space
in the variant itself.
> Anyway if the heap is necessary, I would
> prefer the options 3 or 2 (doesn't matter which
> but with memory allocation policies).
> Option 1 doesn't seem to bad to me neither
> (let higher levels deal with the exception issues).
That's not possible. Once option 1 (no guarantees) lets the program
invariants break there's no way to restore them.
> I'd like to have a policy based solution.
Sheesh. You *do*. The policy is named empty_type.
-- 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