WG14 Post Santa Clara mailing available

[Keld Jørn Simonsen]

The Post Santa Clara mailing is now available from the WG14 web site at
http://www.open-std.org/jtc1/sc22/wg14

I also updated some of the other information on the pages.

Best regards
Keld Simonsen

 

[Keith Thompson]

The Post Santa Clara mailing is now available from the WG14 web site at
http://www.open-std.org/jtc1/sc22/wg14

I also updated some of the other information on the pages.

I suggest posting these announcements to comp.std.c. (A cross-post to
comp.lang.c would probably be ok.)

 

[Antoninus Twink]

I suggest posting these announcements to comp.std.c. (A cross-post to
comp.lang.c would probably be ok.)

Really? How magnanimous! Normally only versions of the C Standard that
were released before the Barcelona Olympics are considered topical here
by you and your allies.

 

[jacob navia]

Really? How magnanimous! Normally only versions of the C Standard that
were released before the Barcelona Olympics are considered topical here
by you and your allies.

The C standard is off topic here

!!!

 

[jacob navia]

The Post Santa Clara mailing is now available from the WG14 web site at
http://www.open-std.org/jtc1/sc22/wg14

I also updated some of the other information on the pages.

Best regards
Keld Simonsen

Thanks for this info.

 

[CBFalconer]

The C standard is off topic here

Now Twink is a pure troll, and only posts to disturb the
newsgroup. You, on the other hand, may disagree with many, but at
least don't appear to bear c.l.c any ill will. Such a comment, if
not surrounded by smilies, is highly harmful and will mislead all
newbies. Even with smilies, it is not good.

Some useful references about C:
<http://www.ungerhu.com/jxh/clc.welcome.txt>
<http://c-faq.com/> (C-faq)
<http://benpfaff.org/writings/clc/off-topic.html> (topicality)
<http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf> (C99)
<http://cbfalconer.home.att.net/download/n869_txt.bz2> (pre-C99)
<http://www.dinkumware.com/c99.aspx> (C-library}
<http://gcc.gnu.org/onlinedocs/> (GNU docs)
<http://clc-wiki.net/wiki/C_community:comp.lang.c:Introduction>

 

[Antoninus Twink]

Such a comment, if not surrounded by smilies, is highly harmful and
will mislead all newbies. Even with smilies, it is not good.

Who is smiling?

 

[Paul Hsieh]

The Post Santa Clara mailing is now available from the WG14 web site
at http://www.open-std.org/jtc1/sc22/wg14

There appears to be some movement towards deprecating auto. However,
the C++ people want to specifically use auto for implicit type
declarations in the next standard:

auto p = find (specificParameter);

the idea being that p becomes declared with the type that find
returns.

So do you guys even pay attention to each other or what?

 

[Keith Thompson]

There appears to be some movement towards deprecating auto. However,
the C++ people want to specifically use auto for implicit type
declarations in the next standard:

auto p = find (specificParameter);

the idea being that p becomes declared with the type that find
returns.

So do you guys even pay attention to each other or what?

Why yes, they do. If you meant to imply otherwise, you've chosen a
particularly odd example.

n1343.pdf, part of the Post Santa Clara mailing, says:

2.2.1 Deprecate "auto" (N1296) (Stoughton)

General agreement to deprecate the "auto" keyword. Should we ask
WG21 to go back to the previous use of "register" (no
address). No, this will not fly with WG 21.

This is in the "LIAISON ACTIVITIES" section.

n1296.pdf, referred to by n1434 says:

Liaison Statement from WG 21 to WG 14

At their February 2008 meeting, WG 21 decided to remove the
storage class specifier "auto" from the C++ language, as proposed
in their paper N2546. This storage class specifier was inherited
from the C language, but is rarely if ever used in C++. In
investigating this, it was also noted that very few if any uses of
"auto" could be found in C programs either.

It is the C++ intention to start using "auto" for a totally
different purpose, and to that end WG 21 would like to encourage
WG 14 to review the role of "auto" in their upcoming revision of
the C standard, and either deprecate or remove it as appropriate.

(WG 21 is the C++ committee; WG 14 is the C committee.)

So yes, they seem to pay a great deal of attention to each other.

Using auto in C for the same purpose as the new C++ will use it is an
interesting idea, but I don't think it has quite as much benefit for C
as it does for C++.

Note that deprecating "auto" means that it would remain in the next
version of the standard, but would be considered for removal in the
next one after that, so it would likely continue to be standard C for
the next 20 years or so. I'm not sure whether it would be better to
allow it to be used as an ordinary identifier or not, but there's
plenty of time to decide.

 

[James Kuyper]

Paul Hsieh said:


Good. It's about time.


I don't follow. C and C++ are different languages.

The committees responsible for the two languages are both committed to a
policy of, among other things, avoiding gratuitous discrepancies between
the two languages. The languages may be different, but they are like
siamese twins, with different limbs, but sharing many internal organs in
common.

... They have superficial
similarities for historical reasons,

They have substantial and deep similarities both for historical reasons
and as a matter of deliberate choice by the original designer of C++ and
of the committees governing both languages. The differences between them
are substantial too, but are more superficial than the differences.

C. It is even possible (and not particularly difficult) to write a program
that is legal in both languages but does completely different things

There are a lot of ways in which the two languages differ, even for code
that is legal in both languages (neither standard uses the term "legal",
I'll assume that you mean code which is both strictly conforming C code,
and well-formed C++ code). However, most of those differences are
subtle, or unlikely to unlikely to come up with normal coding practices.
To produce a program with different behavior in the two languages is
certainly possible, but for such a program to do two completely
different things is unlikely unless it were deliberately designed for
that purpose.

depending on which language the compiler is told it's written in. I see no
particular value in C continuing to maintain a completely useless dinosaur
just because the C++ folks have suddenly discovered brontoburgers.

In C++, use of 'auto' with the meaning that it has in C is no longer
legal. Since that's the only meaning it has in C, deprecating it's use
in C makes the two languages more consistent with each other, not less -
if you read n1296, you'll see that this is in fact the reason for the
proposed change.

 

[Antoninus Twink]

Paul Hsieh said:

I don't follow. C and C++ are different languages. They have
superficial similarities for historical reasons, but it is already
easy to write good C that is not legal C++, and trivial to write good
C++ that is not legal C. It is even possible (and not particularly
difficult) to write a program that is legal in both languages but does
completely different things depending on which language the compiler
is told it's written in.

But in the real world, many people are interested in writing good C that
is (a) legal C++, and (b) has the same semantics in C++. They aren't
interested in playing stupid games with sizeof('a') and the like - they
just want to write everyday code to get something done, not a torture
suite to test a compiler.

For those people, it would be extremely regrettable if the C and C++
committees willfully introduced serious incompatibilities between the
two languages.

 

[James Kuyper]

James Kuyper wrote:
....

... The differences between them
are substantial too, but are more superficial than the differences.

That last word was, of course, intended to be "similarities". :-{

 

[Peter Nilsson]

Using auto in C for the same purpose as the new C++ will
use it is an interesting idea, but I don't think it has
quite as much benefit for C as it does for C++.

If it does what typeof() does on most implementations it
will have instant appeal IMO, unlike the majority of C99
changes so far. What remains to be seen is whether it
becomes a method for implementing type generic functions
with external linkage.

 

[dj3vande]

If it does what typeof() does on most implementations it
will have instant appeal IMO, unlike the majority of C99
changes so far. What remains to be seen is whether it
becomes a method for implementing type generic functions
with external linkage.

It seems to me that external-linkage generics would be Bloody Hard to
do without implementing most of the C++ template mechanism (actually, I
get the impression that it's Bloody Hard even with the C++ template
mechanism - wasn't that the "We support (modulo bugs) the entire C++
standard, except for that one bit we haven't even tried to implement"
feature for most implementations for a few years?), and this meaning
for 'auto' becomes rather less useful (even in generics) if we don't
have overloading. That puts it well into "If you want C++, you know
where to find it" territory.

It would make type-generic macros easier to write:

 

[Paul Hsieh]

In C++, use of 'auto' with the meaning that it has in C is no longer
legal. Since that's the only meaning it has in C, deprecating it's use
in C makes the two languages more consistent with each other, not less -
if you read n1296, you'll see that this is in fact the reason for the
proposed change.

Well, but this just seems pointless. The point is that you can easily
extend C++'s new semantics *BACK* to C where it makes some kind of
sense.

auto fp = fopen ("file.txt", "r");

seems fairly straightforward what it should mean in C. Why deprecate
it entirely, instead of just picking up extra semantics (or leaving it
alone for some future semantic extensions)? Is there some
incompatibility I am not seeing?

 

[jameskuyper]

Well, but this just seems pointless. The point is that you can easily
extend C++'s new semantics *BACK* to C where it makes some kind of
sense.

auto fp = fopen ("file.txt", "r");

seems fairly straightforward what it should mean in C. Why deprecate
it entirely, instead of just picking up extra semantics (or leaving it
alone for some future semantic extensions)? Is there some
incompatibility I am not seeing?

 

[James Kuyper]

Well, something happened to the message I sent ye

Well, but this just seems pointless. The point is that you can easily
extend C++'s new semantics *BACK* to C where it makes some kind of
sense.

auto fp = fopen ("file.txt", "r");

seems fairly straightforward what it should mean in C. Why deprecate
it entirely, instead of just picking up extra semantics (or leaving it
alone for some future semantic extensions)? Is there some
incompatibility I am not seeing?

It is commonplace in C++ code to not be sure what the type of an
expression is. The biggest reason for this is templates; but the
overloading of functions is also a contributing factor. This makes the
new C++ meaning attached to "auto" very convenient.

The benefits of such a change are much smaller in C. Not being certain
of the type of an expression is less common in C, though it can happen.
The type of a numerical literal often depends upon the values of the
*_MAX macros from <limits.h>. Portable code cannot rely upon standard
typedefs such as size_t referring to any specific type, and it's a bad
idea to write code which makes assumptions about which type a
third-party typedef refers to. You can sometimes assume that the result
of an expression involving a typedef'd type will have the same type as
that typedef, but that's not always the case. However, in C you usually
have a pretty good idea what type an expression has. As a result, the
new C++ meaning for "auto" would be much less useful in C.

The new C++ functionality of "auto" is moderately complicated; and the
committee apparently decided the that cost of requiring all C compilers
to support it was too big to justify the minor benefits for typical C
code. I'm not saying that the cost is big; it's not - I'm saying that
the benefit is even smaller, or at least that seems to have been the
committee's judgment.

You talked about "leaving it alone for some future semantic extensions".
If they're going to include such a change in a future version of the C
standard, then the first step should be to deprecate the current usage
of "auto", which is precisely what the committee has decided to do.

 

[Paul Hsieh]

Well, something happened to the message I sent ye






It is commonplace in C++ code to not be sure what the type of an
expression is. The biggest reason for this is templates; but the
overloading of functions is also a contributing factor. This makes the
new C++ meaning attached to "auto" very convenient.

As I understand it, this isn't a lack of being sure, but rather that
its currently a syntactical nightmare that makes code unreadable. (If
you are not sure today, and you type the wrong thing, your compiler
will tell you what you did wrong with an error message -- I sometimes
actually do this deliberately, when I am too lazy to look up the
type.) The purpose, I thought, was to respond to dynamic programming
languages which let you do away with specifying types.

The benefits of such a change are much smaller in C. Not being certain
of the type of an expression is less common in C, though it can happen.

If we instead go with the "syntactical nightmare" reason, we can see
that arrays of function pointers are types we would probably rather be
implicit.

The type of a numerical literal often depends upon the values of the
*_MAX macros from <limits.h>. Portable code cannot rely upon standard
typedefs such as size_t referring to any specific type, and it's a bad
idea to write code which makes assumptions about which type a
third-party typedef refers to. You can sometimes assume that the result
of an expression involving a typedef'd type will have the same type as
that typedef, but that's not always the case.

C++ will have to contend with this issue as well. If they have
decided its worth it, it seems like it would make perfect sense to
ride on their coat tails.

[...] However, in C you usually
have a pretty good idea what type an expression has. As a result, the
new C++ meaning for "auto" would be much less useful in C.

I don't think the rate of knowledge about the type of a declared
variable is all that different between C and C++. It may be more
confusing in C++, but the need to know exactly which one is basically
the same.

The new C++ functionality of "auto" is moderately complicated;

Well, but this is due mostly to C++'s complications that don't exist
in C.

[...] and the
committee apparently decided the that cost of requiring all C compilers
to support it was too big to justify the minor benefits for typical C
code. I'm not saying that the cost is big; it's not - I'm saying that
the benefit is even smaller, or at least that seems to have been the
committee's judgment.

Well you know what I think of the committee's judgment.

You talked about "leaving it alone for some future semantic extensions".

Yes, leaving open the possibility that the C++ idea can be adopted
later. Maybe waiting to see it proven in the C++ universe first or
just watching the Gnu C compiler adopt it as an extension for C as
well or whatever.

If they're going to include such a change in a future version of the C
standard, then the first step should be to deprecate the current usage
of "auto", which is precisely what the committee has decided to do.

I don't follow the logic. Will C++ specifically require the
deprecation of the old use of auto to support its new usage? Or is
this just introducing a difference for no reason?

 

[Keith Thompson]

I don't follow the logic. Will C++ specifically require the
deprecation of the old use of auto to support its new usage? Or is
this just introducing a difference for no reason?

The following is largely speculation on my part.

C++ is adding a new meaning for the "auto" keyword. At the same time,
C++ is dropping the old meaning. These two things are not
*necessarily* connected (C++ could have kept the old meaning), but (a)
use of "auto" with the old meaning is vanishingly rare in both C and
C++, and (b) having two meanings for the same keyword, though it's not
a problem for compilers, would make the language just a little bit
more confusing than it needs to be. (Compare "static".)

The reasons for making either change in C++ aren't quite as strong.
Dropping, or rather deprecating, the old meaning makes some sense, but
the reasons for doing so arguably aren't strong enough by themselves
to justify a language change. Avoiding gratuitous incompatibility
with C++ makes the justification just a little bit stronger. And if,
some day, C adopts C++'s new meaning for auto, having deprecated the
old one makes the resulting new C just a little bit less confusing.

As far as I know, any legal C program that uses the auto keyword would
be unaffected by simply deleting all occurrences. In other words, if
a C compiler had a predefined macro definition equivalent to

#define auto /* nothing */

then it wouldn't break anything. (This wasn't the case for pre-ANSI
C, where "auto x;" at block scope was a legal declaration; I'm not
sure whether it's true in C90.)

 

[James Kuyper]

As I understand it, this isn't a lack of being sure, but rather that
its currently a syntactical nightmare that makes code unreadable.

template <typename T, typename U> void func (
const T&t,
const U&u,
){
what_type temp = t*u;
...

What should what_type be? Perhaps I'm not sufficiently familiar with
C++, but I'm unaware of any other syntax, nightmarical or otherwise,
that achieves the same effect as the new meaning that C++ has attached
to 'auto':

auto temp = t*u;

C++ will have to contend with this issue as well.

Yes, C++ has all the same opportunities that C has to be uncertain of
the type of an initializer expression. My point was that templates and
operator overloads make it orders of magnitude more likely to be a
problem in C++ than it is in C.

... If they have
decided its worth it, it seems like it would make perfect sense to
ride on their coat tails.

C is not C++, however great the overlap between the languages; the fact
that the new meaning for 'auto' is worth it's cost in C++ does not mean
that it's worth it in C.

.....

I don't think the rate of knowledge about the type of a declared
variable is all that different between C and C++. It may be more
confusing in C++, but the need to know exactly which one is basically
the same.

The need is the same; the feasibility of meeting that need is quite
different in the two languages.
....

Yes, leaving open the possibility that the C++ idea can be adopted
later. Maybe waiting to see it proven in the C++ universe first or
just watching the Gnu C compiler adopt it as an extension for C as
well or whatever.


I don't follow the logic. Will C++ specifically require the
deprecation of the old use of auto to support its new usage?

It's not merely deprecated, the old usage of 'auto' is no longer
supported in n2723.pdf, the latest working draft I've picked up of the
next version of the C standard. I don't know whether there was an
intermediate version where the old usage was merely deprecated - I
stopped closely following the C++ standard's development a couple of
years ago. I think there should have been an intermediate version where
the old use was deprecated, and I would strongly favor the C committee
delivering at least one version where 'auto' is deprecated, before
delivering a version where it's current meaning disappears.