From: Philippe A. Bouchard (philippeb_at_[hidden])
Date: 2003-10-05 13:55:30
Douglas Gregor wrote:
> On Sunday 05 October 2003 10:03 am, Philippe A. Bouchard wrote:
>> Let's discuss the "ownership" paradigm:
>> + perfect solution for 1d / 2d / nth d containers, ropes, neural
>> networks, etc.;
>> + is able to play the role of an auto_ptr<> and a weak_ptr<> at the
>> same time;
>> - it is possible to create dangling smart pointers in this case
>> (dangling "weak_ptr<>s");
>> - cannot be easily casted to other pointee types.
> I don't believe I know the ownership paradigm; have a reference
> handy? And, of course, that last bit worries me greatly: what kind of
> casting restrictions are we talking about?
>>> 1) Do you really need BOOST_GC_DEACTIVATE, if could users just
>>> instead switch over to something like shared_ptr if they really
>>> don't want to use GC? There's no need to allow (or require users to
>>> understand) customization when alernatives already exist.
>> If someone wrote his program with shifted_ptr and suddenly decides to
>> accelerate his program he could simply define this macro, recompile
>> & tada! it works like a normal reference count smart pointer &
>> becomes faster.
> Garbage collection can be faster than reference counting, but it all
> depends on usage patterns. For instance, my GC-needing application
> has a phase where it allocates a ton of memory, much of which won't
> be needed later. The next phase runs over the internal representation
> many times (typical compiler/static analyzer behavior).
> Reference-counting would be a killer here, because in the second
> phase we incur all of the overhead of reference counting but get
> little benefit from it, because memory isn't being
> allocated/deallocated much.
> I don't know where you want to take shifted_ptr, but I'm of the
> opinion that it should do one thing (well). Macros aren't the place
> to support major shifts in program behavior. If the user wants to be
> able to switch between different smart pointers, she can use typedefs
> or policy-based pointers that allow such things.
If I disable threads and I am using non-polymorphic types, the following
code will be added each time an object is shared (compiled using gcc 3.2.3):
0x8048da8 <main+360>: test %eax,%eax
0x8048daa <main+362>: mov %eax,0xffffffd8(%ebp)
0x8048dad <main+365>: movl $0x8,0xffffffa8(%ebp)
0x8048db4 <main+372>: je 0x8048dbc <main+380>
0x8048db6 <main+374>: incl 0xfffffff8(%eax)
Accessing the object is a single machine instruction so it is true it
depends what you are doing and the required time to allocate is no more than
a pure garbage collector. But at this level the resulting overalls could be
So what I am earing right now is that shared_ptr / weak_ptr can replace the
ownership alternative of shifted_ptr (as Larry have mentionned). Thanks for
BTW: NRC is just across the river ;)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk