Smart Pointers Are Too Smart

re: Smart Pointers Are Too Smart

sbi — Tue, 23 Aug 2011 08:46:39 GMT

What does "smart" stand for in a "smart pointer" when you have to call a Disown() function for it to get ownership semantics right? A good smart pointer would do ownership transfer at assignment itself, when the possibly failing operations are sorted out.

Yes, you will have to think about the stuff at the low level (this is C++, after all), but only when you are _implementing_ a smart pointer. If you need to think about it when you are _using_ it, it#s the wrong one.

re: Smart Pointers Are Too Smart

Milan Sekler — Sun, 02 Mar 2008 00:09:37 GMT

I can not beleive I found somebody that thinks like I do about the smart pointers. I agree with the author 100% and I spend 10 hours a day looking at C++ code. How do I convince myself to use this &%^@#:

template

typename T,

template <class> class OwnershipPolicy = RefCounted,

class ConversionPolicy = DisallowConversion,

template <class> class CheckingPolicy = AssertCheck,

template <class> class StoragePolicy = DefaultSPStorage

class SmartPtr;

re: Smart Pointers Are Too Smart

indranil banerjee — Sat, 24 Jul 2004 11:45:00 GMT

I agree with Brian that neither example illustrates a problem with smart pointers.

The first is just an example of the unpredictable order of evaluation in C++ program.

This code has exactly the same problem, and no smart pointers:-

map[new Foo('A')] = new Bar("Aarcvark");

The second is just the horrendous complexity of ATL. But then again anything to do with COM is horrendously complex.

re: Smart Pointers Are Too Smart

josep — Sat, 03 Jul 2004 00:28:00 GMT

That's because you have bad smart pointers! Don't blame a concept because of a lame implementation!

Look at boost smart pointers and you'll find referenced count smart pointers which can be inserted in any STL container (shared_ptr).

re: Smart Pointers Are Too Smart

Eric Lippert — Fri, 04 Jun 2004 19:37:00 GMT

No, I'm saying that smart pointers suck because to use them properly, you have to understand _exactly_ what they are doing.

An abstraction is supposed to relieve you of the burden of understanding the abstracted thing, but smart pointers do a poor job of that. In order to use them correctly, you have to understand exactly what they're doing to ensure that you don't use smart pointers to violate the very rules they are designed to abstract away.

That's a lousy abstraction. It is easier for me to learn the rules of COM and apply them than to learn the rules of COM AND learn the entire smart pointer framework.

The .NET framework does a much better job of abstracting away the details of how the underlying system works, because it was designed to do that from day one. Smart pointers are a kludge written post hoc.

re: Smart Pointers Are Too Smart

The Sim — Fri, 04 Jun 2004 18:21:00 GMT

Never mind, I reread the post, that seems to be exactly what you said. C# 4ever, whoop!

re: Smart Pointers Are Too Smart

The Sim — Fri, 04 Jun 2004 18:18:00 GMT

so basically you are saying smart pointers suck, because you don't know how to use them properly?

Aaargh! Part Two

Fabulous Adventures In Coding — Tue, 04 May 2004 21:59:00 GMT

Aaargh! Part Two

Fabulous Adventures In Coding — Tue, 23 Mar 2004 20:58:00 GMT

re: Smart Pointers Are Too Smart

Eric Lippert — Tue, 23 Mar 2004 20:51:00 GMT

> using them is almost always a better idea than trying to manage the refcounts "by hand". I've used them for years and they've been the least of my concerns.

I disagree. I've debugged ref count bugs caused by me forgetting an AddRef, and I've debugged ref count bugs like the one above with the fifteen-deep call stack of meaningless (to me) gibberish, and the former are a whole lot easier to track down.

I agree that COM code looks gross, and that it tends to emphasize the error paths and cleanup code rather than the program logic. Two points: First, given that the error paths and cleanup code are where most of the bugs are, I want them to be as explicit as possible. Those ARE the program logic.

Second, I understand the urge to abstract them away into classes that take care of the details for you. But in my experience, the abstraction is both complex and leaky. The abstraction is easy to use for simple cases, and thereby affords creation of much more subtle, hard-to-debug bugs.

My point, simply, is that AddRef/Release/QI are a pain in the rear to USE, but they are EASY to understand. Smart pointers are easy to use and hard to understand, and I prefer to understand the code I write.