A question about smart pointer
Yong Hu
Thanks,
Daniel T.
"Yong Hu" <yhu2...@gmail.com> wrote:
> Does the smart pointer never lead to memory leak?
You can still get memory leaks even if you use smart pointers. Much
depends, of course on what the smart pointer does but I think all of
them are pretty susceptible to circular reference problems.
Phlip
> Does the smart pointer never lead to memory leak?
I will explain by comparing other languages. In C++, you must build smart
pointers and manage them carefully so they don't leak. If you use a raw
pointer to a 'new' object, you manage it more carefully or it will leak.
And you can create an object without 'new', and it has much lower odds of
leaking.
The language Java was designed to be sold to your boss. The designers want
to tell your boss, "if your programmers use Java, they will never leak
memory, like that naughty C++ language lets them leak."
So Java has built-in smart pointers. You cannot write the smart pointer
with Java - it's part of the language. And all objects must use smart
pointers. No object can create without a secret call to a kind of 'new'
function, deep inside Java.
And Java also leaks memory, plenty, if you abuse it or make many kinds of
mistakes.
In general, Garbage Collection is a very tough problem, and all languages
have compromises. All languages can leak. C++, even with smart pointers,
is higher risk than most languages because C++ lets you write safe code
that goes very fast.
--
Phlip
Richard Herring
Hu <yhu2...@gmail.com> writes
>Does the smart pointer never lead to memory leak?
>
The way to avoid memory leaks is to define a rigorous ownership policy,
and then consistently use the correct tools (which might be smart
pointers, or something else) to implement and enforce it.
--
Richard Herring
mlimber
> Does the smart pointer never lead to memory leak?
Of course not -- particularly because they can be misused. Does a seat
belt always prevent fatalities in auto accidents? No, especially if one
uses it improperly (e.g., laying down across the seat to which one is
belted). Nevertheless, smart pointers (and seat belts) can go a long
way toward improving safety, and smart pointers should usually be
preferred over manual memory management.
Cheers! --M
Axter
The circular reference problem is mostly associated with smart pointers
that have shared ownership logic.
std::auto_ptr does not have shared ownership logic.
And the following smart pointer uses clone ownership logic, and not
shared logic:
http://axter.com/smartptr/classcopy__ptr.htm
Some smart pointers can use either shared logic or clone ownership
logic, like the following policy based smart pointer:
http://axter.com/smartptr
mlimber
Right, and some have sole ownership semantics like std::tr1::scoped_ptr
(aka boost::scoped_ptr) which do not have problems with circular
references.
Cheers! --M
Chandu
Roland Pibinger
wrote:
>So Java has built-in smart pointers. You cannot write the smart pointer
>with Java - it's part of the language. And all objects must use smart
>pointers. No object can create without a secret call to a kind of 'new'
>function, deep inside Java.
Actually, that metaphor is more misleading than enlightening. Pointers
in C/C++ and refences in Java are ultra-lightweight objects that have
2 well-defined, language supported purposes: referencing and
dereferencing. "Smart" pointers in C++, OTOH, are objects that mimic
pointers but may perform some heavy task (eg. reference counting) in
the background which is something entirely different.
Best wishes,
Roland Pibinger
Howard Hinnant
"Chandu" <chandrashe...@gmail.com> wrote:
Of the six smart pointers in the list you referenced, two of them are in
the C++0X working draft: shared_ptr and weak_ptr.
In article <1151608804....@p79g2000cwp.googlegroups.com>,
"mlimber" <mli...@gmail.com> wrote:
> Right, and some have sole ownership semantics like std::tr1::scoped_ptr
> (aka boost::scoped_ptr) which do not have problems with circular
> references.
There is no std::tr1::scoped_ptr. There is only boost::scoped_ptr.
-Howard
Diego Martins
sorry, Java refs may have some way of ref counting too
Phlip
> Roland Pibinger wrote:
>> On Thu, 29 Jun 2006 16:12:41 GMT, Phlip <phli...@gEEEmail.com> wrote:
>> >So Java has built-in smart pointers. You cannot write the smart pointer
>> >with Java - it's part of the language. And all objects must use smart
>> >pointers. No object can create without a secret call to a kind of 'new'
>> >function, deep inside Java.
>>
>> Actually, that metaphor is more misleading than enlightening. Pointers
>> in C/C++ and refences in Java are ultra-lightweight objects that have 2
>> well-defined, language supported purposes: referencing and
>> dereferencing. "Smart" pointers in C++, OTOH, are objects that mimic
>> pointers but may perform some heavy task (eg. reference counting) in the
>> background which is something entirely different.
> sorry, Java refs may have some way of ref counting too
Java refs have more than two language-supported activities, but I decline
to determine what they are. (And I suspected that Java used
mark-and-sweep, where Python uses ref counting.)
The example is leading, for neophytes, because it introduces the general
topic of garbage collection.
It leads to the ideal that no smart pointer, no matter how smart or
language-supported, is utterly leak-proof.
--
Phlip
mlimber
> "mlimber" <mli...@gmail.com> wrote:
> > Right, and some have sole ownership semantics like std::tr1::scoped_ptr
> > (aka boost::scoped_ptr) which do not have problems with circular
> > references.
>
> There is no std::tr1::scoped_ptr. There is only boost::scoped_ptr.
I hadn't noticed that! Any idea why was it not included, too?
(According to http://boost.org/libs/smart_ptr/smart_ptr.htm#History,
the semantics of scoped_ptr were the original semantics for auto_ptr,
but the recommendation of Library Working Group was ignored and
transfer-of-ownership semantics were added to auto_ptr. I find the ToO
semantics quite useful at times, but at the same time adding scoped_ptr
in C++0x would seem to provide a smart pointer that is not susceptible
to accidental destructive copying and would thus serve as the usual
RAII resource manager. In that scheme, auto_ptr would be relegated only
to transferring ownership and would be rather inaptly named.)
Cheers! --M
Howard Hinnant
"mlimber" <mli...@gmail.com> wrote:
I can give only my personal opinion, and not anything official.
I am seeking to deprecate auto_ptr and replace it with unique_ptr:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1856.html#20.4.5
%20-%20Class%20template%20auto_ptr
The link above describes the motivation for deprecating auto_ptr. It
also introduces and completely describes unique_ptr as the safer
replacement. unique_ptr also offers ownership transfer like auto_ptr,
but not with copy syntax as auto_ptr does. Instead it uses move syntax
(which is easily searched for in source code). Given this, accidental
ownership transfer is no longer something to worry about. unique_ptr
functionality is a superset of boost::scoped_ptr, and not likely to be
accidently abused (as is auto_ptr). Thus I'm personally lacking
motivation to have a scoped_ptr in addition to unique_ptr.
Fwiw, here:
http://home.twcny.rr.com/hinnant/cpp_extensions/unique_ptr.html
are some minor improvements to the unique_ptr interface which have
surfaced since the publication of N1856 and which I hope to standardize
as well.
If you have use cases for scoped_ptr that unique_ptr is unsuitable to
fulfill, I would be most interested in hearing about them (so that
scoped_ptr could also be proposed for standardization, or so that
unique_ptr could be improved to meet those use cases). Or if you would
just like to question how unique_ptr would behave in certain contexts
(compared to scoped_ptr or auto_ptr), please feel free to ask me
(publicly or privately).
-Howard
Roland Pibinger
wrote:
>sorry, Java refs may have some way of ref counting too
Java has some language mechanisms that enable GC in general or weak
refernces in particular but calling those mechanisms "built-in smart
pointers" is, IMO, not appropriate.
Best wishes,
Roland Pibinger
mlimber
> I am seeking to deprecate auto_ptr and replace it with unique_ptr:
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1856.html#20.4.5
> %20-%20Class%20template%20auto_ptr
>
> The link above describes the motivation for deprecating auto_ptr. It
> also introduces and completely describes unique_ptr as the safer
> replacement. unique_ptr also offers ownership transfer like auto_ptr,
> but not with copy syntax as auto_ptr does. Instead it uses move syntax
> (which is easily searched for in source code). Given this, accidental
> ownership transfer is no longer something to worry about. unique_ptr
> functionality is a superset of boost::scoped_ptr, and not likely to be
> accidently abused (as is auto_ptr). Thus I'm personally lacking
> motivation to have a scoped_ptr in addition to unique_ptr.
That's good work. Do you have a hunch about whether auto_ptr will be
replaced by (or supplemented with) unique_ptr in C++0x?
> Fwiw, here:
>
> http://home.twcny.rr.com/hinnant/cpp_extensions/unique_ptr.html
>
> are some minor improvements to the unique_ptr interface which have
> surfaced since the publication of N1856 and which I hope to standardize
> as well.
>
> If you have use cases for scoped_ptr that unique_ptr is unsuitable to
> fulfill, I would be most interested in hearing about them (so that
> scoped_ptr could also be proposed for standardization, or so that
> unique_ptr could be improved to meet those use cases). Or if you would
> just like to question how unique_ptr would behave in certain contexts
> (compared to scoped_ptr or auto_ptr), please feel free to ask me
> (publicly or privately).
I don't see anything obvious. unique_ptr seems to cover all my uses for
scoped_ptr (and more).
Cheers! --M
Howard Hinnant
"mlimber" <mli...@gmail.com> wrote:
> Do you have a hunch about whether auto_ptr will be
> replaced by (or supplemented with) unique_ptr in C++0x?
I think the odds are a little better than 50/50 that we will deprecate
auto_ptr (not remove, just deprecate), and add unique_ptr (as specified
in N1856). When last reviewed (Oct. 2005), N1856 had strong support in
the LWG, pending acceptance of the rvalue reference language feature.
Rvalue reference has been approved by the EWG and is currently under
review by the CWG:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2011.htm
-Howard