4 ms·

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

by rch 15y ago

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/ http://math.nist.gov/tnt/

eru 15y ago
By the way, why do C++ people seem to think that reference counting is a good idea?
- gaius 15y ago
  Because in some situations you can't tolerate GC pauses.
  - gigamonkey 15y ago
    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.)
    - blub 15y ago
      If speed requirements are so tight you should preallocate the memory. GC is completely out of the question.
    - sambeau 15y ago
      Generally, that will still be far smaller than copying every object pointed to on the stack.
      - eru 15y ago
        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.
    - NickPollard 15y ago
      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.
    - rch 15y ago
      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.
- Silhouette 15y ago
  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 15y ago
  It's fairly easy to do in C++ with constructors/destructors and smart pointers.
- rch 15y ago
  In TNT the goal is memory-efficiency. Maybe I should have said weak-reference assignment instead?

by rch 15y ago

eru 15y ago

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

gaius 15y ago
Because in some situations you can't tolerate GC pauses.
- gigamonkey 15y ago
  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.)
  - blub 15y ago
    If speed requirements are so tight you should preallocate the memory. GC is completely out of the question.
  - sambeau 15y ago
    Generally, that will still be far smaller than copying every object pointed to on the stack.
    - eru 15y ago
      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.
  - NickPollard 15y ago
    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.
  - rch 15y ago
    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.
Silhouette 15y ago
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 15y ago
It's fairly easy to do in C++ with constructors/destructors and smart pointers.
rch 15y ago
In TNT the goal is memory-efficiency. Maybe I should have said weak-reference assignment instead?