There is this template ambiguity whether in say
  list<list<string>>
one should read ">>" as a single token or as two ">".

Can somebody provide a quote from the standard telling which
interpretation is right?

  Hans Aberg      * Anti-spam: remove "remove." from email address.
                  * Email: Hans Aberg <remove.haberg@member.ams.org>
                  * Home Page: <http://www.matematik.su.se/~haberg/>
                  * AMS member listing: <http://www.ams.org/cml/>

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Hans Aberg <remove.haberg@matematik.su.se> wrote:

> There is this template ambiguity whether in say
>   list<list<string>>
> one should read ">>" as a single token or as two ">".

> Can somebody provide a quote from the standard telling which
> interpretation is right?


Draft standard, section 2.4:

> 3 If the input stream has been parsed into preprocessing tokens up to  a
>   given  character, the next preprocessing token is the longest sequence
>   of characters that could constitute a  preprocessing  token,  even  if
>   that would cause further lexical analysis to fail.
>
> 4 [Example: The program fragment 1Ex is parsed as a preprocessing number
>   token (one that is not a valid floating  or  integer  literal  token),
>   even though a parse as the pair of preprocessing tokens 1 and Ex might
>   produce a valid expression (for example, if Ex were a macro defined as
>   +1).  Similarly, the program fragment 1E1 is parsed as a preprocessing
>   number (one that is a valid floating literal token), whether or not  E
>   is a macro name.]
>
> 5 [Example:  The  program  fragment  x+++++y  is  parsed as x ++ ++ + y,
>   which, if x and y are of built-in  types,  violates  a  constraint  on
>   increment  operators,  even though the parse x ++ + ++ y might yield a
>   correct expression.]

Since >> is a valid token, if you have two >'s together, they are a
single >> token.  Your compiler may very will help you out, and treat it
as two >'s if that's all that would work, but that is an extension that
is NOT required by the standard.

--
Jack Applin
neutron@fc.hp.com
http://www.verinet.com/~neutron/

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Hans Aberg wrote:
>
> There is this template ambiguity whether in say
>   list<list<string>>
> one should read ">>" as a single token or as two ">".
>
> Can somebody provide a quote from the standard telling which
> interpretation is right?
>
It's one token >>, you need to put a space in there for
it to be syntacially correct.  As for a reference, you'll
just have to follow the grammar.  the '>>' is tokenized
(2.1 and 2.4) long before it even decides that there's a template
in the works.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

remove.haberg@matematik.su.se (Hans Aberg) writes:

|>  There is this template ambiguity whether in say
|>    list<list<string>>
|>  one should read ">>" as a single token or as two ">".

|>  Can somebody provide a quote from the standard telling which
|>  interpretation is right?

2.4/3:=20
    If the input stream has been parsed into preprocessing tokens up to
    a given character, the next preprocessing token is the longest
    sequence of characters that could constitute a preprocessing token,
    even if that would cause further lexical analysis to fail.

The longest sequence which forms a valid token, once string has been
tokenized, is ">>".  The token is thus >> (even though this token is
illegal in this context).

--=20
James Kanze                               mailto:kanze@gabi-soft.de
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
Ziegelh=FCttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]