Mixed feelings. The focus is on smart pointers, which is a good idea. I buy the author's idea that smart pointers should be ubiquous. Maybe I'd lack some deeper discussion on the conceptual side (value and reference semantics). Well this aspect is not the topic of this book, which focuses on practical aspects, often on the fringe of exploring tricks. I was very pleased to find --as a detail, not in depth-- my own pet peeves of Operations.
I was sometimes disappointed by some gross errors, arising from quick careless statements. I got tired of coorecting the mistakes. A few below.
The presentation of references is plain wrong, as easily checked by compiling the code
An error in the code of the example. Should be:
class Bar: Foo { // optionally public... public: virtual void Fn(int); };
A weird syntax, that IMHO has never been even suggested at any
stage of the standardization process. I wonder where the author got
this in his mind...
Code example
This discussion is now obsolete, with the advent of template member
functions, allowing smart pointers to be polymorphic.
Anyway, the code provided here:
class Bar: public Foo { ... }; Ptr<Bar> pf1(new Bar); Ptr<Foo> pf2 = pf1;..has never worked on any decent compiler! (I wonder on which compiler it has been checked). It involves two user defined conversions (well, one conversion and one constructor) which a compiler is required not to try (and has consistently been at least since the ARM).
Here, a private copy constructor is defined, which should never be called. It would be simpler and better to only declare it. This is a pretty common advice!
A comment about copy constructors with which I fully disagree. It misses completely the case of classes with reference semantics. For these (IMHO the vast majority of classes), the normal rule should be to disable copy construction.
The coverage of double (and multiple) dispatch is reasonable, including the discussion. The developments later (p 268) are IMHO more disputable.
The call to delete pointee
in the assignment operator
will dump core: it deallocates memory from the pool!??? Quite
surprising basic error. It should call the pointee destructor, as in
the PoolMP destructor.
The master pointer-based use of operator new with arguments is IMHO a recommedable and interesting technique (something positive!)
Hear! Hear! The last paragraph introduces a terminology
--inside-out architectures-- to design Operation-based
frameworks.
Something I can refer to! Of course, his Operation is a plain class,
instead of a template (weak typing!), but this is the same idea
nevertheless.