[rch]

Not so sure about that... Consider the Template Numerical Toolkit: extending it would be Bottom while using it would be Top (reference counting, overloaded for for both row-major or column-major array access, etc.).

C# takes things several steps further down the road.

http://math.nist.gov/tnt/

[eru]

By the way, why do C++ people seem to think that reference counting is a good idea?

[Silhouette]

It is a useful idea, because it allows a certain amount of automation/defensive programming but without the complexity and potentially unpredictable performance of using a full garbage collector. For the kind of job where C++ is still a good choice of programming language, that might be the right balance.

[arghnoname]

It's fairly easy to do in C++ with constructors/destructors and smart pointers.

[gaius]

Because in some situations you can't tolerate GC pauses.

[gigamonkey]

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.)

[NickPollard]

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.

[sambeau]

Generally, that will still be far smaller than copying every object pointed to on the stack.

[eru]

Maybe, but what does that have to do with the discussion? Only because there are copying garbage collectors, doesn't mean you have to use one.

[rch]

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.

[blub]

If speed requirements are so tight you should preallocate the memory. GC is completely out of the question.

[rch]

In TNT the goal is memory-efficiency. Maybe I should have said weak-reference assignment instead?