Interview with Mr Stroustrup

[sandeep]

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.

 

[Marcin Grzegorczyk]

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

 

[Ian Collins]

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.

 

[Ben Pfaff]

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.

 

[Chris H]

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.

 

[Keith Thompson]

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.

 

[BartC]

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.

 

[Ian Collins]

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

 

[Jorgen Grahn]

.

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

 

[sandeep]

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

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.

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.

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!

 

[Ian Collins]

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?

 

[Chris H]

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 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 H]

VLAs already break this gaol.


Shouldn't that be the other way round?

Yes. And that is the only practical option.

 

[Ian Collins]

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.

 

[Keith Thompson]

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.

[...]

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]

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

 

[Ian Collins]

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

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

 

[Noob]

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.

 

[Chris H]

Shouldn't that be the other way round?




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.

 

[jacob navia]

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.