From: Greg Colvin (gcolvin_at_[hidden])
Date: 1999-12-05 14:45:01
From: Darin Adler <darin_at_[hidden]>
> An alternative is to have the default constructor construct an instance of
> the pointed-to type with (new and) its default constructor. I'm not sure if
> that's a good idea either; seems it might be a bit inefficient.
The efficiency worries me some, especially the case of creating a
big empty array to fill in later. Also, I'm just not so afraid of
nulls that I'd pay much price to be rid of them -- and I've done
lots of coding on a platform where writing to address zero would
overwrite the system interrupt vector.
> What I meant is that you don't get at the value of the "optional strong
> pointer" without first checking if it is null. After you do that, you call
> "get()" and it returns a "strong pointer".
I see. We are diverging from the current shared_ptr interface.
> When I say the interface "promotes checking for null", I mean that it
> promotes a style with explicit checks for null in the client code. It would
> be considered bad style to dereference an optional pointer (yielding a
> non-optional one) without checking for null explicitly just before that.
Unless your design is such that it can't be null at that point,
in which case an assertion is called for, but not a runtime
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk