On Jan 21, 2009, at 10:31 PM, Chris Lattner wrote:
>
> On Jan 9, 2009, at 9:18 AM, Douglas Gregor wrote:
>
>> Author: dgregor
>> Date: Fri Jan 9 11:18:27 2009
>> New Revision: 61994
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=61994&view=rev
>> Log:
>> Provide a new kind of iterator, the specific_decl_iterator, that
>> filters the decls seen by decl_iterator with two criteria: the
>> dynamic
>> type of the declaration and a run-time predicate described by a
>> member
>> function. This simplifies EnumDecl, RecordDecl, and ObjCContainerDecl
>> considerably. It has no measurable performance impact.
>
> Very nice!
>
> Two random questions:
>
>> + template<typename SpecificDecl>
>> + class specific_decl_iterator {
>> + /// Current - The current, underlying declaration iterator,
>> which
>> + /// will either be the same as End or will point to a
>> declaration of
>> + /// type SpecificDecl.
>> + DeclContext::decl_iterator Current;
>> +
>> + /// End - One past the last declaration within the DeclContext.
>> + DeclContext::decl_iterator End;
>
> Is there a sentinel that identifies the end of list (e.g. null)
> which could be used instead of storing the End iterator here?
There is now! (But there wasn't when the original patch went in <g>)
>> + /// Acceptable - If non-NULL, points to a member function that
>> + /// will determine if a particular declaration of type
>> + /// SpecificDecl should be visited by the iteration.
>> + bool (SpecificDecl::*Acceptable)() const;
>
> Could this be a template argument?
Yep, but I thought I'd get skewered for such fancy C++ :)
Anyway, it means that we now have two iterator classes
(specific_decl_iterator and filtered_decl_iterator) to cope with, but
they're only one pointer large (yay).
Thanks for the suggestions!
- Doug
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
