Andrew Sutton <andrew.n.sut...@gmail.com> writes: | > * 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.
Ah, OK, that makes sense. [...] | > | - /* 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. OK; in that case, add some expalanation :-) Once you've committed the patch, let me know so I can synchronize with trunk -- or is there another patch coming in this week? -- Gaby
