Someone made the statement in a newsgroup that most C++ programmers use
smart pointers. His actual phrase was "most of us" but I really don't think
that most C++ programmers use smart pointers, but I just don't know.
I don't like them because I don't trust them. I use new and delete on pure
pointers instead.
Do you use smart pointers?
92  4987 
Jim Langston wrote:
Someone made the statement in a newsgroup that most C++ programmers
use smart pointers. His actual phrase was "most of us" but I really
don't think that most C++ programmers use smart pointers, but I just
don't know.
I don't like them because I don't trust them. I use new and delete
on pure pointers instead.
Do you use smart pointers?
Yes.
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
Does smart pointer use too many resource?
Victor Bazarov wrote:
Jim Langston wrote:
Someone made the statement in a newsgroup that most C++ programmers
use smart pointers. His actual phrase was "most of us" but I really
don't think that most C++ programmers use smart pointers, but I just
don't know.
I don't like them because I don't trust them. I use new and delete
on pure pointers instead.
Do you use smart pointers?
Yes.
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
Jim Langston wrote:
Someone made the statement in a newsgroup that most C++ programmers use
smart pointers. His actual phrase was "most of us" but I really don't think
that most C++ programmers use smart pointers, but I just don't know.
I don't like them because I don't trust them. I use new and delete on pure
pointers instead.
Do you use smart pointers?
Yes, from the Standard Library, from boost, and custom.
Best regards,
Tom
Mingming wrote:
Does smart pointer use too many resource?
No.
Best regards,
Tom
Jim Langston wrote:
Someone made the statement in a newsgroup that most C++ programmers use
smart pointers. His actual phrase was "most of us" but I really don't think
that most C++ programmers use smart pointers, but I just don't know.
I don't like them because I don't trust them. I use new and delete on pure
pointers instead.
Do you use smart pointers?
Whenever possible (which is most of the time), yes.
Cheers! --M
Do you use smart pointers?
No, because I don't trust myself to use them right. Besides I never had
a real need for them.
Regards,
Thomas Kowalski
"Mingming" <xm******@gmail.comschrieb im Newsbeitrag
news:11*********************@m7g2000cwm.googlegrou ps.com...
Does smart pointer use too many resource?
No, but debugging problems with raw pointers does use too many of MY
resources.
Heinz
"Jim Langston" <ta*******@rocketmail.comschrieb im Newsbeitrag
news:xU*************@newsfe04.lga...
Someone made the statement in a newsgroup that most C++ programmers use
smart pointers. His actual phrase was "most of us" but I really don't
think that most C++ programmers use smart pointers, but I just don't know.
I don't like them because I don't trust them. I use new and delete on
pure pointers instead.
Then write your own implementation. And if you don't trust yourself then,
how can you trust yourself when using raw pointers?
Do you use smart pointers?
Yes.
Heinz
Jim Langston wrote:
Someone made the statement in a newsgroup that most C++ programmers use
smart pointers. His actual phrase was "most of us" but I really don't
think that most C++ programmers use smart pointers, but I just don't know.
Correct use of smart pointers is part of knowing C++. The language cannot
rely on just its raw keywords, or on its Standard Library. C++ also requires
a corpus of "sane subset" guidelines to use correctly, to write flexible
code with low risk.
I don't like them because I don't trust them. I use new and delete on
pure pointers instead.
Do your colleagues approve? Don't you ever leak?
(Note I don't claim my colleagues approve of my smart pointers, or that I
never leak!;)
--
Phlip http://www.greencheese.us/ZeekLand <-- NOT a blog!!!
Mingming wrote:
Does smart pointer use too many resource?
Premature optimization is the root of all evil.
(Google for that sentence!)
Small smart pointers are the same size as pointers, and they insert opcodes
to call 'delete' into all the places where you should have coded 'delete'.
So their resource impact is minimal.
--
Phlip http://www.greencheese.us/ZeekLand <-- NOT a blog!!!
Heinz Ozwirk wrote:
>I don't like them because I don't trust them. I use new and delete on
pure pointers instead.
Then write your own implementation. And if you don't trust yourself then,
how can you trust yourself when using raw pointers?
Next tip: Always fold duplicated code into reusable abstractions. So put
your many 'delete's into one place and reuse it. The destructor of a smart
pointer.
Next tip: Prefer automatic and member objects over heap objects. ;-)
--
Phlip http://www.greencheese.us/ZeekLand <-- NOT a blog!!!
Jim Langston wrote:
Someone made the statement in a newsgroup that most C++ programmers use
smart pointers. His actual phrase was "most of us" but I really don't
think that most C++ programmers use smart pointers, but I just don't know.
I don't like them because I don't trust them.
Care to explain why you don't trust them?
I use new and delete on pure pointers instead.
Do you use smart pointers?
Yes. I made it a point to eliminate raw pointers from most of my code: I
even have a pointer_to<T,Alloctemplate that just wraps a raw pointer. It
does not add much: a hook for a custom allocator (defaults to new/delete)
and a compile time check against the use of polymorphic pointers when the
underlying base type has no virtual destructor.
Another smart pointer that I use for debugging is a drop in replacement for
pointer_to<that traces allocations and deallocations and helps in
diagnosing memory leaks and double deletion.
I use reference counted smart pointers for managing shared resources that
shall be released when the last co-owner dies.
Best
Kai-Uwe Bux
"Phlip" <ph******@yahoo.comwrote in message
news:7o*****************@newssvr25.news.prodigy.ne t...
Jim Langston wrote:
>Someone made the statement in a newsgroup that most C++ programmers use
smart pointers. His actual phrase was "most of us" but I really don't
think that most C++ programmers use smart pointers, but I just don't
know.
Correct use of smart pointers is part of knowing C++. The language cannot
rely on just its raw keywords, or on its Standard Library. C++ also
requires a corpus of "sane subset" guidelines to use correctly, to write
flexible code with low risk.
>I don't like them because I don't trust them. I use new and delete on
pure pointers instead.
Do your colleagues approve? Don't you ever leak?
(Note I don't claim my colleagues approve of my smart pointers, or that I
never leak!;)
I leak sometimes, but that's why they invented Ptr_Depends, the smart
pointer guaranteed to stop those embarassing leaks!
(Sorry, couldn't resist.)
-Howard
Jim Langston wrote:
Someone made the statement in a newsgroup that most C++ programmers use
smart pointers. His actual phrase was "most of us" but I really don't think
that most C++ programmers use smart pointers, but I just don't know.
I don't like them because I don't trust them. I use new and delete on pure
pointers instead.
That is absolute rubbish. You should trust library code which has been
tested by lots of users all over the world and distrust other code -
including your own.
>
Do you use smart pointers?
Whenever I can. I am working on a very old codebase right now, and
there are raw pointers here and there. I do intend to replace all raw
pointers (to an extent that I will not find a delete in the "user"-code
anywhere).
Unfortunately, theres still a long way to go.
/Peter
"peter koch" <pe***************@gmail.comwrote in message
news:11*********************@m7g2000cwm.googlegrou ps.com...
>
Jim Langston wrote:
>Someone made the statement in a newsgroup that most C++ programmers use
smart pointers. His actual phrase was "most of us" but I really don't
think
that most C++ programmers use smart pointers, but I just don't know.
I don't like them because I don't trust them. I use new and delete on
pure
pointers instead.
That is absolute rubbish. You should trust library code which has been
tested by lots of users all over the world and distrust other code -
including your own.
Kind of harsh isn't it, calling someone's personal opinion "absolute
rubbish"?
I still don't use smart pointers very often, mainly because I've been using
raw pointers for many years now, and it's often easier for me to keep doing
what I've always been doing.
Also, don't the STL containers require smart pointers which are not
themselves found in the STL? It seems to me that things like std::vector
require using something like the Boost smart pointers. I forget the
reasoning exactly, but that's correct, isn't it? And many of us don't have
Boost, so what's the alternative?
As my confusion above might illustrate, many of us probably just don't know
the best way to make regular use of smart pointers, or which one(s) to use.
Perhaps we just need a little nudge in the right direction...?
-Howard
* Phlip:
Heinz Ozwirk wrote:
>>I don't like them because I don't trust them. I use new and delete on
pure pointers instead.
Then write your own implementation. And if you don't trust yourself then,
how can you trust yourself when using raw pointers?
Next tip: Always fold duplicated code into reusable abstractions.
On my current project, working as a hired hand after some years off the
job market, the manager insists on duplicating a whole set of some forty
plus files in two mutually communicating applications, and that the
files absolutely /must/ be different (it's specifically and very very
strongly disallowed to make one file that can be used identically in
both places), using manual update to keep the files in synch, and source
control merging (twice for each near-duplicated file) as a general
solution to the problem of him working on the same files as others.
This simple device allows the manager, who also does some programming,
to create any desired amount of problems for the others, who are placed
physically at maximally separated locations in a large building, so as
to avoid any teamwork or cross-communication (60% of the project members
are now on the way out of not just the project but out of the firm).
Needless to say I won't be working there again, but amazingly they /do/
use smart pointers, and these smart pointers have a feature that allow
raw pointers to be passed around, even for smart-pointer managed
objects, namely, that the smart pointers are intrusive, keeping the
reference count in the referred object rather than in the smart pointer.
The smart pointers also have implicit conversion to and from raw
pointers, to make it even more simple & natural to use raw pointers for
managed objects. Still, this was such a great improvement over just raw
pointers that one of the original developers commented at lunch that "I
now think we should have used /only/ smart pointers, everywhere".
Uh, have I said enough?
Think so, yes...
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Alf P. Steinbach wrote:
* Phlip:
Heinz Ozwirk wrote:
>I don't like them because I don't trust them. I use new and delete on
pure pointers instead.
Then write your own implementation. And if you don't trust yourself then,
how can you trust yourself when using raw pointers?
Next tip: Always fold duplicated code into reusable abstractions.
On my current project, working as a hired hand after some years off the
job market, the manager insists on duplicating a whole set of some forty
plus files in two mutually communicating applications, and that the
files absolutely /must/ be different (it's specifically and very very
strongly disallowed to make one file that can be used identically in
both places), using manual update to keep the files in synch, and source
control merging (twice for each near-duplicated file) as a general
solution to the problem of him working on the same files as others.
Yes, insainity.
The problem I have at my current position is that 'management' is
scared to use anything that requires they learn something new. The new
manager is better than the last who decided everything should be
written in-house but is still queezy about learning new things.
Problem is that most everything is new to them...I am the resident
expert on C++ and the STL and that is just sad. Hell, when I first got
there I had to justify every use of std::string - it should be the
other way, justify when you don't.
Frankly I don't understand anyone that doesn't constantly teach
themselves new techniques and _want_ to learn everything they can. I'm
always getting books, reading material on the web, experimenting at
home...these guys do only what they have to at work and do no extra
learning at home. It rather tripps me out.
Howard wrote:
"peter koch" <pe***************@gmail.comwrote in message
news:11*********************@m7g2000cwm.googlegrou ps.com...
Jim Langston wrote:
Someone made the statement in a newsgroup that most C++ programmers use
smart pointers. His actual phrase was "most of us" but I really don't
think
that most C++ programmers use smart pointers, but I just don't know.
I don't like them because I don't trust them. I use new and delete on
pure
pointers instead.
That is absolute rubbish. You should trust library code which has been
tested by lots of users all over the world and distrust other code -
including your own.
Kind of harsh isn't it, calling someone's personal opinion "absolute
rubbish"?
I still don't use smart pointers very often, mainly because I've been using
raw pointers for many years now, and it's often easier for me to keep doing
what I've always been doing.
Also, don't the STL containers require smart pointers which are not
themselves found in the STL?
The standard containers do not require smart pointers, but using smart
pointers with the standard containers makes life much easier than using
the standard containers with raw pointers.
It seems to me that things like std::vector
require using something like the Boost smart pointers.
Not true. Raw pointers work fine, but are a sure recipe for leaks.
I forget the
reasoning exactly, but that's correct, isn't it?
No.
And many of us don't have
Boost, so what's the alternative?
The FAQ includes a perfectly adequate intrusive smart pointer that I
have used for years: http://www.parashift.com/c++-faq-lit...html#faq-16.22
And why can't you use boost? Does your employer not permit it?
As my confusion above might illustrate, many of us probably just don't know
the best way to make regular use of smart pointers, or which one(s) to use.
Perhaps we just need a little nudge in the right direction...?
The FAQ will start you in the right direction. Jossuttis' The C++
Standard Library has some good examples of using a non-intrusive smart
pointer (using code supplied in the book) that works well with standard
containers.
Best regards,
Tom
"Jim Langston" <ta*******@rocketmail.comwrites:
Someone made the statement in a newsgroup that most C++ programmers use
smart pointers. His actual phrase was "most of us" but I really don't think
that most C++ programmers use smart pointers, but I just don't know.
"Nobody knows what most C++ developers do"
- Bjarne Stroustrup
That having been said...
I don't like them because I don't trust them. I use new and delete
on pure pointers instead.
This is just crazy, as most of the other replies in this thread
point out.
Do you use smart pointers?
Our main product is ~80k SLOC of highly mathematical C++; there's
not a bare pointer to be seen, except in the depths of some of the
math libraries (which are not for the faint of heart). We switched
from raw pointers to Boost's shared pointer a while back, and
haven't had a memory leak since. We rely on them completely, and
have _never_ had a problem.
The only good reason _not_ to use them AFAIK is the memory overhead
of the ref count (which can be mitigated in several ways) and the
run-time overhead of the extra redirection. We estimate that the
run-time penalty in our application for using smart pointers is
around 2%. We may, in the future, have to do something about this,
but it's unlikely.
----------------------------------------------------------------------
Dave Steffen, Ph.D.
Software Engineer IV Disobey this command!
Numerica Corporation - Douglas Hofstadter
dgsteffen at numerica dot us
Jim Langston schrieb:
Someone made the statement in a newsgroup that most C++ programmers use
smart pointers. His actual phrase was "most of us" but I really don't think
that most C++ programmers use smart pointers, but I just don't know.
There are C++ programmers who use char* with null-terminated strings
everywhere and don't know, or don't want to use std::string. There are C++
programmers who don't use std::vector and the other containers for the same
reasons.
They likely don't use smart pointers.
I don't like them because I don't trust them. I use new and delete on pure
pointers instead.
I wrote my own string class and linked list class some years ago because I
didn't trust the standard library containers. It is a kind of "fear of the
unknown". Now I use the standard containers because I learned that they are
better designed and better implemented than my own implementations.
When I started reading this newsgroup, I learned about the boost library
and started using its classes as well, including the smart pointers.
Do you use smart pointers?
Yes.
--
Thomas http://www.netmeister.org/news/learn2quote.html
Howard wrote:
"peter koch" <pe***************@gmail.comwrote in message
news:11*********************@m7g2000cwm.googlegrou ps.com...
Jim Langston wrote:
Someone made the statement in a newsgroup that most C++ programmers use
smart pointers. His actual phrase was "most of us" but I really don't
think
that most C++ programmers use smart pointers, but I just don't know.
I don't like them because I don't trust them. I use new and delete on
pure
pointers instead.
That is absolute rubbish. You should trust library code which has been
tested by lots of users all over the world and distrust other code -
including your own.
Kind of harsh isn't it, calling someone's personal opinion "absolute
rubbish"?
Right - it looks needlessly harsh, and was not intended as such (I hope
Jim Langston accepts my apologies). Still believing in your own code
and distrusting professional grade code from places such as boost is
foolish (but also very human!).
As for the questions I snipped below, they have been answered perfectly
by Tomas Tutone (if i remember correctly).
/Peter
[snip]
-Howard
In article <xU*************@newsfe04.lga>, ta*******@rocketmail.com
says...
Someone made the statement in a newsgroup that most C++ programmers use
smart pointers. His actual phrase was "most of us" but I really don't think
that most C++ programmers use smart pointers, but I just don't know.
I think part of that depends somewhat on what you include as a smart
pointer. Would you, for example, include vector? One on hand, it doesn't
even attempt to act much like a pointer (e.g. it doesn't include a '->'
member) but at the same time, it really IS a wrapper around a pointer.
In fact, nearly all of the standard collection templates use pointers
internally, to at least some degree -- but most of them don't attempt to
imitate a pointer.
What most people call "smart pointer" I'd call "semi-smart pointers",
where most things like collection classes are "really smart pointers". A
typical smart pointer hides some of the ugliness of real pointers, but
most collection classes hide considerably more of it.
I don't like them because I don't trust them. I use new and delete on pure
pointers instead.
I'm sorry to hear that. Most of us did that (to some degree or other) at
one time, and there's little room for question that it's much more
difficult to write solid, dependable code this way.
Do you use smart pointers?
Personally, I make relatively little use of what most people class as
smart pointers, but a LOT of use of classes that wrap pointers
intelligently enough that there's little external evidence that what
you're dealing with is ultimately a pointer.
--
Later,
Jerry.
The universe is a figment of its own imagination.
Thomas J. Gritzan wrote:
I wrote my own string class and linked list class some years ago because I
didn't trust the standard library containers. It is a kind of "fear of the
unknown". Now I use the standard containers because I learned that they are
better designed and better implemented than my own implementations.
The design of std::string (unlike most of the STL) is not the best, but
nonetheless, it is still almost always better than raw arrays or even
rolling your own string class.
Cheers! --M
"Howard" <al*****@hotmail.comwrites:
"peter koch" <pe***************@gmail.comwrote in message
news:11*********************@m7g2000cwm.googlegrou ps.com...
Jim Langston wrote:
Someone made the statement in a newsgroup that most C++ programmers use
smart pointers. His actual phrase was "most of us" but I really don't
think
that most C++ programmers use smart pointers, but I just don't know.
I don't like them because I don't trust them. I use new and delete on
pure
pointers instead.
That is absolute rubbish. You should trust library code which has been
tested by lots of users all over the world and distrust other code -
including your own.
Kind of harsh isn't it, calling someone's personal opinion "absolute
rubbish"?
Well, maybe, but my first response to your post was exactly the
same. I don't know of _any_ good reason not to use smart pointers,
except in cases where the overhead isn't acceptable; and I'll bet
money those cases are not only rare, but much more rare than most
people would think.
Also, don't the STL containers require smart pointers which are not
themselves found in the STL? It seems to me that things like
std::vector require using something like the Boost smart pointers.
I forget the reasoning exactly, but that's correct, isn't it? And
many of us don't have Boost, so what's the alternative?
Well, yes, STL containers-of-pointers are much better done as
containers-of-smart-pointers. And yes, the standard library
originally had only one kind of smart pointer, 'auto_ptr', which was
there for very specific purposes, and not suitable for use in std
containers.
You have two alternatives: the first is Boost, if you don't have it
then get it; things like smart pointers ("should" have been in the
standard library but weren't) is why Boost was started in the first
place.
Second, get a standard library that implements TR1, which
more-or-less took Boost's smart pointers and made 'em standard.
----------------------------------------------------------------------
Dave Steffen, Ph.D.
Software Engineer IV Disobey this command!
Numerica Corporation - Douglas Hofstadter
dgsteffen at numerica dot us
Jim Langston wrote:
I don't like them because I don't trust them. I use new and delete on pure
pointers instead.
sorry to hear that.
Why not rely on compiler generated code instead?
Smart pointers are a necessary if you want to write exception safe
code.
Do you use smart pointers?
I usually use a smart pointer which relies on the pointed object to
provide Addref()/Release() methods. This has the advantage to the boost
smart pointer that one does not need an additional memory allocation
for the reference count object.
And one can create additional smart pointers from the raw pointer
without mistakes.
Usually I make the constructor private and provide a static method
which returns a smart pointer to the created object.
Jerry Coffin wrote:
What most people call "smart pointer" I'd call "semi-smart pointers",
where most things like collection classes are "really smart pointers".
I think is much clear to call the collections "collections" and "smart
pointers" things that are used like pointers, unless you want that most
people misunderstand what you say.
--
Salu2
Peter wrote:
Smart pointers are a necessary if you want to write exception safe
code.
By "necessary", you mean to rapidly write flexible code despite exceptions
and such.
Anyone can hard-code 'delete' calls all over the place. Not rapid or
flexible!!
--
Phlip http://www.greencheese.us/ZeekLand <-- NOT a blog!!!
Phlip wrote:
Mingming wrote:
>Does smart pointer use too many resource?
Small smart pointers are the same size as pointers, and they insert opcodes
to call 'delete' into all the places where you should have coded 'delete'.
So their resource impact is minimal.
Well, I don't know what a "small smart pointer" would be, but TR1's
smart pointer (and Boost's, which it's based on) can be fairly expensive:
void f()
{
int *ip = new int(3);
delete ip;
}
void g()
{
std::tr1::shared_ptr<intsp(new int(3));
}
The first function makes one allocation from the free store, asking for
sizeof(int) bytes. The second makes two allocations, one for sizeof(int)
bytes and one for however many bytes are needed for shared_ptr's control
block, which holds a reference count, a pointer, and perhaps another
pointer to a cleanup function (empty in this example). I don't consider
using four times as much memory to be minimal.
That's not to say that shared_ptr isn't useful, but it's not something
you should automatically use everywhere.
--
-- Pete
Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." For more information about this book, see www.petebecker.com/tr1book.
Mingming wrote:
Does smart pointer use too many resource?
Please don't top-post. Your replies belong following or interspersed
with properly trimmed quotes. See the majority of other posts in the
newsgroup, or the group FAQ list:
<http://www.parashift.com/c++-faq-lite/how-to-post.html>
Pete Becker wrote:
Phlip wrote:
Mingming wrote:
Does smart pointer use too many resource?
Small smart pointers are the same size as pointers, and they insert opcodes
to call 'delete' into all the places where you should have coded 'delete'.
So their resource impact is minimal.
Well, I don't know what a "small smart pointer" would be, but TR1's
smart pointer (and Boost's, which it's based on) can be fairly expensive:
void f()
{
int *ip = new int(3);
delete ip;
}
void g()
{
std::tr1::shared_ptr<intsp(new int(3));
}
The first function makes one allocation from the free store, asking for
sizeof(int) bytes. The second makes two allocations, one for sizeof(int)
bytes and one for however many bytes are needed for shared_ptr's control
block, which holds a reference count, a pointer, and perhaps another
pointer to a cleanup function (empty in this example). I don't consider
using four times as much memory to be minimal.
That's not to say that shared_ptr isn't useful, but it's not something
you should automatically use everywhere.
std::auto_ptr is such a "small smart pointer." It requires "essentially
no overhead" (TC++PL 14.4.2).
Cheers! --M
Pete Becker wrote:
Phlip wrote:
Mingming wrote:
Does smart pointer use too many resource?
Small smart pointers are the same size as pointers, and they insert opcodes
to call 'delete' into all the places where you should have coded 'delete'.
So their resource impact is minimal.
Well, I don't know what a "small smart pointer" would be, but TR1's
smart pointer (and Boost's, which it's based on) can be fairly expensive:
void f()
{
int *ip = new int(3);
delete ip;
}
void g()
{
std::tr1::shared_ptr<intsp(new int(3));
}
shared_ptr is not the appropriate smart pointer for that use...
>
The first function makes one allocation from the free store, asking for
sizeof(int) bytes. The second makes two allocations, one for sizeof(int)
bytes and one for however many bytes are needed for shared_ptr's control
block, which holds a reference count, a pointer, and perhaps another
pointer to a cleanup function (empty in this example). I don't consider
using four times as much memory to be minimal.
....and that would be why.
That's not to say that shared_ptr isn't useful, but it's not something
you should automatically use everywhere.
It's also not the only smart pointer available...not even the only one
available in tr1. The whole purpose of weak_ptr is to use shared_ptr
without the costs when unnecissary, such as passing shared_ptrs as
arguments or returns (except in cases like above of course). You also
have auto_ptr at your disposal for cases like the above and
boost::scoped_ptr, which was made just for such situations, if you are
using boost.
A reference counting smart pointer is only one type of smart pointer
that serves a particular purpose. Just because your pointers are smart
doesn't mean you don't still have to be. Correct tools for the job and
all that...you wouldn't generalize the performance of all STL
containers based on a misuse of std::vector.
I know you know this but others might percieve what you are saying as
an argument against smart pointers and if it is it isn't a very good
one.
On Fri, 22 Sep 2006 06:52:19 -0700, "Jim Langston"
<ta*******@rocketmail.comwrote:
>Someone made the statement in a newsgroup that most C++ programmers use
smart pointers. His actual phrase was "most of us" but I really don't think
that most C++ programmers use smart pointers, but I just don't know.
I don't like them because I don't trust them. I use new and delete on pure
pointers instead.
Do you use smart pointers?
No! 'Smart' pointers are very unsmart.
You should have asked why someone would use 'smart' pointers. In fact,
the concept of 'smart' pointers is flawed in so many ways that I
amazed that some people still recommend them. The deficiencies are
well known: transfer of ownership, error-prone usage, inefficiency
(esp. for ref-counted s.p.).
Just say no to 'smart' pointers.
Roland Pibinger
Pete Becker wrote:
Phlip wrote:
>Mingming wrote:
>>Does smart pointer use too many resource?
Small smart pointers are the same size as pointers, and they insert
opcodes to call 'delete' into all the places where you should have
coded 'delete'. So their resource impact is minimal.
Well, I don't know what a "small smart pointer" would be, but TR1's
smart pointer (and Boost's, which it's based on) can be fairly
expensive:
void f()
{
int *ip = new int(3);
delete ip;
}
void g()
{
std::tr1::shared_ptr<intsp(new int(3));
}
The first function makes one allocation from the free store, asking
for sizeof(int) bytes. The second makes two allocations, one for
sizeof(int) bytes and one for however many bytes are needed for
shared_ptr's control block, which holds a reference count, a pointer,
and perhaps another pointer to a cleanup function (empty in this
example). I don't consider using four times as much memory to be
minimal.
That's not to say that shared_ptr isn't useful, but it's not something
you should automatically use everywhere.
Your example looks somewhat contrived, Pete. Who in their right mind
would allocate a single int from the free store? I don't mean to
question the need for small objects, I just don't think that this is
a valid example to prove the expensiveness of the smart pointer.
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
"Jim Langston" <ta*******@rocketmail.comwrote in message
news:xU*************@newsfe04.lga...
Someone made the statement in a newsgroup that most C++ programmers use
smart pointers. His actual phrase was "most of us" but I really don't
think that most C++ programmers use smart pointers, but I just don't know.
I don't like them because I don't trust them. I use new and delete on
pure pointers instead.
Do you use smart pointers?
Yes, I do now. I always used to be of the opinion that you might as well use
raw pointers and avoid the overhead - after all, "real programmers don't let
their code leak". Ahem...well...that says maybe. On the other hand, with the
benefit of a bit more experience:
* Using raw pointers involves cognitive overhead that you can do without.
Your brain is best employed elsewhere.
* Unless smart pointers are significantly slower, you might as well be using
them. You can start with them, profile, and replace them with raw pointers
if necessary later on.
* You might be a "real programmer", whatever that is. All it takes is one
person on your team who isn't... It might even be you, if you're really
unlucky ("unreal"(?!) programmers don't often know it...). [Incidentally,
that wasn't directed at you. It was more a remark aimed at people who think
they're better at something than they are. It's an easy trap to fall into,
but best avoided.]
* Simplicity is a good thing. Manually keeping track of the places where you
need to use delete is not always as easy as it looks. (Yes, yes, we all know
that "real programmers laugh in the face of complexity". Why not *avoid*
complexity to the greatest extent possible instead? Or to take an analogy,
the ability to win a battle doesn't always mean you should fight it.)
* Making things exception-safe is harder with raw pointers.
Regards,
Stu
Roland Pibinger wrote:
On Fri, 22 Sep 2006 06:52:19 -0700, "Jim Langston"
<ta*******@rocketmail.comwrote:
Someone made the statement in a newsgroup that most C++ programmers use
smart pointers. His actual phrase was "most of us" but I really don't think
that most C++ programmers use smart pointers, but I just don't know.
I don't like them because I don't trust them. I use new and delete on pure
pointers instead.
Do you use smart pointers?
No! 'Smart' pointers are very unsmart.
You should have asked why someone would use 'smart' pointers. In fact,
the concept of 'smart' pointers is flawed in so many ways that I
amazed that some people still recommend them. The deficiencies are
well known: transfer of ownership, error-prone usage,
Interesting. Those are the exact weaknesses of raw pointers that smart
pointers avoid. Explain how you see them on the other side.
inefficiency
(esp. for ref-counted s.p.).
Well, someone else showed how inefficient use of certain constructs
results in inefficient code but when a ref-counted smart pointer is
actually needed is it really less efficient than the raw pointer
alternative? Since ref counted smart pointers are meant to aliviate
the difficulties associated with ownership semantics what is your raw
pointer alternative that is so much more efficient?
Roland Pibinger wrote:
On Fri, 22 Sep 2006 06:52:19 -0700, "Jim Langston"
<ta*******@rocketmail.comwrote:
Someone made the statement in a newsgroup that most C++ programmers use
smart pointers. His actual phrase was "most of us" but I really don't think
that most C++ programmers use smart pointers, but I just don't know.
I don't like them because I don't trust them. I use new and delete on pure
pointers instead.
Do you use smart pointers?
No! 'Smart' pointers are very unsmart.
You should have asked why someone would use 'smart' pointers. In fact,
the concept of 'smart' pointers is flawed in so many ways that I
amazed that some people still recommend them. The deficiencies are
well known: transfer of ownership
True of std::auto_ptr if you don't know what you're doing, and of raw
pointers as well (again, if you don't know what you're doing). Not
true of reference-counted pointers.
error-prone usage,
i.e., people who use them not understanding what they're doing. But
the same is true of raw pointers - if you don't know what you're doing,
a lot of error-prone usage. Smart pointers work fine when used as
directed.
inefficiency
(esp. for ref-counted s.p.).
There's no point to using a reference-counted pointer where an auto_ptr
or weak_ptr would do the job, but if you have multiple pointers
pointing to the same object, keeping track of it all so that you delete
it at the proper time gets very complicated. I have yet to find a case
where the supposed marginal inefficiency of using a reference-counted
pointer in that situation had an effect that mattered. Have you
encountered such a case? Can you describe it please?
Just say no to 'smart' pointers.
I'm curious, Roland.
How do you write exception-safe code without them? Do you simply not
use exceptions and assume your use of library functions won't throw?
Do you have elaborate try-catch blocks every time you allocate from the
free-store?
Does your disdain for smart pointer extend to the entire RAII idiom, or
is it confined just to smart pointers?
My questions are not rhetorical - I believe that you are sincere in
your beliefs, and I am genuinely interested in your answers.
Best regards,
Tom
In article <11**********************@m73g2000cwd.googlegroups .com>, ml*****@gmail.com says...
[ ... use of smart pointers ]
No, it really is necessary in certain circumstances. See
http://www.gotw.ca/publications/xc++-auto_ptr.htm
Interestingly, this starts with the statement that: "Finally, auto_ptr
is sometimes essential to writing exception-safe code." The same
article, however, also says: "One way to solve the problem is to return
a pointer to a dynamically allocated String, but the best solution is to
go a step farther and return the pointer in an auto_ptr..."
IOW, it's self-contradictory: auto_ptr is really a convenience, NOT a
necessity as originally stated.
In this article, the challenge was to make this code strongly exception
safe:
String f()
{
String result;
result = "some value";
cout << "some output";
return result;
}
and the solution he gives is:
auto_ptr<Stringf()
{
auto_ptr<Stringresult = new String;
*result = "some value";
cout << "some output";
return result;
// rely on transfer of
// ownership; this can't throw
}
But IMO, it would probably be better to use something like:
void f(String &result) {
String r;
r = "some value";
cout << "some output";
r.swap(result);
}
which is basically just hi-jacking the exception-safe assignment from
Item 13 of the same book, and using it to do an exception-safe
assignment of the return value. Of course, this requires that the String
class contain a swap that doesn't throw -- but as the aforementioned
Item 13 makes clear, you should almost certainly have that in any case.
--
Later,
Jerry.
The universe is a figment of its own imagination.
On 22 Sep 2006 11:43:59 -0700, "Noah Roberts" <ro**********@gmail.com>
wrote:
>inefficiency
(esp. for ref-counted s.p.).
Well, someone else showed how inefficient use of certain constructs
results in inefficient code but when a ref-counted smart pointer is
actually needed is it really less efficient than the raw pointer
alternative?
Yes, of course. Actually, inefficiency is Stroustrups major argument
against ref-counted s.p. ( http://www.research.att.com/~bs/DnE2005.pdf
look for "Smart pointer"). IMO, 'transfer' semantics is the stronger
argument against s.p.
>Since ref counted smart pointers are meant to aliviate
the difficulties associated with ownership semantics
S.p. create more problems WRT ownership that they solve.
>what is your raw
pointer alternative that is so much more efficient?
RAII. I mean pure RAII so that "allocation and deallocation disappear
from the surface level of your code"
( http://www.artima.com/intv/modern3.html). Encapsulation without
transfer of ownership.
Best wishes,
Roland Pibinger
Pete Becker wrote:
>Well, I don't know what a "small smart pointer" would be, but TR1's
smart pointer (and Boost's, which it's based on) can be fairly expensive:
boost::intrusive_ptr is another example.
>That's not to say that shared_ptr isn't useful, but it's not something
you should automatically use everywhere.
Noah Roberts schrieb:
It's also not the only smart pointer available...not even the only one
available in tr1. The whole purpose of weak_ptr is to use shared_ptr
without the costs when unnecissary, such as passing shared_ptrs as
arguments or returns (except in cases like above of course).
Huh? What costs does shared_ptr have that weak_ptr doesn't have?
weak_ptr holds a pointer that doesn't go into the reference count, which is
usefull to break circular references.
--
Thomas http://www.netmeister.org/news/learn2quote.html
On 22 Sep 2006 11:46:09 -0700, "Thomas Tutone"
<Th***********@yahoo.comwrote:
>Roland Pibinger wrote:
>The deficiencies are well known: transfer of ownership
True of std::auto_ptr
and shared_ptr and ...
>if you don't know what you're doing, and of raw
pointers as well (again, if you don't know what you're doing). Not
true of reference-counted pointers.
Real pointers don't transfer ownership because the never own any
pointed-to object.
>error-prone usage,
i.e., people who use them not understanding what they're doing. But
the same is true of raw pointers - if you don't know what you're doing,
a lot of error-prone usage. Smart pointers work fine when used as
directed.
Of course, you always should understanding what you're doing. But the
point is that there are better and worse interfaces.
The C++ Standard library doesn't 'new' anything what has to be deleted
by the user and, vice versa, doesn't delete anything that has been
'newed' by the user (similar in C with malloc/free). The only
exception is auto_ptr (and shared_ptr in the future) which violates
that principle.
>How do you write exception-safe code without them? Do you simply not
use exceptions and assume your use of library functions won't throw?
Do you have elaborate try-catch blocks every time you allocate from the
free-store?
No try/catch cascades, just pure RAII as described by Stroustrup: http://www.artima.com/intv/modern3.html. The pattern was called
"Object As Sole Owner" by Cargill in his seminal article which is now
available online: http://www.ddj.com/184409895 (BTW, objects typically
are not created in the constructor but in any member function).
Best regards,
Roland Pibinger
Roland Pibinger wrote:
On 22 Sep 2006 11:43:59 -0700, "Noah Roberts" <ro**********@gmail.com>
wrote:
inefficiency
(esp. for ref-counted s.p.).
Well, someone else showed how inefficient use of certain constructs
results in inefficient code but when a ref-counted smart pointer is
actually needed is it really less efficient than the raw pointer
alternative?
Yes, of course. Actually, inefficiency is Stroustrups major argument
against ref-counted s.p. (http://www.research.att.com/~bs/DnE2005.pdf
look for "Smart pointer").
The key part is: 'Smart pointers are popular, but should be approached
with care. They are not the panacea that they are sometimes presented
to be. In particular, they are far more expensive to use than ordinary
pointers, destructors for objects "owned" by a set of shared_ptrs
will run at unpredictable times, and if a lot of objects are deleted at
once because the last shared_ptr to them is deleted you can incur
"garbage collection delays" exactly as if you were running a
general collector. The costs primarily relate to free store allocation
of use count objects and especially to locking during access to the use
counts in threaded systems. Do not simply replace all your ordinary
pointers with smart_ptrs if you are concerned with performance or
predictability. These concerns kept smart_ptrs "ancestor",
counted_ptr, out of the 1998 standard.'
It is not likely, however, that these concerns will keep them out of
C++0x, not least because our collective experienced with smart pointers
has increased since 1998. Not to disregard the venerable Creator's
words, but other gurus have made the opposite case that "Correctness is
worth the cost [of smart pointers]" (C++ Coding Standards, item 60),
and they suggest "If you use [Boost] and [TR1] for nothing else, use
them for shared_ptr."
IMO, 'transfer' semantics is the stronger argument against s.p.
Please elaborate. (We all know about std::auto_ptr. What about
std::tr1::shared_ptr or boost::scoped_ptr, which doesn't allow
transferring at all?)
Since ref counted smart pointers are meant to aliviate
the difficulties associated with ownership semantics
S.p. create more problems WRT ownership that they solve.
Bald assertions don't prove your case.
what is your raw
pointer alternative that is so much more efficient?
RAII. I mean pure RAII so that "allocation and deallocation disappear
from the surface level of your code"
(http://www.artima.com/intv/modern3.html). Encapsulation without
transfer of ownership.
The explicit purpose of std::auto_ptr is to support RAII (TC++PL,
14.4.2).
Cheers! --M
Someone made the statement in a newsgroup that most C++ programmers use
smart pointers. His actual phrase was "most of us" but I really don't think
that most C++ programmers use smart pointers, but I just don't know.
I am a C++ noob, but I am a total fan of boost pointers and I use them
wnever possible. The only time I don't is when I want non-ownership
access to an object that is on the stack.
They are totally worth the time and effort to learn about them and I
think they should become part of the C++ standard library.
In article <45**************@news.utanet.at>, rp*****@yahoo.com says...
[ ... ]
No try/catch cascades, just pure RAII as described by Stroustrup:
http://www.artima.com/intv/modern3.html. The pattern was called
"Object As Sole Owner" by Cargill in his seminal article which is now
available online: http://www.ddj.com/184409895
It wasn't particuarly new then. Just for example, see:
(BTW, objects typically
are not created in the constructor but in any member function).
Best regards,
Roland Pibinger
--
Later,
Jerry.
The universe is a figment of its own imagination.
Thomas J. Gritzan wrote:
What costs does shared_ptr have that weak_ptr doesn't have?
weak_ptr doesn't do any counting. It provides access to the pointer
and to the reference when needed but doesn't do any upkeep so is pretty
close to a raw pointer. The only time you pay reference costs with a
weak ptr is when you try to create a shared_ptr out of it. It does
have extra space requirements to access the reference count (maybe, not
really sure) so still isn't appropriate for the use in question but it
still lessens the cost of using shared_ptr objects by providing a non
counting interface when such a count isn't useful.
On 22 Sep 2006 12:37:04 -0700, "mlimber" <ml*****@gmail.comwrote:
>It is not likely, however, that these concerns will keep them out of
C++0x,
bad for C++38 ...
>not least because our collective experienced with smart pointers
has increased since 1998. Not to disregard the venerable Creator's
words, but other gurus have made the opposite case that "Correctness is
worth the cost [of smart pointers]" (C++ Coding Standards, item 60),
and they suggest "If you use [Boost] and [TR1] for nothing else, use
them for shared_ptr."
Which "Correctness"? The 'usual' smart pointers use questionable
"transfer of ownership" semantics and don't check for NULL before they
dereference a pointer. The following compiles without a warning on
popular compilers:
int i = 0;
auto_ptr<intap (&i);
BTW, even gurus may change their mind
( http://www.gotw.ca/publications/index.htm):
"Most people have heard of the standard auto_ptr smart pointer
facility, but not everyone uses it daily. That's a shame, because it
turns out that auto_ptr neatly solves common C++ design and coding
problems, and using it well can lead to more robust code." Herb
Sutter, 1999
"Avoid using auto_ptr, instead use shared_ptr which is widely
available and being added to the standard library." Herb Sutter,
2004.
Best wishes,
Roland Pibinger
* Noah Roberts:
Thomas J. Gritzan wrote:
>What costs does shared_ptr have that weak_ptr doesn't have?
weak_ptr doesn't do any counting. It provides access to the pointer
and to the reference when needed but doesn't do any upkeep so is pretty
close to a raw pointer.
Are you sure about that? I haven't checked any implementation, but a
weak pointer must be able to detect whether the managed object still
exists or not, in order to not conjure up a non-null shared_ptr for an
already destroyed object. Thus, I think it likely that for a shared_ptr
managed object O there exists a hidden reference holder object, call it
Refs, that contains (1) a raw pointer to O, (2) a count nHardRefs of
shared_ptr instances for O, and (3) a count nWeakRefs of weak_ptr
instances for O, such that O is destroyed when nHardRefs goes to zero,
and Refs is destroyed at that point iff nWeakRefs is 0, or later on when
nWeakRefs goes to zero -- which implies weak_ptr reference counting.
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail? This thread has been closed and replies have been disabled. Please start a new discussion. |
