Boost logo

Boost :

From: E. Gladyshev (egladysh_at_[hidden])
Date: 2003-10-08 19:18:08


--- 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.

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).

>
> > > My personal preference would be for (3). I'd take the performance
> > penalty
> > > (the double allocation?) to get the strong guarantee - just do the right
> > > thing you know.
> >
> > I agree with you in general, but IMO variant is a very basic type
> > that should be useable in application where performance is important.
>
> Yeah, you (and Dave) are certainly right about this. I was just wondering
> if some day it might be common to specify exception guarantee level via
> policy. I personally can't think of any places where I would care enough to
> change the default, but it seemed like an interesting idea.

I'd like to have a policy based solution.

Eugene

__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com


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