--- Gregory Colvin <[EMAIL PROTECTED]> 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.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
