> * Check against cxx11 dialect, not cxx0x.
Let's talk about this tomorrow. I'm not quite sure how to do this.
> * Any particular reason to use classes with operator() for the
> parseers and the combinators? GCC can inline indirect calls to
> functions with internal linkage. That should cut down on the
> constructor boilerplates. This particular change can be addressed
> after the commit.
Some of the other combinators that I've built for the requires
expression have data fields that act as arguments to the actual other
cp_parser_* calls. I'll submit those with the relevant patch.
This should be easy to refactor, though.
> | +template<typename T>
> | +inline T* take(T*& p)
> | +{
> | + T* q = p;
> | + p = NULL;
> | + return q;
> | +}
> | +} // namespace
> | +
> | +
>
> Call it 'release' -- following standard library terminology.
Ah... yes. Good name.
> Suggestion: nonnull_or_else? or assert_nonnull? or check_nonnull?
> or validate?
check_nonnull is a good name.
> | - /* 1 spare bit */
> | + unsigned concept_p : 1; /* var or fn */
> | + /* 0 spare bit */
> | };
>
> Hmm I don't understand the comment "var or fn".
> If it is declared a concept, how can it it be a var?
Copied from the other bits in the class. I think it means it applies
to either variables or functions. I left it that way in anticipation
of template variables.
