Boost logo

Boost :

From: Dave Gomboc (dave_at_[hidden])
Date: 2003-09-01 01:13:11

> [Dave Abrahans]
> Optional is a container. I've never seen a container in C++ which didn't
> have both a value interface and an element-access interface. How do
> you propose to achieve that with optional?

It darn well shouldn't be a container, it should be a concrete type! ;-)

> [Joel de Guzman]
> One can think of an optional<T> as conceptually a specialized but
> nevertheless, *IS-A* T, with the added specialization that it can
> be in a dead-uninitialized state. Maybe we'll call it a zombie object,
> undead object, you name it ;-)

Indeed. However, I suppose I actually have it backwards, because I'm so
used to thinking about T. We know that the set of states T can take is a
proper subset of the set of states nilable<T> can take. This means that
when we want to write generic code it is sufficient to support nilable<T>:
with an implicit conversion from T to nilable<T>, support for T directly
will come along for free. (Or is it not possible to create such an
implicit conversion?)

I've been trying to set things up so that code is written for T that can
then also use nilable<T> seamlessly, but doing things the other way around
might be an improvement.

> [Brian McNamara]
> I was originally arguing with Joel because I thought he wanted to use
> exactly "nv" and not anything like "nv.get()". I think now that we've
> cleared up the confusion about get() returning a reference instead of a
> pointer, we're all back on the same page.

Well, I guess you're still arguing with me ;-) because I _do_ want to use
exactly "nv" and not anything like "nv.get()". I don't like get() because
I cannot write x.get() when x is a POD. This would mean I have to support
nilable<T> and T with different code, which is exactly what I'm trying to

I do agree that if there's a get(), it should return by reference.


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