Re: [boost] Re: Variant implementation change (was re: unions) final summary

From: Brian McNamara (lorgon_at_[hidden])
Date: 2003-10-10 01:27:59

On Thu, Oct 09, 2003 at 10:53:22PM -0700, E. Gladyshev wrote:
> Of course I read the standard and I reread 12.6.2 
> it is not relevant to reusing storage.
> What is relevant is 3.7.4

I am not a language lawyer (at least not today), so I won't get into
this portion of the discussion.  I just wanted to share one other quick
thought, and then I am 'bowing out' of this thread, too.

Regardless of what the standard actually says, the people who wrote it
presumably chose to wrote it the way they did because of some intent.
I wasn't there when it was written, so I can only speculate about the
intent.  I am going to do that right now.

I speculate that perhaps the reason all of the "object lifetime" and
"reusing storage" stuff is written the way it is in the standard is to
specifically prohibit people from treating non-POD objects as a "bag of
bits", in order to allow for, e.g., implementations which automagically
garbage-collect (GC) all non-POD objects.

Consider a GCing C++ implementation.  The compiler does some magic,
instrumenting constructors and destructors and such, in order to be able
to always know where all the non-POD objects in the system live.
Hopefully now the problem with treating an object as a bag-of-bits is
obvious: you have broken an invariant the implementation relies upon.
Specifically, in your variant implementation, imagine that, the moment
after moving the bits from a T1 object off the side, and moving the
bits of a T2 object into the same location, the collector kicks in.
Perhaps it's a mark-and-sweep collector, and it traces through all the
objects in the system to find live data.  When it comes to the memory
location we are messing with inside variant, it expects a T1 object to
live in those bits.  Sadly, this is not the case; the bit pattern
corresponds to the representation of a T2 object instead.  The
collector gets all fouled up now, and if we're lucky, our program will
crash soon afterwards.

The point is, I think the standard writers intended for your variant
implementation to be illegal.  I do not think they had such an
intention because they wanted to frustrate you or because they wanted
to make an efficient variant implementation difficult/impossible.
Rather, I think they had this intention because they foresaw unusual
future implementations of C++ (e.g. GCing ones), and they realized that
disallowing the bag-of-bits treatment of objects would enable other
useful things.  I think they faced a trade-off, and they made an
explicit choice to go one way rather than the other.  The way they went
makes it possible to implement (e.g.) GCing C++ implementations, at the
cost of making it harder to implement variant.

This is all speculation.  The point is that I wanted to give one
possible "big picture" view, as no one will get anywhere by arguing all
the ticky-tack details about what section 12.3.7.4 of the standard says
or doesn't say.

-- 
-Brian McNamara (lorgon_at_[hidden])