Re: [boost] Why no non-null smart pointers?

From: Ross MacGregor (gordonrossmacgregor_at_[hidden])
Date: 2008-04-04 14:23:14

"Johan Råde" <rade_at_[hidden]> wrote in message 
news:ft10ag$6nn$1_at_ger.gmane.org...

>Your idea certainly could be useful.
>It should probably be combined with the Null Object Pattern.

Yes, it would be a way to enforce the Null Object Pattern.
Although one should only use null objects where they make sense.
Null objects should not be used to pass additional state 
information. If you create a find function that returns a null 
object if no items are found, you really gain nothing from using 
the pattern and the code will probably be more prone to error.

>However, having many different smart pointers would make it more
>difficult for different software components to interact with 
>each
>other.

Yes I think this variant of smart pointer will encounter 
resistance from the community because it is much easier to have 
only one shared_ptr to worry about. This is why we have the 
boost::shared_ptr and not a policy based one. The nullability 
attribute would fit nicely into a policy based smart pointer as 
the policy design avoids the complexity explosion of many 
separate classes.

Thinking about this some more, I think there may be a more 
fundamental problem at play here. I would suggest that smart 
pointers as we have come to know them are poorly designed. It's 
only natural that they evolved to reflect the capabilities of the
C++ pointer (indeed they are called smart POINTERS), but are the
semantics of C++ pointers a good idea in terms of a class 
interface? I would argue that they are not. A smart pointer fails 
the One Responsibility Rule regarding the its nullability.
Allowing a smart pointer to be null is an extra state carried by 
the class when it could be maintained by other means.

If we remove null capability from all smart pointers, essentially 
turning them into smart references, what do we do when we 
absolutely need to represent a reference that does not exist (or 
dare I say optional)? Well boost already has the answer. We use 
boost::optional; a template for representing optional values.
Using boost::optional would free us from a proliferation of smart 
pointers (nullable and not) and usability concerns.

I'm sure no one is going argue that optional<int> creates too 
much interface friction because int is used commonly as component 
interface type. Therefore optional<WidgetRef> should not create 
problems for components that use WidgetRef.

I know it is an insane idea to suggest changing the entire 
boost::smart_ptr library to a boost::smart_ref libary, but I 
think it may actually be the right thing to do. Does anyone 
agree?

-Ross