Beszedes Arpad wrote:
>
> > > How does it classify each of the following examples:
> > >
> > > struct T
> > > {
> > >         int m;
> > >         T(int i) m(i) {};
> > >         T(int i, int j) m(i*j) {};
> > > };
> > > int a;
> > >
> > > T(a)->m = 7;
> > > T(a)++;
> > > T(a,5)<<c;
> > > T(*d)(int);
> > > T(e)[5];
> > > T(f) = { 1,2 };
> > > T(*g)(double(3));
....
> You have syntax errors is your examples, don't you? E.g.
>          T(int i) m(i) {};
>          T(int i, int j) m(i*j) {};
> should be
>          T(int i) : m(i) {}
>          T(int i, int j) : m(i*j) {}

Yes - sorry. A definition for T was a last-minute add-on, which I
obviously didn't think through thoroughly enough. If your 'E.g.' implies
that you've found other errors as well, they're likely to have been
typing errors on my part; those examples are supposed to be direct
quotes from the standard.

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

> > How does it classify each of the following examples:
> >
> > struct T
> > {
> >         int m;
> >         T(int i) m(i) {};
> >         T(int i, int j) m(i*j) {};
> > };
> > int a;
> >
> > T(a)->m = 7;
> > T(a)++;
> > T(a,5)<<c;
> > T(*d)(int);
> > T(e)[5];
> > T(f) = { 1,2 };
> > T(*g)(double(3));
> >
> > struct S{
> >    S(int);
> > };
> >
> > void foo(double a)
> > {
> >    S w(int(a));
> >    S x(int());
> >    S y((int)a);
> >    S z = int(a);
> > }

You have syntax errors is your examples, don't you? E.g.
         T(int i) m(i) {};
         T(int i, int j) m(i*j) {};
should be
         T(int i) : m(i) {}
         T(int i, int j) : m(i*j) {}


--
***********************************************
*  Arpad Beszedes (research engineer)         *
*                                             *
*  Research Group on Artificial Intelligence  *
*  Hungarian Academy of Sciences              *
*  Attila Jozsef University, Szeged, Hungary  *
*  e-mail: beszedes@cc.u-szeged.hu            *
*  tel.: (+36) 62/544-145                     *
***********************************************
* "To err is human, but to really mess things *
*          up you need a computer."           *
***********************************************

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Desmond Germans wrote:
> I'm working on a set of prettyprinter/analysis/management-tools for
> cross-platform C++ development, and for this I've written a fully
> compliant ANSI C++ grammar (including namespaces, templates,
> exceptions, etc.) for Bison. Right now it is down to 40 S/R
> conflicts, of which most are harmless (an exact copy of the grammar
> proposed by ANSI has about 200 S/R and 150 R/R conflicts). The
> grammar still contains * and &-conflicts, and other nasty ones, as
> reported by Jim Roskind in his work. Unlike GNU C++ or even his work,
> it is very readable, and sticks very much to the ANSI terms and names.

S/R conflicts are almost always benign, so don't worry about them.
It's R/R conflicts that cause headaches, and they should be removed
completely if possible.

I'm curious, do you expect type-names (such as struct tags and typedef
names) to be returned by the lexer as a token different than
<identifier> once it's known they are type names?

> I'm planning to make it free for everyone, probably including some
> parse-tree functionality. However, I don't feel too confident on its
> correctness yet, so I'd first like to ask grammar-gurus to take a look
> at it. Please contact me if you are interested,
> your input is greatly appreciated.

Even though you don't think it's in polished form yet, go ahead and post
your grammar, or at least put it on the web and post the URL.  This
would
allow for more feedback, since people could see the actual
work-in-progress.

--
One thing that would be nice, even though it's an extension to the
grammar,
is to allow '>>' tokens to parse properly when used as nested template
parameter brackets.  For example, treat these two declarations
identically:

    Foo<Bar<int>>   obj;
    Foo<Bar<int> >  obj;

(There is a Java precompiler that adds template capabilities to Java,
called GJ, that handles this little syntactic wart quite nicely.  This
might be too complicated for C++, though.)

--
David R. Tribble, mailto:david@tribble.com, http://david.tribble.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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

> How does it classify each of the following examples:
>
> struct T
> {
>         int m;
>         T(int i) m(i) {};
>         T(int i, int j) m(i*j) {};
> };
> int a;
>
> T(a)->m = 7;
> T(a)++;
> T(a,5)<<c;
> T(*d)(int);
> T(e)[5];
> T(f) = { 1,2 };
> T(*g)(double(3));
>
> struct S{
>    S(int);
> };
>
> void foo(double a)
> {
>    S w(int(a));
>    S x(int());
>    S y((int)a);
>    S z = int(a);
> }

Very interesting comprehensive example of virtually all the problems
that can arise :) Thanks. The parser parses it quite adequately, and it
helped alot to solve some conflicts that were unworkable. I'm now stuck
with the function declaration "S y((int)a)" in your example and
Roskind's problems considering "((T1))T;". Working on it :)

Grtz,
  Desmond.

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

I made the current version of the grammar available at

http://www.nat.vu.nl/~desmond/Satu/grammar.y

and (if needed) the accompanying lexer at

http://www.nat.vu.nl/~desmond/Satu/scanner.l

Remember, it's not at all complete, and I sort of tore it open to expose
some nasty conflicts. It's in progress.

Grtz,
  Desmond.

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Desmond Germans wrote:
>
> > How does it classify each of the following examples:
> >
> > struct T
> > {
> >         int m;
> >         T(int i) m(i) {};
> >         T(int i, int j) m(i*j) {};
> > };
> > int a;
> >
> > T(a)->m = 7;
> > T(a)++;
> > T(a,5)<<c;
> > T(*d)(int);
> > T(e)[5];
> > T(f) = { 1,2 };
> > T(*g)(double(3));
> >
> > struct S{
> >    S(int);
> > };
> >
> > void foo(double a)
> > {
> >    S w(int(a));
> >    S x(int());
> >    S y((int)a);
> >    S z = int(a);
> > }
>
> Very interesting comprehensive example of virtually all the problems
> that can arise :) Thanks. ...

I can't take credit. Those examples were extracted from the two
unrelated sections of the standard titled "Ambiguity resolution":  6.8
and 8.2. I wasn't sure, from your comments, whether you were aware of
those sections.
The only thing I added was the definition of T. The ambiguities are a
matter of syntax, not semantics, so section 6.8 says only that T is a
_simple-type-specifier_. However, I figured it would be easier to test
your parser with a specific definition of T.

> ... The parser parses it quite adequately, and it
> helped alot to solve some conflicts that were unworkable. I'm now stuck
> with the function declaration "S y((int)a)" in your example and
> Roskind's problems considering "((T1))T;". Working on it :)

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

C++-grammar freaks,

I'm working on a set of prettyprinter/analysis/management-tools for
cross-platform C++ development, and for this I've written a fully
compliant ANSI C++ grammar (including namespaces, templates, exceptions,
etc.) for Bison. Right now it is down to 40 S/R conflicts, of which most
are harmless (an exact copy of the grammar proposed by ANSI has about
200 S/R and 150 R/R conflicts). The grammar still contains * and
&-conflicts, and other nasty ones, as reported by Jim Roskind in his
work. Unlike GNU C++ or even his work, it is very readable, and sticks
very much to the ANSI terms and names.

I'm planning to make it free for everyone, probably including some
parse-tree functionality. However, I don't feel too confident on its
correctness yet, so I'd first like to ask grammar-gurus to take a look
at it. Please contact me if you are interested,
your input is greatly appreciated.

Grtz,

  Desmond Germans
  Channel Three Video Software

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Hello Desmond, you wrote

> it is very readable, and sticks very much to the ANSI terms and names

Just curious; how do you handle the ambiguities (e.g. between
'expression_statement' and 'declaration_statement') in a
"very readable ..." manner.

--
Norbert Berzen (norbert@dune.gia.rwth-aachen.de)
Geodaetisches Institut der RWTH Aachen, Templergraben 55, D-52062 Aachen
Tel.: +49 (0)241   80 52 95
Fax.: +49 (0)241 8 88 81 42

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

> Hello Desmond, you wrote
>
> > it is very readable, and sticks very much to the ANSI terms and names
>
> Just curious; how do you handle the ambiguities (e.g. between
> 'expression_statement' and 'declaration_statement') in a
> "very readable ..." manner.

Well, the ';'-ambiguity is sort of trivial, so that doesn't really
affect the readability :)  The hard part is disambiguating the
declarator and the expression, and the only way to solve it is by
deferring a reduce as much as possible. Right now I defer until the
start of a declarator-tail is read (function parameters, arrays, etc.),
so you can very 'nicely' call a declarator a 'indefinite-lead
declarator-tail' and a postfix-expression a 'indefinite-lead
postfix-tail'. However, the primary conflict still exists in the
grammar, but at very rare cases now.

Grtz,
  Desmond.

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Desmond Germans wrote:
>
> > Hello Desmond, you wrote
> >
> > > it is very readable, and sticks very much to the ANSI terms and names
> >
> > Just curious; how do you handle the ambiguities (e.g. between
> > 'expression_statement' and 'declaration_statement') in a
> > "very readable ..." manner.
>
> Well, the ';'-ambiguity is sort of trivial, so that doesn't really
> affect the readability :)  The hard part is disambiguating the
> declarator and the expression, and the only way to solve it is by
> deferring a reduce as much as possible. Right now I defer until the
> start of a declarator-tail is read (function parameters, arrays, etc.),
> so you can very 'nicely' call a declarator a 'indefinite-lead
> declarator-tail' and a postfix-expression a 'indefinite-lead
> postfix-tail'. However, the primary conflict still exists in the
> grammar, but at very rare cases now.

How does it classify each of the following examples:

struct T
{
 int m;
 T(int i) m(i) {};
 T(int i, int j) m(i*j) {};
};
int a;

T(a)->m = 7;
T(a)++;
T(a,5)<<c;
T(*d)(int);
T(e)[5];
T(f) = { 1,2 };
T(*g)(double(3));


struct S{
   S(int);
};

void foo(double a)
{
   S w(int(a));
   S x(int());
   S y((int)a);
   S z = int(a);
}

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Desmond Germans (desmond@nat.vu.nl) wrote:

[...]

: Well, the ';'-ambiguity is sort of trivial, so that doesn't really
: affect the readability :)  The hard part is disambiguating the
: declarator and the expression, and the only way to solve it is by
: deferring a reduce as much as possible. Right now I defer until the
: start of a declarator-tail is read (function parameters, arrays, etc.),
: so you can very 'nicely' call a declarator a 'indefinite-lead
: declarator-tail' and a postfix-expression a 'indefinite-lead
: postfix-tail'. However, the primary conflict still exists in the
: grammar, but at very rare cases now.

After starting to write a grammar, too, I came to the comclusion, that
it is not possible to remove all ambiguity, therefore I switched to
BTYacc, which is capable of backtracking and therefore does not have
these problems.

- Matthias Meixner

--
Matthias Meixner                   meixner@rbg.informatik.tu-darmstadt.de
Technische Universit   t Darmstadt
Rechnerbetriebsgruppe                          Telefon (+49) 6151 16 6670
Wilhelminenstra   e 7, D-64283 Darmstadt, Germany    Fax (+49) 6151 16 4701


---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]