From: Larry Evans (cppljevans_at_[hidden])
Date: 2006-08-31 17:28:06
On 08/31/2006 03:07 PM, Paul Mensonides wrote:
>>-----Original Message-----
[snip]
>>>smart pointer so that it doesn't require a double
>>>allocation.)
>>
>>I assume you mean one which doesn't use an intrusive
>>refcount, IOW, uses a "detached" refcount like the existing
>>shared_ptr? IOW, with the current shared_ptr, an one
>>allocation is for the pointed-to object, the other is for the
>>refcount.
> Yes, basically you have the smart pointer allocate the
> pointed-to-object itself as a data member of a struct that also
> contains the reference count. E.g.
> template<class T> class smart_ptr {
> // ...
> private:
> struct data {
> unsigned long rc;
> T value;
> } * p_;
> smart_ptr(data* p);
> };
> You need a forwarding contructor on the 'data' structure to directly
> initialize the 'value' member. You also need a forwarding function
> on whatever takes the arguments from clients--so the resulting
> syntax looks something like:
> smart_ptr<X> p = make_ptr<X>(a, b, 123);
> The make_ptr<X> function has to construct a 'smart_ptr<X>::data'
> object and initialize a smart_ptr with it and return that smart_ptr.
The above make_ptr<X> is close to the managed_ptr::
auto_overhead<X,ulong_rc> where:
template<class>
struct ulong_rc
{
unsigned long rc;
};
and instead of:
smart_ptr(data* p)
there would only be:
smart_ptr(auto_overhead<T,ulong_rc>& a_auto)
IOW, auto_overhead is simply derived from auto_ptr with the pointee
being an instance of the managed_ptr::
overhead_referent_vals<ulong_rc,T>. IOW,
overhead_referent_vals<ulong_rc,T> corresponds to your
smart_ptr<T>::data. The reason for the elaborate overhead_referent_*
classes is to allow different smart_ptr policies, e.g. to allow strong
and weak pointers. The reason for disallowing:
smart_ptr(overhead_referent_vals<ulong_rc,T>*)
is to never expose a raw pointer to the client.
> One problem of forwarding is arity (which can be more-or-less solved
> with code generation). The more stubborn problem with forwarding is
> temporaries. They cannot be bound to a non-const reference, and the
> template mechanism cannot deduce T as const U in a parameter of type
> T&. OTOH, non-temporaries don't have any problem deducing T as U or
> const U in a parameter of type T&.
Yeah, I had that problem which is why the a_auto above is not 'const &'.
I remember some attempt at a workaround, but can't remember the
details or even if it worked.
> Unfortunately, the only way to handle it transparently is to
> overload via cv-qualifier--which leads the the combinatorial
> explosion when multiple parameters are involved.
:(
>
>>the workaround implemented with the help of
>>managed_ptr_ctor_forwarder.hpp:
>>
>> http://tinyurl.com/o7zlg
>>
>>generates CTOR's of the form:
>>
>> template
>> < class VecOfTypes
>> >
>> ctor_this_type
>> ( VecOfTypes const&
>> , mpl::at_c<VecOfTypes,0>::type a0
>> , mpl::at_c<VecOfTypes,1>::type a1
>> , ...
>> , mpl::at_c<VecOfTypes,n>::type an
>> )
>> : ctor_base_type
>> ( a0
>> , a1
>> , ...
>> , an
>> )
>> {}
>>
>>IOW, the client has to specify the "signature" of the
>>ctor_base_type CTOR via a single VecOfTypes template arg to
>>the ctor_this_type CTOR. The justification for this was that
>>the client would have to know which ctor_base_type CTOR he
>>wanted anyway, so it would not be that much of a burden for
>>him to name it, indirectly, by supplying the "signature".
>
> I'm not sure why you need to add this into each class (rather than
> just to the smart-pointer-related interfaces).
Sorry I was unclear. This above is only needed for the auto_overhead
class. IOW, replace ctor_this_type with auto_overhead and
ctor_base_type with Referent from auto_overhead<Referent,Overhead>.
Of course it's a little more complicated, but that's essentially
what's happening with the MANAGED_PTR_CTOR_FORWARDER_OVERLOAD macro
invokation in the middle of the auto_overhead class definition.
> It may be that we're not talking about the same thing, but the
> smart_ptr facilities above could be designed without *any* intrusive
> requirements on the type pointed-to
Likewise, auto_overhead does not have *any* intrusive requirements
since the only allocation is for
overhead_referent_vals<ulong_rc,pointee_type>.
> and without *any* manual listing of argument types by the client.
> Granted, you can only support a fairly low number of parameters
> (larger if you ignore volatile).
And this, AFAICT, is the advantage of make_ptr vs. auto_overhead.
IOW, auto_overhead does have to supply, as mentioned in my previous
post, the signature (VecOfTypes in the above code) of the desired
"target" CTOR.