quote:Okay so i have sat down and tried to understand your version
To little effect, apparently.
quote:as far as i can tell, it just uses an iterator to tell where in the list to delete, however where do i get that iterator from?
No, you''ve completely misunderstood the purpose.
The principle problem with using a std::list to contain pointers is that operations which remove elements don''t delete what the pointers point to. Similarly, destroying the list entirely doesn''t delete any pointed-at elements.
What my code does is redress these issues. The destructor deletes each element in the list, and the list members which remove list elements also delete the element they''re about to remove.
quote:i would presumably need to search the list for it in the first place, or have everything keep track of iterators to objects instead of pointers to them. However, as far as i understand it an insert and delete operation invalidates all iterators, so that wouldnt work.
Then you''re pretty ignorant of the guarantees a list offers. The only operation that invalidates list iterators is erasing the entry the iterator refers to. Insertions invalidate no iterators at all, removals invalidate only iterators referring to the removed element.
quote:say i have a class A, lots of people are creating and using class A''s, each person calls a function to create one, that creates it and adds it to a linked list, and returns the pointer, they can use the pointer to do whatever they want with A
now when it comes to destroy a, it needs to be removed from the linked list, under STL, that means somewhere, the list needs to be searched for the pointer to A.
But that''s no problem -- the function just returns an iterator. They can then use the iterator to do whatever they want with the object. When they want to destroy the object, it needs to be removed from teh list, so they can simply pass the iterator to the complementary function to their "create object and add it to a list" function -- a "destroy object and remove it from a list" function.
quote:now by including the next and previous pointers inside the object itself, the list never needs to be searched, instead it just needs to be unlinked which is easy enough as we have direct access to the previous and next pointers.
This can be achieved with a normal list and an iterator instead of a raw pointer.
quote:I dont need extra allocations for my list, there is a single allocation for the object, there doesnt need to be a second allocation for a block just to store a pointer to my "object" and the pointers to the next and the previous item in the list.
But you will need multiple allocations so that each element can store its position in an arbitrary number of lists -- your current mechanism by which you limit the number of lists an element can be in seems frankly bizarre.
quote:a) because i can?
That doesn''t appear immediately obvious.
quote:b) so that i can do complete, efficient memory tracking with file and linenumber support, time of allocation etc,
I''m not sure why any of those things need a custom memory allocator.
quote:so i can customize allocation where needed,
Wouldn''t it be prudent to determine the need
first and
then write the allocator?
quote:so i can add electric fence/bounds checker type support if required.
Your platform has no pre-existing support for such a thing?
