reference-counting

std::shared_ptr needs to allocate a control block on the heap which holds the reference count. There was another approach I learnt from http://ootips.org/yonat/4dev/smart-pointers.html which keeps all the references in a doubly linked list. It doesn't need additional allocations nor a counter but the reference object itself is larger. Is there a benchmark or any clear reason showing one implementation is better than the others? The standard does in theory allow a linked list to be used, but because copying a shared_ptr must be threadsafe it would be harder to implement that with a linked list.

Please have a look at the following code: #include <pthread.h> #include <boost/atomic.hpp> class ReferenceCounted { public: ReferenceCounted() : ref_count_(1) {} void reserve() { ref_count_.fetch_add(1, boost::memory_order_relaxed); } void release() { if (ref_count_.fetch_sub(1, boost::memory_order_release) == 1) { boost::atomic_thread_fence(boost::memory_order_acquire); delete this; } } private: boost::atomic<int> ref_count_; }; void* Thread1(void* x) { static_cast<ReferenceCounted*>(x)->release(); return NULL; } void* Thread2(void* x) { static_cast<ReferenceCounted*>(x)->release(); return

I'm curious because I couldn't find out about this on MSDN. I've found the Release() function is present in various COM objects which I'm obviously supposed to use for deleting pointers. But I'm not sure what does it return exactly? I used to think it would return the number of references which still exist to the object remaining, therefore something like: while( pointer->Release() > 0 ); Would obviously release all references to that pointer? Or am I not seeing something? *note I'm talking about this from the concept of the IDirect3DTexture9::Release() function Your theory is true. COM memory

I have always wondered why the garbage collector in Java activates whenever it feels like it rather than do: if(obj.refCount == 0) { delete obj; } Are there any big advantages to how Java does it that I overlooked? Thanks Each JVM is different, but the HotSpot JVM does not primarily rely on reference counting as a means for garbage collection. Reference counting has the advantage of being simple to implement, but it is inherently error-prone. In particular, if you have a reference cycle (a set of objects that all refer to one another in a cycle), then reference counting will not correctly

in this example procedure foobar; var tab:array of integer; begin setlength(tab,10); end; is the array destroyed or the memory is leaking? The memory is freed. (That is, no memory leak!) The array is automatically freed, but I've seen obscure cases where it isn't for some reason. I solved it by setting the array to nil. 来源： https://stackoverflow.com/questions/3113296/is-a-dynamic-array-automatically-deallocated-when-it-goes-out-of-scope

This is a very Delphi specific question (maybe even Delphi 2007 specific). I am currently writing a simple StringPool class for interning strings. As a good little coder I also added unit tests and found something that baffled me. This is the code for interning: function TStringPool.Intern(const _s: string): string; var Idx: Integer; begin if FList.Find(_s, Idx) then Result := FList[Idx] else begin Result := _s; if FMakeStringsUnique then UniqueString(Result); FList.Add(Result); end; end; Nothing really fancy: FList is a TStringList that is sorted, so all the code does is looking up the string