Xref: utzoo gnu.g++.help:159 comp.lang.c++:10465
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!AI.MIT.EDU!rms
From: rms@AI.MIT.EDU (Richard Stallman)
Newsgroups: gnu.g++.help,comp.lang.c++
Subject: (none)
Message-ID: <9011201747.AA29363@mole.ai.mit.edu>
Date: 20 Nov 90 17:47:28 GMT
Sender: daemon@tut.cis.ohio-state.edu
Followup-To: gnu.g++.help
Organization: Gatewayed from the GNU Project mailing list help-g++@prep.ai.mit.edu
Lines: 25


    >The grammar ambiguity shows up in
    >
    >   int (x);
    >
    >which could either declare `x' as an integer or convert it to one.

    I don't know what you mean by this. How does this break C programs when
    compiled under C++?

It could break a few, since this is a valid declaration in C, but it
isn't likely to break very many.  However, I think a grammatical
ambiguity is a problem in itself.  I mentioned this as an example of
careless design, because chosing a slightly different syntax would
have avoided the problem entirely.

    ARM, Ellis & Stroustrup Sec. 5.4:
    " An explicit type converson can be expressed using either functional
      notation or the _cast_ notation"

    The manual then goes on to define the grammar of the cast notation.  Looks
    to me like its compatible with C.

The cast notation is not where the problem is.
It is in the functional notation.