[boost] Re: implicit smart pointer conversions

From: Dave Abrahams (abrahams_at_[hidden])
Date: 2000-03-19 19:53:00

on 3/19/00 6:48 PM, Beman Dawes at beman_at_[hidden] wrote:

> At 01:37 AM 3/19/00 -0800, Nathan Myers wrote:
> 
>> Indeed, some of us argued for naming them member of auto_ptr<> that
>> reveals the raw pointer value "auto_ptr<>::leak()".  To me it seems
>> a grave, grave design error to provide an automatic conversion for
>> that purpose.  Automatic conversions are dangerous enough in general,
>> but when they contradict the base purpose of the component, it makes
>> me wonder why somebody wants such a component at all.
> 
> Because it hides details.  Because it makes code more readable.
> Secondarily, because it makes smart pointers behave more like real pointers.
> 
> It is an issue of writing code for compilers versus writing code for human
> readers.
> 
> Nathan, you have been a real leader when it comes to teaching people to
> avoid harmful implicit conversions, but it seems to me this is a grey case
> when the advantages may balance out the disadvantages.

What's needed here are examples.  We programmers often come up with a rule
about what works, what is appropriate or dangerous, that is based on real
experiences but doesn't generalize well. Our science involves continually
refining our theories to match observations. Unlike other scientists we
often cling to our theories long after they've become obsolete.

Here's one:
A junior programmer I work with recently had me review his smart pointer
class that included an implicit conversion. The purpose of the class was to
hold a Python object (which, by the way, is intrusively counted). My first
reaction was to treat the implicit conversion with extreme suspicion, but we
went through the analysis of the upsides and potential downsides and came up
clearly in favor of allowing the conversion. The pointers being held would
often need to be passed (raw) back to Python API functions. Requiring
explicit get() calls would have interfered with the readability and
maintainability of code using the pointer. We couldn't find any serious
downsides to allowing the conversion.

I still think my initial extreme suspicion was the appropriate reaction, and
I still think we made the right choice in this case. Nathan's theory is
appealingly simple; unfortunately, I have nothing to offer as an alternative
other than "use good judgement".

Whether or not this anecdote should be applied to boost smart pointers
remains to be seen. In part, it may depend on who we think our customers
are.

I would like to see examples which contradict this one, even if they are
contrived. This is not meant as a challenge, but as a way of furthering the
discussion.

-Dave