In article <83c3lc$qah$1@nnrp1.deja.com>, AllanW <allan_w@my-deja.com>
writes
>By a strange coincidence, both papers were originally published in
>JOOP in April. Small world, isn't it?

Both in April, but not both in JOOP.  Give credit where credit is due.


Francis Glassborow      Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
---
[ 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              ]

David R Tribble wrote:
>
> Steve Clamage wrote:
> [...]
> > No, that's not a rule:
> >
> >         class C {
> >                 int a; // ; required
> >                 ; // error
> >                 int f1(); // ; required
> >                 int f2() { ... }
> >                 ; // optional     [A]
> >         };
>
> Why on earth did the committee allow optional semicolons following
> member function definitions (at [A])?

It has always been allowed in C++. The committee chose not to
break existing programs in this regard.

> And if they saw fit to allow those particular semicolons to be
> optional, why couldn't they also allow null member declarations?

IMHO there is no valid reason to forbid null declarations.
I don't think anyone ever proposed allowing them, however.

--
Steve Clamage, stephen.clamage@sun.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              ]

>But I'm curious; if you dislike 'continue' so much, what else is it
>good for?  Would you consider dropping it from the language, since
>its effects can be simulated using other methods?


I dislike continue only as the last statement in the iteration where it is
redundant. Other then there it has many likeable uses.




[ 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              ]

David R Tribble <david@tribble.com> writes:
> David Tribble wrote:
> >> Most uses of null statements can be replaced with something better.
> >> For example:
> >>
> >>    while (process())
> >>        ;               // uck
> >>
> >>    while (process())
> >>        continue;       // ahh

Others disagreed with the "uck" and "ahh"...

> No, this use of 'continue' has exactly the semantics expected of it,
> namely, to continue with the next iteration of the controlling loop.
...
> Neither can 'continue' be mistaken for anything else - it has only
> one meaning.
...
> But I'm curious; if you dislike 'continue' so much, what else is it
> good for?  Would you consider dropping it from the language, since
> its effects can be simulated using other methods?

I think the objection is that continue is not a no-op, but here, it is
being used as one.  (I.e., it is used where a no-op would suffice.)
The reader is forced to think about why `continue' was used instead of
a no-op.

> It has the pleasant side effect of being a rather obvious non-empty
> statement, indicating that it was intentional and not simply an
> accidental mistyping.

I think it is misleading - it suggests that it may have been
accidental, because `continue' is used, but unnecessary.


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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Francis Glassborow wrote:
> > IMHO, the use of the Null statement is obvious because the
> > code on the next line is NOT indented.

Steve Clamage <stephen.clamage@sun.com> wrote:
> Francis, perhaps you are being too hasty. I think this is a good
> motivation for Professor Stavtrup's "overloading whitespace" proposal
> (JOOP, April 1992). Maybe someone knows where to find an online
> copy of the paper.

Dr. Stroustrup acknowledges Professor Stavtrup's work and extends
it in his own paper "Generalizing Overloading for C++2000",
available online at http://www.research.att.com/~bs/whitespace98.pdf
(if you read it, be SURE to check out the free implementation at
http://www.research.att.com/~bs/whitespace.html -- it's a real
eye-opener!).

By a strange coincidence, both papers were originally published in
JOOP in April. Small world, isn't it?

--
Allan_W@my-deja.com is a "Spam Magnet," never read.
Please reply in newsgroups only, sorry.


Sent via Deja.com http://www.deja.com/
Before you buy.


[ 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              ]

In article <83c3m2$qal$1@nnrp1.deja.com>, AllanW <allan_w@my-deja.com>
writes
>By a strange coincidence, both papers were originally published in
>JOOP in April. Small world, isn't it?

Actually the second one was published in an April issue of Overload (As
it was written in response to my paper in EXE on providing a
language_cast and the deadlines would have been too tight for JOOP.

>

Francis Glassborow      Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation


[ 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              ]

Christian Bau wrote:
>
> AllanW <allan_w@my-deja.com> wrote:
>
> > I have no knowledge that the committee ever considered getting rid
> > of the null statement. But if they did, they likely decided to keep
> > it in order to protect it's usage in a for-statement body:
> >
> >     int strlen(const char*x) {
> >         const char*y;
> >         for (y=x; *y; ++y)
> >             ; // Null statement
> >         return y-x;
> >     }
> >
> > That's the textbook case of giving the null statement a value. The
> > well-known problem with this is it's unintentional use:
> >
> >     int length_of_next_section(const char*x) {
> >         const char*y;
> >         for (y=x; *y; ++y);
> >             if (','==*y) return y-x;
> >         return y-x;
> >     }
> >
> > Personally, I think that good compilers should give a warning for
> > null statements, just as they do for possible misuse of operator=:
>
> A good compromise, and a bit harder to implement: Give a warning if
> there is not enough separation between the semicolon and the closing
> bracket of the for statement. A good rule for giving a warning IMHO
> opinion would be that there must be either a comment between for (;;)
> and the semicolon, or the semicolon must be on the next line.
>
> Unfortunately, this means that information about white space has to be
> sent from the scanner to the parser :-(

Not necessarily; associating a line number to each token would
provide enough information to deduce that the empty ';' does not
occur on a separate line from the 'for(...)'.  It seems reasonable
to assume that most compilers do indeed provide line number info
for each token, so that diagnostics can be issued with meaningful
line numbers.

-- David R. Tribble, 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              ]

Steve Clamage wrote:
>
>
> IMHO there is no valid reason to forbid null declarations.
> I don't think anyone ever proposed allowing them, however.

I meant to say "compelling" reason. I realize that some people
have expressed the opinion that null declarations are bad. I
don't mean to claim that their reasons are invalid. I just
don't find them compelling.

--
Steve Clamage, stephen.clamage@sun.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              ]

Francis Glassborow wrote:
> > IMHO, the use of the Null statement is obvious because the
> > code on the next line is NOT indented.

Steve Clamage <stephen.clamage@sun.com> wrote:
> Francis, perhaps you are being too hasty. I think this is a good
> motivation for Professor Stavtrup's "overloading whitespace" proposal
> (JOOP, April 1992). Maybe someone knows where to find an online
> copy of the paper.

Dr. Stroustrup acknowledges Professor Stavtrup's work and extends
it in his own paper "Generalizing Overloading for C++2000",
available online at http://www.research.att.com/~bs/whitespace98.pdf
(if you read it, be SURE to check out the free implementation at
http://www.research.att.com/~bs/whitespace.html -- it's a real
eye-opener!).

By a strange coincidence, both papers were originally published in
JOOP in April. Small world, isn't it?

--
Allan_W@my-deja.com is a "Spam Magnet," never read.
Please reply in newsgroups only, sorry.


Sent via Deja.com http://www.deja.com/
Before you buy.
---
[ 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              ]

David R Tribble wrote:
> >>    while (process())
> >>        continue;       // ahh
>
> Marc van Leeuwen wrote:
> > Obviously the semantics of "continue" is being abused here; the
> > reader not used to this has to think a while and then conclude that
> > it does nothing (it's like a goto to a label that immediately
> > follows the jump itself). I think this is meant mostly to resemble
> > a common practice in FORTRAN, where by contrast CONTINUE is a no-op
> > by definition, and usually used as a (labelled) final statement in
> > a loop.
>
> No, this use of 'continue' has exactly the semantics expected of it,
> namely, to continue with the next iteration of the controlling loop.

I'd rather say more explicitly: skip the remainder of the loop body and
continue with the next iteration. Clearly this does the right thing when that
remainder is empty, but I don't think "continue" was introduced for that
purpose. I don't suppose you habitually put "continue" at the end of every
loop body, just to indicate that processing will thereafter continue with the
next iteration (note though that most people do place "break" after the final
case of a "switch").

>
> It has the pleasant side effect of being a rather obvious non-empty
> statement, indicating that it was intentional and not simply an
> accidental mistyping.
>
> Marc:
> > However, in all such situations in C, I would prefer the following:
> >
> >    while (process())
> >        {}       // an empty compound-statement
> >
> > I think this is clearer since an empty compound-statement is
> > obviously a valid statement that does nothing; more importantly, it
> > cannot be mistaken for anything else (the syntax even forbids empty
> > initializers, although of course one wouldn't expect an initializer
> > here).
>
> Neither can 'continue' be mistaken for anything else - it has only
> one meaning.
>
> I agree that '{}' is clearer than a lone ';'.  If you really can't
> stand using 'continue', then by all means use '{}' instead.
>
> But I'm curious; if you dislike 'continue' so much, what else is it
> good for?  Would you consider dropping it from the language, since
> its effects can be simulated using other methods?

Ah, if we could only drop everything from the language who's effect can be
simulated using other methods... Seriously though, there are more useful
applications of "continue" than serving as an empty loop body. I'm not sure
though that having special facilities for prematurely leaving language
constructs in some cases, which depending on the case are called "continue",
"break" or "return", while depending on the general "goto" mechanism for the
cases not covered by these, makes for a particularly elegant language design.

--
Marc van Leeuwen
Universite de Poitiers
http://wwwmathlabo.univ-poitiers.fr/~maavl/
---
[ 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              ]

>Most uses of null statements can be replaced with something better.
>For example:
>
>    while (process())
>        ;               // uck
>
>    while (process())
>        continue;       // ahh

I disagree with the "uck" and the "ahh." I'd reverse them, but it depends on
what you mean by "most." If you refer to future code, it's true, assuming
you can change the habits burned in by convention and tradition. If you
refer to legacy code, most *can* be replaced, but is it fair to break all
that code that follows a 30-year tradition?
---
[ 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              ]

Francis Glassborow wrote:
....
> sense.  What is required is that some form of diagnostic (In the UK, the
> BSI ruled that playing a tune did not constitute a diagnostic within the
> meaning of the act:) ...

Which act are you referring to? Maybe that act adds words that aren't in
the standard itself, but I don't think that ruling would be correct,
based only on the standard. A diagnostic must be a output message, but
there's no requirement that the message be in words. As long as it's
documented, a tune should be permissible. If not, where do we draw the
line? Is a diagnostic required to appear on-screen? if so, are blind
people required to buy a useless monitor to use an standard-conforming
implementation? If diagnostics are allowed to come out of the speaker,
are they required to be spoken rather than sung? If they can be sung, is
it required that the words be sung by a human voice in a natural
language? Must R2D2 be non-conforming?

That would be over-specification. If an implementation want to use a
simple 'beep' as a diagnostic, that would be fine with me for certain
contexts, such as code that's running on a watch-computer. Of course,
that doesn't work for diagnostics produced by #error and assert(), which
the standard requires to contain particular text.
---
[ 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              ]

Four wrote:
>
> On 11 Dec 1999 18:05:29 GMT, "Al Stevens" <alstevens@midifitz.com>
> wrote:
>
> >>Most uses of null statements can be replaced with something better.
> >>For example:
> >>
> >>    while (process())
> >>        ;               // uck
> >>
> >>    while (process())
> >>        continue;       // ahh
>
> I'd reverse "uck" and "ahh" too, prefering not to use "continue"
> unless it greatly unclutters the code that follows (and is well
> commented or at least visibly commented).  This is similar to how I
> prefer not to use "return" in the middle of a function unless the
> benefit outweighs other issues.

Obviously the semantics of "continue" is being abused here; the reader not
used to this has to think a while and then conclude that it does nothing (it's
like a goto to a label that immediately follows the jump itself). I think this
is meant mostly to resemble a common practice in FORTRAN, where by contrast
CONTINUE is a no-op by definition, and usually used as a (labelled) final
statement in a loop.

However, in all such situations in C, I would prefer the following

while (process())
       {}       // an empty compound-statement

I think this is clearer since an empty compound-statement is obviously a valid
statement that does nothing; more importantly, it cannot be mistaken for
anything else (the syntax even forbids empty initializers, although of course
one wouldn't expect an initializer here). By contrast, a lone semicolon could
be any of a whole bunch of things, depending on the context; most
significantly, it could be the obligatory-but-otherwise-good-for-nothing
semicolon that has to follow a "do ... while (...)" construct, and in the
example given one couldn't tell that it isn't without reading backwards before
the "while".

Given this possibility, the null statement represented by a semicolon can
always be avoided without any pain at all, and IMHO it should never have been
included in the language in the first place. But then C's syntax has never
been a showpiece of good design (which is probably why so many other languages
copied it :-).

> Maybe this has been mentioned already, but another situation where
> free semicolons are helpful is to avoid something like the following:
>
> if (!bCondition && something)
>    statement1;
> else if (!bCondition && somethingElse)
>    statement2;
> ...
> if (!bConditon)     {trap early so don't have to worry about latter}
>    ;                {null statement)

I suppose you meant "if(bCondition)". Again this could be

if (bConditon)       // trap early so don't have to worry about it latter
   {}                // do nothing

> else if (something) {on to bigger and better things}
>    statement1;
> else if (somethingElse)
>    statement2;
> ...
--
Marc van Leeuwen
Universite de Poitiers
http://wwwmathlabo.univ-poitiers.fr/~maavl/
---
[ 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              ]

In article <christian.bau-1312990957520001@christian-
mac.isltd.insignia.com>, Christian Bau <christian.bau@isltd.insignia.com
> writes
>A good compromise, and a bit harder to implement: Give a warning if there
>is not enough separation between the semicolon and the closing bracket of
>the for statement. A good rule for giving a warning IMHO opinion would be
>that there must be either a comment between for (;;) and the semicolon, or
>the semicolon must be on the next line.

Not in my book :)  (When I get to write it).

IMHO, the use of the Null statement is obvious because the code on the
next line is NOT indented.


Francis Glassborow      Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
---
[ 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              ]

Francis Glassborow wrote:
>
> In article <christian.bau-1312990957520001@christian-
> mac.isltd.insignia.com>, Christian Bau <christian.bau@isltd.insignia.com
> > writes
> >A good compromise, and a bit harder to implement: Give a warning if there
> >is not enough separation between the semicolon and the closing bracket of
> >the for statement. A good rule for giving a warning IMHO opinion would be
> >that there must be either a comment between for (;;) and the semicolon, or
> >the semicolon must be on the next line.
>
> Not in my book :)  (When I get to write it).
>
> IMHO, the use of the Null statement is obvious because the code on the
> next line is NOT indented.

Francis, perhaps you are being too hasty. I think this is a good
motivation for Professor Stavtrup's "overloading whitespace" proposal
(JOOP, April 1992). Maybe someone knows where to find an online
copy of the paper.

--
Steve Clamage, stephen.clamage@sun.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              ]

Four <meta__forms@space__1999.net> wrote in message
news:3852d1e8.202423945@news.itol.com...
> Maybe this has been mentioned already, but another situation where
> free semicolons are helpful is to avoid something like the following:
>
> if (!bCondition && something)
>    statement1;
> else if (!bCondition && somethingElse)
>    statement2;
> else if (!bCondition && somethingDifferent)
>    statement3;
> {etc.}
>
> If (bCondition) must be checked for each time to exclude it when
> False, but a False bCondition doesn't need a separate action of its
> own, the above can be harder to read in *real* code than a real-code
> version of the following:
>
> if (!bConditon)     {trap early so don't have to worry about latter}
>    ;                {null statement)
> else if (something) {on to bigger and better things :-}
>    statement1;
> else if (somethingElse)
>    statement2;
> else if (somethingDifferent)
>    statement3;
> {etc.}

I personally would prefer something along the lines of
if (!bCondition)
   if (something)
      statement1;
   else if (somethingElse)
      statement2;
   else if (sometihngDifferent)
      statement3;
   {etc.}



[ 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              ]

David Tribble wrote:
>> Most uses of null statements can be replaced with something better.
>> For example:
>>
>>    while (process())
>>        ;               // uck
>>
>>    while (process())
>>        continue;       // ahh

Al Stevens wrote:
> I disagree with the "uck" and the "ahh." I'd reverse them, but it
> depends on what you mean by "most." If you refer to future code,
> it's true, assuming you can change the habits burned in by
> convention and tradition. If you refer to legacy code, most *can*
> be replaced, but is it fair to break all that code that follows a
> 30-year tradition?

I meant "conceptually replaced" - I'm not saying anyone should
actually alter existing code.  Rephrasing: Most uses of null
statements can [conceptually] be coded as something better.

Four wrote:
> I'd reverse "uck" and "ahh" too, prefering not to use "continue"
> unless it greatly unclutters the code that follows (and is well
> commented or at least visibly commented).  This is similar to how I
> prefer not to use "return" in the middle of a function unless the
> benefit outweighs other issues.

Marc van Leeuwen wrote:
> Obviously the semantics of "continue" is being abused here; the
> reader not used to this has to think a while and then conclude that
> it does nothing (it's like a goto to a label that immediately
> follows the jump itself). I think this is meant mostly to resemble
> a common practice in FORTRAN, where by contrast CONTINUE is a no-op
> by definition, and usually used as a (labelled) final statement in
> a loop.

No, this use of 'continue' has exactly the semantics expected of it,
namely, to continue with the next iteration of the controlling loop.

It has the pleasant side effect of being a rather obvious non-empty
statement, indicating that it was intentional and not simply an
accidental mistyping.

Marc:
> However, in all such situations in C, I would prefer the following:
>
>    while (process())
>        {}       // an empty compound-statement
>
> I think this is clearer since an empty compound-statement is
> obviously a valid statement that does nothing; more importantly, it
> cannot be mistaken for anything else (the syntax even forbids empty
> initializers, although of course one wouldn't expect an initializer
> here).

Neither can 'continue' be mistaken for anything else - it has only
one meaning.

I agree that '{}' is clearer than a lone ';'.  If you really can't
stand using 'continue', then by all means use '{}' instead.

But I'm curious; if you dislike 'continue' so much, what else is it
good for?  Would you consider dropping it from the language, since
its effects can be simulated using other methods?

-- David R. Tribble, david@tribble.com, http://david.tribble.com --
Troll:
    while (ch = getc(in), ch != EOF)
        putc(ch, out);


[ 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              ]

Steve Clamage <stephen.clamage@sun.com> wrote:
> An expression statement ends with a semicolon, and the
> expression part is optional. A plain semicolon can therefore
> be used any place a statement is allowed. It can be thought of
> as the "null statement".
>  if( condition_with_side_effects )
>   ; // null expression statement
>  x = 1;;;;;;;;;;;;;;;;;; // silly, but valid

While null expression statements can be of use, neither of these
examples demonstrate it. After all, these can trivially be
replaced by

    condition_with_side_effects;
    x=1;

I have no knowledge that the committee ever considered getting rid
of the null statement. But if they did, they likely decided to keep
it in order to protect it's usage in a for-statement body:

    int strlen(const char*x) {
        const char*y;
        for (y=x; *y; ++y)
            ; // Null statement
        return y-x;
    }

That's the textbook case of giving the null statement a value. The
well-known problem with this is it's unintentional use:

    int length_of_next_section(const char*x) {
        const char*y;
        for (y=x; *y; ++y);
            if (','==*y) return y-x;
        return y-x;
    }

This code is designed to find the next comma, or else the end of the
string. But it doesn't work because of the "stray" semicolen at the
end of the for() statement.

Personally, I think that good compilers should give a warning for
null statements, just as they do for possible misuse of operator=:

    bool isEqual(int i, int j) {
        if (i=j) return true;
        else     return false;
    }

Although assignment (=) is legal here, most compilers assume that
this is not what the programmer meant to use. This is safe because
if the programmer DID mean this, there's an easy work-around:

    if ((i=j) != 0)

Similarly, if the null statement as the for-body gave warning
messages, there are several work-arounds available. The most
obvious two:

    for (y=x; *y; ++y)
        continue;

    for (y=x; *y; ++y)
        { }

Granted that this would generate false warnings for legacy
programs, but it wouldn't actually break any code at all.
I think that it would solve a lot more problems than it causes.

...But I guess warning messages aren't covered by the standard,
so this becomes a Quality issue?

--
Allan_W@my-deja.com is a "Spam Magnet," never read.
Please reply in newsgroups only, sorry.


Sent via Deja.com http://www.deja.com/
Before you buy.


[ 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              ]

>Most uses of null statements can be replaced with something better.
>For example:
>
>    while (process())
>        ;               // uck
>
>    while (process())
>        continue;       // ahh


I disagree with the "uck" and the "ahh." I'd reverse them, but it depends on
what you mean by "most." If you refer to future code, it's true, assuming
you can change the habits burned in by convention and tradition. If you
refer to legacy code, most *can* be replaced, but is it fair to break all
that code that follows a 30-year tradition?




[ 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              ]

CrazyPete@spamtrap.net wrote:
>
> Quick question, the compiler I am using gives an error
> at the common header sandwich extern "C" { ... };
> complaining about the ending semicolon.  Is this a
> valid error per the ISO standard?

"A _linkage-specification_ shall occur only in namespace scope." (7.5
p4)

Linkage specifications don't end with ';'. (7.5 p2)

The only thing that a lone ';' could be interpreted as is as a null
statement, and statements are only allowed in functions.


[ 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              ]

Steve Clamage <stephen.clamage@sun.com> wrote:
...
> the semicolon rules are ... well, I was going to say they are
> complex, but that isn't true. In fact, there is no specific
> semicolon rule!  Some constructs end with a semicolon, others
> do not, and still others have an optional semicolon.
>
> int f1() { ... } // ; forbidden
> class C {
>  int f2() { ... } // ; optional
> }; // ; required

The rule seems to be that extra semicolens within braces are
always allowed, with the exception of the braces of a
namespace statement.

But the last one (marked "required") is completely different
from the others. Recall that it's completely legal to use a
class-definition as a type-specifier in a declaration, like so:

    class C {
        long a;
        void b() const;
        int c;
    } c1, c2, c3;

This is a C legacy, left over from

    struct { // Anonymous struct
        long a;
        int c;
   } c1, c2, c3;

Making that particular semicolen optional would mean removing
this construct from the language. Big loss? I don't know, but
it would decrease compatibility with C.

--
Allan_W@my-deja.com is a "Spam Magnet," never read.
Please reply in newsgroups only, sorry.


Sent via Deja.com http://www.deja.com/
Before you buy.


[ 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              ]

In article <385154EA.DC46FF5@tribble.com>,
David R Tribble  <david@tribble.com> wrote:
>
>[This originated in comp.std.c++, but I've cross-posted to comp.std.c
>because of its relevance to both C and C++.  -drt]
>
>[Discussing empty, or "null", struct member declarations that consist
>of only a semicolon.]
>
>Al Stevens wrote:
>>
>> (Here we go again.)
>>
>>> There is no good reason for the rule, IMHO.
>>
>> Except that there is no specific need or use for null declarations
>> whereas there are uses for null statements.
>
>Most uses of null statements can be replaced with something better.
>For example:
>
>    while (process())
>        ;               // uck
>
>    while (process())
>        continue;       // ahh

It is amazing what turns people on!  I marginally prefer the first
style, actually.

>(The only exception is an empty statement following a label.)

One of the most common uses for them in well-structure code :-(


Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QG, England.
Email:  nmm1@cam.ac.uk
Tel.:  +44 1223 334761    Fax:  +44 1223 334679


[ 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              ]

AllanW wrote:
>
> Steve Clamage <stephen.clamage@sun.com> wrote:
> ...
> > the semicolon rules are ... well, I was going to say they are
> > complex, but that isn't true. In fact, there is no specific
> > semicolon rule!  Some constructs end with a semicolon, others
> > do not, and still others have an optional semicolon.
> >
> > int f1() { ... } // ; forbidden
> > class C {
> >       int f2() { ... } // ; optional
> > }; // ; required
>
> The rule seems to be that extra semicolens within braces are
> always allowed, with the exception of the braces of a
> namespace statement.

No, that's not a rule:

 class C {
  int a; // ; required
  ; // error
  int f1(); // ; required
  int f2() { ... }
  ; // optional
 };

> But the last one (marked "required") is completely different
> from the others. Recall that it's completely legal to use a
> class-definition as a type-specifier in a declaration, like so:
>
>     class C {
>         long a;
>         void b() const;
>         int c;
>     } c1, c2, c3;

No, not a different case. The declarators are optional, but the
semicolon is required whether declarators are present or not.

Semicolons are part of various syntactic constructs. There is no
simple set of rules that describes where to use semicolons.

--
Steve Clamage, stephen.clamage@sun.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              ]

nmm1@cus.cam.ac.uk (Nick Maclaren) writes:
> In article <385154EA.DC46FF5@tribble.com>,
> David R Tribble  <david@tribble.com> wrote:
> >(The only exception is an empty statement following a label.)
>
> One of the most common uses for them in well-structure code :-(

Even then, there are other forms of no-op: `0;'.


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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <3850C2F6.7508FDA6@lucent.com>, Michiel Salters
<salters@lucent.com> writes
>Must the compiler emit an error?

I do not think that the Standard has any concept of an error in that
sense.  What is required is that some form of diagnostic (In the UK, the
BSI ruled that playing a tune did not constitute a diagnostic within the
meaning of the act:) What happens after that is entirely up to the
compiler writers.

>
>I thought any diagnostic would be OK, and I'm suprised by the number
>of compilers who implement this as an error instead of a warning.
>Especially since it's likely this can be changed easily.
>
>Of course, it doesn't promote the writing of portable code if some
>compilers started doing this.
>
>Michiel Salters
>

Francis Glassborow      Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
---
[ 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              ]

On 11 Dec 1999 18:05:29 GMT, "Al Stevens" <alstevens@midifitz.com>
wrote:

>>Most uses of null statements can be replaced with something better.
>>For example:
>>
>>    while (process())
>>        ;               // uck
>>
>>    while (process())
>>        continue;       // ahh
>
>
>I disagree with the "uck" and the "ahh." I'd reverse them, but it depends on
>what you mean by "most." If you refer to future code, it's true, assuming
>you can change the habits burned in by convention and tradition. If you
>refer to legacy code, most *can* be replaced, but is it fair to break all
>that code that follows a 30-year tradition?

I'd reverse "uck" and "ahh" too, prefering not to use "continue"
unless it greatly unclutters the code that follows (and is well
commented or at least visibly commented).  This is similar to how I
prefer not to use "return" in the middle of a function unless the
benefit outweighs other issues.

Maybe this has been mentioned already, but another situation where
free semicolons are helpful is to avoid something like the following:

if (!bCondition && something)
   statement1;
else if (!bCondition && somethingElse)
   statement2;
else if (!bCondition && somethingDifferent)
   statement3;
{etc.}

If (bCondition) must be checked for each time to exclude it when
False, but a False bCondition doesn't need a separate action of its
own, the above can be harder to read in *real* code than a real-code
version of the following:

if (!bConditon)     {trap early so don't have to worry about latter}
   ;                {null statement)
else if (something) {on to bigger and better things :-}
   statement1;
else if (somethingElse)
   statement2;
else if (somethingDifferent)
   statement3;
{etc.}

I don't know how highly this sort of usage is regarded, but it is
pretty common, and often helps readability.


---- ---- ---- ----
My e-address does not really have
any underscore characters in 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              ]

In article <82sa72$r0d$1@nnrp1.deja.com>, AllanW <allan_w@my-deja.com> wrote:

> I have no knowledge that the committee ever considered getting rid
> of the null statement. But if they did, they likely decided to keep
> it in order to protect it's usage in a for-statement body:
>
>     int strlen(const char*x) {
>         const char*y;
>         for (y=x; *y; ++y)
>             ; // Null statement
>         return y-x;
>     }
>
> That's the textbook case of giving the null statement a value. The
> well-known problem with this is it's unintentional use:
>
>     int length_of_next_section(const char*x) {
>         const char*y;
>         for (y=x; *y; ++y);
>             if (','==*y) return y-x;
>         return y-x;
>     }
>
> Personally, I think that good compilers should give a warning for
> null statements, just as they do for possible misuse of operator=:

A good compromise, and a bit harder to implement: Give a warning if there
is not enough separation between the semicolon and the closing bracket of
the for statement. A good rule for giving a warning IMHO opinion would be
that there must be either a comment between for (;;) and the semicolon, or
the semicolon must be on the next line.

Unfortunately, this means that information about white space has to be
sent from the scanner to the parser :-(

Maybe even more useful would be a warning for any obviously "wrong" indentation.


[ 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              ]

Quick question, the compiler I am using gives an error
at the common header sandwich extern "C" { ... };
complaining about the ending semicolon.  Is this a
valid error per the ISO standard?
Thanks
---
[ 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              ]

CrazyPete@spamtrap.net wrote:
>
> Quick question, the compiler I am using gives an error
> at the common header sandwich extern "C" { ... };
> complaining about the ending semicolon.  Is this a
> valid error per the ISO standard?

An expression statement ends with a semicolon, and the expression part
is optional. A plain semicolon can therefore be used any place a
statement is allowed. It can be thought of as the "null statement".
 if( condition_with_side_effects )
  ; // null expression statement
 x = 1;;;;;;;;;;;;;;;;;; // silly, but valid

But there is no "null declaration". In places where a declaration
but not a statement is required, you cannot use a plain semicolon.

There is no good reason for the rule, IMHO. There is no conceptual
difficulty with allowing null declarations.  Compilers must
make a special check for "null declarations" so that they can
emit an error message. It would be easier to ignore them.

--
Steve Clamage, stephen.clamage@sun.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              ]

Steve Clamage wrote:

> CrazyPete@spamtrap.net wrote:

> > Quick question, the compiler I am using gives an error
> > at the common header sandwich extern "C" { ... };
> > complaining about the ending semicolon.  Is this a
> > valid error per the ISO standard?

> An expression statement ends with a semicolon, and the expression part
> is optional. A plain semicolon can therefore be used any place a
> statement is allowed. It can be thought of as the "null statement".

> But there is no "null declaration". In places where a declaration
> but not a statement is required, you cannot use a plain semicolon.

> There is no good reason for the rule, IMHO. There is no conceptual
> difficulty with allowing null declarations.  Compilers must
> make a special check for "null declarations" so that they can
> emit an error message. It would be easier to ignore them.

Must the compiler emit an error?

I thought any diagnostic would be OK, and I'm suprised by the number
of compilers who implement this as an error instead of a warning.
Especially since it's likely this can be changed easily.

Of course, it doesn't promote the writing of portable code if some
compilers started doing this.

Michiel Salters


[ 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              ]

(Here we go again.)

>There is no good reason for the rule, IMHO.

Except that there is no specific need or use for null declarations whereas
there are uses for null statements.

>Compilers must make a special check for "null declarations" so that they
can emit an error message.

Really? Translators have to check for all out-of-place lexical tokens. I'd
expect this one to be caught by the same switch default statement that finds
a stray asterisk, for example, where an extern declaration is expected by
the grammar. Permitting null declarations could just as likely add to what a
translator checks for.

>It would be easier to ignore them.

Assuming a translator for which that is true, why have a language idiom that
serves no purpose except to make it easier on some particular translator?
Probably you can trot out examples that do just that, but why add to that
list?

On the other hand, gcc 2.95.2 permits the null declaration in both its C and
C++ compilers. So apparently someone in the gcc developer's camp agrees with
you. Or else it's a bug.




[ 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              ]

Michiel Salters wrote:
>
> Steve Clamage wrote:
...
> > difficulty with allowing null declarations.  Compilers must
> > make a special check for "null declarations" so that they can
> > emit an error message. It would be easier to ignore them.
>
> Must the compiler emit an error?

No, it can emit an error message, instead :-)

> I thought any diagnostic would be OK, and I'm suprised by the number
> of compilers who implement this as an error instead of a warning.
> Especially since it's likely this can be changed easily.

A null statement in a location where statements are prohibited is a
syntax error. As such, it requires at least one diagnostic. The standard
doesn't distinguish between error messages and warning messages, but
only between code that requires a diagnostic, and code which allows a
diagnostic (there's no situation in which a diagnostic is prohibited).

Most compilers I know of adhere pretty closely to the convention of
emmitting error messages for mandatory diagnostics, and warnings for
things which might be errors, in some circumstances. The one I use most
often includes a third level: "remark", which is even weaker than a
warning, for things the vendor thinks represent poor (but legal) coding
practices.


[ 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              ]

Al Stevens wrote:
>
> (Here we go again.)

Yeah. :-)

>
> >There is no good reason for the rule, IMHO.
>
> Except that there is no specific need or use for null declarations whereas
> there are uses for null statements.

But the semicolon rules are ... well, I was going to say they are
complex, but that isn't true. In fact, there is no specific semicolon
rule!  Some constructs end with a semicolon, others do not,
and still others have an optional semicolon.

int f1() { ... } // ; forbidden
class C {
 int f2() { ... } // ; optional
}; // ; required
namespace N {
 int f3() { ... } // ; forbidden
} // ; forbidden

One reason for disallowing extra tokens (like commas in a list)
is that allowing them is likely to mask an editing glitch.
 int f(int a, int b, ); // something missing?
 enum E { a, b, c, };   // something missing?
(I have always thought that allowing the trailing comma inside a
brace-initializer was a mistake in K&R C.)

IMHO there is no such consideration for extra semicolons separating
declarations. It doesn't provide any extra detection of editing
errors, except for the putative error of deleting all but the
terminating semicolon of a declaration. It does not confuse the
reader or the writer of the code. It does not introduce any
ambiguities. It makes using semicolons easier.

>
> >Compilers must make a special check for "null declarations" so that they
> can emit an error message.
>
> Really? Translators have to check for all out-of-place lexical tokens. I'd
> expect this one to be caught by the same switch default statement that finds
> a stray asterisk, for example, where an extern declaration is expected by
> the grammar. Permitting null declarations could just as likely add to what a
> translator checks for.

The details depend on the compiler organization and what kind of error
reporting it wants to provide.  A compiler might want to be more
specific about certain kinds of tokens:
 line 23: unexpected '@'
 line 40: ')' has no matching '('
 line 62: ';' not permitted between declarations

Allowing null declarations is simple. Add ';' to the list of tokens
that can start a declaration. If the first token of a decl is ';',
skip the rest of the decl processing and consume the ';' normally.
It might mean that a null expression-statement would be treated
as a null declaration-statement, but that doesn't change the
meaning of any code.

--
Steve Clamage, stephen.clamage@sun.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              ]

[This originated in comp.std.c++, but I've cross-posted to comp.std.c
because of its relevance to both C and C++.  -drt]

[Discussing empty, or "null", struct member declarations that consist
of only a semicolon.]

Al Stevens wrote:
>
> (Here we go again.)
>
>> There is no good reason for the rule, IMHO.
>
> Except that there is no specific need or use for null declarations
> whereas there are uses for null statements.

Most uses of null statements can be replaced with something better.
For example:

    while (process())
        ;               // uck

    while (process())
        continue;       // ahh

(The only exception is an empty statement following a label.)

>> Compilers must make a special check for "null declarations" so that
>> they can emit an error message.
>
> Really? Translators have to check for all out-of-place lexical
> tokens. I'd expect this one to be caught by the same switch default
> statement that finds a stray asterisk, for example, where an extern
> declaration is expected by the grammar. Permitting null declarations
> could just as likely add to what a translator checks for.

The difference between a stray semicolon and, say, a stray asterisk
is that a semicolon is always used to terminate something (a
definition, a declaration, a statement), whereas most of the other
punctuation tokens are used in the middle of expressions or
declarators.  Thus a stray semicolon could almost always be
considered benign, terminating an empty entity; other stray
punctuation tokens could not make such a claim, and can always be
considered erroneous.

>> It would be easier to ignore them.
>
> Assuming a translator for which that is true, why have a language
> idiom that serves no purpose except to make it easier on some
> particular translator? Probably you can trot out examples that do
> just that, but why add to that list?

Personally, I'd like to see empty member declarations allowed
in standard C and C++.

    struct Abc
    {
        int  a;
        int  b;
        ;           // should be benign
        int  c;
    };

Some syntatic niceties exist for the benefit of machine-generated
code.  For example, a (useless) trailing comma is allowed in
array initializer lists:

    int  a[] = { 1, 2, 3 };
    int  a[] = { 1, 2, 3, };

This sort of thing makes it easier to write programs that produce
C/C++ code (e.g., YACC and Lex), especially when generating very
large array initializers.

C99 also allows a trailing comma in enum definitions:

    enum Color { RED, BLUE, GREEN };
    enum Color { RED, BLUE, GREEN, };

There are also two different, but semantically equivalent, ways
for the preprocessor to check for a macro definition:

    #if defined NAME
    #if defined(NAME)

Then there's sizeof:

    i = sizeof a;
    i = sizeof(a);

Yes, the argument can be made that all of these syntactical
redundancies are overkill and exist just to clutter up the language,
but in reality they sometimes make it easy for somebody.
Programs are (usually) meant to be read and maintained by humans,
after all.

> On the other hand, gcc 2.95.2 permits the null declaration in both
> its C and C++ compilers. So apparently someone in the gcc
> developer's camp agrees with you. Or else it's a bug.

QoI.  Exactly like Pascal compilers that allow extra semicolons
to act more like statement terminators (esp. preceding 'else'),
even though the language uses semicolons as statement separators.
In other words, these niceties also cater to the limitations of
human programmers.

-- David R. Tribble, 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              ]

Steve Clamage <stephen.clamage@sun.com> writes:
> I have always thought that allowing the trailing comma inside a
> brace-initializer was a mistake in K&R C.

I think you are wrong to think so. In code that we write, we often have
static initialized arrays to which we occasionally add new entries at
the end. It is very annoying to try to remember to go back and add a
comma at the end of the previous last item when you are adding new items.

It is even more annoying when generating these automatically to keep
track of whether you are on the last item so as not to generate a
trailing comma.


[ 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              ]

Hyman Rosen wrote:
>
> In code that we write, we often have
> static initialized arrays to which we occasionally add new entries at
> the end. It is very annoying to try to remember to go back and add a
> comma at the end of the previous last item when you are adding new items.
>

This issue can be solved by the following coding style:

  int foo[] = {
        10
      , 100
      , 1000
  };

> It is even more annoying when generating these automatically to keep
> track of whether you are on the last item so as not to generate a
> trailing comma.

I agree on this.

--
Regards,
Biju Thomas


[ 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              ]

CrazyPete@spamtrap.net wrote:

> Quick question, the compiler I am using gives an error
> at the common header sandwich extern "C" { ... };
> complaining about the ending semicolon.  Is this a
> valid error per the ISO standard?

Yes.

There is an empty statement, called the null statement. So inside a function
definition, or anywhere else that has a list of statements, you can have an
extra semicolon. The semicolon marks the end of the null statement. [6.2/1]

But outside a function definition, where you can have declarations but not
statements, you can't have an extra semicolon. This would be an empty
declaration, a "null declaration", and the language doesn't allow those.
[7/3]

    -- Darin
---
[ 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              ]

Michiel Salters wrote:
>
> Steve Clamage wrote:
>
> > But there is no "null declaration". In places where a declaration
> > but not a statement is required, you cannot use a plain semicolon.
>
> > There is no good reason for the rule, IMHO. There is no conceptual
> > difficulty with allowing null declarations.  Compilers must
> > make a special check for "null declarations" so that they can
> > emit an error message. It would be easier to ignore them.
>
> Must the compiler emit an error?
>
> I thought any diagnostic would be OK, and I'm suprised by the number
> of compilers who implement this as an error instead of a warning.

According to the standard, the code is ill-formed, so the compiler
is required to emit a "diagnostic message".  The standard never
requires a compiler to reject a program, and it makes no statements
about "error" versus "warning" messages.

Compiler can choose to accept invalid code, and most compilers
have options to allow or disallow various kinds of invalid code.

--
Steve Clamage, stephen.clamage@sun.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              ]

David R Tribble <david@tribble.com> writes:
> The difference between a stray semicolon and, say, a stray asterisk
> is that a semicolon is always used to terminate something (a
> definition, a declaration, a statement), whereas most of the other
> punctuation tokens are used in the middle of expressions or
> declarators.

(Excepting for (;;), but that doesn't conflict with your point.)

> Some syntatic niceties exist for the benefit of machine-generated
> code.  For example, a (useless) trailing comma is allowed in
> array initializer lists:
>
>     int  a[] = { 1, 2, 3 };
>     int  a[] = { 1, 2, 3, };

Trailing commas are helpful beacuse they make the comma a terminator
rather than a separator, and terminators are easier to generate.
Semicolons are already terminators, so I don't think commas are too
relevant here.


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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]