On 02/27/2012 02:29 AM, Martin Nowak wrote:
On Sun, 26 Feb 2012 20:26:41 +0100, Walter Bright
<newshou...@digitalmars.com> wrote:
On 2/26/2012 7:04 AM, Simon wrote:
On 26/02/2012 03:22, Walter Bright wrote:
On 2/25/2012 4:01 PM, Simon wrote:
On 25/02/2012 22:55, Walter Bright wrote:
Enter C++'s shared_ptr. But that works by, for each object,
allocating a
*second* chunk of memory to hold the reference count. Right off
the bat,
you've got twice as many allocations & frees with shared_ptr than
a GC
would have.
http://www.boost.org/doc/libs/1_43_0/libs/smart_ptr/make_shared.html
so you don't have to have twice as many allocations.
There are many ways to do shared pointers, including one where the
reference count is part of the object being allocated. But the C++11
standard share_ptr does an extra allocation.
The stl one is based on boost, so it has make_shared as well:
http://en.cppreference.com/w/cpp/memory/shared_ptr
and it's in vs 2010
http://msdn.microsoft.com/en-us/library/ee410595.aspx
Not that I'm claiming shared pointers are superior to GC.
At the GoingNative C++ conference, the guy who is in charge of STL for
VS said that it did an extra allocation for the reference count.
It's actually quite nice to combine unique_ptr and shared_ptr.
One can lazily create the refcount only when the pointers are shared.
Often one can get away with unique ownership.
Ok. Btw, if the utility is in charge of allocation, then the refcount
can be allocated together with the storage.
https://gist.github.com/1920202
Neat. Possible improvement (if I understand your code correctly): Don't
add the GC range if all possible aliasing is through Ptr.
