But you can tolerate ref counting pauses? (When you release the last reference to the last object keeping a large tree of objects alive and have a lengthy cascade of objects being freed.)
If you use reference counting for a full tree hierarchy of objects, then you have to expect that.
The point is that sometimes in C or C++ you have a small, flat selection of objects that you want to dynamically create and destroy, whilst everything else falls into fairly stable patterns than can easily be handled manually.
An example from my field; computer games: It's quite common for game engines to use reference counting for resources such as textures. These days, it is very common for textures to be streamed into and out of memory during gameplay, either because it's a large game-world with whole sections being streamed, or simply for LoD (level-of-detail) reasons - objects in the distance have low resolution textures, when they get closer they become higher resolution.
To handle this, it's common to have a pool of textures that use reference counting, and every model/renderable that uses a particular texture increments or decrements the refcount as appropriate. The texture itself is just a flat blob of data, so when a texture is freed, there's no worry of large cascading frees.
This approach is very simple and easy to implement when you only want it on a small selection of the program.
When it matters, I'm usually keeping a pool of de-referenced objects around anyway, so I can just reinitialize rather than allocate... memory is explicitly managed, not blindly RCed/GCed.
The point is that sometimes in C or C++ you have a small, flat selection of objects that you want to dynamically create and destroy, whilst everything else falls into fairly stable patterns than can easily be handled manually.
An example from my field; computer games: It's quite common for game engines to use reference counting for resources such as textures. These days, it is very common for textures to be streamed into and out of memory during gameplay, either because it's a large game-world with whole sections being streamed, or simply for LoD (level-of-detail) reasons - objects in the distance have low resolution textures, when they get closer they become higher resolution.
To handle this, it's common to have a pool of textures that use reference counting, and every model/renderable that uses a particular texture increments or decrements the refcount as appropriate. The texture itself is just a flat blob of data, so when a texture is freed, there's no worry of large cascading frees.
This approach is very simple and easy to implement when you only want it on a small selection of the program.