David R Tribble wrote:
>
> Christopher Eltschka wrote:
> >
> > Steve Clamage wrote:
> > >
> > > "Greg Brewer" <nospam.gregb@hal-pc.org> writes:
> > >
> > > >You have yet to give me one good reason why a null data statement
> > > >should not be allowed.
> > >
> > > There is no good reason. That is, there is no technical difficulty
> > > in allowing null declarations, and I can't think of a program that
> > > would break if they were allowed in the language.
> > >
> > > C didn't allow them, and nobody made an effort to add the capability
> > > to C++.
> > >
> > > The difficulty is greater in C, it seems to me. Suppose you have
> > >
> > > void foo()
> > > {
> > >     int i;;
> > >     xxxx
> > > }
> > >
> > > In C, can xxx be a declaration? It can only if the extra semicolon
> > > creates a null declaration, because in C declarations cannot follow
> > > statements in the same block. So to decide if the extra semicolon
> > > is a null statement or a null declaration, you need to look at
> > > what follows it -- which requires arbitrary amounts of lookahead.
> > > Or you could disallow null declarations at block scope, allowing
> > > them elsewhere.
> >
> > Another fix could be to say that ";" is a null declaration
> > whereever declarations are allowed, and a null statement
> > elsewhere.
> > After "int i;" a declaration is allowed, therefore the additional
> > ";" is a null declaration, and therefore xxx may be a declaration
> > as well.
> > No lookahead is needed for this rule.
>
> No, potentially infinite lookahead is still required:
>
>     void bar()
>     {
>         int  i;
>         ; ; ;       /* null declarations */
>         int  j;
>         ; ; ;       /* null declarations or null statements? */

int j; is a declaration. Therefore after int j; declarations
are allowed. Therefore the above are null declarations.
No lookahead is required (is lookahead required to decide
if "int unique;" is legal at a point? Probably not. And
a null declaration is allowed whereever this would be
allowed).

>         i = 0;
>         ; ; ;       /* null statements */
>     }
>
> But this is only a problem with C89/C90.  C9X, like C++, allows mixed
> statements and declarations in any order.

As I've shown, it is no problem even with C89/C90.
Just try to replace the ";" with "int unique;", and
if the resulting code would be legal, it's a null
declaration.
Of course, if it would go into a C standard, it would be C9x
or later, and therefore the question if it poses a problem
with C89/C90 is not really relevant.

[...]


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

"Greg Brewer" <nospam.gregb@hal-pc.org> writes:

>David R Tribble <david@tribble.com> wrote in message
>news:37BD8DAC.7727FB3B@tribble.com...
>> Greg Brewer wrote:
>> > ... I have yet to hear of 1 reason why it is not allowed.
>> History.  Because it never was allowed, and no one ever made a
>> proposal to ANSI/ISO that it should be.

>I'm wondering something.  Does the standard in fact disallow it?  It occurs
>to me that it may not say one way or the other.  One of the implementation
>dependent areas.

There is no syntax production that combined with semantic restrictions
allows just a semicolon where a declaration is required. (The syntax
alone seems to allow empty declarations, but other restrictions
forbit them.)

By constrast, where a statement is allowed, you can have an
expression-statement. An expression-statement consists of an
optional expression followed by a semicolon.

As I said in an earlier post, there is no technical reason why
empty declarations should not be allowed. They happened not to
be allowed in C, and C++ never added them as an extension.

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

In article <7pgqtb$1lnk$1@news.hal-pc.org>, "Greg Brewer"
<nospam.gregb@hal-pc.org> wrote:

> James Kuyper <kuyper@wizard.net> wrote in message
> news:37BB316D.844901D1@wizard.net...
>>
>>> James Kuyper Jr. <kuyper@wizard.net> wrote in message
>>> news:37BAAC8C.731D8A16@wizard.net...
>>>> Because it's not needed. If you do think it's needed, and want to
>>>> convince us, you'll have to show us why. What you've shown so far
>>>> doesn't need it.
>>>
>>> I say it is and I say it is a waste for the compiler to waste time
>>
>> So you're just going to assert that it's needed, without showing why?
>> That's OK, but I wouldn't expect to convince anybody using those
>> methods.
>
> Yes I am.  I want someone to explain why it should be disallowed.  If you
> will review the subject of this thread, it is "Why's of ...".  I really
> don't think "Because I don't need it" or "There is another way to do it"
> qualify as very good reasons.  That reasoning leads one back to plain ol' C
> since you can do everything in C that you can do in C++.
[snip]

Do you really think in such extreme terms? Engineering is about tradeoffs,
particularly between theory and practicality. Unless there is a strong
need for null data declarations, they shouldn't be in the language. It's
just the way a usable piece of engineering is made. If you put every
little feature you come up with into it, it will become unusable because
practicality has been pushed aside.
---
[ 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 <acgv3.103$S24.5974@ultra>, Matt Seitz <mseitz@meridian-
data.com> writes
>The answer to the first question seems to be "To keep the language as simple
>and small as possible, one should not allow something unless there is a need
>for it."  Since no one saw a need for this, it was not allowed.

I suspect that the answer is even simpler.  I think it just fell out of
the grammar and as no one had any use for empty declarations nobody
asked for a change.

Perhaps the proponent would like to rewrite the grammar and ensure that
nothing silly happens as a consequence.

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 <david@tribble.com> wrote in message
news:37BD8DAC.7727FB3B@tribble.com...
> Greg Brewer wrote:
> > ... I have yet to hear of 1 reason why it is not allowed.
> History.  Because it never was allowed, and no one ever made a
> proposal to ANSI/ISO that it should be.

I'm wondering something.  Does the standard in fact disallow it?  It occurs
to me that it may not say one way or the other.  One of the implementation
dependent areas.

Greg Brewer
---
[ 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 <7pkfia$1584$1@news.hal-pc.org>, "Greg Brewer"
<nospam.gregb@hal-pc.org> wrote:

> David R Tribble <david@tribble.com> wrote in message
> news:37BD8DAC.7727FB3B@tribble.com...
> > Greg Brewer wrote:
> > > ... I have yet to hear of 1 reason why it is not allowed.
> > History.  Because it never was allowed, and no one ever made a
> > proposal to ANSI/ISO that it should be.
>
> I'm wondering something.  Does the standard in fact disallow it?  It occurs
> to me that it may not say one way or the other.  One of the implementation
> dependent areas.

Implementation-dependent areas are based on hardware considerations, since
there is a wide range of differing hardware that C++ is meant to support.
Implementation-defined areas don't apply to syntax! That would be a mess.
---
[ 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 <francis@robinton.demon.co.uk> wrote in message
news:HIdUewAOSbv3EwsX@robinton.demon.co.uk...
> Perhaps the proponent would like to rewrite the grammar and ensure that
> nothing silly happens as a consequence.

Since I started the discussion, I would guess "the proponent" would be me.
I would prefer it to be a proponent.  I will be retired before any such
change could be approved and implemented.  I consider these discussions to
be of an academic nature to see if anyone sees a hidden flaw to the idea or
if the problem is widespread.  My patience did get taxed by those who
answered "because its not needed".
---
[ 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              ]

James Kuyper Jr. <kuyper@wizard.net> wrote in message
news:37BEF24D.60E7B89E@wizard.net...
> You never provided enough detail to make it clear why a null member
> declaration was needed. I suspect that if you were to provide the
> additional details, we'd be able to show you how to do it without null
> member declarations. However, we'll never know for sure unless and until
> you provide a sufficiently complete (but preferably simplified) example.

That is not the purpose of this discussion.  I am looking for a definitive
reason why not.  While programming, I have had some problems with compilers
complaining about null declarations.  I was able to eliminate them easily
enough.  I've wondered why they are not allowed.

The answer seems to be because that is the way it is in C.  In C,
declarations must come before all statements and C defines a sequence that
resolves to a semicolon, whitespace, semicolon as a statement.  Therefore,
declaration;;declaration would be a declaration after a statement.  In C++,
this is no problem inside a function.  However, it is a problem inside a
struct since statements are not allowed in a struct except as part of an
inline function.

Personally, I think this should be changed.  But even if everyone absolutely
agreed with me, I don't expect that I would ever use a compiler that
implements the change.

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

Christopher Eltschka wrote:
>
> Steve Clamage wrote:
> >
> > "Greg Brewer" <nospam.gregb@hal-pc.org> writes:
> >
> > >You have yet to give me one good reason why a null data statement
> > >should not be allowed.
> >
> > There is no good reason. That is, there is no technical difficulty
> > in allowing null declarations, and I can't think of a program that
> > would break if they were allowed in the language.
> >
> > C didn't allow them, and nobody made an effort to add the capability
> > to C++.
> >
> > The difficulty is greater in C, it seems to me. Suppose you have
> >
> > void foo()
> > {
> >     int i;;
> >     xxxx
> > }
> >
> > In C, can xxx be a declaration? It can only if the extra semicolon
> > creates a null declaration, because in C declarations cannot follow
> > statements in the same block. So to decide if the extra semicolon
> > is a null statement or a null declaration, you need to look at
> > what follows it -- which requires arbitrary amounts of lookahead.
> > Or you could disallow null declarations at block scope, allowing
> > them elsewhere.
>
> Another fix could be to say that ";" is a null declaration
> whereever declarations are allowed, and a null statement
> elsewhere.
> After "int i;" a declaration is allowed, therefore the additional
> ";" is a null declaration, and therefore xxx may be a declaration
> as well.
> No lookahead is needed for this rule.

No, potentially infinite lookahead is still required:

    void bar()
    {
        int  i;
        ; ; ;       /* null declarations */
        int  j;
        ; ; ;       /* null declarations or null statements? */
        i = 0;
        ; ; ;       /* null statements */
    }

But this is only a problem with C89/C90.  C9X, like C++, allows mixed
statements and declarations in any order.

OTOH, null member declarations shouldn't be a problem:

    struct Xyzzy
    {
        int   i;
        ; ; ;        /* ignored */
        int   j;
        ; ; ;        /* ignored */
    };

The problem is finding a suitable reason for relaxing the syntax
this way.  And if we should allow it, should we also allow:

    enum Color
    {
        RED,
        , , ,        /* ignored */
        BLUE,
        GREEN,
        ,,,          /* ignored */
    };

But again, is there a real need for this?

Greg Brewer wrote:
> ... I have yet to hear of 1 reason why it is not allowed.

History.  Because it never was allowed, and no one ever made a
proposal to ANSI/ISO that it should be.

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

Greg Brewer <nospam.gregb@hal-pc.org> wrote in message
news:7pi5dh$2k38$1@news.hal-pc.org...
> Moreover, I have yet to hear of 1 reason why it is not allowed.

It seems there are two questions.  First, "Why was it not allowed in the
first place?"  Second, "Should we now change the standard to allow it?"

The answer to the first question seems to be "To keep the language as simple
and small as possible, one should not allow something unless there is a need
for it."  Since no one saw a need for this, it was not allowed.

To answer the second question, we need to ask "Do the benefits outweigh the
costs/risks?".

Benefits:
Allowing your macro to work

Costs/risks:
Modifying every C++ compiler, with all the chances for introducing errors
and possible unforeseen consequences that implies

To me, while the cost may seem relatively small, the benefit seems even
smaller.

You are correct that no one has identified a specific problem that would
definitely be caused by adding this.  However, I would prefer that the
committee err on the side of caution.  Before adding a new feature, I want
positive evidence that the new feature will have substantial benefits that
outweigh the costs and risks.  I believe it is the responsibility of the
party advocating change to prove that the change is beneficial.




[ 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 <37BA77BD.11B6D57D@physik.tu-muenchen.de>,
  Christopher Eltschka <celtschk@physik.tu-muenchen.de> wrote:
> Steve Clamage wrote:
> >
> > "Greg Brewer" <nospam.gregb@hal-pc.org> writes:

> > >You have yet to give me one good reason why a null data statement
> > >should not be allowed.

> > There is no good reason. That is, there is no technical difficulty
> > in allowing null declarations, and I can't think of a program that
> > would break if they were allowed in the language.

> > C didn't allow them, and nobody made an effort to add the capability
> > to C++.

> > The difficulty is greater in C, it seems to me. Suppose you have
> >
> > void foo()
> > {
> >     int i;;
> >     xxxx
> > }

> > In C, can xxx be a declaration? It can only if the extra semicolon
> > creates a null declaration, because in C declarations cannot follow
> > statements in the same block. So to decide if the extra semicolon
> > is a null statement or a null declaration, you need to look at
> > what follows it -- which requires arbitrary amounts of lookahead.
> > Or you could disallow null declarations at block scope, allowing
> > them elsewhere.

> Another fix could be to say that ";" is a null declaration whereever
> declarations are allowed, and a null statement elsewhere.
> After "int i;" a declaration is allowed, therefore the additional ";"
> is a null declaration, and therefore xxx may be a declaration as well.
> No lookahead is needed for this rule.

An easier fix would be to define a null statement in C/C++, and drop the
optional from the expression in an expression statement.  At that point,
you might want to argue whether an empty statement is a declaration or
not; I'd argue that it should be, in order to allow it outside of a
function.  (Note that the problem Steve Clamage cites for C no longer
exists anyway, since the FDIS for C9x adopts the C++ rule of allowing
declarations anywhere.)

Personally, I'm fairly sure that the fact a simple ';' outside a
function isn't allowed in C is a historical artifact.  C and C++ don't
have, and never have had, empty statements.  Anywhere.  They do have
expression statements (whose side effects may contain things like
assignment or function calls).  And the expression in an expression
statement is optional.  So what looks like an empty statement is in fact
an expression statement, and naturally, expression statements cannot
occur outside of function bodies.

Given that both C and C++ now allow declaration statements anywhere any
statement is legal, the simplest solution to me would seem to be to not
allow empty expressions, create an explicit empty statement whose syntax
is simply ';', and declare that an empty statement is a legal
declaration.

--
James Kanze                   mailto: James.Kanze@dresdner-bank.com
Conseils en informatique orient   e objet/
                  Beratung in objekt orientierter Datenverarbeitung
Ziegelh   ttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.


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

Greg Brewer wrote:
>
> Pete Becker <petebecker@acm.org> wrote in message
> news:37BB6E4F.A3A1742C@acm.org...
> > You have yet to give one good reason, other than examples that don't
> > illustrate your point, why a null statment should be allowed.
>
> I tried to accommidate your request but since you can't be accomidated, I
> give up.  Giving a good reason wasn't the point.  Try rereading the subject
> line and tell me why not.  Other than that, I would say you should go back
> to C since all that extra stuff they added to it for C++ isn't really
> needed.

You never provided enough detail to make it clear why a null member
declaration was needed. I suspect that if you were to provide the
additional details, we'd be able to show you how to do it without null
member declarations. However, we'll never know for sure unless and until
you provide a sufficiently complete (but preferably simplified) example.


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

James Kuyper <kuyper@wizard.net> wrote in message
news:37BB316D.844901D1@wizard.net...
>
> > James Kuyper Jr. <kuyper@wizard.net> wrote in message
> > news:37BAAC8C.731D8A16@wizard.net...
> > > Because it's not needed. If you do think it's needed, and want to
> > > convince us, you'll have to show us why. What you've shown so far
> > > doesn't need it.
> > I say it is and I say it is a waste for the compiler to waste time
> So you're just going to assert that it's needed, without showing why?
> That's OK, but I wouldn't expect to convince anybody using those
> methods.

Yes I am.  I want someone to explain why it should be disallowed.  If you
will review the subject of this thread, it is "Why's of ...".  I really
don't think "Because I don't need it" or "There is another way to do it"
qualify as very good reasons.  That reasoning leads one back to plain ol' C
since you can do everything in C that you can do in C++.

> > complaining about a program that is good in every other way except that
it
> > has an extra comment inside a structure declaration.  That should not be
an
> > error.
> I thought you were concerned about a problem due to an illegally placed
> semicolon, not an extra comment. Is there something else involved here?

Opps.  I meant to say semicolon.   I have no idea how I happen to type
comment!

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

Pete Becker <petebecker@acm.org> wrote in message
news:37BB6E4F.A3A1742C@acm.org...
> You have yet to give one good reason, other than examples that don't
> illustrate your point, why a null statment should be allowed.

I tried to accommidate your request but since you can't be accomidated, I
give up.  Giving a good reason wasn't the point.  Try rereading the subject
line and tell me why not.  Other than that, I would say you should go back
to C since all that extra stuff they added to it for C++ isn't really
needed.

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

Greg Brewer wrote:
>
> I think you have it backwards.  Unless there is a good reason to make
> something illegal, it should be legal.  Because you have no interest in
> rabbit photography is not a reason to support laws that forbid my persuit of
> my passion.
>

But that doesn't mean that I have to supply you with a camera. We're not
talking about designing a new language, but about changing one that's
already in use. It's not a matter of simply deciding not to prohibit
something, but of changing compilers to handle something that did not
exist before. That takes time and money.

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

> But that doesn't mean that I have to supply you with a camera. We're not
> talking about designing a new language, but about changing one that's
> already in use. It's not a matter of simply deciding not to prohibit
> something, but of changing compilers to handle something that did not
> exist before. That takes time and money.

Never asked you to supply the camera.  Not even asking you to own or use the
camera.  But it appears that someone has decided to prohibit something!  As
near as I can tell, the compiler code looks something like

   if (c == ' ' || c == '\t' || ...)
      continue;
   if (c == ';')
      if (definingStruct)
         if (!definition[0])
            raiseError(...);
         else
            ....

instead of

   if (c == ' ' || c == '\t' || ...)
      continue;
   if (c == ';')
      if (definingStruct)
         if (!definition[0])
            continue;
         else
            ....

which should be no biggie.  Frankly, I don't understand your hostility to
the idea.  Moreover, I have yet to hear of 1 reason why it is not allowed.

Greg Brewer




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

James Kuyper Jr. <kuyper@wizard.net> wrote in message
news:37BAAC8C.731D8A16@wizard.net...
> Because it's not needed. If you do think it's needed, and want to
> convince us, you'll have to show us why. What you've shown so far
> doesn't need it.

I say it is and I say it is a waste for the compiler to waste time
complaining about a program that is good in every other way except that it
has an extra comment inside a structure declaration.  That should not be an
error.

Greg Brewer




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

Greg Brewer wrote:
>
> James Kuyper Jr. <kuyper@wizard.net> wrote in message
> news:37BAAC8C.731D8A16@wizard.net...
> > Because it's not needed. If you do think it's needed, and want to
> > convince us, you'll have to show us why. What you've shown so far
> > doesn't need it.
>
> I say it is and I say it is a waste for the compiler to waste time

So you're just going to assert that it's needed, without showing why?
That's OK, but I wouldn't expect to convince anybody using those
methods.

> complaining about a program that is good in every other way except that it
> has an extra comment inside a structure declaration.  That should not be an
> error.
>
> Greg Brewer

I thought you were concerned about a problem due to an illegally placed
semicolon, not an extra comment. Is there something else involved here?


[ 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:
>
> "Greg Brewer" <nospam.gregb@hal-pc.org> writes:
>
> >You have yet to give me one good reason why a null data statement should not
> >be allowed.
>
> There is no good reason. That is, there is no technical difficulty
> in allowing null declarations, and I can't think of a program that
> would break if they were allowed in the language.
>
> C didn't allow them, and nobody made an effort to add the capability
> to C++.
>
> The difficulty is greater in C, it seems to me. Suppose you have
>
> void foo()
> {
>     int i;;
>     xxxx
> }
>
> In C, can xxx be a declaration? It can only if the extra semicolon
> creates a null declaration, because in C declarations cannot follow
> statements in the same block. So to decide if the extra semicolon
> is a null statement or a null declaration, you need to look at
> what follows it -- which requires arbitrary amounts of lookahead.
> Or you could disallow null declarations at block scope, allowing
> them elsewhere.

Another fix could be to say that ";" is a null declaration
whereever declarations are allowed, and a null statement
elsewhere.
After "int i;" a declaration is allowed, therefore the additional
";" is a null declaration, and therefore xxx may be a declaration
as well.
No lookahead is needed for this rule.

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

blargg <postmast.root.admi.gov@iname.com> wrote in message
news:user-1808990207340001@aus-as5-186.io.com...
>
> In your case, it is not acting like anything in the language, thus it
> shouldn't look like it.
>
>     struct Foo {
>         MEMBERS1
>         MEMBERS2
>     };
>
> It's very clear that these are special macros that do special things. I
> see no reason want to put semicolons at the end of the lines, as it
> wouldn't do anything to enhance readability. Adding a special language
> feature is out of the question.
>
> > You have yet to give me one good reason why a null data statement should
not
> > be allowed.
> As others have said, null statement = no-op.
> Null data member = ?
> Does it have zero size? Does it insert padding?

Zero size?  Of course.  Padding?  never.  Treat it just like it isn't there.
null statement is not no-op.  no-op is an assembly instruction.  I've
looked, a null statement generates no code with my compiler.

> Also, as someone mentioned, unless one has a good reason to make something
> allowed (that wouldn't be otherwise), there is no good reason to make it
> allowed. I feel like I'm stating the obvious (probably beacause I am).

I think you have it backwards.  Unless there is a good reason to make
something illegal, it should be legal.  Because you have no interest in
rabbit photography is not a reason to support laws that forbid my persuit of
my passion.

I can think of 3 reasons for allowing null data members.  1) I prefer that
my macros have them in my structure definitions.  2) It should simplify the
compiler design.  3)  It may be easier for a generated structure to not have
to worry about extra semi-colons.

Whether or not you agree with my reasons, I think they weigh heavily against
your 0 reasons to oppose.

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

Greg Brewer wrote:
>
> Pete Becker <petebecker@acm.org> wrote in message
> news:37B98E61.FBF1AE9F@acm.org...
> > Greg Brewer wrote:
> > >    #define Char(id,sz) char id[sz+1];
> > >    #define Float(id)      float id;
> > Change them to (note the absence of semicolons):
> >     #define Char(id,sz) char id[sz+1]
> >     #define Float(id)      float id
> > Now your initial struct definition works just fine.
>
> Please give me some credit.  If that would work I would have done it.  I
> would offer to email you the code seperately so I can display all the
> different cases the definitions must handle; however, my boss wouldn't like
> that.  This is why I was so vague to begin with; IT IS COMPLICATED.
>
> You have yet to give me one good reason why a null data statement should not
> be allowed.

You have yet to give one good reason, other than examples that don't
illustrate your point, why a null statment should be allowed.

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

Greg Brewer wrote:
...
> I can think of 3 reasons for allowing null data members.  1) I prefer that
> my macros have them in my structure definitions.  2) It should simplify the
> compiler design.  3)  It may be easier for a generated structure to not have
> to worry about extra semi-colons.
>
> Whether or not you agree with my reasons, I think they weigh heavily against
> your 0 reasons to oppose.

I would say that "if it ain't broke, don't fix it" outweighs all three
of those reasons combined. Lots of compilers exist right now that give
error or at least warning messages when this comes up. They'd have to be
re-written if it were made legal, even if there were no other
consequences. As a general rule, a ';' in a structure that didn't
terminate an actual declaration will usually be a typo - I LIKE
languages that detect my typos as syntax errors. ";" as a null statement
has at least a few places where it's useful, such as for() and while()
loops.

Your reason 1 is essentially irrelevant as an argument for changing the
standard, being a purely personal preference. It would carry more weight
if you can claim a significant number of people who share that
preference. It would help even more if you could show an example of code
that could be significantly simpler if that rule were changed.
I have no idea about the compiler design issue - I do know that the
effects of a rule change on compilers are often highly non-intuitive.
Reason 3 is not clear; I can't imagine that the cost of making sure that
a ';' is issued only after non-empty declarations is significant.


[ 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 <7pf1a3$fa7$1@news.hal-pc.org>, "Greg Brewer"
<nospam.gregb@hal-pc.org> wrote:

> blargg <postmast.root.admi.gov@iname.com> wrote in message
> news:user-1808990207340001@aus-as5-186.io.com...
> >
> > In your case, it is not acting like anything in the language, thus it
> > shouldn't look like it.
> >
> >     struct Foo {
> >         MEMBERS1
> >         MEMBERS2
> >     };
> >
> > It's very clear that these are special macros that do special things. I
> > see no reason want to put semicolons at the end of the lines, as it
> > wouldn't do anything to enhance readability. Adding a special language
> > feature is out of the question.
> >
> > > You have yet to give me one good reason why a null data statement should
> not
> > > be allowed.
> > As others have said, null statement = no-op.
> > Null data member = ?
> > Does it have zero size? Does it insert padding?
>
> Zero size?  Of course.  Padding?  never.  Treat it just like it isn't there.
> null statement is not no-op.  no-op is an assembly instruction.  I've
> looked, a null statement generates no code with my compiler.

Ummm, structure = data. Statement = code.

Also, on the CPU I use, there is no "no-op" opcode.

Null statement = statement = it does something.

Idea of null data member = it is as if it wasn't there. It's as if it
didn't exist. Why have something that has no effect?

> > Also, as someone mentioned, unless one has a good reason to make something
> > allowed (that wouldn't be otherwise), there is no good reason to make it
> > allowed. I feel like I'm stating the obvious (probably beacause I am).
>
> I think you have it backwards.  Unless there is a good reason to make
> something illegal, it should be legal.  Because you have no interest in
> rabbit photography is not a reason to support laws that forbid my persuit of
> my passion.

I think you mis-read what I wrote. I basically said that unless there is
some good reason to invest more energy in elaborating something, one
should just use whatever the outcome (side-effect) of something is.

> I can think of 3 reasons for allowing null data members.  1) I prefer that
> my macros have them in my structure definitions.

You prefer? Well, I prefer to be able to type "STUPID COMPILER! OPTIMIZE
THAT BETTER" without a comment line occasionally, and have the compiler
ignore it (or maybe listen to it!), but that's not a reason to add it to
the language.

> 2) It should simplify the compiler design.

By requiring more work put into all compilers. See above about investing
more energy into something. It is the way it is now. Simplification would
come at a cost of maintenance.

> 3)  It may be easier for a generated structure to not have
> to worry about extra semi-colons.

Wl;inkpkljE,lkjlkljKJLLL lII oDONn th have tuuioo worry about extra
ijkeystyrokews hgere vbut I don't; see the upoint

Oops I just couldn't type well, but the compiler should sift through the junk.

> Whether or not you agree with my reasons, I think they weigh heavily against
> your 0 reasons to oppose.

And that concludes this thread for me. <personal comments deleted>


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

Pete Becker <petebecker@acm.org> wrote in message
news:37B98E61.FBF1AE9F@acm.org...
> Greg Brewer wrote:
> >    #define Char(id,sz) char id[sz+1];
> >    #define Float(id)      float id;
> Change them to (note the absence of semicolons):
>     #define Char(id,sz) char id[sz+1]
>     #define Float(id)      float id
> Now your initial struct definition works just fine.

Please give me some credit.  If that would work I would have done it.  I
would offer to email you the code seperately so I can display all the
different cases the definitions must handle; however, my boss wouldn't like
that.  This is why I was so vague to begin with; IT IS COMPLICATED.

You have yet to give me one good reason why a null data statement should not
be allowed.

Greg Brewer




[ 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:
>
> You asked:
>
> >What do you mean by it is required?
>
> Then you said,
>
> >I[t] evades rather than answers a question.
>
> No, it very specifically says why you need ; and ;; in the statement
> block.  Once again:
>
>     while(foo())
>         ;
>     for (;;)
>         // ...
>
> You've got to have null statements to support those things.

I would prefer outlawing null statements and simply resort to using
'{}' or 'continue' instead:

    while (foo())
        continue;

    for (;;)
    {}

If nothing else, this would eliminate many bugs, since it's too
easy to type an erroneous ';' every now and then.

> You want to know why you can't similarly have extra ;'s in a
> structure member list. The answer is because there is no need for
> it as there is in statement blocks. If there was, it would be
> permitted. What other answer could there be? Please correct me if
> I am wrong. Instead of simply asking why you can't do
> it, try to ask what need there is for it.

OTOH, an extra trailing ',' is allowed in array initializers,
which was put there to simplify machine-generated code:

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

I'm not sure if allowing empty ';' member declarations within structs
is a good idea, but I sure can't see that it would do any harm.

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

"Greg Brewer" <nospam.gregb@hal-pc.org> writes:

>You have yet to give me one good reason why a null data statement should not
>be allowed.

There is no good reason. That is, there is no technical difficulty
in allowing null declarations, and I can't think of a program that
would break if they were allowed in the language.

C didn't allow them, and nobody made an effort to add the capability
to C++.

The difficulty is greater in C, it seems to me. Suppose you have

void foo()
{
    int i;;
    xxxx
}

In C, can xxx be a declaration? It can only if the extra semicolon
creates a null declaration, because in C declarations cannot follow
statements in the same block. So to decide if the extra semicolon
is a null statement or a null declaration, you need to look at
what follows it -- which requires arbitrary amounts of lookahead.
Or you could disallow null declarations at block scope, allowing
them elsewhere.

In C++ you don't have the limitation on declaration order.
A block-scope declaration IS a statement, so xxx can be, but
need not be, a declaration.

At namespace scope or inside a structure definition, the
extra semicolons don't cause any problems. In fact, the
compiler has to go to extra trouble to report them as errors.
And some compilers quietly accept null declarations anyway,
contrary to the requirements of the standard.

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

In article <7pcgrm$1por$1@news.hal-pc.org>, "Greg Brewer"
<nospam.gregb@hal-pc.org> wrote:

> Pete Becker <petebecker@acm.org> wrote in message
> news:37B98E61.FBF1AE9F@acm.org...
> > Greg Brewer wrote:
> > >    #define Char(id,sz) char id[sz+1];
> > >    #define Float(id)      float id;
> > Change them to (note the absence of semicolons):
> >     #define Char(id,sz) char id[sz+1]
> >     #define Float(id)      float id
> > Now your initial struct definition works just fine.
>
> Please give me some credit.  If that would work I would have done it.  I
> would offer to email you the code seperately so I can display all the
> different cases the definitions must handle; however, my boss wouldn't like
> that.  This is why I was so vague to begin with; IT IS COMPLICATED.

One thing I've found is that trying to fix complicated things with more
complexity causes yet even more complexity, which can be solved with more
complexity etc. :-)

Solve the complex problem by making it simpler.

There are some people who don't use complex macros like that, and they
manage. It's possible to declare some aspects of the language as "not very
usable" and favor others instead. What if you didn't have macros? How
would you solve this problem?

When I make designs that can only be implemented in a very particular way
with the language, I find that they are really uncomfortable to use since
they will likely run into compiler limitations/language limitations (as
yours is). It's too easy to get caught up in the language details and lose
sight of what you're trying to do overall. I sometimes wonder what it
would be like if this medium (languages and processor behavior) were very
different from what it is now, and what the commonalities there would be.
The commonalities are the important things.

For this particular case, as I remember, it was involving some structure
members being defined by a macro:

    struct Foo {
        MEMBERS1;
        MEMBERS2;
        // etc.
    };

On the rare occasions I use macros, unless it looks and acts very similar
to some built-in construct, I don't want it to look like one in user code.

// yes

    flush_cache_line( ptr ); // looks and acts like function

    // looks and acts like value-returning function
    if ( test_condition_code( cc_cr0 ) ) {
        // ...
    }

// no

    DEFINE_FORWARDING_FUNC( foo ); // why the semicolon?

    struct Foo {
        MEMBERS1; // why the semicolon? It certainly isn't a member
    };

In your case, it is not acting like anything in the language, thus it
shouldn't look like it.

    struct Foo {
        MEMBERS1
        MEMBERS2
    };

It's very clear that these are special macros that do special things. I
see no reason want to put semicolons at the end of the lines, as it
wouldn't do anything to enhance readability. Adding a special language
feature is out of the question.

> You have yet to give me one good reason why a null data statement should not
> be allowed.

As others have said, null statement = no-op.

Null data member = ?

Does it have zero size? Does it insert padding?

Also, as someone mentioned, unless one has a good reason to make something
allowed (that wouldn't be otherwise), there is no good reason to make it
allowed. I feel like I'm stating the obvious (probably beacause I am).


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

Greg Brewer wrote:
>
> Pete Becker <petebecker@acm.org> wrote in message
> news:37B98E61.FBF1AE9F@acm.org...
> > Greg Brewer wrote:
> > >    #define Char(id,sz) char id[sz+1];
> > >    #define Float(id)      float id;
> > Change them to (note the absence of semicolons):
> >     #define Char(id,sz) char id[sz+1]
> >     #define Float(id)      float id
> > Now your initial struct definition works just fine.
>
> Please give me some credit.  If that would work I would have done it.

You need to earn that credit. You're claiming to need something we know
of no need for. That claim justifies our considering the possibility
that you've missed a simple alternative. Your example gave support to
that idea, since Pete's proposed fix would in fact handle the cases
you've explained so so far.

I
> would offer to email you the code seperately so I can display all the
> different cases the definitions must handle; however, my boss wouldn't like
> that.  This is why I was so vague to begin with; IT IS COMPLICATED.

Then simplify it. Remove details that are specific to what you're
actually doing, but are irrelevant to the issue of whether a null member
declaration is needed. If your actual code contains 20 of something, but
the problem is due only to the fact that there are more than one of
them, simplify the example down to 2 of them. Shorten the names of
things, and remove the application-specific information stored in those
names. If even the simplified version would give away your company's
trade secrets, change it around to display the same problem in a
different context that has nothing to do with your actual code.

> You have yet to give me one good reason why a null data statement should not
> be allowed.

Because it's not needed. If you do think it's needed, and want to
convince us, you'll have to show us why. What you've shown so far
doesn't need 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              ]

Pete Becker <petebecker@acm.org> wrote in message
news:37B4947F.E3621CA9@acm.org...
> Reread the example that you snipped. It demonstrated the need for a null
> statement.

Don't need to, I remember it.  I evades rather than answers a question.
---
[ 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              ]

You asked:

>What do you mean by it is required?

Then you said,

>I[t] evades rather than answers a question.

No, it very specifically says why you need ; and ;; in the statement block.
Once again:

    while(foo())
        ;
    for (;;)
        // ...

You've got to have null statements to support those things. You want to know
why you can't similarly have extra ;'s in a structure member list. The
answer is because there is no need for it as there is in statement blocks.
If there was, it would be permitted. What other answer could there be?
Please correct me if I am wrong. Instead of simply asking why you can't do
it, try to ask what need there is for 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              ]

Greg Brewer wrote:
>
> Al Stevens <alstevens@midifitz.com> wrote in message
> news:5PVs3.17673$Gm.426256@newscene.newscene.com...
> >
> > >void foo(void) { printf("abc"); /**/; }  // this is allowed
> > >
> > >struct Foo { int abc; /**/;};   // this is not allowed
> > >
> > >Can anyone explain why?
> > The first usage is required. It represents a null statement that executes,
> > sort of:
> > [snip]
> > The second usage serves no purpose.
> Huh?  What do you mean by it is required?  In a C/C++ program the following
> is allowed in the executable section:  ";;;;;;;;;;;;;;;;;;;;;" .  But it is
> not allowed in a structure definition.  Why not?  Neither necessarilly
> serves a useful purpose.  So why was the later disallowed?

What he's saying is that there are situations where the syntax calls for
a statement, but where no actual processing should occur. Such as:

 for(i=0; i<N && array[i]!=0; i++);

Therefore, the language needs to provide a way of specifying an empty
statement. It doesn't need a way to specify an empty structure member. A
dummy member is sometimes needed, but never a member with a no name,
type or size.
---
[ 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[t] evades rather than answers a question.
>
> No, it very specifically says why you need ; and ;; in the statement
block.
> Once again:
>
>     while(foo())
>         ;
>     for (;;)
>         // ...
>
> You've got to have null statements to support those things. You want to
know
> why you can't similarly have extra ;'s in a structure member list. The
> answer is because there is no need for it as there is in statement blocks.
> If there was, it would be permitted. What other answer could there be?
> Please correct me if I am wrong. Instead of simply asking why you can't do
> it, try to ask what need there is for it.

Well, obviously I found a situation where I one would have been convenient.
Using your example,
   while (foo())
   {
   }
works but is less convenient.  In my case, I have a macro that expands to
member definitions.  I think
  struct STATION {
      stationKeys;
      stationNonkeys;
   };
looks better; however, I couldn't use it because I needed the macros to end
with a ';' for other reasons and I got an error on a null data definition.
So I was wondering why a null data declaration was disallowed.  I find it
difficult to believe the reason was "I can't think of any reason that anyone
would need it!"  Sounds very short sighted to me!

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

Greg Brewer wrote:
...
> works but is less convenient.  In my case, I have a macro that expands to
> member definitions.  I think
>   struct STATION {
>       stationKeys;
>       stationNonkeys;
>    };
> looks better; ....

"looks better" than what? You're example is rather unclear without at
least a simplified version of the macro definition you'd like to use,
preferably with an example of how it would be normally be used, and also
and example showing the case where it fails.

> ... however, I couldn't use it because I needed the macros to end
> with a ';' for other reasons and I got an error on a null data definition.

At this point your question sounds a little like someone saying "Why
don't cars come with umbrellas attached to the exhaust? I have a reason
which I can't go into why I need one there." It's none of our business,
if you don't want to explain, but you can't expect us to understand
without the explanation.

> So I was wondering why a null data declaration was disallowed.  I find it
> difficult to believe the reason was "I can't think of any reason that anyone
> would need it!"  Sounds very short sighted to me!

"I can't think of any reason that anyone would need it!" sounds to me
like one of the best possible reasons for not bothering to do something.
Having read all that you've written so far, I still am not clear why you
need 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              ]

James Kuyper <kuyper@wizard.net> wrote in message
news:37B87F27.120BE3AB@wizard.net...
>
> Greg Brewer wrote:
> ...
> > works but is less convenient.  In my case, I have a macro that expands
to
> > member definitions.  I think
> >   struct STATION {
> >       stationKeys;
> >       stationNonkeys;
> >    };
> > looks better; ....
>
> "looks better" than what? You're example is rather unclear without at
> least a simplified version of the macro definition you'd like to use,
> preferably with an example of how it would be normally be used, and also
> and example showing the case where it fails.

You're asking for too much!  I could tell you the defines for these macros
  #define stationKeys \
        Char(stationid,16)   \
        Long(timestamp) \
        Short(revision)
   #define stationNonkeys \
       Char(stationname,40) \
       Float(altitute) \
but then you'll want to know the definitions for Char Long Short and Float.
When I tell you that at the time struct STATION is defined, they are have
definitions like
   #define Char(id,sz) char id[sz+1];
   #define Float(id)      float id;
then you'll want to know why I didn't just code the data definitions
directly instead of going through this rigamoroll of macro definitions.
Then I'll have to explain that STATION has a mate STATION_RECORD which has
all of the same data members defined except the type macros are defined
   #define Char(id,sz) char id[sz];
   #define Float(id)     char id[8];
and that there are a dozen structs like STATION with mates and that for each
and everyone of them I have to move the data to/from each data member using
a conversation routine and that I can do that by defining a function
   #define Char(id,sz) strncpy(dst->id, src->id, sz);
   #define Float(id)      float2real(dst->id, src->id);
   void Store(STATION_RECORD *dst, STATION *src) {
       stationKeys;
       stationNonkeys;
   }
and after saying all though, you want understand that this is the best way I
have of insuring that STATION and STATION_RECORD records corresponding data
elements and that the functions to move data into, out of, etc the records
operate on each and every data element.

> > ... however, I couldn't use it because I needed the macros to end
> > with a ';' for other reasons and I got an error on a null data
definition.
>
> At this point your question sounds a little like someone saying "Why
> don't cars come with umbrellas attached to the exhaust? I have a reason
> which I can't go into why I need one there." It's none of our business,
> if you don't want to explain, but you can't expect us to understand
> without the explanation.

No, its more like you living in Mexico City and saying you see no need why
any car would need an electric engine block heater.


> > So I was wondering why a null data declaration was disallowed.  I find
it
> > difficult to believe the reason was "I can't think of any reason that
anyone
> > would need it!"  Sounds very short sighted to me!
>
> "I can't think of any reason that anyone would need it!" sounds to me
> like one of the best possible reasons for not bothering to do something.
> Having read all that you've written so far, I still am not clear why you
> need it.

No, it is not.

Greg Brewer




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

Greg Brewer wrote:
>
> James Kuyper <kuyper@wizard.net> wrote in message
> news:37B87F27.120BE3AB@wizard.net...
> >
> > Greg Brewer wrote:
> > ...
> > > works but is less convenient.  In my case, I have a macro that expands
> to
> > > member definitions.  I think
> > >   struct STATION {
> > >       stationKeys;
> > >       stationNonkeys;
> > >    };
> > > looks better; ....
> >
> > "looks better" than what? You're example is rather unclear without at
> > least a simplified version of the macro definition you'd like to use,
> > preferably with an example of how it would be normally be used, and also
> > and example showing the case where it fails.
>
> You're asking for too much!  I could tell you the defines for these macros
>   #define stationKeys \
>         Char(stationid,16)   \
>         Long(timestamp) \
>         Short(revision)
>    #define stationNonkeys \
>        Char(stationname,40) \
>        Float(altitute) \

Change them to (note the semicolons):
   #define stationKeys \
         Char(stationid,16);   \
         Long(timestamp); \
         Short(revision)
    #define stationNonkeys \
        Char(stationname,40); \
        Float(altitute) \

> but then you'll want to know the definitions for Char Long Short and Float.
> When I tell you that at the time struct STATION is defined, they are have
> definitions like
>    #define Char(id,sz) char id[sz+1];
>    #define Float(id)      float id;

Change them to (note the absence of semicolons):
    #define Char(id,sz) char id[sz+1]
    #define Float(id)      float id

Now your initial struct definition works just fine.

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

Al Stevens <alstevens@midifitz.com> wrote in message
news:5PVs3.17673$Gm.426256@newscene.newscene.com...
>
> >void foo(void) { printf("abc"); /**/; }  // this is allowed
> >
> >struct Foo { int abc; /**/;};   // this is not allowed
> >
> >Can anyone explain why?
> The first usage is required. It represents a null statement that executes,
> sort of:
> [snip]
> The second usage serves no purpose.
Huh?  What do you mean by it is required?  In a C/C++ program the following
is allowed in the executable section:  ";;;;;;;;;;;;;;;;;;;;;" .  But it is
not allowed in a structure definition.  Why not?  Neither necessarilly
serves a useful purpose.  So why was the later disallowed?

Greg Brewer




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

Greg Brewer wrote:
>
> Al Stevens <alstevens@midifitz.com> wrote in message
> news:5PVs3.17673$Gm.426256@newscene.newscene.com...
> >
> > >void foo(void) { printf("abc"); /**/; }  // this is allowed
> > >
> > >struct Foo { int abc; /**/;};   // this is not allowed
> > >
> > >Can anyone explain why?
> > The first usage is required. It represents a null statement that executes,
> > sort of:
> > [snip]
> > The second usage serves no purpose.
> Huh?  What do you mean by it is required?  In a C/C++ program the following
> is allowed in the executable section:  ";;;;;;;;;;;;;;;;;;;;;" .  But it is
> not allowed in a structure definition.  Why not?  Neither necessarilly
> serves a useful purpose.  So why was the later disallowed?
>

Reread the example that you snipped. It demonstrated the need for a null
statement.

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