Boost logo

Boost :

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-07-02 03:35:24

From: "Douglas Gregor" <gregod_at_[hidden]>

> I personally favor the first view, and therefore the name variant_cast.
> the variant type we're describing (I'll get to PyObject* in a moment...),
> think of the favorite expression example:
> class Plus;
> class Minus;
> typedef variant<Plus, Minus, double> expression;
> Does the 'expression' type contain an expression or is it an expression?
> textbooks would tell us to write the object hierarchy like this:
> class Expression { /* ... */ };
> class Plus : public Expression { /* ... */ };
> class Minus : public Expression { /* ... */ };
> class Literal : public Expression { /* ... */ };
> Why? Because Plus is-a(n) Expression, and a Literal is-a(n) Expression.

'xcept it ain't. There is no is-a relationship with variant. If there was,
I'd be able to pass a double* where an expression* was expected.
Structurally speaking you've got it inside-out, in fact. Given an
expression lvalue, we can get a double lvalue.

> With PyObject*, I think it is the same question. A PyObject* is a just a
> placeholder for a type we can't determine statically (like 'Expression'
> the hierarchy above).

Well, it might be multiple types. Probably is, in fact.

> When we know the type dynamically, we cast to that
> type, just like we would dynamic_cast in the OO style.
> PyObject*, variant, any -- they're all just union types. Is a union a
> container of one?

Yes! A union definitely does *not* present a logical is-a relationship.


Boost list run by bdawes at, gregod at, cpdaniel at, john at