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

Discussion in 'C++' started by johanatan, Dec 20, 2007.

  1. johanatan

    johanatan Guest

    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.
    johanatan, Dec 20, 2007
    #1
    1. Advertising

  2. johanatan

    Ian Collins Guest

    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.
    Ian Collins, Dec 20, 2007
    #2
    1. Advertising

  3. johanatan

    johanatan Guest


    > 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.
    johanatan, Dec 20, 2007
    #3
  4. In message
    <>,
    johanatan <> 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
    Richard Herring, Jan 10, 2008
    #4
  5. johanatan

    James Kanze Guest

    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:
    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
    James Kanze, Jan 10, 2008
    #5
  6. On Dec 20 2007, 4:28 am, johanatan <> 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.
    tragomaskhalos, Jan 10, 2008
    #6
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Derek
    Replies:
    2
    Views:
    617
    Derek
    Dec 8, 2003
  2. Ryan Mitchley
    Replies:
    6
    Views:
    11,116
    Maxim Yegorushkin
    Jun 26, 2004
  3. =?UTF-8?B?UmFmYcWCIE1haiBSYWYyNTY=?=

    boost::weak_ptr and shared_ptr pointers from "this"

    =?UTF-8?B?UmFmYcWCIE1haiBSYWYyNTY=?=, Apr 5, 2006, in forum: C++
    Replies:
    2
    Views:
    1,213
    Joe Gottman
    Apr 6, 2006
  4. Toby Bradshaw
    Replies:
    6
    Views:
    1,723
    Kai-Uwe Bux
    Jun 2, 2006
  5. Colin Caughie
    Replies:
    1
    Views:
    693
    Shooting
    Aug 29, 2006
Loading...

Share This Page