A question about smart pointer

[Yong Hu]

Does the smart pointer never lead to memory leak?

Thanks,

[Daniel T.]

In article <11**********************@75g2000cwc.googlegroups. com>,
"Yong Hu" <yh*******@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]

Yong Hu wrote:

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]

In message <11**********************@75g2000cwc.googlegroups. com>, Yong
Hu <yh*******@gmail.com> writes

Does the smart pointer never lead to memory leak?

It's "smart", not "magic".

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]

Yong Hu wrote:

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]

Daniel T. wrote:

In article <11**********************@75g2000cwc.googlegroups. com>,
"Yong Hu" <yh*******@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.

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]

Axter wrote:

Daniel T. wrote:

In article <11**********************@75g2000cwc.googlegroups. com>,
"Yong Hu" <yh*******@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.

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

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]

Please check
http://www.boost.org/libs/smart_ptr/smart_ptr.htm

They are already part of C++0x

[Roland Pibinger]

On Thu, 29 Jun 2006 16:12:41 GMT, Phlip <ph*******@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.

Best wishes,
Roland Pibinger

[Howard Hinnant]

In article <11**********************@d56g2000cwd.googlegroups .com>,
"Chandu" <ch******************@gmail.com> wrote:

Please check
http://www.boost.org/libs/smart_ptr/smart_ptr.htm

They are already part of C++0x
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 <11*********************@p79g2000cwp.googlegroups. com>,
"mlimber" <ml*****@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]

Roland Pibinger wrote:

On Thu, 29 Jun 2006 16:12:41 GMT, Phlip <ph*******@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.

Best wishes,
Roland Pibinger

sorry, Java refs may have some way of ref counting too

[Phlip]

Diego Martins wrote:

Roland Pibinger wrote:

On Thu, 29 Jun 2006 16:12:41 GMT, Phlip <ph*******@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]

Howard Hinnant wrote:

"mlimber" <ml*****@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]

In article <11**********************@h44g2000cwa.googlegroups .com>,
"mlimber" <ml*****@gmail.com> wrote:

Howard Hinnant wrote:

"mlimber" <ml*****@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.)

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/wg...56.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...nique_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]

On 30 Jun 2006 13:16:36 -0700, "Diego Martins" <jo********@gmail.com>
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]

Howard Hinnant wrote:

I am seeking to deprecate auto_ptr and replace it with unique_ptr:

http://www.open-std.org/jtc1/sc22/wg...56.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...nique_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]

In article <11**********************@p79g2000cwp.googlegroups .com>,
"mlimber" <ml*****@gmail.comwrote:

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/wg...2006/n2011.htm

-Howard