Accelerated C++ - Ch 13 & 14 - Is a handle the same thing as a smart pointer?

Question

I'm just about done Koenig & Moo's Accelerated C++ and in Chapters 13 & 14 they lay out the idea and implementation of a few Handle classes (simple, shared, reference counted).

The classes encpasulate a raw pointer and abstract the allocation / deallocation of dynamic objects away from the client code to avoid all the dangers of raw pointers as well allowing the user to dereference them to access the pointed to object. Basically a 'safer' way to interface with raw memory resources.

Are the classes presented in these chapters essentially implementations of smart pointers? Smart pointers are still pretty new to me but from what I understand these Handle classes are performing the same function.

Is there a a distinction between the two or is it just another name for the same thing?

Assuming they're equivalent in function, in practice would a class like this ever be written from scratch rather than using an already made smart pointer solution?

EDIT

I should add that the classes they develop in these chapters are template classes so they're not bound to a specific resource, as in they're not designing a specific FileHandle class for example.

I found this article:

http://www.informit.com/articles/article.aspx?p=25264

and the code in the first code snippet there, 7.1, is pretty much what they've got in the chapters I'm referring to.

Thanks SO,

Answer 1

I would say that a handle is a more general concept than a smart pointer.

Consider, for example, file handles. A file handle may in effect be a smart pointer to a data structure representing an open file, but the client doesn't really treat it a pointer, rather they just pass the handle down to an API.

So, yes I have on several occasions written my own handle classes.

Answer 2

From your description it sounds like a smart pointer.
Though personally I would not use the term handle as it is slightly ambiguous (just call a smart pointer a smart pointer).

Q: Could you write a smart pointer from scratch?
A: Yes

Q: Should you write your own smart pointer.
A: No. Its a lot trickier than you think. Even the description in the book only glossed over the more complex problems. Stick with the standard ones that are provided by reputable libraries.

Q: Handles what does it mean.
A: It used to mean a pointer to a pointer. But the term has come ambiguous over the years as the term has been re-used. But you can consider it a pointer to a resource where the resource can be accessed by other methods and in this context their description is sort of valid.

Q: Should you use smart pointers instead of raw memory.
A: Never use RAW memory unless absolutely necessary (which is practically never) always encapsulate it in a class that manages it. Whether the class is a smart pointer or another type of object is a good question. std::vector is not considered a smart pointer but it encapsulates a RAW pointer.

Q: Should you abstract memory management from business logic:
A: That's a tricky one and some would may disagree. But I would say always. A class should do one thing. The thing is either resource management OR business logic. combining the two leads too unforeseen complexities.

Answer 3

If you'll forgive a bit of metaphorical C++, the relationship is something like: class smart_pointer : public handle;. A smart pointer is a handle that provides a specific (pointer-like) style of interface between the handle and whatever it's handling. A handle that's not a smart pointer will generally have (at least vaguely) similar operations, but their interface may be entirely different.

At some point, somebody obviously has to write the smart pointer class(es). At the same time, this is not something to undertake lightly. Unless you have an extremely precise specification, you'll probably get at least a few details wrong -- and that "extremely precise specification" only reduces the odds to about 50:50...

OTOH, it's still not nearly as bad as designing a smart pointer. This tends to be tricky in the extreme. For an obvious example, auto_ptr was designed and re-designed a number of times during standardization, but it still sees relatively little use in real life, and is already being deprecated in C++0x (replaced by std::unique_ptr, which is the product of a lot of work, debate, and no small amount of experimentation and testing).