Re: boost weak pointers and boost optional
Thant Tessman wrote:
Peter Dimov wrote:
Your legitimate goal is obviously to avoid the possibility of
dereferencing a null pointer. Can you show the user code that
accomplishes it? Change the interface of .lock any way you like.
(boost::optional<> doesn't work, because you can dereference an empty
optional<>.)
Yes, I figured that out after I sent the original message. I'm used to
thinking of an 'optional' as an instance of a variant containing two
types: void, and T.
I actually agree with that point of view, and I was surprised that I
couldn't create a variant<void,foo,bar> in the past sometimes.
In the case of weak pointers, it would have to look more like:
struct nothing {};
template <typename T>
struct weak_pointer {
[...]
typename boost::variant<nothing,shared_ptr<T> > Optional;
Optional lock() const;
[...]
}
This still doesn't change anything. You still have to check the returned
value, only that now you have an object that needs to hold an identifier
for the type (i.e. whether it's a 'nothing' or 'shared_ptr<T>') plus the
shared_ptr payload, i.e. you just introduced additional overhead. And the
pointer can still be null, too!
You could perhaps introduce a nonnull_shared_ptr, which guarantees that it
is not null. However, replacing shared_ptr in the original weak_ptr with
variant<nothing,nonnull_shared_ptr> only shifts the syntax, you replace a
type with a distinct signal value with another type with a distinct signal
value, only that they look a bit different.
weak_ptr's lock() can yield an object or not, so you must check the
returnvalue. There is only one way you can change that, and that is when
you don't return if there is no object but rather throw an exception.
Anything else will only shift the syntax in this or that direction, but the
fundamental fact that you must check the returnvalue remains.
Further, there is nothing that makes using variant<> any different than
using optional<>, except that the syntax is different. You still have to
check what is contained and you still have a content that already reserves
one signal value to mean "no object" (the null pointer).
BTW: I agree that reserving the meaning of zero to mean "invalid address" is
unfortunate in some contexts, in particular because it actually is a valid
address that can be written to (BTW: I heard of a compiler that used the
actual address 0xffff as null pointer value, for exactly those reasons). In
fact any conceivable pointer value on most machines could be an address of
writable and readable memory, so a signal value would have to extend the
valid range, e.g. using optional<>. However, that wasn't available when the
design for pointers was laid...
Uli
--
Sator Laser GmbH
Gesch??ftsf??hrer: Thorsten F??cking, Amtsgericht Hamburg HR B62 932
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]