boost::shared_ptr is great
Author
I think shared_ptr and weak_ptr is a great solution for reference counting. I had been deriving the objects that I wanted reference counted from a ReferenceCountedObject. I wasn''t very happy with the implications; mostly, that whatever used the class had to do things like ->AddReference(), and I couldn''t just call delete, I had to use ->Release(), etc.
shared_ptr takes the reference counting away from the actual object, and puts it into the hands of whatever is using the object. And since shared pointers are usually declared somewhere and just *used* other places, weak_ptr is great also. Well, at least, thats how I use them in my current project.
You may be thinking, "right...what a pointless post." But, I just had to spout my joy! I just downloaded the boost library today (big deal, I''m on 56k) and I will definitely be using it.
Right now I''m looking into concept-checking also. I think it will help a lot when working with templates.
nice if they made you happy.
yes, they are sweet.
disadvantage is they are (a tiny tiny tiny bit) slower than normal pointers, (due double indirection)
still, they _are_ great. i use them everywhere. them, containers, and that.
i don''t use pointers,new,new[],delete,delete[], etc..
and guess what? i never had any crash in my apps since i started to use them.. :D
now i wait for my compiler to support real throw semantics.. then the code will be about perfectly save..
"take a look around" - limp bizkit
www.google.com
yes, they are sweet.
disadvantage is they are (a tiny tiny tiny bit) slower than normal pointers, (due double indirection)
still, they _are_ great. i use them everywhere. them, containers, and that.
i don''t use pointers,new,new[],delete,delete[], etc..
and guess what? i never had any crash in my apps since i started to use them.. :D
now i wait for my compiler to support real throw semantics.. then the code will be about perfectly save..
"take a look around" - limp bizkit
www.google.com
quote:You may be thinking, "right...what a pointless post." But, I just had to spout my joy! I just downloaded the boost library today (big deal, I''m on 56k) and I will definitely be using it.
Congratulations.
Documents [ GDNet | MSDN | STL | OpenGL | Formats | RTFM | Asking Smart Questions ]
C++ Stuff [ MinGW | Loki | SDL | Boost. | STLport | FLTK | ACCU Recommended Books ]
quote:
disadvantage is they are (a tiny tiny tiny bit) slower than normal pointers, (due double indirection)
I have yet to see a common compiler that does not inline the call when you turn on optimisations.
quote:Original post by davepermenI''ve checked the source. I can only see one level of indirection...
disadvantage is they are (a tiny tiny tiny bit) slower than normal pointers, (due double indirection)
quote:Original post by davepermenA tiny tiny tiny bit? In a program of mine, I changed the (performance-critical) pointers from raw to shared_ptr, and it''s execution time rose from 9 seconds to 19 seconds (!). Both tested on release build, naturally.
disadvantage is they are (a tiny tiny tiny bit) slower than normal pointers, (due double indirection)
A normal application may not have millions of pointers moving around though, so using shared_ptr isn''t likely to change their execution speed that much. But claiming that shared_ptr itself isn''t much slower is wrong. It''s slowness just doesn''t affect much if your program''s bottleneck is elsewhere.
quote:Original post by civguyA tiny tiny tiny bit? In a program of mine, I changed the (performance-critical) pointers from raw to shared_ptr, and it''s execution time rose from 9 seconds to 19 seconds (!). Both tested on release build, naturally.Original post by davepermen
disadvantage is they are (a tiny tiny tiny bit) slower than normal pointers, (due double indirection)
A normal application may not have millions of pointers moving around though, so using shared_ptr isn''t likely to change their execution speed that much. But claiming that shared_ptr itself isn''t much slower is wrong. It''s slowness just doesn''t affect much if your program''s bottleneck is elsewhere.
Which compiler are you using?
you can always get a situation where it hurts hard that the implementation has one additional indirection. in most it doesn''t hurt at all, and in some performance eating, it hurts a bit.
why it hurts?
a normal pointer has this:
a shared pointer has this:
a second indirection. now depending on how lucky your processor is with caching and all, it can hurt in performance situations..
i suggest then to add some other method to him, a "precache" call, wich fetches the pointer yet with inline asm.. and does not fetch the actual pointer itself (dunno again if this is actually possible)..
but as said, in most situations you gain so much savety, and you don''t ever feel the performance drop..
i just suggest to not have shared_ptr, but shared_ptr :D..
and in a performance critical situation, i would suggest to drop savety anyways.. as you normally know in an inner loop that you don''t need to be save in every loop that your pointer is valid, but at the start, and the ending.. that just as a suggestion:D
"take a look around" - limp bizkit
www.google.com
why it hurts?
a normal pointer has this:
std_ptr<int>:int* x; a shared pointer has this:
struct shared_ptr<int> {std_ptr<int> ptr;int ref_count;int weak_count;};shared_ptr<int> x(new int);*x = 10;//would technically be then*(*x->ptr) = 10; a second indirection. now depending on how lucky your processor is with caching and all, it can hurt in performance situations..
i suggest then to add some other method to him, a "precache" call, wich fetches the pointer yet with inline asm.. and does not fetch the actual pointer itself (dunno again if this is actually possible)..
but as said, in most situations you gain so much savety, and you don''t ever feel the performance drop..
i just suggest to not have shared_ptr, but shared_ptr :D..
and in a performance critical situation, i would suggest to drop savety anyways.. as you normally know in an inner loop that you don''t need to be save in every loop that your pointer is valid, but at the start, and the ending.. that just as a suggestion:D
"take a look around" - limp bizkit
www.google.com
quote:Original post by civguyVC++ 7.0Original post by Gorg
Which compiler are you using?
Intriguing. I never tried it. I use Borland5 and GCC3.2 has my main compilers, and in release mode(borland) and GCC3.2 -O3, I get the same speed has the function call is inlined.
Are you sure you weren''t missing an inline optimisation feature?
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
