$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
From: Jason Hise (chaos_at_[hidden])
Date: 2005-05-10 16:14:22
Rob Stewart wrote:
>From: "Pavel Vozenilek" <pavel_vozenilek_at_[hidden]>
>  
>
>>"Rob Stewart" wrote:
>>
>>    
>>
>>>>>1. Creator policy is redundant with the standard Allocator concept, I
>>>>>think. Though the standard Allocator concept has some subtle, tricky
>>>>>semantics, I think it's nevertheless worth using: that would permit
>>>>>interoperability with existing allocator implementations.
>>>>>
>>>>>          
>>>>>
>>>>Thinking it again: you are likely right here.
>>>>
>>>>Handling of constructor arguments could be separated
>>>>from allocation.
>>>>        
>>>>
>>>I don't know about that, but perhaps an adapter could be provided
>>>to make a standard allocator look like a creator?
>>>
>>>      
>>>
>>I should be possible w/o adapter. Just expecting std::allocator like
>>parameter in template.
>>    
>>
>
>That's only true if you separate the construction functionality
>from the allocation.  If you can't for some reason (I haven't
>looked to see whether it is possible), an adapter can rely on the
>allocator for its memory management.
>
Just to make sure... have you looked at create_using_std_allocator?  It 
is designed to make it easy to use anything that fits the description of 
a standard allocator, and allows you to specify whether or not failed 
allocation (returning null) results in a bad_alloc exception being thrown.
I personally do not feel that creation and allocation are redundant.  
Allocation is initialization of memory, and creation is the 
initialization of an object.
Additionally, I feel that it is important that creators be easy for 
client code to write when necessary.  The current interface required for 
a singleton creator is, IMO, much simpler to meet than the interface for 
a standard allocator.  Being able to write a creator makes it easy to 
wrap other existing libraries with singletons relatively quickly.
-Jason