[boost] Variant Library: variant size and strong guaranty

From: Gennadiy Rozental (gennadiy.rozental_at_[hidden])
Date: 2003-04-02 02:24:04

> > 7. Variant size
> > Unfortunately I was not able to follow exact logic behind usage of 2
> > different storages. But one thing I know:
> > sizeof(boost::variant<int,std::string>) could not be 28.
> > >From what I view it seems that types that are used to construct
> > storage2 also used when constructed storage1. So we definitely have
> > size duplication here.
>
> The two storages implement Anthony William's "double storage"
> technique. (See
> http://aspn.activestate.com/ASPN/Mail/Message/boost/1314807 for an
> overview.) This technique is necessary to provide a general guarantee
> of strong exception-safety, which in turn is necessary to maintain
> a "never empty" invariant for variant.

What is this invariant? And why is it that important.

>From what I see in above message, Anthony clearly indicate that here we have
a tradeoff between strong guaranty and doubled variant size. Not arguing the
importance of strong guaranty I still believe you are not allowed to make
this important decision for the Variant library users. We either need to
find a different way to implement boost::variant with strong guaranty or
need to provide a way for the user to decide what is more important. BTW why
do you need to carry this second storage all the way through the variant
object lifetime. Why couldn't you use stack allocated buffer in copy/assign
methods?

> In regard to the particularly large size you report, I believe it
> results from a problem either with boost::type_with_alignment itself or
> with my understanding of it. Thus, I am aware of the problem, but I am
> still determining how best to address it.

I think this should be resolved before boost::variant is going in release.

> > Separate issue is the type of which field. Having it as int is an
> > overkill. It would be enough in majority of the cases have char. But
> > we should be able to deduce the correct type depends on number of
> > argument types.
>
> You're probably right: I doubt more than 127 types will ever be needed.
> Still, this is an implementation issue, and variant::which() will
> return int.

This is implementation issue that affect the library design (it affects an
abstraction overhead). So it's as important as issues above.

Gennadiy