Modern C++ Design

(From Ch. 7, Smart Point­ers)

Smart point­ers may man­age own­er­ship in var­i­ous ways, each ap­pro­pri­ate to a cat­e­gory of prob­lems. Some smart point­ers trans­fer own­er­ship au­to­mat­i­cally: Af­ter you copy a smart pointer to an ob­ject, the source smart pointer be­comes null, and the des­ti­na­tion points to (and holds own­er­ship of) the ob­ject. This is the be­hav­ior im­ple­mented by the stan­dard-pro­vided std::au­to_ptr. Other smart point­ers im­ple­ment ref­er­ence count­ing: They track the to­tal count of smart point­ers that point to the same ob­ject, and when this count goes down to zero, they delete the pointed-to ob­ject. Fi­nally, some oth­ers du­pli­cate their pointed-to ob­ject when­ever you copy them.

In short, in the smart point­ers' world, own­er­ship is an im­por­tant topic. By pro­vid­ing own­er­ship man­age­ment, smart point­ers are able to sup­port in­tegrity guar­an­tees and full value se­man­tics. Be­cause own­er­ship has much to do with con­struct­ing, copy­ing, and de­stroy­ing smart point­ers, it's easy to fig­ure out that these are the most vi­tal func­tions of a smart pointer.

The fol­low­ing few sec­tions dis­cuss var­i­ous as­pects of smart pointer de­sign and im­ple­men­ta­tion. The goal is to ren­der smart point­ers as close to raw point­ers as pos­si­ble, but not closer. It's a con­tra­dic­tory goal: Af­ter all, if your smart point­ers be­have ex­actly like dumb point­ers, they are dumb point­ers.

In im­ple­ment­ing com­pat­i­bil­ity be­tween smart point­ers and raw point­ers, there is a thin line be­tween nicely fill­ing com­pat­i­bil­ity check­lists and paving the way to chaos. You will find that adding seem­ingly worth­while fea­tures might ex­pose the clients to costly risks. Much of the craft of im­ple­ment­ing good smart point­ers con­sists of care­fully bal­anc­ing their set of fea­tures. [...]

[read this chap­ter for free]
[Table of Con­tents]

Home > Books > Mod­ern C++ De­sign

Mod­ern C++ De­sign

This book has for­ever changed all as­pects of soft­ware de­sign and im­ple­men­ta­tion us­ing the C++ pro­gram­ming lan­guage. To this day it is an au­thor­i­ta­tive guide to ad­vanced de­sign tech­niques and their re­al­iza­tion in C++.

Re­sources

Trivia

  • Due to lack of ex­pe­ri­ence, An­drei was ini­tially afraid to work alone on the the book so he pro­posed co-au­thor­ship to Scott Mey­ers. An­drei would pro­vide the de­signs and the code and Scott would do the writeup. Scott in­sisted that An­drei raises up to the task, warmly rec­om­mended him to Ad­di­son Wes­ley, and men­tored him through­out. The two ended up be­com­ing long­time friends.
  • At pub­li­ca­tion time not all code was com­pi­l­able with ex­ist­ing com­pil­ers, and dif­fer­ent com­pil­ers ac­cepted dif­fer­ent sub­sets of the code. An­drei com­piled cer­tain snip­pets "on pa­per" by pe­rus­ing the C++ stan­dard doc­u­ment.
  • "Com­piles all of Loki" be­came an in­for­mal yard­stick for C++ com­pil­ers. Com­piler ven­dors took no­tice and im­proved their com­pil­ers ac­cord­ingly.