WG14 Post Santa Clara mailing available

Discussion in 'C Programming' started by Keld Jørn Simonsen, Oct 12, 2008.

  1. 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
    Keld Jørn Simonsen, Oct 12, 2008
    #1
    1. Advertising

  2. Keld Jørn Simonsen <> writes:
    > 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) <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"
    Keith Thompson, Oct 12, 2008
    #2
    1. Advertising

  3. On 12 Oct 2008 at 18:58, Keith Thompson wrote:
    > Keld Jørn Simonsen <> writes:
    >> 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.
    Antoninus Twink, Oct 12, 2008
    #3
  4. Keld Jørn Simonsen

    jacob navia Guest

    Antoninus Twink wrote:
    > On 12 Oct 2008 at 18:58, Keith Thompson wrote:
    >> Keld Jørn Simonsen <> writes:
    >>> 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, Oct 12, 2008
    #4
  5. Keld Jørn Simonsen

    jacob navia Guest

    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
    jacob navia, Oct 12, 2008
    #5
  6. Keld Jørn Simonsen

    CBFalconer Guest

    jacob navia wrote:
    > Antoninus Twink wrote:
    >> Keith Thompson wrote:
    >>> Keld Jørn Simonsen <> writes:
    >>>
    >>>> 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.
    CBFalconer, Oct 13, 2008
    #6
  7. On 13 Oct 2008 at 0:24, CBFalconer wrote:
    > jacob navia wrote:
    >> Antoninus Twink wrote:
    >>> Keith Thompson wrote:
    >>>> Keld Jørn Simonsen <> writes:
    >>>>> 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?
    Antoninus Twink, Oct 13, 2008
    #7
  8. Keld Jørn Simonsen

    Paul Hsieh Guest

    On Oct 12, 3:59 am, 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


    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/
    Paul Hsieh, Oct 14, 2008
    #8
  9. Paul Hsieh <> writes:
    > On Oct 12, 3:59 am, 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

    >
    > 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) <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"
    Keith Thompson, Oct 14, 2008
    #9
  10. Keld Jørn Simonsen

    James Kuyper Guest

    Richard Heathfield wrote:
    > Paul Hsieh said:
    >
    >> On Oct 12, 3:59 am, 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

    >> 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.
    James Kuyper, Oct 14, 2008
    #10
  11. 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.
    Antoninus Twink, Oct 14, 2008
    #11
  12. Keld Jørn Simonsen

    James Kuyper Guest

    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". :-{
    James Kuyper, Oct 14, 2008
    #12
  13. Keith Thompson <> wrote:
    > 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
    Peter Nilsson, Oct 14, 2008
    #13
  14. Keld Jørn Simonsen

    Guest

    In article <>,
    Peter Nilsson <> wrote:
    >Keith Thompson <> wrote:
    >> 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
    , Oct 14, 2008
    #14
  15. Keld Jørn Simonsen

    Paul Hsieh Guest

    On Oct 14, 3:49 am, James Kuyper <> wrote:
    > 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, Oct 17, 2008
    #15
  16. Keld Jørn Simonsen

    Guest

    Paul Hsieh wrote:
    > On Oct 14, 3:49�am, James Kuyper <> wrote:
    > > 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/
    , Oct 17, 2008
    #16
  17. Keld Jørn Simonsen

    James Kuyper Guest

    Well, something happened to the message I sent ye

    Paul Hsieh wrote:
    > On Oct 14, 3:49 am, James Kuyper <> wrote:
    >> 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.
    James Kuyper, Oct 18, 2008
    #17
  18. Keld Jørn Simonsen

    Paul Hsieh Guest

    On Oct 18, 6:30 am, James Kuyper <> wrote:
    > Well, something happened to the message I sent ye
    >
    > Paul Hsieh wrote:
    > > On Oct 14, 3:49 am, James Kuyper <> wrote:
    > >> 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/
    Paul Hsieh, Oct 18, 2008
    #18
  19. Paul Hsieh <> writes:
    > On Oct 18, 6:30 am, James Kuyper <> wrote:

    [...]
    >> 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) <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"
    Keith Thompson, Oct 18, 2008
    #19
  20. Keld Jørn Simonsen

    James Kuyper Guest

    Paul Hsieh wrote:
    > On Oct 18, 6:30 am, James Kuyper <> wrote:

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

    >> 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.
    James Kuyper, Oct 19, 2008
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.

Share This Page