Interview with Mr Stroustrup

Discussion in 'C Programming' started by sandeep, Jan 11, 2011.

  1. sandeep

    sandeep Guest

    I have been reading a very interesting interview with the creator and
    maintainer of C++, Mr B Stroustrup: http://www.codeguru.com/cpp/misc/
    article.php/c18357/An-Interview-with-C-Creator-Bjarne-Stroustrup.htm

    In it he reveals that a new ISO standard for C++ will soon be available.
    I believe this has many serious implications for ISO C. Here are some of
    the main points.

    ===
    I declared p without explicitly mentioning the type of p. Instead, I used
    auto, which means "use the type of the initializer." So p is a
    vector<pair<string,int>>::iterator. That saves a fair bit of typing and
    removes the possibility of a few kinds of bugs. This is the oldest C++0x
    feature; I implemented it in 1983, but was forced to take it out for C
    compatibility reasons.
    ===

    This is a major issue because auto is a keyword in C with a different
    meaning! Recommendation: revise the semantics of auto in C to match C++.
    So you could have:

    auto fp = fopen("foo", "r"); /* fp will have type FILE*, not int */

    Compilers will be able to provide switches like -traditional for legacy
    code that uses auto in the old sense

    ===
    Direct and type safe support for the traditional threads-and-locks style
    of system-level concurrency. Together with a detailed memory model and
    facilities for lock-free programming, this provides support for portable
    and efficient concurrency.
    ===

    Multithreading is the future - many-core processors are already becoming
    the norm. Recommendation: C should follow the lead of C++ and standardize
    multithreading in the same way.

    ===
    A regular expression standard library component
    ===

    Recommendation: Many programs use regular expressions, so this would be a
    useful addition to C's standard library, again it should be done to
    maintain compatibility with C++.

    There are many other new things too, and I would advise all members of
    the ISO C panel to think carefully about how to integrate the new
    features of C++1x, into the next version of the ISO C standard.
    sandeep, Jan 11, 2011
    #1
    1. Advertising

  2. sandeep wrote:
    > I have been reading a very interesting interview with the creator and
    > maintainer of C++, Mr B Stroustrup: http://www.codeguru.com/cpp/misc/ar...nterview-with-C-Creator-Bjarne-Stroustrup.htm
    >
    > In it he reveals that a new ISO standard for C++ will soon be available.
    > I believe this has many serious implications for ISO C. Here are some of
    > the main points.
    >
    > ===
    > I declared p without explicitly mentioning the type of p. Instead, I used
    > auto, which means "use the type of the initializer." So p is a
    > vector<pair<string,int>>::iterator. That saves a fair bit of typing and
    > removes the possibility of a few kinds of bugs. This is the oldest C++0x
    > feature; I implemented it in 1983, but was forced to take it out for C
    > compatibility reasons.
    > ===
    >
    > This is a major issue because auto is a keyword in C with a different
    > meaning! Recommendation: revise the semantics of auto in C to match C++.


    Could be a nice feature, but I very much doubt it'll happen in C1X. Are
    there C compilers that already support this feature, BTW?

    [...]
    > ===
    > Direct and type safe support for the traditional threads-and-locks style
    > of system-level concurrency. Together with a detailed memory model and
    > facilities for lock-free programming, this provides support for portable
    > and efficient concurrency.
    > ===
    >
    > Multithreading is the future - many-core processors are already becoming
    > the norm. Recommendation: C should follow the lead of C++ and standardize
    > multithreading in the same way.


    I suggest you take a look at the latest C1X draft :)
    --
    Marcin Grzegorczyk
    Marcin Grzegorczyk, Jan 11, 2011
    #2
    1. Advertising

  3. sandeep

    Ian Collins Guest

    On 01/12/11 11:24 AM, Kenneth Brody wrote:
    > On 1/11/2011 4:04 PM, sandeep wrote:
    >> I have been reading a very interesting interview with the creator and
    >> maintainer of C++, Mr B Stroustrup: http://www.codeguru.com/cpp/misc/
    >> article.php/c18357/An-Interview-with-C-Creator-Bjarne-Stroustrup.htm
    >>
    >> In it he reveals that a new ISO standard for C++ will soon be available.
    >> I believe this has many serious implications for ISO C. Here are some of
    >> the main points.
    >>
    >> ===
    >> I declared p without explicitly mentioning the type of p. Instead, I used
    >> auto, which means "use the type of the initializer." So p is a
    >> vector<pair<string,int>>::iterator. That saves a fair bit of typing and
    >> removes the possibility of a few kinds of bugs. This is the oldest C++0x
    >> feature; I implemented it in 1983, but was forced to take it out for C
    >> compatibility reasons.
    >> ===
    >>
    >> This is a major issue because auto is a keyword in C with a different
    >> meaning! Recommendation: revise the semantics of auto in C to match C++.
    >> So you could have:
    >>
    >> auto fp = fopen("foo", "r"); /* fp will have type FILE*, not int */
    >>
    >> Compilers will be able to provide switches like -traditional for legacy
    >> code that uses auto in the old sense

    > [...]
    >
    > This would require a tremendous amount of overhead AFAICT. You would,
    > for example, need to carry the type along with the value. And, you would
    > have to include runtime support for all operations on all types.
    >
    > For example:
    >
    > auto foo;


    No.

    > Or could you only assign it a value on the declaration?


    Yes, auto is used as

    auto x = expression;

    The type has to be deduced at compile time, so there isn't any run time
    overhead.

    --
    Ian Collins
    Ian Collins, Jan 11, 2011
    #3
  4. sandeep

    Ben Pfaff Guest

    Kenneth Brody <> writes:
    > On 1/11/2011 4:04 PM, sandeep wrote:
    >> So you could have:
    >>
    >> auto fp = fopen("foo", "r"); /* fp will have type FILE*, not int */
    >>
    >> Compilers will be able to provide switches like -traditional for legacy
    >> code that uses auto in the old sense

    > [...]
    >
    > This would require a tremendous amount of overhead AFAICT. You would,
    > for example, need to carry the type along with the value. And, you
    > would have to include runtime support for all operations on all types.
    >
    > For example:
    >
    > auto foo;
    >
    > switch(bar)
    > {
    > case 1: foo = fopen("foo","r"); break;
    > case 2: foo = some_int_function(); break;
    > case 3: foo = some_float_function(); break;
    > }


    I think that this new 'auto' syntax is only allowed when the
    variable declaration includes an initializer.
    --
    Ben Pfaff
    http://benpfaff.org
    Ben Pfaff, Jan 11, 2011
    #4
  5. sandeep

    Chris H Guest

    In message <igigks$rp7$>, sandeep <>
    writes
    >I have been reading a very interesting interview with the creator and
    >maintainer of C++, Mr B Stroustrup:


    He is not the maintainer. ISO WG21 is. This is made up or people from
    many National Standards Bodies.

    >In it he reveals that a new ISO standard for C++ will soon be available.


    We know, everyone knows there is nothing to "reveal"

    >I believe this has many serious implications for ISO C. Here are some of
    >the main points.


    Why? C and C++ are separate languages that went their separate ways
    long before the first C standard.

    >Recommendation: Many programs use regular expressions, so this would be a
    >useful addition to C's standard library, again it should be done to
    >maintain compatibility with C++.


    Why do we need compatibility between C and C++ they are separate
    languages.

    >There are many other new things too, and I would advise all members of
    >the ISO C panel to think carefully about how to integrate the new
    >features of C++1x, into the next version of the ISO C standard.


    At the moment WG23 are looking at making some parts of C99 optional
    never mind adding things.

    What C++ does is up to WG21 it does not mean that WG14 has to follow it
    at all.

    --
    \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
    \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
    \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
    Chris H, Jan 11, 2011
    #5
  6. sandeep <> writes:
    > I have been reading a very interesting interview with the creator and
    > maintainer of C++, Mr B Stroustrup: http://www.codeguru.com/cpp/misc/
    > article.php/c18357/An-Interview-with-C-Creator-Bjarne-Stroustrup.htm
    >
    > In it he reveals that a new ISO standard for C++ will soon be available.
    > I believe this has many serious implications for ISO C. Here are some of
    > the main points.
    >
    > ===
    > I declared p without explicitly mentioning the type of p. Instead, I used
    > auto, which means "use the type of the initializer." So p is a
    > vector<pair<string,int>>::iterator. That saves a fair bit of typing and
    > removes the possibility of a few kinds of bugs. This is the oldest C++0x
    > feature; I implemented it in 1983, but was forced to take it out for C
    > compatibility reasons.
    > ===
    >
    > This is a major issue because auto is a keyword in C with a different
    > meaning! Recommendation: revise the semantics of auto in C to match C++.
    > So you could have:
    >
    > auto fp = fopen("foo", "r"); /* fp will have type FILE*, not int */
    >
    > Compilers will be able to provide switches like -traditional for legacy
    > code that uses auto in the old sense


    It's not that big a deal. The existing "auto" keyword in C is
    never necessary, and is almost never used. The new C++ feature,
    of being able to infer the type of a declared object from the type
    of its initializer, might be nice to have, but it's not as useful
    in C as it is in C++; usually in C you already know the type.

    C++ is not strictly upward compatible with C anyway; this reuse of an
    obscure keyword doesn't make the situation significantly worse.

    > ===
    > Direct and type safe support for the traditional threads-and-locks style
    > of system-level concurrency. Together with a detailed memory model and
    > facilities for lock-free programming, this provides support for portable
    > and efficient concurrency.
    > ===
    >
    > Multithreading is the future - many-core processors are already becoming
    > the norm. Recommendation: C should follow the lead of C++ and standardize
    > multithreading in the same way.


    C201X already proposes to add threading. I don't know how similar
    it is to C++ threading.

    > ===
    > A regular expression standard library component
    > ===
    >
    > Recommendation: Many programs use regular expressions, so this would be a
    > useful addition to C's standard library, again it should be done to
    > maintain compatibility with C++.


    C/C++ compatibility generally means that C code is valid C++ code, not
    the other way around. C++ has lots of stuff that C doesn't (classes,
    exceptions, templates, etc.); this regular expression library
    would be just one more such feature.

    It *might* be sufficiently useful to add to C, but C++ compatibility
    isn't a strong reason to do so. And it might not be C-compatible
    anyway, for example if it's defined in terms of C++ classes.
    (I haven't looked at it.)

    > There are many other new things too, and I would advise all members of
    > the ISO C panel to think carefully about how to integrate the new
    > features of C++1x, into the next version of the ISO C standard.


    I believe the C and C++ committees are already in close contact.

    --
    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, Jan 11, 2011
    #6
  7. sandeep

    BartC Guest

    "sandeep" <> wrote in message
    news:igigks$rp7$...
    > I have been reading a very interesting interview with the creator and
    > maintainer of C++, Mr B Stroustrup: http://www.codeguru.com/cpp/misc/
    > article.php/c18357/An-Interview-with-C-Creator-Bjarne-Stroustrup.htm
    >
    > In it he reveals that a new ISO standard for C++ will soon be available.
    > I believe this has many serious implications for ISO C. Here are some of
    > the main points.
    >
    > ===
    > I declared p without explicitly mentioning the type of p. Instead, I used
    > auto, which means "use the type of the initializer." So p is a
    > vector<pair<string,int>>::iterator. That saves a fair bit of typing and
    > removes the possibility of a few kinds of bugs. This is the oldest C++0x
    > feature; I implemented it in 1983, but was forced to take it out for C
    > compatibility reasons.
    > ===
    >
    > This is a major issue because auto is a keyword in C with a different
    > meaning! Recommendation: revise the semantics of auto in C to match C++.
    > So you could have:
    >
    > auto fp = fopen("foo", "r"); /* fp will have type FILE*, not int */
    >
    > Compilers will be able to provide switches like -traditional for legacy
    > code that uses auto in the old sense


    Or we can just use a different keyword; 'auto' isn't exactly the most apt.

    Is auto meant also for initialising from literals? Because I can't see it
    working too well in code like this:

    signed int a = 42;
    unsigned int b = 42;
    signed short c = 42;
    unsigned short d = 42;
    signed char e = 42;
    unsigned char f = 42;
    signed long long g = 42;
    unsigned long long h = 42;
    float x = 42.0
    double y = 42.0

    char *s = "abcdef";
    char t[] = "abcdef";

    If all the type-specs are replaced by 'auto' (or something better..), then
    the literals, even with a few 'L' and 'LL' modifiers, would be hard-pressed
    to represent exactly the type needed in each case.

    And string literals have similar problems.

    Would auto x[n]=y create an array of whatever type y is? In that case y
    would be the wrong initialiser... So presumably names declared with auto
    can't be formed into pointers, arrays and functions as can normal
    declarations, at least not in the same declaration.

    Even when initialising from an expression with a specific type, I can see
    problems:

    auto F = fopen(...) // from your example

    If a variable G needed to match the type of F, how would that be done? Would
    something like this be needed:

    typeof(F) G; // ?

    And if the type of G was hardcoded, then there would be problems when the
    initialiser for F changed type.

    --
    Bartc
    BartC, Jan 12, 2011
    #7
  8. sandeep

    Ian Collins Guest

    On 01/12/11 02:21 PM, BartC wrote:
    > "sandeep" <> wrote in message
    > news:igigks$rp7$...
    >> I have been reading a very interesting interview with the creator and
    >> maintainer of C++, Mr B Stroustrup: http://www.codeguru.com/cpp/misc/
    >> article.php/c18357/An-Interview-with-C-Creator-Bjarne-Stroustrup.htm
    >>
    >> In it he reveals that a new ISO standard for C++ will soon be available.
    >> I believe this has many serious implications for ISO C. Here are some of
    >> the main points.
    >>
    >> ===
    >> I declared p without explicitly mentioning the type of p. Instead, I used
    >> auto, which means "use the type of the initializer." So p is a
    >> vector<pair<string,int>>::iterator. That saves a fair bit of typing and
    >> removes the possibility of a few kinds of bugs. This is the oldest C++0x
    >> feature; I implemented it in 1983, but was forced to take it out for C
    >> compatibility reasons.
    >> ===
    >>
    >> This is a major issue because auto is a keyword in C with a different
    >> meaning! Recommendation: revise the semantics of auto in C to match C++.
    >> So you could have:
    >>
    >> auto fp = fopen("foo", "r"); /* fp will have type FILE*, not int */
    >>
    >> Compilers will be able to provide switches like -traditional for legacy
    >> code that uses auto in the old sense

    >
    > Or we can just use a different keyword; 'auto' isn't exactly the most apt.
    >
    > Is auto meant also for initialising from literals? Because I can't see
    > it working too well in code like this:
    >
    > signed int a = 42;
    > unsigned int b = 42;
    > signed short c = 42;
    > unsigned short d = 42;
    > signed char e = 42;
    > unsigned char f = 42;
    > signed long long g = 42;
    > unsigned long long h = 42;
    > float x = 42.0
    > double y = 42.0
    >
    > char *s = "abcdef";
    > char t[] = "abcdef";


    The original proposal is here:

    http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1984.pdf

    --
    Ian Collins
    Ian Collins, Jan 12, 2011
    #8
  9. sandeep

    Jorgen Grahn Guest

    On Tue, 2011-01-11, Chris H wrote:
    ....
    >>Recommendation: Many programs use regular expressions, so this would be a
    >>useful addition to C's standard library, again it should be done to
    >>maintain compatibility with C++.

    >
    > Why do we need compatibility between C and C++ they are separate
    > languages.


    I think almost all C++ programmers and many C programmers want some
    degree of compatibility, but what he's talking about is something
    else.

    If we started importing C++ features into C, I doubt these brand new
    regex classes would be first in line -- before RAII, operator
    overloading, the standard containers ...

    You see where this is leading: if you want C++, use a C++ compiler.

    /Jorgen

    --
    // Jorgen Grahn <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .
    Jorgen Grahn, Jan 12, 2011
    #9
  10. sandeep

    sandeep Guest

    Keith Thompson writes:
    > sandeep <> writes:
    >> I have been reading a very interesting interview with the creator and
    >> maintainer of C++, Mr B Stroustrup: http://www.codeguru.com/cpp/misc/
    >> article.php/c18357/An-Interview-with-C-Creator-Bjarne-Stroustrup.htm
    >>
    >> In it he reveals that a new ISO standard for C++ will soon be
    >> available. I believe this has many serious implications for ISO C. Here
    >> are some of the main points.
    >>
    >> ===
    >> I declared p without explicitly mentioning the type of p. Instead, I
    >> used auto, which means "use the type of the initializer." So p is a
    >> vector<pair<string,int>>::iterator. That saves a fair bit of typing and
    >> removes the possibility of a few kinds of bugs. This is the oldest
    >> C++0x feature; I implemented it in 1983, but was forced to take it out
    >> for C compatibility reasons.
    >> ===
    >>
    >> This is a major issue because auto is a keyword in C with a different
    >> meaning! Recommendation: revise the semantics of auto in C to match
    >> C++. So you could have:
    >>
    >> auto fp = fopen("foo", "r"); /* fp will have type FILE*, not int */
    >>
    >> Compilers will be able to provide switches like -traditional for legacy
    >> code that uses auto in the old sense

    >
    > It's not that big a deal. The existing "auto" keyword in C is never
    > necessary, and is almost never used. The new C++ feature, of being able
    > to infer the type of a declared object from the type of its initializer,
    > might be nice to have, but it's not as useful in C as it is in C++;
    > usually in C you already know the type.


    Yes, but consistently using the auto keyword could be very helpful in
    futureproofing code. For example, if the return type of fopen would
    change in the future, then the code above could just be recompiled
    without any changes and it would still work.

    > C++ is not strictly upward compatible with C anyway; this reuse of an
    > obscure keyword doesn't make the situation significantly worse.


    In my opinion, compatibility with C++ is one of C's greatest assets. I
    recommend the ISO C body to move towards these two goals viz-a-viz C++:

    1. any program that is syntactically valid both in C and C++, should have
    the same semantics in both languages

    2. as much syntactically valid C++ as possible, should also be valid C

    >> ===
    >> Direct and type safe support for the traditional threads-and-locks
    >> style of system-level concurrency. Together with a detailed memory
    >> model and facilities for lock-free programming, this provides support
    >> for portable and efficient concurrency.
    >> ===
    >>
    >> Multithreading is the future - many-core processors are already
    >> becoming the norm. Recommendation: C should follow the lead of C++ and
    >> standardize multithreading in the same way.

    >
    > C201X already proposes to add threading. I don't know how similar it is
    > to C++ threading.


    This is a good proposal, hopefully it will agree in all respects with the
    C++ proposal.

    >> ===
    >> A regular expression standard library component ===
    >>
    >> Recommendation: Many programs use regular expressions, so this would be
    >> a useful addition to C's standard library, again it should be done to
    >> maintain compatibility with C++.

    >
    > C/C++ compatibility generally means that C code is valid C++ code, not
    > the other way around. C++ has lots of stuff that C doesn't (classes,
    > exceptions, templates, etc.); this regular expression library would be
    > just one more such feature.
    >
    > It *might* be sufficiently useful to add to C, but C++ compatibility
    > isn't a strong reason to do so. And it might not be C-compatible
    > anyway, for example if it's defined in terms of C++ classes. (I haven't
    > looked at it.)


    Don't forget that C++ classes can be emulated in C using structs with a
    vtable of function-pointers for the methods.

    >> There are many other new things too, and I would advise all members of
    >> the ISO C panel to think carefully about how to integrate the new
    >> features of C++1x, into the next version of the ISO C standard.

    >
    > I believe the C and C++ committees are already in close contact.


    I hope you are right. All my reading on this subject, gives the
    impression that standards bodies pride themselves on working in glorious
    isolation!
    sandeep, Jan 12, 2011
    #10
  11. sandeep

    Ian Collins Guest

    On 01/13/11 10:52 AM, sandeep wrote:
    > Keith Thompson writes:
    >
    >> C++ is not strictly upward compatible with C anyway; this reuse of an
    >> obscure keyword doesn't make the situation significantly worse.

    >
    > In my opinion, compatibility with C++ is one of C's greatest assets. I
    > recommend the ISO C body to move towards these two goals viz-a-viz C++:
    >
    > 1. any program that is syntactically valid both in C and C++, should have
    > the same semantics in both languages


    VLAs already break this gaol.

    > 2. as much syntactically valid C++ as possible, should also be valid C


    Shouldn't that be the other way round?

    --
    Ian Collins
    Ian Collins, Jan 12, 2011
    #11
  12. sandeep

    Chris H Guest

    In message <igl7r6$33a$>, sandeep <>
    writes

    >In my opinion, compatibility with C++ is one of C's greatest assets.


    It is one of it's biggest problems.

    > I
    >recommend the ISO C body to move towards these two goals viz-a-viz C++:


    NEVER going to happen. I would vote against it every time. As it is
    parts of C99 are being made optional in C1*. If you want C and C++
    compatibility change C++ to be compatible with C. Lives depend on it.

    >> I believe the C and C++ committees are already in close contact.

    >
    >I hope you are right.


    They are in close contact.

    > All my reading on this subject, gives the
    >impression that standards bodies pride themselves on working in glorious
    >isolation!


    Not at all C and C++ are different languages designed for different
    things. If you want more compatibility between C and C++ you will have
    to move C++ to be compatible with C
    --
    \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
    \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
    \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
    Chris H, Jan 12, 2011
    #12
  13. sandeep

    Chris H Guest

    In message <>, Ian Collins <ian-
    > writes
    >On 01/13/11 10:52 AM, sandeep wrote:
    >> Keith Thompson writes:
    >>
    >>> C++ is not strictly upward compatible with C anyway; this reuse of an
    >>> obscure keyword doesn't make the situation significantly worse.

    >>
    >> In my opinion, compatibility with C++ is one of C's greatest assets. I
    >> recommend the ISO C body to move towards these two goals viz-a-viz C++:
    >>
    >> 1. any program that is syntactically valid both in C and C++, should have
    >> the same semantics in both languages

    >
    >VLAs already break this gaol.
    >
    >> 2. as much syntactically valid C++ as possible, should also be valid C

    >
    >Shouldn't that be the other way round?


    Yes. And that is the only practical option.
    --
    \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
    \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
    \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
    Chris H, Jan 12, 2011
    #13
  14. sandeep

    Ian Collins Guest

    On 01/13/11 11:53 AM, Chris H wrote:
    > In message<igl7r6$33a$>, sandeep<>
    > writes
    >
    >> In my opinion, compatibility with C++ is one of C's greatest assets.

    >
    > It is one of it's biggest problems.


    Shouldn't that be the other way round?

    :)

    > Not at all C and C++ are different languages designed for different
    > things. If you want more compatibility between C and C++ you will have
    > to move C++ to be compatible with C


    In some domains, where they overlap compatibility should be considered.
    Threading is probably the most important of these.

    --
    Ian Collins
    Ian Collins, Jan 12, 2011
    #14
  15. sandeep <> writes:
    > Keith Thompson writes:
    >> sandeep <> writes:

    [...]
    >> C++ is not strictly upward compatible with C anyway; this reuse of an
    >> obscure keyword doesn't make the situation significantly worse.

    >
    > In my opinion, compatibility with C++ is one of C's greatest assets. I
    > recommend the ISO C body to move towards these two goals viz-a-viz C++:


    I'd say that compatibility with C is an asset of C++ (the reverse
    of what you wrote). Whether it's one of its *greatest* assets is
    an open question.

    > 1. any program that is syntactically valid both in C and C++, should have
    > the same semantics in both languages


    That's mostly true now, and the exceptions are unlikely to go away.
    For example, there are good reasons for character constants to be
    of type int in C and of type char in C++.

    > 2. as much syntactically valid C++ as possible, should also be valid C


    The only way to fully achieve that goal would be to make C a clone
    of C++. C will always be (nearly) a subset of C++; that's what
    the "++" means. Moving C closer to C++ just for the sake of doing
    so is not particularly useful. If C++ is what you want, you know
    where to find it.

    [...]

    >>> ===
    >>> A regular expression standard library component ===
    >>>
    >>> Recommendation: Many programs use regular expressions, so this would be
    >>> a useful addition to C's standard library, again it should be done to
    >>> maintain compatibility with C++.

    >>
    >> C/C++ compatibility generally means that C code is valid C++ code, not
    >> the other way around. C++ has lots of stuff that C doesn't (classes,
    >> exceptions, templates, etc.); this regular expression library would be
    >> just one more such feature.
    >>
    >> It *might* be sufficiently useful to add to C, but C++ compatibility
    >> isn't a strong reason to do so. And it might not be C-compatible
    >> anyway, for example if it's defined in terms of C++ classes. (I haven't
    >> looked at it.)

    >
    > Don't forget that C++ classes can be emulated in C using structs with a
    > vtable of function-pointers for the methods.


    And requiring that kind of machinery in a C standard regexp library
    would be absurd.

    http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3126.pdf is
    the current draft of the upcoming C++ standard. Chapter 28 covers
    the regular expression library. Take a look at it, and think about
    implementing something equivalent in C. (For starters, there are
    dozens of occurrences of the "template" keyword.)

    [...]

    --
    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, Jan 12, 2011
    #15
  16. Ian Collins <> writes:
    > On 01/13/11 10:52 AM, sandeep wrote:
    >> Keith Thompson writes:
    >>> C++ is not strictly upward compatible with C anyway; this reuse of an
    >>> obscure keyword doesn't make the situation significantly worse.

    >>
    >> In my opinion, compatibility with C++ is one of C's greatest assets. I
    >> recommend the ISO C body to move towards these two goals viz-a-viz C++:
    >>
    >> 1. any program that is syntactically valid both in C and C++, should have
    >> the same semantics in both languages

    >
    > VLAs already break this gaol.


    Just curious, was that a typo or a deliberate pun?

    ("Gaol" is the UK English word for what US English calls "jail"; both
    are pronounced the same way, modulo regional accent.)

    --
    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, Jan 13, 2011
    #16
  17. sandeep

    Ian Collins Guest

    On 01/13/11 01:02 PM, Keith Thompson wrote:
    > Ian Collins<> writes:
    >> On 01/13/11 10:52 AM, sandeep wrote:
    >>> Keith Thompson writes:
    >>>> C++ is not strictly upward compatible with C anyway; this reuse of an
    >>>> obscure keyword doesn't make the situation significantly worse.
    >>>
    >>> In my opinion, compatibility with C++ is one of C's greatest assets. I
    >>> recommend the ISO C body to move towards these two goals viz-a-viz C++:
    >>>
    >>> 1. any program that is syntactically valid both in C and C++, should have
    >>> the same semantics in both languages

    >>
    >> VLAs already break this gaol.

    >
    > Just curious, was that a typo or a deliberate pun?


    The former, but I like the idea of the latter more!

    --
    Ian Collins
    Ian Collins, Jan 13, 2011
    #17
  18. sandeep

    Noob Guest

    sandeep wrote:

    > There are many other new things too, and I would advise all members
    > of the ISO C panel to think carefully about how to integrate the new
    > features of C++1x, into the next version of the ISO C standard.


    You might want to subscribe to comp.std.c if you want to discuss
    current and future C standards.
    Noob, Jan 13, 2011
    #18
  19. sandeep

    Chris H Guest

    In message <>, Ian Collins <ian-
    > writes
    >On 01/13/11 11:53 AM, Chris H wrote:
    >> In message<igl7r6$33a$>, sandeep<>
    >> writes
    >>
    >>> In my opinion, compatibility with C++ is one of C's greatest assets.

    >>
    >> It is one of it's biggest problems.

    >
    >Shouldn't that be the other way round?
    >
    >:)
    >
    >> Not at all C and C++ are different languages designed for different
    >> things. If you want more compatibility between C and C++ you will have
    >> to move C++ to be compatible with C

    >
    >In some domains, where they overlap compatibility should be considered.
    >Threading is probably the most important of these.


    Only if C++ moves to C. C is still very widely used on 8 and 16 bit
    MCU's (which still make up the majority of processors on the planet) in
    self hosted embedded systems where safety and high reliability are
    required.

    As it is no one and bothered to fully implement the current C99 standard
    in the 12 years since it's release and in fact for the next standard
    they is a move to make parts of C99 optional.... so if anything ISO-C is
    going to get smaller never mind adding to it.

    If you want all these extra things by all means add them to C++ and use
    C++ just don't mess about with C.

    What happened in the 90's was C90 harmonised and Standardised the state
    of the actual compilers in use. Tightened it up 90 to 95 but from 95
    to 99 they added a lot of "cool" and "useful" things that the industry
    did not want.

    We don't want history to repeat itself.


    --
    \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
    \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
    \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
    Chris H, Jan 13, 2011
    #19
  20. sandeep

    jacob navia Guest

    Le 13/01/11 11:05, Chris H a écrit :
    >
    > As it is no one and bothered to fully implement the current C99 standard
    > in the 12 years since it's release



    No compiler fully implements the 1998 C++ standard either. There are
    several almost
    perfect implementations of C99: Intel, gcc, IBM and others. Partial
    implementations are very common. You want to destroy C99 and reduce
    C to a language for 8 bit microcontrollers. There are people that
    do not agree with you.

    > and in fact for the next standard
    > they is a move to make parts of C99 optional.... so if anything ISO-C is
    > going to get smaller never mind adding to it.
    >


    That is just a wish from you.

    > If you want all these extra things by all means add them to C++ and use
    > C++ just don't mess about with C.
    >


    You do not own C. And if people want to program in C and want to
    ìmprove the language its their right.

    > What happened in the 90's was C90 harmonised and Standardised the state
    > of the actual compilers in use. Tightened it up 90 to 95 but from 95
    > to 99 they added a lot of "cool" and "useful" things that the industry
    > did not want.
    >


    IBM, Intel, gcc, and many other compilers have implemented C99. In the
    microcontroller world, many implementations exists and the last time
    you brought two examples of compilers from the embedded world that did
    not implement C99 I could prove you that they started implementing it.
    jacob navia, Jan 13, 2011
    #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.
Similar Threads
  1. Oplec
    Replies:
    26
    Views:
    791
    Oplec
    Oct 24, 2003
  2. Steven T. Hatton
    Replies:
    6
    Views:
    4,195
    Steven T. Hatton
    Apr 12, 2004
  3. Graham
    Replies:
    3
    Views:
    387
  4. Russell Wood

    Interview with Stroustrup, Leaked.

    Russell Wood, May 24, 2006, in forum: C++
    Replies:
    13
    Views:
    501
    Default User
    May 25, 2006
  5. reema
    Replies:
    0
    Views:
    243
    reema
    Aug 26, 2008
Loading...

Share This Page