Re: [boost] Re: what happened to allocators in boost?

From: Gregory Colvin (gregory.colvin_at_[hidden])
Date: 2003-08-29 08:43:36

On Friday, Aug 29, 2003, at 00:52 America/Denver, E. Gladyshev wrote:
> --- Gregory Colvin <gregory.colvin_at_[hidden]> wrote:
>> On Thursday, Aug 28, 2003, at 23:48 America/Denver, E. Gladyshev 
>> wrote:
>
>>> *pseudo-code*
>>>
>>> template< typename T >
>>> sturct  my_allocator
>>> {
>>>    my_heap_control _heap;
>>>
>>>    T* create()
>>>    {
>>>       return _heap.create();
>>>    }
>>>    void operator()( T* d )
>>>    {
>>>       _heap.destroy(d);
>>>    }
>>> };
>>>
>>> Now if I do something like the following code (that looks perfecly
>>> fine).
>>>
>>> f()
>>> {
>>>   my_allocator<int> a;
>>>
>>>   {
>>>      shared_ptr<int> s( a.create(), a );
>>>      ...
>>>      int* n = a.create();
>>>      a(n);
>>>   }
>>> }
>>>
>>> I got a problem, because by the time when 's' deletes my data
>>> the heap state is changed while 's' still has an old copy
>>> of the heap state.
>>>
>>> * If we state that boost allocators must be implemented
>>> like statless policies not like real data types,
>>> this problem is not a big deal.
>>
>> I am not understanding the above at all, maybe because I don't
>> know what you mean by "heap control block" or "stateless policies"
>> or "real data types".
>
> I called "stateless policies" data types that define some actions
> (policies) that never change the state of any of this data
> type instances.
>
> The "heap control block" is a data type that manages
> the state of a memory heap.  For instance it can keep
> a list/directory of pointers to free block in the heap.
>
> No imagine the the my_allocator has a list of pointers
> to free memory blocks in some memory heap.
>
> template< typename T >
> sturct  my_allocator
> {
>        char** _freeblocks[100];
> };
>
> When you write
> shared_ptr<int> s( a.create(), a );
>
> 's' will create an internal copy of 'a'.
>
> The internal copy will have a copy of _freeblocks[100];
>
> Now we create a new object, that changes the state of _freeblocks[100]
> int* n = a.create();
>
> Next, 's' goes out scope and deallocates its object using
> its own copy of _freeblocks[100] but this copy is already bad.
> It doesn't represent the current configuration of free blocks
> in the heap.
>
> Does it make sense?

Not to me.  Sounds like a very broken allocator design.