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
Oct 12 '08
26  1767 
Richard Heathfield wrote:
Paul Hsieh said:
>On Oct 12, 3:59 am, Keld Jørn Simonsen <k...@dkuug.dkw rote:
>>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 (specificParame ter);
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.
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 incompatibiliti es between the
two languages.
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 "similariti es". :-{
Keith Thompson <ks...@mib.orgw rote:
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
In article <e4************ *************** *******@u29g200 0pro.googlegrou ps.com>,
Peter Nilsson <ai***@acay.com .auwrote:
>Keith Thompson <ks...@mib.orgw rote:
>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
On Oct 14, 3:49*am, James Kuyper <jameskuy...@ve rizon.netwrote:
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/
Paul Hsieh wrote:
On Oct 14, 3:49�am, James Kuyper <jameskuy...@ve rizon.netwrote:
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/
Well, something happened to the message I sent ye
Paul Hsieh wrote:
On Oct 14, 3:49 am, James Kuyper <jameskuy...@ve rizon.netwrote:
>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.
On Oct 18, 6:30*am, James Kuyper <jameskuy...@ve rizon.netwrote:
Well, something happened to the message I sent ye
Paul Hsieh wrote:
On Oct 14, 3:49 am, James Kuyper <jameskuy...@ve rizon.netwrote:
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 "syntactica l 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/
In article
<94************ *************** *******@u29g200 0pro.googlegrou ps.com>, Paul
Hsieh <we******@gmail .comwrote:
On Oct 18, 6:30=A0am, James Kuyper <jameskuy...@ve rizon.netwrote:
[...]
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). This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics | |
by: Jan Roland Eriksson |
last post by:
I have worked some more on this suggested new mFAQ version trying to get
all user input to blend into the text.
Another review by the NG would be welcome.
=====
Archive-name: www/stylesheets/newsgroup-faq
Posting-Frequency: once a week
Last-modified: July 22, 2004
|
by: Jan Roland Eriksson |
last post by:
Some more fine tuning and inclusion of last suggested text from regulars
has been done to this test post #4 of the mFAQ.
As usual, rip it up anywhere you feel that it's appropriate to do so.
=====
Archive-name: www/stylesheets/newsgroup-faq
Posting-Frequency: once a week
Last-modified: 2004-07-26
|
by: VK |
last post by:
Following the side thread about the time precision in browser at
<http://groups.google.com/group/comp.lang.javascript/browse_frm/thread/91b9f3fd90513161/1ea06131c63cfdf0?hl=en#doc_620f160f0cb57c8c>
Statement:
At the very least Internet Explorer doesn't go by "real" time in script
methods. Instead it provides to script methods "application ticks" with
predefined amount of milliseconds in them. If the requested time frame
fits into an...
|
by: Martin |
last post by:
Hello,
We are in the process of putting together an A class PHP Development
team(ecommerce / billing applications) for a project in the Bay Area.
Reqt. details:
ReqId : Req-3616 - Senior PHP Developer
Primary Skills: PHP, Linux, Apache
Secondary Skills: C++, SQL
|
by: Martin |
last post by:
Hello,
We are in the process of putting together an A class C++ Development
team(ecommerce / billing applications) for a project in the Bay Area.
Reqt. details:
ReqId : Req-3911 - C++ Senior Developer
Primary Skills: C++, SQL
Secondary Skills: XML, Oracle
Description: As a part of the development team for our client's
| | |
by: Michael Hudson |
last post by:
The PyPy team is sprinting at EuroPython again and we invite
you to participate in our 3 day long sprint at the conference hotel
- Reval Hotel Lietuva.
If you plan to attend the sprint we recommend you to listen to the PyPy
technical talks (`EuroPython schedule`_) during the
conference since it will give you a good overview of the status of development.
On the morning of the first sprint day (12th) we will also have a
tutorial session...
|
by: =?iso-8859-1?q?Keld_J=F8rn?= Simonsen |
last post by:
The 2008-06 post Sophia mailing, the core WG issues list revision 56 and
the library WG issues list revision 57 are now available from the WG21
site at http://www.open-std.org/jtc1/sc22/wg21/
Best regards
Keld Simonsen
|
by: =?iso-8859-1?q?Keld_J=F8rn?= Simonsen |
last post by:
The WG14 Pre Santa Barbara mailing is now available from the WG14 sita ay
http://www.open-std.org/jtc1/sc22/wg14
There is also a new draft for the C standard N1336 and a new draft for
the security enhanced functions N1337.
est regards
Keld Simonsen
|
by: =?iso-8859-1?q?Keld_J=F8rn?= Simonsen |
last post by:
The 2008-10 Post San Francisco mailing is now available from the WG21
web site at http://www.open-std.org/jtc1/sc22/wg21/
Also the core WG issues list rev 59 and the library WG issuse list rev 60
are now availabe.
I also did a number of updates of other pages on the WG21 site.
Best regards
Keld Simonsen
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However, people are often confused as to whether an ONU can Work As a Router. In this blog post, we’ll explore What is ONU, What Is Router, ONU & Router’s main usage, and What is the difference between ONU and Router. Let’s take a closer look !
Part I. Meaning of...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed.
This is as boiled down as I can make it.
Here is my compilation command:
g++-12 -std=c++20 -Wnarrowing bit_field.cpp
Here is the code in...
| | |
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows Update option using the Control Panel or Settings app; it automatically checks for updates and installs any it finds, whether you like it or not. For most users, this new feature is actually very convenient. If you want to control the update process,...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the choice of these technologies. I'm particularly interested in Zigbee because I've heard it does some...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then launch it, all on its own....
Now, this would greatly impact the work of software developers. The idea...
|
by: conductexam |
last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and then checking html paragraph one by one.
At the time of converting from word file to html my equations which are in the word document file was convert into image.
Globals.ThisAddIn.Application.ActiveDocument.Select();...
|
by: 6302768590 |
last post by:
Hai team
i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated we have to send another system
|
by: muto222 |
last post by:
How can i add a mobile payment intergratation into php mysql website.
| | |
by: bsmnconsultancy |
last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating effective websites that not only look great but also perform exceptionally well. In this comprehensive...
| |
