> It is safe. The commas in the member initialisation list> are sequence points. Therefore in the example the first> SomeResource will be allocated, constructed and assigned> to p_ before the second SomeResource begins construction.>

No, the commas are *not* sequence points. The order of initialization is defined in the data-member list for the class. E.g.

struct T{ T() : p( new X ), q( new X ) { }

X * q; X * p;};

q is *always* initialized before p.

In the article, the order of the members matched the order in the initializer list, so all is fine - and no confusion to anyone.

> >It couldn't, due to the copy assignment operator.> Hmm, I don't quite understand where the problem is.

The problem in the general case is that the auto_ptr must always own a dynamically allocated object that supports (copy) assignment.

In this case, the above is always true, so const auto_ptr would indeed have worked.

> Well scoped_ptr and const auto_ptr<> are more or less the> same.

There are a couple of differences that I think are important:

* A scoped_ptr can be reset, a const auto_ptr cannot. * A const auto_ptr requires the reader of the code to recognize the importance of the constness, whereas scoped_ptr is always true to its name, and simply does not transfer ownership, period.

> When the object is copied, you will either want to have> reference counting or deep copy semantic for its owned> resources.

Yes.

> If you opt for reference semantics, a suitable smart> pointer can just do it.

Exactly.

> To enable deep copy semantic, the smart pointer would need> to accept some copy mechanism function (object) pointer.> You would either use a creation function rsp. a factory> function if a specific type has to be created, or make use> of the clone idiom if a polymorphic copy is needed. (If> you are not afraid of Mad COW Disease, you could even try> to figure out a generic COW solution.)

There are variations and techniques relating to create/clone/copy that make it possible to cover many use cases with little or no extra effort on behalf of the user.

> Some very special cases might remain unsolved, but often> the "Rule of The Big Zero" would be a good - and probably> very attractive - solution.

I agree. The general case is the "Law of the Big Three". The typical case is the "Law of the Big Two". The ideal case is the "Law? What Law?", but it typically comes at a cost in space and/or time (that may or may not be acceptable). More on this interesting topic in a future installment...

> Hello Uwe,> > > Why stop here?> > > > Why not make it "The Rule of The Big Zero"?> > Hey, have you been reading through my drafts? ;-)

No, I've been reading your mind. ;-)

Sometimes, a C++ programmer MUST dive down through all these levels of abstraction, to get the optimum efficiency.

> > When the object is copied, you will either want to have> > reference counting or deep copy semantic for its owned> > resources. > > Yes.> > > If you opt for reference semantics, a suitable smart> > pointer can just do it. > > Exactly. > > > To enable deep copy semantic, the smart pointer would> need> > to accept some copy mechanism function (object)> pointer.> > You would either use a creation function rsp. a factory> > function if a specific type has to be created, or make> use> > of the clone idiom if a polymorphic copy is needed. (If> > you are not afraid of Mad COW Disease, you could even> try> > to figure out a generic COW solution.)> > There are variations and techniques relating to> create/clone/copy that make it possible to cover many use> cases with little or no extra effort on behalf of the> user.

Some of these techniques will look quite "alexandresque", won't they?

> > Some very special cases might remain unsolved, but> often> > the "Rule of The Big Zero" would be a good - and> probably> > very attractive - solution.> > I agree. The general case is the "Law of the Big Three".> The typical case is the "Law of the Big Two". The ideal> case is the "Law? What Law?",

This is sometimes called "true encapsulation".

> but it typically comes at a> cost in space and/or time (that may or may not be> acceptable). More on this interesting topic in a future> installment...

I think smart_ptr's are worth every penny and your law of big 2 will work most of the time. However if someone uses the law of the two in a base class from which a heirarchy of classes are derived then the 'virtual' aspect of the destructor will be lost. Also the compiler will generate non-virtual destructors for all derived classes. This will be a very bad thing.

Of course to correct this they need to declare the base classes' destructor virtual, in which case the compiler will generate virtual destructors

> > Of course to correct this they need to declare the base> > classes' destructor virtual, in which case the compiler> > will generate virtual destructors

> Well one school of thought recommends not deriving from> classes with no virtual DTR ;-) (or alternatively always> give classes you intend to be derived from a virtual DTR).

That's generally excellent advice in runtime polymorphic (aka "classic") C++ world. However, it's a little too coarse-grained, IMO. If you're dealing with types with value semantics, then they're not likely to be in a (well-written) runtime-polymorphic hierarchy. As such, you're unlikely to be deleting them, if at all, via base class pointers.

I think this is especially the case in template-world. It's very useful to be able to apply a compile-time adaptation to (value) types, via templates that inherit from their parameterising types. Again, such types are not going to be deleted by pointers to base class, so there's no need to encumber original class or composite with a vtable.

Naturally, it's open to abuse, but that's why I'm stressing value types. It's most certainly the case that this could be abused if applied to (runtime polymorphic) entity types.

Well that was my point ;-) Value types will not (generally) have virtual DTRs, so you shouldn't (generally) derive from them.

(And I don't know about "classic"; C++ has long been multi-paradigm)

But it's a good point, well made. The difference between Value and Polymorphic/Entity/... behaviour is often not stressed enough.

> > I think this is especially the case in template-world.> It's very useful to be able to apply a compile-time> adaptation to (value) types, via templates that inherit> from their parameterising types.

Yes. The "Curiously Recurring Template Pattern". The base classes are generally mixin types in this case, tho, and have no state, just behaviour.

> Again, such types are not> going to be deleted by pointers to base class, so there's> no need to encumber original class or composite with a> vtable.

Agreed. My own practice is to make the DTR protected and non-virtual in the base, thus preventing any misuse.

> > Naturally, it's open to abuse, but that's why I'm> stressing value types. It's most certainly the case that> this could be abused if applied to (runtime polymorphic)> entity types.

When I say "Classes you intend to derive from" I mean "Polymorphic and/or Entity Types"; I should have made that clearer. By Entity Types I mean types generally used to indicate behavioural contract, like Interfaces.

Well, I think the point I was making was that because value typesshould not be dealt with polymorphically anyway, there's no reasonto *not* derive from them, except for the fact that it might inclinethe unwary to start treating them polymorphically.

Personally, I'm quite happy with doing so via templates, but I stillget an uneasy feeling seeing it done in a non-template way. (Too muchexposure to clients' codebases containing classes deriving from std::string in order to provide an implicit conversionoperator a la CString. Groan ...)

> (And I don't know about "classic"; C++ has long been multi-paradigm)

Fair point. ;)

Maybe it's old farts like me that have spent so many years playingaround before templates were widely usable.

> But it's a good point, well made. The difference between Value and> Polymorphic/Entity/... behaviour is often not stressed enough.

Agreed. (<blatant>My new book does make this distinction, and looks a little deeply into the meaning of value types</blatant>)

> > I think this is especially the case in template-world.> > It's very useful to be able to apply a compile-time> > adaptation to (value) types, via templates that inherit> > from their parameterising types. > > Yes. The "Curiously Recurring Template Pattern". The base classes are > generally mixin types in this case, tho, and have no state, just behaviour.

While CRTP is most certainly an example of what I'm talking about, it'smore specialised. The idea I'm talking about is not necessarily recursive. It looks like the following:

In my book <sorry, I don't mean to be such a tool ;)> I discuss the conceptsof Veneers and Bolt-ins, which both follow this pattern. Veneers are thethings we're talking about here, for adapting/adorning value-types, sincethey are not allowed to add non-static member variables, and must respectthe polymorphic nature of their primary parameterising type.

An example from the STLSoft libs is the mfcstl::cstring_veneer, which adaptsthe old CString class into something with a std::basic_string<>-like interface,i.e. c_str(), iterators, etc.

> > Again, such types are not> > going to be deleted by pointers to base class, so there's> > no need to encumber original class or composite with a> > vtable.> > Agreed. My own practice is to make the DTR protected and non-virtual in the> base, thus preventing any misuse.

Agreed. Herb's new book - Exceptional C++ Style - talks about this specifically.

> > Naturally, it's open to abuse, but that's why I'm> > stressing value types. It's most certainly the case that> > this could be abused if applied to (runtime polymorphic)> > entity types.> > When I say "Classes you intend to derive from" I mean "Polymorphic and/or > Entity Types"; I should have made that clearer. By Entity Types I mean > types generally used to indicate behavioural contract, like Interfaces.

Yup. Or std::vector<> to get a public Length "Property". I've seen 'em!

> Maybe it's old farts like me that have spent so many years> playing> around before templates were widely usable.

>8^>

> In my book <sorry, I don't mean to be such a tool ;)>

OK OK, it's been on my to-get list for a while, I admit.

> discuss the concepts> of Veneers and Bolt-ins, which both follow> this pattern.

These (and CRTP) are arguably expert-level, best kept well under the covers. STLSoft is a library, and these techniques have a place there, in much the same way as allocators in the Standard Lib (albeit with more utility ;-).

> [me] ...so you shouldn't (generally) derive from them.

hence the "generally".

> > Agreed. My own practice is to make the DTR protected and> non-virtual in the> > base, thus preventing any misuse.> > Agreed. Herb's new book - Exceptional C++ Style -> talks about this specifically.

Well I don't have that book, but I definitely picked up the technique from Herb amongst others. Kevlin Henney seems a likely candidate.