[PATCH] D57106: [AST] Introduce GenericSelectionExpr::Association
Aaron Ballman via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Sat Jan 26 12:22:26 PST 2019
aaron.ballman added inline comments.
================
Comment at: include/clang/AST/Expr.h:5084
+ /// storage of Stmt * and TypeSourceInfo * in GenericSelectionExpr.
+ template <bool Const> class AssociationIteratorTy {
+ friend class GenericSelectionExpr;
----------------
riccibruno wrote:
> aaron.ballman wrote:
> > riccibruno wrote:
> > > aaron.ballman wrote:
> > > > riccibruno wrote:
> > > > > dblaikie wrote:
> > > > > > Worth using any of the iterator helpers LLVM has? (iterator_facade or the like)
> > > > > I did try to use `iteratore_facade` but for some reason I was getting strange overload resolution failures with it.
> > > > >
> > > > > In the end it did not save much and so I just rewrote the boiler-plate (especially given that if we end up going with an input iterator there is not going to be much boiler-plate).
> > > > Does using the `iterator_facade_base` help now that we're back to an input iterator? It seems like that should be able to get rid of some of the boilerplate.
> > > I must be holding it wrong; for some reason the post-fix operator ++ is not getting found when I use `iterator_facade_base`. It also forces me to define `operator==` as a member instead of a non-member function. Do you mind terribly if I don't use it ? It only at best avoid me to write `operator!=` and `operator++(int)`.
> > It also removes all of the typedefs and `operator->()`, so it does remove quite a bit of boilerplate. You shouldn't have to do anything special to get it to locate the postfix operator++ though (so long as you use public inheritance), which makes me wonder what's going on for your use. I would like to understand more about why this base class doesn't work here when it seems to work fine for the other uses in the code base.
> Right. Let me try again then. I will still have to provide `operator->` though since the implementation from `iterator_facade_base` is not adequate as far as I can tell.
Yeah, I think you're right about `operator->()`; because of the odd semantics of the Association object, the facade implementation won't work there because it would return a pointer to a temporary.
Repository:
rC Clang
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D57106/new/
https://reviews.llvm.org/D57106
More information about the cfe-commits
mailing list