[boost] Re: new_policied (was Re: shifted_ptr review)

From: Fernando Cacciola (fcacciola_at_[hidden])
Date: 2003-10-07 15:05:10

cppljevans_at_[hidden] wrote:

>> On 10/01/2003 09:17 PM, Fernando Cacciola wrote:
>> [snip]
>>>
>>> FWIW, this is already supported by Boost.Optional.
>>> The syntax is: in_place(a0,a1,a2), or in_place<T>(a0,a1,a2) for
>>> Variant.
>>> The code is already in main CVS: boost/detail/in_place_factory.hpp
>>> and typed_inplace_factory.hpp
>>>
>> I'm having trouble using this code.  The attachment contains what I
>> want to do with in_place<T>, but somehow, I can't figure how to
>> used in_place(a0,a1,a2) instead of new_policied(a0,a1,a2).  In other
>> words, just as in_place can be followed by an arbitrary number of
>> parameters up to a maximum (I think), I'd like somehow to do the
>> same with new_policied.  The purpose of new_policied is to avoid
>> some of the dangers of shifted pointer by explicitly allocating
>> the StoragePolicy along with the Referent, and storing the result
>> in auto_ptr.  This auto_ptr would then be passed to the shifted_ptr
>> CTOR; thus assuring the StoragePolicy preceded the Referent.
>> The StoragePolicy might be reference counting or reference linking
>> or shifted_ptr's shifted_header or just a bit for mark-scan garbage
>> collection.
>>
>> Any ideas how to enable an arbitrary number and types of args to
>> new_policied CTOR?
>>

Hi, sorry for the late response, I've been busy as usual.

I don't think I undestand your problem.

What doesn't work with new_policied.cpp exactly?

The code in the attachement alone looks fine to me,

so why desn't it work?

FWIW, the difference between new_policied() and in_place() is that new_policied is not storing the arguments itslef but rather
constructing the Referent on the fly (while in_place() creates an object that merely stores arguments to be used by a
specialized subject constructor).

Fernando Cacciola