Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > lack of implicit casting to T* and boost::shared_ptr::get()

Reply
Thread Tools

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

 
 
johanatan
Guest
Posts: n/a
 
      12-20-2007
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.
 
Reply With Quote
 
 
 
 
Ian Collins
Guest
Posts: n/a
 
      12-20-2007
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.
 
Reply With Quote
 
 
 
 
johanatan
Guest
Posts: n/a
 
      12-20-2007

> 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.
 
Reply With Quote
 
Richard Herring
Guest
Posts: n/a
 
      01-10-2008
In message
<(E-Mail Removed)>,
johanatan <(E-Mail Removed)> writes
>
>> 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
 
Reply With Quote
 
James Kanze
Guest
Posts: n/a
 
      01-10-2008
On Jan 10, 3:47 pm, Richard Herring <junk@[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:(E-Mail Removed)
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
 
Reply With Quote
 
tragomaskhalos
Guest
Posts: n/a
 
      01-10-2008
On Dec 20 2007, 4:28*am, johanatan <(E-Mail Removed)> wrote:
>
> 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.


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Up casting and down casting Sosuke C++ 2 12-20-2009 03:24 PM
Implicit casting on references kalki70 C++ 2 02-06-2007 07:31 PM
Templates & Implicit Casting Brian Byrne C++ 3 08-23-2005 09:26 AM
Another question about inheritance (up-casting and down-casting) kevin Java 11 01-08-2005 07:11 PM
Avoiding Implicit Casting Simon C Programming 9 10-06-2003 08:36 PM



Advertisments