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
>>> template< typename T >
>>> sturct my_allocator
>>> my_heap_control _heap;
>>> T* create()
>>> return _heap.create();
>>> void operator()( T* d )
>>> Now if I do something like the following code (that looks perfecly
>>> my_allocator<int> a;
>>> shared_ptr<int> s( a.create(), a );
>>> int* n = a.create();
>>> 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;
> 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;
> Now we create a new object, that changes the state of _freeblocks
> int* n = a.create();
> Next, 's' goes out scope and deallocates its object using
> its own copy of _freeblocks 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk