Indeed, the reverse iterator is not intended as a solution to a problem,
but as useful functionality in the absence of a solution (and because
the solution is likely to take a long time to be implemented). Also, is
there a disadvantage in having the reverse iterator functionality?
At the micro level, NULL is not a valid value for objects of type
std::reverse_iterator<T>, so the compiler would not compile the code
with RNull replaced by NULL.
Cheers!
Alex
On 11/14/2012 04:48 PM, Jordan Rose wrote:
I hate to say it, but trying to solve the attributes-on-types problem
this way seems like a bad idea.
int [[attr1]] * [[attr2, attr3]] var;
int [[attr1, attr2]] * [[attr3]] var;
We should be able to distinguish those, but we don't. And this won't
help us do that, and pretending that it does is not a good thing, IMHO.
Jordan
P.S. At the micro level, what's wrong with using NULL as the
reverse_iterator sentinel?
On Nov 14, 2012, at 14:00 , Alexandros Tzannes <[email protected]
<mailto:[email protected]>> wrote:
Hi all,
the current Clang implementation has a
specific_attr_iterator<AttrType> that allows iterating over the
attributes of a certain type (all attributes are kept in a single
llvm::SmallVector), but it lacks a reverse iterator. This patch adds
this functionality.
Why is this useful/needed (in the short run).
-----------------------------------------------------------
The C++11 standard allows attributes to appertain to types and
portions of the declarator, e.g.:
int[[attr1] *[[attr2] *[[attr3] var;
However, Clang is still collapsing those attributes on the
declaration itself:
int **var [[attr1,attr2,attr3]].
According to C++11 when multiple attributes of the same kind
appertain to the same "node", their order is irrelevant (note that
these attributes may have different attribute parameters):
int var [[attrA("x"), attrA("y")]]
and
int var [[attrA("y"), attrA("x")]]
must mean the same thing.
However, until attributes are allowed to appertain to all the new
locations described by C++11, it would be useful to use their order
to "map" them onto the different nodes they should appertain. The
specific_attr_reverse_iterator provides some functionality towards
that goal.
Implementation
----------------------
The implementation is a slightly modified version of the code of the
corresponding forward iterator. A small difference is that the
forward iterator returns a pointer to the underlying type *T, whereas
the reverse one returns an object of type typedef
std::reverse_iterator<iterator
<http://llvm.org/docs/doxygen/html/classllvm_1_1SmallVectorTemplateCommon.html#a309d93eaafb8f5a8dfb7de2a231335ea>>.
For that reason, Decl::attr_rbegin() and Decl::attr_rend() for
attr_reverse_iterator check if the Decl has attributes, and if so,
return the begin or the end; otherwise, they return a sentinel RNull,
which is implemented as a static member of Decl.
Using the RNull sentinel is a bit awkward. Two alternatives are the
following:
1. Make the user responsible of checking if a Decl has an attributes
vector before trying to get a specific_attr_reverse_iterator. Trying
to get such an iterator on a Decl without any attrs will generate an
assertion failure. This approach gets rid of RNull, but requires
users to treat fwd and reverse iterators differently.
2. Each time the user tries to get a reverse iterator on a Decl
without attributes, create an empty attribute vector and return the
beginning (or the end) of it. This approach also removes the awkward
RNull, but may create many unneeded empty attribute vectors.
Please let me know if one of these alternatives is preferable.
Cheers!
Alex Tzannes
[[written during the Hacker Lab at last week's LLVM devellopers'
meeting]]
<specific_attr_reverse_iterator.diff>_______________________________________________
cfe-dev mailing list
[email protected] <mailto:[email protected]>
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
