From: Fernando Cacciola (fernando_cacciola_at_[hidden])
Date: 2002-12-13 17:09:39
"Augustus Saunders" <infinite_8_monkey_at_[hidden]> wrote in message
> Fernando Cacciola wrote:
> >And pointers have historically been used to deal with optional
> >objects precisely because they model this concept.
> I think this is important, and so I want to dwell on it for a moment.
> For many years, if a programmer needed optional functionality, she
> used a pointer. There are a large number of existing libraries and
> APIs that use pointers to convey exactly this notion. A pointer is
> essentially a defacto standard for this usage.
> Consider one more time, why do iterators look like pointers? I
> wouldn't be surprised if a similar discussion took place back in the
> A: "I've got it! Make iterators look like pointers!"
> B: "Hmm... That might confuse people. They aren't really pointers."
> A: "You're right, some operators won't work on iterators."
> C: "On the other hand, it would be convenient."
> A: "Exactly! "
> A,B,C: (thinks real hard)
> C: "Also, if we make iterators look like pointers, then we can write
> generic code that takes either. That way, we can interface to legacy
> systems with generic code."
> Eventually, they come up with concepts, which at the time I'm sure
> was a radical idea. If there weren't already a large number of
> libraries that use this idiom, then generic code wouldn't really
> Yes, this generic code is hypothetical right now. Since the
> OptionalValue concept has not been defined, nobody has tried to use
> it. If we do define it and release it into the wild, will it lead to
> better libraries? Consider your OS of choice's system APIs. How
> many functions take or return pointers for this purpose?
> Please do not dismiss the pointer interface until you have considered
> this. And remember that if you push hard enough, you will discover
> that smart pointers and iterators aren't really pointers. The
> equivalence doesn't need to be absolute; just *useful* and *safe*.
I couldn't agree more.
In fact, I think the OptionalValue concept has been implicitly defined for
decades and this is why I prefer the pointer-like interface even if it
requires the poisoned relops.
I realize now that part of the confusion was introduced by the poor
documentation which didn't set the concepts straight. (which of course was a
direct reflex of my poor understanding of the issues)
Thanks to the clear arguments made by the reviewers, I see the picture a lot
more clear now.
Specially the fact that optional<> is itself a container, or perhaps, a
union of T and nil_t.
But your previous post were you developed those concepts were very helpful
as an argument to keep the pointer-like interface.
I have a deeper understanding of the issues involved now and I'm deeply
reworking the documentation.
Of course, I will formally present the OptionalValue concept on the
documentation, and you will be credited for that :-)
-- Fernando Cacciola
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk