In article <H00002c4020eb9ab@MHS> paul.black@vf.vodafone.co.uk writes:

|> sean@delta.com (Sean L. Palmer) wrote:
|> > What is the behavior defined in the standard for a semicolon without a
|> > declaration? (An 'extra' semicolon)
|> >
|> > My current compiler treats it as it would a declaration, and complains
|> > that it couldn't find an identifier. (BC++5.0)
|> >
|> > Having the compiler silently ignore 'extra' semicolons is a Good Thing
|> > (TM) when writing macros, which may or may not be called with a trailing
|> > semicolon.

|> Section 6.2 of the draft is about expression statements and states: "An
|> expression statement with the expression missing is called a null statement.
"
|> The message is that extra semi colons should not affect the compilation.

All that this says is that extra semi-colons are legal where ever a
null statement is legal.  Which doesn't say much.  Note that null
statements DO affect the compilation:

 if ( x ) expr ; ; else ...

The second `;' is a null statement which terminates the `if' statement,
making the else illegal.

I think that the ideal solution would be to simply say that a null
statement can appear anywhere.  I'm not sure, however, that there are
no problems with this; I've not done a thorough analysis.  (And while I
know of a number of contexts in which an added semi-colon is legal, I'm
sure I couldn't specify them all with any degree of certainty.)
--
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils, itudes et rialisations en logiciel orienti objet --
                -- A la recherche d'une activiti dans une region francophone
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

kanze@lts.sel.alcatel.de (James Kanze US/ESC 60/3/141 #40763) writes:

>I think that the ideal solution would be to simply say that a null
>statement can appear anywhere.  I'm not sure, however, that there are
>no problems with this; I've not done a thorough analysis.  (And while I
>know of a number of contexts in which an added semi-colon is legal, I'm
>sure I couldn't specify them all with any degree of certainty.)

An alternative solution to this problem is to simply *not use macros*.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article <4r3mn7$e56@mulga.cs.mu.OZ.AU> fjh@mundook.cs.mu.OZ.AU
(Fergus Henderson) writes:

|> kanze@lts.sel.alcatel.de (James Kanze US/ESC 60/3/141 #40763) writes:

|> >I think that the ideal solution would be to simply say that a null
|> >statement can appear anywhere.  I'm not sure, however, that there are
|> >no problems with this; I've not done a thorough analysis.  (And while I
|> >know of a number of contexts in which an added semi-colon is legal, I'm
|> >sure I couldn't specify them all with any degree of certainty.)

|> An alternative solution to this problem is to simply *not use macros*.

Agreed.  So what alternative do you propose for:

 GB_USE( std::abort ) ;

(Obviously, the macro expands differently according to whether the
compiler supports namespaces or not.  And when there is no support for
namespaces, it expands to nothing, resulting in a spurious semi-colon.)
--
James Kanze           (+33) 88 14 49 00          email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
Conseils en informatique industrielle --
                            -- Beratung in industrieller Datenverarbeitung
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Fergus Henderson wrote:
> kanze@lts.sel.alcatel.de (James Kanze US/ESC 60/3/141 #40763)
> writes:
>> I think that the ideal solution would be to simply say that a
>> null statement can appear anywhere.[...]
>> (And while I know of a number of contexts in which
>> an added semi-colon is legal, I'm sure I couldn't specify them
>> all with any degree of certainty.)

> An alternative solution to this problem is to simply *not use
> macros*.[...]
> Fergus Henderson <fjh@cs.mu.oz.au>[...]

Which misses the point.  The original question was not about macros
and the bit that you quote is not about macros.  It's about null
declarations in aggregate data types.  The part you quote has a
point in that the presence or absence of terminating semicolons
is inconsistent at file scope and that the intended semantics of
a null statement would witout danger be extended to null
declarations.
  -- Eric Gindrup ! gindrup@okway.okstate.edu
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

> > What is the behavior defined in the standard for a semicolon
> > without a declaration? (An 'extra' semicolon)
> > [...]
> > Having the compiler silently ignore 'extra' semicolons is a
> > Good Thing (TM) when writing macros, which may or may not be
> > called with a trailing semicolon.
>
> Always terminate your macro invocations with semicolons.
> Never change the language.
> MACRO_FOO
> is poor style and will make maintaining the code more difficult.
> MACRO_FOO;
> is better style and makes maintaining the code as difficult as
> any other part.

That is part of the problem. If the macro is something like:

#define FOO(X) \
private: \
  X; \
public:

then when you do this:

class MyClass {
  FOO(int x);
};

you end up with an 'extra' semicolon and the compiler barfs. I wanted to
talk the committee into allowing those extra semicolons.
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

kanze@gabi-soft.fr (J. Kanze) writes:

>fjh@mundook.cs.mu.OZ.AU (Fergus Henderson) writes:
>
>|> An alternative solution to this problem is to simply *not use macros*.
>
>Agreed.  So what alternative do you propose for:
>
> GB_USE( std::abort ) ;
>
>(Obviously, the macro expands differently according to whether the
>compiler supports namespaces or not.  And when there is no support for
>namespaces, it expands to nothing, resulting in a spurious semi-colon.)

Using macros to simulate missing language features is usually a losing
proposition, IMHO.

If I had to ensure that my code was portable to compilers that didn't
support namespaces, I would just use `#include <stdlib.h>' rather than
`#include <stdlib>', so that the `using std::abort;' declaration was
not necessary.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article <31d4045b.8981995@news.ultranet.com>
phalpern@truffle.ma.ultranet.com (Pablo Halpern) writes:

|> P.S. Here is a common example. I often correct this in my student's
|> code:

|> class foo
|> {
|>     int i;
|>   public:
|>     void clear() { i = 0; } ;
|> //                          ^ extra semicolon does not belong.
|> //                            This is a *null declaration*, not a
|> //                            *null statement*. Is it legal?
|> };

According to the grammar (appendix A), yes.  In a member declaration, a
member function definition may be followed by an optional `;'.

I have a very vague memory of reading somewhere that Bjarne Stroustrup
made this legal because he could never remember himself when the
semi-colon was necessary, and when it was illegal.  I could very easily
be wrong about this, but if not, your students are in good company.

I've not had problems with this myself (at least in classes, globally,
GB_USE is a problem, see my other posting).  But it does seem simpler
to allow null statements (almost) everywhere.  Looking at the grammar,
this would require:

1.  Defining a null-statement as a statement, and making the expression
in an expression statement mandatory (A.5).

2.  Adding null-statement to the list of declarations (A.6).

3.  Adding null-statement to the list of member-declaration in a class
(A.8).

4.  Drop the optional semi-colon after function-definition in
member-declaration.  There are probably other optional semi-colons that
I've missed which should be dropped as well.

There are possibly other places, too, that I've missed, and one might
want to ban certain vacuous declarations ("template< class T >;"), but
I think that the above covers it.
--
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils, itudes et rialisations en logiciel orienti objet --
                -- A la recherche d'une activiti dans une region francophone
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

sean@delta.com (Sean L. Palmer) wrote:
> What is the behavior defined in the standard for a semicolon without a
> declaration? (An 'extra' semicolon)
>
> My current compiler treats it as it would a declaration, and complains
> that it couldn't find an identifier. (BC++5.0)
>
> Having the compiler silently ignore 'extra' semicolons is a Good Thing
> (TM) when writing macros, which may or may not be called with a trailing
> semicolon.

Section 6.2 of the draft is about expression statements and states: "An
expression statement with the expression missing is called a null statement."
The message is that extra semi colons should not affect the compilation.

Paul



[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Sean L. Palmer wrote:
>
> What is the behavior defined in the standard for a semicolon
> without a declaration? (An 'extra' semicolon)
> [...]
> Having the compiler silently ignore 'extra' semicolons is a
> Good Thing (TM) when writing macros, which may or may not be
> called with a trailing semicolon.

Always terminate your macro invocations with semicolons.
Never change the language.
MACRO_FOO
is poor style and will make maintaining the code more difficult.
MACRO_FOO;
is better style and makes maintaining the code as difficult as
any other part.
  -- Eric Gindrup ! gindrup@okway.okstate.edu


[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

paul.black@vf.vodafone.co.uk writes:

>sean@delta.com (Sean L. Palmer) wrote:
>> What is the behavior defined in the standard for a semicolon without a
>> declaration? (An 'extra' semicolon)

If a bare semicolon appears where only a declaration may appear (e.g.
at file scope), then it is an error, and the translation unit is
ill-formed.  A conforming compiler must report a diagnostic.

>> My current compiler treats it as it would a declaration, and complains
>> that it couldn't find an identifier. (BC++5.0)

Your compiler is behaving in a standard-conforming manner in this
respect.

>> Having the compiler silently ignore 'extra' semicolons is a Good Thing
>> (TM) when writing macros, which may or may not be called with a trailing
>> semicolon.
>
>Section 6.2 of the draft is about expression statements and states: "An
>expression statement with the expression missing is called a null statement."
>The message is that extra semi colons should not affect the compilation.

Only if they occur where a statement could occur.

 // foo.c
 void func() {
  ;  // ok
 }
 ;   // error

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

paul.black@vf.vodafone.co.uk wrote:

>sean@delta.com (Sean L. Palmer) wrote:
>> What is the behavior defined in the standard for a semicolon without a
>> declaration? (An 'extra' semicolon)
>>
>> My current compiler treats it as it would a declaration, and complains
>> that it couldn't find an identifier. (BC++5.0)
>> [ ... ]
>
>Section 6.2 of the draft is about expression statements and states: "An
>expression statement with the expression missing is called a null statement."
>The message is that extra semi colons should not affect the compilation.

I believe Sean was not refering to expression statements but to
declarations. There are places in the language where statements are not
permitted, but declarations are (e.g. outside any function block or
inside a class declaration). You have not answered the real question.
Unfortunately, I do not know the answer either. Anybody?

P.S. Here is a common example. I often correct this in my student's
code:

class foo
{
    int i;
  public:
    void clear() { i = 0; } ;
//                          ^ extra semicolon does not belong.
//                            This is a *null declaration*, not a
//                            *null statement*. Is it legal?
};

-------------------------------------------------------------
Pablo Halpern                   phalpern@truffle.ultranet.com

I am self-employed. Therefore, my opinions *do* represent
those of my employer.


[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]