Hey Dave, have you ever run into a situation though where you needed complex interdependencies between smart pointers to a point where you were making circular references without being aware of it?
I've always used them mainly to avoid having to write destructors and also as temporaries in functions so that if an exception it thrown or some other condition causes me to leave the function abruptly, I won't have to remember to deallocate it. While I haven't written any truly large scale systems yet, I have used C++ for a good 6 years (and very frequently on a dialy basis as well) and I've written a few online games that spanned a little over 200k lines of code for all the different editors, servers, and client code and I've never had a need for smart pointers to an extent where I ran into any serious problems like this.
On a side note, I hated C++ for quite a while before I began to appreciate some of its finer features. I was far more into Pascal, BASIC(bleh) and Java when I first started using it and thought C++ code was just plain ugly and unnecessarily complex. I felt I could write better applications faster in other languages, though now I feel the opposite. I now feel like I can write many applications better and faster in C++ than in C# or Java, though there are still applications where I prefer Java or C# instead - especially ones with complex GUIs. Nevertheless, this is because of the libraries that come with C# and Java more so than the true language features themselves. If I omit the libraries and focus only on the language features, however, I think I can almost undoubtedly write more efficient applications with less code that's also more manageable and more reusable in most situations using C++.
Getting back to the point, I think circular references and other issues can be completely avoided, however, to a point where you don't even have to worry about them.
There was a time when I wanted to use a smart pointer to enable me to work with multiple, modifyable instances of a single point/polygon (I was working on a geometry plugin for Lightwave). I wanted the memory for a point or polygon to be deallocated when all instances were no longer in use. Containing all the point and polygon object instances in reference-counted smart pointers seemed like the way to go, but upon thinking further, I found a much easier solution by making the internal members of the point and polygon classes contained in a smart pointer. Simplified example:
class Point
{
private:
shared_ptr<SomeType> data;
/* ... */
};
Now I could just essentially shallow copy the internal data of the point without having to deal with the smart pointer in the client:
Point p1(some constructor arguments);
Point p2 = p1;
As opposed to doing this:
class Point
{
private:
SomeType data;
};
shared_ptr<Point> p1 = new Point(some constructor arguments);
shared_Ptr<Point> p2 = p1;
Looking back at the first example, I did not need to ever copy points, only allow multiple instances to the same one, but if I needed to, I could have made an explicit clone method like the ones provided in the object class in .NET that makes a deep copy.
The first example made it so that the actual point and polygon instances(as visible from the client's perspective) did not have to be allocated dynamically. They could be copied, passed, and returned all over the place by value, yet they would naturally just be shallow copied into multiple instances of the same data(because the internal members of the class were managed by a smart pointer).
Therefore, the smart pointer was encapsulated in the class, and I was still able to have multiple objects of a Point by copying/passing/returning by value. The problem with the second version is that it becomes the responsibility of the client code outside the class to handle the shallow copying, and I imagine it's when this happens that you end up getting smart pointers to objects which contain smart pointers which contain smart pointers and so forth.
The fact that the smart pointers weren't exposed in the first example allowed me to avoid having to worry about complex things like making smart pointers that point to smart pointers and the client didn't have to worry about using smart pointers either.
Simiarly, if objects of Point were needed for another class, I wouldn't have to worry about having to use smart pointers in that class, and I imagine the problem of circular references will be virtually wiped out this way.
By using solutions like this to make memory management contained fully inside a class and avoiding the need to deal with memory management issues outside the class, I don't think you would ever run into a stumbling block or have to worry about the possibility of circular references or any other difficulties.
Take the example you showed me, for instance, of how to prevent the destructor from being called through a circular reference. While I know the example was meant to just be a simple thing to demonstrate how this would happen (and I'm sure the real situations the problem occurs in are extremely more complex), the problem simply wouldn't exist if you avoided making instances of the class containing the data managed by a smart pointer and instead made only the primitive data at the lowest level of the hierarchy managed by a smart pointer (and nothing else). When you do this, you never have to worry about the destructor of an object not being called because dynamic allocation and smart pointers simply won't be involved at all when creating instances of these objects.
Also, you probably knew this and just wanted to illustrate the possibility of it happening, but in your example, it simply wouldn't make sense to make a smart pointer of IDontWantToDie since its member is already contained in a smart pointer. There's no need to make a smart pointer to something in which its data is already shallow copied and reference-counted in the first place.
Still, I acknowledge the fact that it is a problem, though I think there are always ways to work around it or even avoid it completely in the first place. I do think C#'s GC method is handy, but I don't think it or any other features in C# make it clearly better because C# is missing a few really great features that are offered in C++. I think both languages can be equally matched considering their various strengths and weaknesses.
I think the two biggest things missing in C# that I miss from C++ are:
1) A means of statically generating similar code with only small vartiations(i.e, templates)
2) The ability to mix procedural programming with object-oriented programming. Some may view this as a bad thing, but I think the C++ STL demonstrates how the two can work in harmony.
There are also a number of smaller things like multiple inheritance.
Like you said earlier, I also like to manage stuff myself sometimes where I know the lifetime and ownership. In fact, the majority of the time I want to be able to do this. I think the ideal solution would be to have the option of using GC without being required to. C# could just provide it as another type of smart pointer that has built-in language support for its garbage collection methods or work like managed C++ and let you use keywords to specify whether a certain class has automated garbage collection or not.
- David Ikeda
[edited by - nyugfu on February 19, 2004 9:21:07 PM]
) can be done automatically in C++ Builder for example, at the click of a mouse. 
