Topic: Q: Why has vector<vector<int>> been *kept* illegal?


Author: "Samee Zahur" <samee.zahur@gmail.com>
Date: Fri, 13 May 2005 00:04:40 CST
Raw View
We know that > can be a 'greater-than' operator, or it can be an
ending-delimiter for template parameters.

So why has the >> operator not been defined as being capable of ending
two template paramenter lists in a row? That would make things like
vector<vector<int>> legal without any extra space!

I know it is sometimes good coding practice to keep the space, but
shouldn't coding style be there for the programmer to decide? What is
the rationale behind this language design?

Samee

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]





Author: llewelly.at@xmission.dot.com (Llewelly)
Date: Fri, 13 May 2005 13:08:41 GMT
Raw View
"Samee Zahur" <samee.zahur@gmail.com> writes:

> We know that > can be a 'greater-than' operator, or it can be an
> ending-delimiter for template parameters.
>
> So why has the >> operator not been defined as being capable of ending
> two template paramenter lists in a row? That would make things like
> vector<vector<int>> legal without any extra space!
[snip]

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1757.html

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]





Author: dave@boost-consulting.com (David Abrahams)
Date: Fri, 13 May 2005 13:42:48 GMT
Raw View
"Samee Zahur" <samee.zahur@gmail.com> writes:

> We know that > can be a 'greater-than' operator, or it can be an
> ending-delimiter for template parameters.
>
> So why has the >> operator not been defined as being capable of ending
> two template paramenter lists in a row? That would make things like
> vector<vector<int>> legal without any extra space!
>
> I know it is sometimes good coding practice to keep the space, but
> shouldn't coding style be there for the programmer to decide? What is
> the rationale behind this language design?

No particular rationale; it's being fixed for the next version of the
C++ standard.

--
Dave Abrahams
Boost Consulting
www.boost-consulting.com

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]





Author: petebecker@acm.org (Pete Becker)
Date: Fri, 13 May 2005 14:24:43 GMT
Raw View
David Abrahams wrote:

>
> No particular rationale; it's being fixed for the next version of the
> C++ standard.
>

One very good rationale: it's a fundamental change to the maximum munch
rule that C and C++ lexing is explicitly based on. Which is why making
this change requires careful analysis, as in the paper cited in another
reply.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]





Author: nagle@animats.com (John Nagle)
Date: Sat, 14 May 2005 02:44:38 GMT
Raw View
Llewelly wrote:
> "Samee Zahur" <samee.zahur@gmail.com> writes:
>
>
>>We know that > can be a 'greater-than' operator, or it can be an
>>ending-delimiter for template parameters.
>>
>>So why has the >> operator not been defined as being capable of ending
>>two template paramenter lists in a row? That would make things like
>>vector<vector<int>> legal without any extra space!
>
> [snip]
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1757.html

    That breaks existing code, silently. The committee usually
rejects such suggestions.

    John Nagle

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]





Author: "Jerry Coffin" <jcoffin@taeus.com>
Date: Fri, 13 May 2005 21:45:14 CST
Raw View
Samee Zahur wrote:
> We know that > can be a 'greater-than' operator, or it can be an
> ending-delimiter for template parameters.
>
> So why has the >> operator not been defined as being capable of
> ending two template paramenter lists in a row? That would make
> things like vector<vector<int>> legal without any extra space!
>
> I know it is sometimes good coding practice to keep the space, but
> shouldn't coding style be there for the programmer to decide? What is
> the rationale behind this language design?

I don't believe there's a way of changing this without breaking or
changing the meaning of at least some existing, legitimate code. This
seems to be widely enough seen as a problem that it'll probably change,
but when it does it will probably break or change the meaning of
something else. It does seem likely that the "Something else" in
question is obscure, while this is common, so the tradeoff may be
reasonable, but it should at least be clear to those involved that it
really is a tradeoff, not a simple situation of fixing something that
has no side-effects.

--
    Later,
    Jerry.

The universe is a figment of its own imagination.

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]





Author: "Samee Zahur" <samee.zahur@gmail.com>
Date: 15 May 2005 16:30:02 GMT
Raw View
Thanks everyone for the replies and references. I read through n1757,
but how far has it gone into actually being accepted? I feel the
proposal there is fine, since I really doubt if there really is any
existing code out in the real world that actually will break down.
(except for tutorial codes meaning to show a possible source of
programmer's confusion)

For everyone's scrutiny, let me give another alternative here which
will not break any existing code - parse it as it does now, and try to
accept >> as a double angle bracket only if treating it like a
right-shift op raises a syntax error.I believe that this approach will
make it easier for compiler vendors to implement this (since all
existing rules stay as-is), although I will admit that I've never been
involved in any compiler writing before. Downsides I can think of:

- humans may find it harder to figure out the real meaning of a '>>'
token in certain contexts.
- in case of multiple instances of '>>' in the same line, there can be
more than one valid interpretation. In these particularly rare cases,
the statement can be flagged an error due to ambiguity forcing the
programmer to resort back to inserting a space wherever needed. Or,
there can be priority rules which decide which one gets interpreted as
what (but this can in turn lead to silent bugs since the compiler reads
something the programmer didn't mean - not a good approach).

Any opinions on this?

Samee

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]





Author: jdennett@acm.org (James Dennett)
Date: Mon, 16 May 2005 16:22:07 GMT
Raw View
John Nagle wrote:

>
> Llewelly wrote:
>
>> "Samee Zahur" <samee.zahur@gmail.com> writes:
>>
>>
>>> We know that > can be a 'greater-than' operator, or it can be an
>>> ending-delimiter for template parameters.
>>>
>>> So why has the >> operator not been defined as being capable of ending
>>> two template paramenter lists in a row? That would make things like
>>> vector<vector<int>> legal without any extra space!
>>
>>
>> [snip]
>>
>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1757.html
>
>
>    That breaks existing code, silently. The committee usually
> rejects such suggestions.
>
>                 John Nagle

True, however this particular case seems to have significant
support because of the perceived cost of sticking with the
status quo, and the apparent scarcity of code which would
be broken by the change.

-- James

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]





Author: house@usq.edu.au (Ron House)
Date: Mon, 16 May 2005 16:20:50 GMT
Raw View
Samee Zahur wrote:
> We know that > can be a 'greater-than' operator, or it can be an
> ending-delimiter for template parameters.
>
> So why has the >> operator not been defined as being capable of ending
> two template paramenter lists in a row? That would make things like
> vector<vector<int>> legal without any extra space!
>
> I know it is sometimes good coding practice to keep the space, but
> shouldn't coding style be there for the programmer to decide? What is
> the rationale behind this language design?

I can think of one reason: it complicates the parser no end. A recursive
algorithm looking for a type is primed to find vector<something>, and
that something is recursively any type, and so might be vector<int>. But
to detect that >> ends two different recursive levels involves a big
redesign of such a parser - and for no real benefit; bung in the space
and it's fixed.

--
Ron House     house@usq.edu.au
               http://www.sci.usq.edu.au/staff/house

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]