lack of implicit casting to T* and boost::shared_p tr::get()

[johanatan]

Does anyone know the reasons for the lack of an implicit casting
operator in any greater depth than:

A. Automatic conversion is believed to be too error prone.

(from the FAQ at the bottom of: http://www.boost.org/libs/smart_ptr/shared_ptr.htm)

Can anyone say specifically what about the implicit conversion would
be dangerous? I can think of a few things that would require care
about usage of smart pointers with implicit conversions, but nothing
that I would consider 'error-prone'.

In any language, there are implications and C++ certainly has its fair
share of other implicit behaviors.

[Ian Collins]

johanatan wrote:

Does anyone know the reasons for the lack of an implicit casting
operator in any greater depth than:

A. Automatic conversion is believed to be too error prone.

(from the FAQ at the bottom of: http://www.boost.org/libs/smart_ptr/shared_ptr.htm)

Can anyone say specifically what about the implicit conversion would
be dangerous? I can think of a few things that would require care
about usage of smart pointers with implicit conversions, but nothing
that I would consider 'error-prone'.

Ownership and reference counting issues? The last thing you want is for
the smart pointer to delete the object while something else still holds
a pointer to it.

One of the main reasons for using a smart pointer type is to manage the
lifetime of a object.

I've always avoided implicit conversions from smart pointers. Requiring
one is a design smell

--
Ian Collins.

[johanatan]

Ownership and reference counting issues? The last thing you want is for
the smart pointer to delete the object while something else still holds
a pointer to it.

That was one of the few things that I had thought of. But, requiring
a get() method does little to help with that. Aren't you always just
going to call get() and use dumb ptr as you would have if it were
implicitly converted? To think that this will somehow alleviate the
programmer from reasoning about such things is quite naive (and in
fact, it could be argued that it gives novice programmers a false
sense of security). You still have to be careful with what you do
with a ptr that you obtain through get() as well as one implicitly
converted.

One of the main reasons for using a smart pointer type is to manage the
lifetime of a object.

I've always avoided implicit conversions from smart pointers. Requiring
one is a design smell

I suppose our senses of smell are subjective then. :-) I don't think
that C++, the language, was ever designed to prevent programmers from
doing stupid things (and boost is definitely breaking with the
tradition of C++ on this one). If 'safety' is what you want, you
might be using the wrong language. Any type of casting operator
overload is going to be 'unsafe' by this definition (not just those
relating to smart ptrs).

I've thought quite a bit about this and the only somewhat reasonable
situation I could see it being an issue is when converting a large
project over from dumb ptrs to smart ptrs (and missing one of the
conversions). But, if you are writing code from scratch, why wouldn't
you just use the smart ptrs everywhere? Performance impact is
minimal. If you get a situation where you really need to optimize for
performance, then isolate the bottleneck and write in assembly or C.
If you are careful enough to think about using dumb ptrs here for perf
reasons or smart ptrs there for convenience, then you should be
careful enough to be 'safe' doing it.

[Richard Herring]

In message
<c3************ *************** *******@e23g200 0prf.googlegrou ps.com>,
johanatan <jo*******@gmai l.comwrites

>

>Ownership and reference counting issues? The last thing you want is for
the smart pointer to delete the object while something else still holds
a pointer to it.

That was one of the few things that I had thought of. But, requiring
a get() method does little to help with that. Aren't you always just
going to call get() and use dumb ptr as you would have if it were
implicitly converted?

No. Mostly you're going to call operator->() and not use get() at all.

To think that this will somehow alleviate the
programmer from reasoning about such things is quite naive (and in
fact, it could be argued that it gives novice programmers a false
sense of security). You still have to be careful with what you do
with a ptr that you obtain through get() as well as one implicitly
converted.

True, but on the whole once the raw pointer has been wrapped in the
smart one, you don't "obtain" the actual pointer at all, you use the ->
or * operators to access the pointed-to object.

>

>One of the main reasons for using a smart pointer type is to manage the
lifetime of a object.

I've always avoided implicit conversions from smart pointers. Requiring
one is a design smell

I suppose our senses of smell are subjective then. :-)

The problem with implicit conversion is that the smell only appears in
the declaration of the pointer class, not where the conversion gets
invoked. An explicit call of get() is highly visible in the code whereas
an implicit conversion is not.

I don't think
that C++, the language, was ever designed to prevent programmers from
doing stupid things (and boost is definitely breaking with the
tradition of C++ on this one). If 'safety' is what you want, you
might be using the wrong language. Any type of casting operator
overload is going to be 'unsafe' by this definition (not just those
relating to smart ptrs).

No doubt that's why many coding standards forbid them.

>I've thought quite a bit about this and the only somewhat reasonable
situation I could see it being an issue is when converting a large
project over from dumb ptrs to smart ptrs (and missing one of the
conversions) . But, if you are writing code from scratch, why wouldn't
you just use the smart ptrs everywhere?

Interfacing to legacy C-style libraries may require raw pointers. Other
than that, you're right - in which case, maybe you should be using a
smart pointer that has neither implicit conversion nor get().

>Performance impact is
minimal.

With any reasonable compiler, the performance impact of indirecting
through a smart pointer should be zero. It's only creating, copying and
deleting the pointers that has any overhead.

If you get a situation where you really need to optimize for
performance, then isolate the bottleneck and write in assembly or C.
If you are careful enough to think about using dumb ptrs here for perf
reasons or smart ptrs there for convenience, then you should be
careful enough to be 'safe' doing it.

And you're probably prematurely optimising anyway.

--
Richard Herring

[James Kanze]

On Jan 10, 3:47 pm, Richard Herring <ju**@[127.0.0.1]wrote:

[...]

With any reasonable compiler, the performance impact of
indirecting through a smart pointer should be zero. It's only
creating, copying and deleting the pointers that has any
overhead.

It depends. If the compiler doesn't see into the constructor of
the smart pointer, then it must assume that others can see it,
and modify it. That could affect optimization. (But it's hard
to imagine a scenario where the difference would be
significant.)

--
James Kanze (GABI Software) email:ja******* **@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[tragomaskhalos]

On Dec 20 2007, 4:28*am, johanatan <johana...@gmai l.comwrote:

>
I suppose our senses of smell are subjective then. :-) *I don't think
that C++, the language, was ever designed to prevent programmers from
doing stupid things (and boost is definitely breaking with the
tradition of C++ on this one). *If 'safety' is what you want, you
might be using the wrong language. *Any type of casting operator
overload is going to be 'unsafe' by this definition (not just those
relating to smart ptrs).

There's also history to consider. Back in the day, implicit
conversion operators were all the rage; years of experience
have made people aware of the pitfalls, few of which were
anticipated at the time. Hence e.g. std::string's has c_str()
whereas most pre-standard string libraries would provide an
operator const char*.
As a more general trend, of course, savvy C++ people are
moving away from the "unsafe" features of the language by
wrapping them in abstractions - even "naked" new/delete seems
to be frowned upon these days. The unsafe features are alive
and well, but are only used inside said abstractions which
are written by the more capable programmers, leaving the
ordinary rank and file with much less scope for doing the
wrong thing. So it's not that C++ might be the wrong language,
rather that one should be aware of how best practice C++
usage is evolving, with traditional patterns (that reflect
inexperience with the language and an over-reliance on C
idioms) being displaced by the safer/more robust ones that
have emerged over recent years.