4 ms·

Would it be conceivable to implement Automatic Reference Counting for C/C++? Basically gets you the advantages of GC without the performance impact of GC cycles

• andrewchambers 11y ago
  Don't you know about the std:: smart pointers?
  • antimagic 11y ago
    ARC actually has some interesting advantages over smart pointers. For one, there is a large amount of static analysis done at compile time that allows the system to avoid unnecessary increment/decrements of the reference counter - this can have significant performance improvements in tight inner loops, and can't be achieved using smart pointers.
    • plorkyeran 11y ago
      My experience has been that the awesomeness of ARC's optimizations is greatly overstated. The compiler inserts retain/release pairs around every operation that could potentially need them, and then the optimizer eliminates the redundant ones. Pretty much the only interesting nonlocal optimization it does it turn autoreleased return values into retained returns, which isn't an issue for shared_ptr to begin with.
    • pjmlp 11y ago
      Nothing in ANSI C++ forbids compiler vendors to make their compilers *_ptr<>() aware, but AFAIK none of them take advantage of it.
• flohofwoe 11y ago
  RAII in C++ solves the same problems as ARC in Obj-C, just don't use raw pointers but smart pointers. But having said that, both approaches are bad. ARC is sort of a crutch in Objective-C because objects are usually (mostly? always?) created on the heap (C++'s equivalent would be new() or make_shared()), but in C++ it is possible (and good style) to minimize this type of 'fine-grained' heap-object usage as much as possible, otherwise you have this huge soup of tiny objects all over the place and a lot of pointer-chasing and cache misses, good luck getting sensible performance out of this mess. It's usually a broken C++ coding-style like this when Java-, C#- or Objective-C benchmarks can claim that they are 'even faster then C++' ;)
• vidarh 11y ago
  Any garbage collection algorithms (of which reference counting algorithms is a subset) for C/C++ need to deal with the fact that it is not possible to do a fully generic gc for C/C++ without either a) being conservative (that is, you will miss out on some memory) or b) putting additional constraints on the developers that the language doesn't. So yes, you can do ARC for C/C++, but it would need to be opt-in, and it would not be sufficient for all memory allocation in C/C++ because the moment you link in a third party library that doesn't play ball you need to do things differently. The chosen approach in C++ has largely "smart pointers" - template classes that implement various reference counting semantics - coupled with RAII. E.g. one part of the problem for a fully generic solution in C/C++ is that in C/C++ nothing stops you from taking an arbitrary bit-pattern and treating it as a pointer and vice versa. As an example, take BPTR's in AmigaOS - core parts of AmigaDOS were written on contract due to time constraints, and they were written in BCPL, and that's where they came from. BPTR's were pointers that had been bit-shifted right two bits - basically BCPL was treating memory as an array of 32bit quantities. So a lot of pointers in AmigaOS are stored in memory as values that don't actually match any memory address. So one hand your compiler don't know when/where to apply a reference count, and on the other hand a generic non-ref-counting gc won't know whether or not any specific value is a pointer, and if so whether it meant to point at the actual memory address indicated by the value or if it needs to be bit-shifted. In C this is perfectly legal. But to gc apps that do stuff like that, your gc must either be smart enough to figure out every possible pointer manipulation (meet the halting problem, it wants to have a word), or it needs explicit support from the developer.
• vardump 11y ago
  Reference counting? What about scalability, if you have more than a few CPU cores? You know how expensive atomic fetch-and-add (aka LOCK XADD) is, right? Atomic compare-and-swap loop is even worse. Put simply, those things broadcast coherence information on inter-core (and inter-processor) network. It's ok for a low number of cores, but this solution just won't work well with more CPU cores. Good for a mobile phone with two cores.
• pjmlp 11y ago
  C++/CX does ARC for C++ for those of us on Windows, but it comes with the cost of making C++ classes into COM ones.
  • deleted 11y ago
    [deleted]