This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [C++ PATCH] Make parser revert digraph "<:"


"Zack Weinberg" <zack@codesourcery.com> writes:

| Therefore I think that "'<::' cannot begin a template-argument list"
| (with additional explanation in note:s) is clear and factually
| accurate, while remaining appropriately brief.

It is certainly brief but it is neither clear nor factually accurate.

| > | #pragma STDCXX (DIGRAPHS|TRIGRAPHS) (ON|OFF)
| > | 
| > | ?  This would be trivial to implement under the #pragma GCC namespace
| > | as a demonstration.
| >
| > I'm afraid anything that starts with pragma is not a first step.
| 
| Why?  The alternative is to contort the grammar in order to make
| digraphs be parsed as "intended", when what is really wanted is for
| there not to be digraphs at all.

No. If digraphs were intended not to be supported at all then there
would have been a statement to abolish them.  That is not the case.
Rather, it is intented that in this specific case, '<::' be lexed
as < ::.  That is different from throwing random pragmas in. 
Second, I disagree that "pragma" (or dogma or whatever CPP thingy
it is) is a programmer control; at least as far as C++ is conerned.
Third, the contorsion is NOT making the grammar less surprising but
the presence of digraph, trigraphs or quadrigraphs or whatever.

| > This kind of thing can be handled without pragma/dogma intervening.
| > I've already seen a patch for the ">>" thingy. 
| 
| The >> thingy, yeah, that does need to be handled by contorting the
| grammar,

There is no contorting of the grammar.

| because there's no practical way to get rid of the >> token
| at this stage;

you should look at the actual patch.

| but the <: token *can* be dispensed with, under
| programmer control.

but pragma is not such a control.

| > | >     http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1512.html
| > | >
| > | > for things like
| > | >
| > | >     vector<list<int>> vl;
| > | 
| > | What is GJ?
| >
| > I don't understand what you mean by "GJ".
| 
| quoting the website you referenced:
| 
|     ES018. >>
| 
|     Allow >> to terminate two specializations; e.g. 
|     vector<list<int>> vli;
| 
|     Not being able to do this surprises and annoys novices, leads to
|     harder to read code, and occationally catches even experts. It has
|     also become the target of a popular jibe from GJ proponents.
| 
| That GJ.

Generic Java.

-- Gaby


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]