WG14 Post Santa Clara mailing available

[=?iso-8859-1?q?Keld_J=F8rn?= 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]

Keld Jørn Simonsen <ke**@dkuug.dkwrites:

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.)

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Antoninus Twink]

On 12 Oct 2008 at 18:58, Keith Thompson wrote:

Keld Jørn Simonsen <ke**@dkuug.dkwrites:

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

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]

Antoninus Twink wrote:

On 12 Oct 2008 at 18:58, Keith Thompson wrote:

>Keld Jørn Simonsen <ke**@dkuug.dkwrites:

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

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.

The C standard is off topic here

!!!
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[jacob navia]

Keld Jørn Simonsen wrote:

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.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[CBFalconer]

jacob navia wrote:

Antoninus Twink wrote:

>Keith Thompson wrote:

>>Keld Jørn Simonsen <ke**@dkuug.dkwrites:

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

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.

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>

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

[Antoninus Twink]

On 13 Oct 2008 at 0:24, CBFalconer wrote:

jacob navia wrote:

>Antoninus Twink wrote:

>>Keith Thompson wrote:
Keld Jørn Simonsen <ke**@dkuug.dkwrites:
The Post Santa Clara mailing is now available from the WG14
web site at http://www.open-std.org/jtc1/sc22/wg14

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

Really? How magnanimous!

The C standard is off topic here

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]

On Oct 12, 3:59*am, Keld Jørn Simonsen <[e-mail]:

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?

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

[Richard Heathfield]

Paul Hsieh said:

On Oct 12, 3:59 am, Keld Jørn Simonsen <[e-mail]:

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

Good. It's about time.

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?

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. I see no
particular value in C continuing to maintain a completely useless dinosaur
just because the C++ folks have suddenly discovered brontoburgers.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Keith Thompson]

Paul Hsieh <we******@gmail.comwrites:

On Oct 12, 3:59*am, Keld Jørn Simonsen <[e-mail]:

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

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.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[James Kuyper]

Richard Heathfield wrote:

Paul Hsieh said:

>On Oct 12, 3:59 am, Keld Jørn Simonsen <[e-mail]:

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

Good. It's about time.

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

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]

On 14 Oct 2008 at 4:33, Richard Heathfield wrote:

Paul Hsieh said:

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

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]

Keith Thompson <[e-mail]:

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.

--
Peter

[dj3vande]

In article <e4**********************************@u29g2000pro. googlegroups.com>,
Peter Nilsson <ai***@acay.com.auwrote:

>Keith Thompson <[e-mail]:

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

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:
--------
/*Look! We don't need the type as a macro parameter anymore!*/
#define SWAP(a,b) do{auto t=a; a=b; b=t;}while(0);
--------
But that's the only use that I can think of for it in C.
dave

--
Dave Vandervies dj3vande at eskimo dot com
You can save yourself a lot of work by just making up some results;
they'll be just as good as those you'd get if you actually ran the
survey. --Eric Sosman in comp.lang.c

[Paul Hsieh]

On Oct 14, 3:49*am, James Kuyper <[e-mail]:

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?

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

[jameskuyper]

Paul Hsieh wrote:

On Oct 14, 3:49�am, James Kuyper <[e-mail]:

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?

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

[James Kuyper]

Well, something happened to the message I sent ye

Paul Hsieh wrote:

On Oct 14, 3:49 am, James Kuyper <[e-mail]:

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

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]

On Oct 18, 6:30*am, James Kuyper <[e-mail]:

Well, something happened to the message I sent ye

Paul Hsieh wrote:

On Oct 14, 3:49 am, James Kuyper <[e-mail]:

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?

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?

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

[blargg]

In article
<94**********************************@u29g2000pro. googlegroups.com>, Paul
Hsieh <we******@gmail.comwrote:

On Oct 18, 6:30=A0am, James Kuyper <[e-mail]:

[...]

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.

I think the point here was that this is one case where C++0x's auto could
be useful in C, not that this case of numeric types poses a problem for a
C++0x compiler implementing auto. The point was that the programmer can't
always easily predict the resulting type of a numeric expression, so auto
would be of use.

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

It's partly that it can be very verbose in C++, and violate the Don't
Repeat Yourself principle if one doesn't use lots of typedefs. For
example,

vector<Foo<Bar v;
vector<Foo<Bar::iterator iter = v.begin();

is verbose and repeats the type of v, adding maintenance cost. A typedef
fixes some of this,

typedef vector<Foo<Bar v_t;
v_t v;
v_t::iterator iter = v.begin();

but is still tedious compared to C++0x's auto:

vector<Foo<Bar v;
auto iter = v.begin();

In C, at the most you'll have a typedef in the library

/* library */
typedef int return_type;
return_type func();

/* user */
return_type t = func();

[...]

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?

The way I understand it:

C++98: auto has old meaning
C++03: auto has old meaning
C++0x: auto has only new meaning, so code using old meaning breaks

C89: auto has old meaning
C99: auto has old meaning
Cxx: auto is deprecated
Cxx+1: auto could be given C++0x's new meaning

Thus, C would be taking a more gradual approach, with an intervening
deprecation period so that potential future adoption of C++0x's meaning
would break less code (though apparently C++0x's more rapid approach will
break very little C++ code).

[Keith Thompson]

Paul Hsieh <we******@gmail.comwrites:

On Oct 18, 6:30*am, James Kuyper <[e-mail]:

[...]

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

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.)

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[James Kuyper]

Paul Hsieh wrote:

On Oct 18, 6:30 am, James Kuyper <[e-mail]:

....

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

template <typename T, typename Uvoid 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;

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

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

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

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.

[Harald van =?UTF-8?b?RMSzaw==?=]

On Sat, 18 Oct 2008 23:14:52 +0000, James Kuyper wrote:

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.

You had me confused there. I'm sure you meant to say n2723 is a draft of
the next version of the C++ standard.

[blargg]

In article <M5****************@nwrddc01.gnilink.net>, James Kuyper
<ja*********@verizon.netwrote:

Paul Hsieh wrote:

On Oct 18, 6:30 am, James Kuyper <[e-mail]:

...

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.

template <typename T, typename Uvoid 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;

There is an ugly solution that's not very flexible, just mentioning it for
completeness:

template <typename T, typename U, typename what_typevoid func_ (
const T&t,
const U&u,
what_type temp
){
...
}

template <typename T, typename Uvoid func (
const T&t,
const U&u,
){
func_( t, u, t*u );
}

[James Kuyper]

Harald van Dijk wrote:

On Sat, 18 Oct 2008 23:14:52 +0000, James Kuyper wrote:

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

You had me confused there. I'm sure you meant to say n2723 is a draft of
the next version of the C++ standard.

You are correct.

[James Kuyper]

blargg wrote:

In article <M5****************@nwrddc01.gnilink.net>, James Kuyper
<ja*********@verizon.netwrote:

[Re: planned new meaning for 'auto' in C++ - connection to planned
deprecation of 'auto' in C.]

>template <typename T, typename Uvoid 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;

There is an ugly solution that's not very flexible, just mentioning it for
completeness:

template <typename T, typename U, typename what_typevoid func_ (
const T&t,
const U&u,
what_type temp
){
...
}

template <typename T, typename Uvoid func (
const T&t,
const U&u,
){
func_( t, u, t*u );
}

Yes - "not very flexible" indeed.

[Anand Hariharan]

On Sat, 18 Oct 2008 10:21:32 -0700, Paul Hsieh <we******@gmail.comwrote:

On Oct 18, 6:30Â*am, James Kuyper <[e-mail]:

(...)

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

(...)

If anything, this thread in comp.lang.c++.moderated, viz.,

MID: 47**************@erdani.org

suggests introducing 'auto' could be murky in both C as well as C++.

- Anand