[llvm-commits] [llvm] r53210 - in /llvm/trunk: include/llvm/ADT/alist.h include/llvm/ADT/alist_node.h include/llvm/ADT/ilist.h include/llvm/Support/Recycler.h include/llvm/Support/RecyclingAllocator.h include/llvm/SymbolTableListTraits.h lib/Support/Allocator.cpp

[Chris Lattner]

On Jul 10, 2008, at 4:28 PM, Dan Gohman wrote:

>>
>>
>>> +// do not implement. this is to catch errors when people try to use
>>> +// them as random access iterators
>>
>> isn't it better to just not implement them?  Then people will get a
>> compile time error instead of a link-time one.
>
> The whole situation in LLVM with iterators and pointers being
> two-way implicit-convertable has its conveniences, but it has
> its dark sides too. If the above aren't declared, overload
> resolution will make different choices.

Ok

>>> +/// alist - This class is an ilist-style container that
>>> automatically
>>> +/// adds the next/prev pointers. It is designed to work in
>>> cooperation
>>> +/// with <llvm/Support/Recycler.h>.
>>
>> Would it be possible to replace ilist with this or merge alist and
>> ilist?  When would someone use ilist vs alist?  When would someone  
>> use
>> alist vs ilist?
>
> Currently, alist is mostly just like ilist except that it doesn't
> require
> the element types to provide their own next+prev pointers. And it's
> Recycler-friendly.

Could (aka 'would it make sense for') ilist be made to do this?

>>> +/// Recycler - This class manages a linked-list of deallocated  
>>> nodes
>>> +/// and facilitates reusing deallocated memory in place of
>>> allocating
>>> +/// new memory. The objects it allocates are stored in alist_node
>>> +/// containers, so they may be used in alists.
>>> +///
>>
>> Ok, if this is the motivation for alist, I have to ask: isn't it
>> easier to just not try to use pointers in the nodes?  Why not blast
>> over the first two words of the recycled memory with next/prev
>> pointers regardless of what the type is?  It seems that doing so  
>> would
>> simplify the design fairly substantially.
>
> I'll think about it. Right now it's convenient for Recycler to
> "know" about alist_nodes, so that it can hide the details from
> its users.

Ok

-Chris