From -1115128425556517191
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 109fba,9a6b7da9ba54eaea
X-Google-Attributes: gid109fba,public
X-Google-Thread: f78e5,9a6b7da9ba54eaea
X-Google-Attributes: gidf78e5,public
X-Google-ArrivalTime: 1993-06-30 14:20:21 PST
Xref: gmd.de comp.lang.c++:25481 comp.std.c++:2911
Path: gmd.de!xlink.net!howland.reston.ans.net!gatech!psuvax1!news.ecn.bgu.edu!siemens!princeton!allegra!alice!ark
From: ark@alice.att.com (Andrew Koenig)
Newsgroups: comp.lang.c++,comp.std.c++
Subject: Re: C++ Language Extensions
Message-ID: <25886@alice.att.com>
Date: 30 Jun 93 13:44:14 GMT
Article-I.D.: alice.25886
References: <25807@alice.att.com> <rfgC91JEK.182@netcom.com> <25820@alice.att.com> <rfgC9FE01.ALz@netcom.com>
Reply-To: ark@alice.UUCP ()
Organization: AT&T Bell Laboratories, Murray Hill NJ
Lines: 85

In article <rfgC9FE01.ALz@netcom.com> rfg@netcom.com (Ronald F. Guilmette) writes:

> >> In other words, the `static' specifiers in the previous set of declarations
> >> are entirely superfluous in C, and they are (in effect) simply ignored by
> >> any conformant ANSI C compiler.

> >Not quite true.  It is true for these particular declarations...

> So what was I talking about???  I agree that my statement applied to the
> things that I said (very plainly) it applied to.

I meant exactly what I said.  Your statement is not quite true:
the "static" specifiers are superfluous (so that part of the statement
is true) but they are not simply ignored (so that part of the statement
is not true).  If they were simply ignored, then there would be no way
to distinguish a declaration with the "static"

	static struct foo {
		int a;
	};

from one without it:

	struct foo {
		int a;
	};

But there is a way -- merely insert "static" in front of each one:

	static static struct foo {
		int a;
	};

	static struct foo {
		int a;
	};

Now the first one becomes invalid and the second does not.

A compiler that fails to make this distinction cannot be a conforming compiler.
A compiler that ignores "static" in the first example above cannot make
this distinction.
Therefore no conforming compiler can ignore "static" in this context.

> In other words, if you want to disagree with what I have said, please try
> to understand that I meant exactly what I said, and nothing else.  In
> particular, I did not mean something else that you seem to wish to
> interpret me to have really meant.

And I also meant exactly what I said, and nothing else.  I did not think
it would be necessary to go into this much detail, but you seem to insist.

> I did make a statement that C++ compilers should be able to accept and
> ignore the `static' keyword in places where this very same keyword is
> accepted and ignored by ANSI C compilers.

Of course it should.  This is not at issue, and has never been.

> I don't mind if you want to disagree with what I have said, but if you
> choose to do so, please do make some effort to understand what I REALLY
> said, not what you belived you thought you heard me say.

Ditto.  I couldn't have said it better myself.

> You named three members of x3j16 (out of 100+ members?) who are on really
> intimate terms with the ANSI C standard.  (I could name perhaps two or
> three more, but so what?)

> I think the very fact that you could only come up with three names actually
> tends to support my earlier statement.

Hmmm... If I remember correctly, you said you thought it was a pity that
the C++ committee was not populated by experts in the C standard.  In that
case, I must continue to disagree -- there are plenty of expert C programmers
on the C++ committee but I don't think having additional experts in the
C standard would help.  There are relatively few issues that come up in
the meetings for which knowledge of the C standard is relevant in that
level of detail; when such issues do come up they are invariably referred
to one of the people know the appropriate details.

In any event, since the committee is open to anyone who wants to pay dues,
such regrets are moot.
-- 
				--Andrew Koenig
				  ark@research.att.com


