Interview with Mr Stroustrup

[Ian Collins]

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.

That is why I said compatibility should be considered where C and C++
overlap.

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.

Sun did.

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

Well if C is to have a future on all but the smallest single core
processors, threading should be considered, at least as an option.

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.

Just as we don't want C to be left behind. The C++ standard has adapted
to modern hardware by incorporating threading into the core language and
the C1x drafts do likewise.

 

[Chris H]

Le 13/01/11 11:05, Chris H a écrit :


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.

There are a lot of very good C90 implementations There are a few
partial implementations of C99. Most were C90+ now we are (over a
decade on ) starting to get C99- compilers.

You want to destroy C99 and reduce
C to a language for 8 bit microcontrollers. There are people that
do not agree with you.

But the majority do agree. That is the majority who pay money and buy
compilers. Hence the industry has done what people want. C95

That is just a wish from you.

And it seems the ISO-C WG who are making things optional.

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

That was the argument use by those who took C95 and destroyed it by
making C99

IBM, Intel, gcc, and many other compilers have implemented C99.

Intel IBM and GC have partial implementations (like many others) who
have C90+ compilers.

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.

Yes.... Over a DECADE after the C99 you can show that they are
*STARTING* to implement *SOME* of it. Meanwhile ISO-C WG is making parts
of C99 "optional" In the 2007 meeting of the ISO-C-WG in London it was
discussed dropping parts of C99 altogether. The compromise is to make
them "optional"

When C1* comes out people will move to that and C99 will be come the
standard that never was because even if you implement full C1* it will
not be a superset of C99.

The industry has voted with it's feet.

 

[Chris H]

Well if C is to have a future on all but the smallest single core
processors, threading should be considered, at least as an option.

C is used on 8-128 bit systems and many of them have been multi core for
a decade. Also they have had multiple threads and multi tasking with and
without an RTOS.

Just as we don't want C to be left behind. The C++ standard has adapted
to modern hardware by incorporating threading into the core language
and the C1x drafts do likewise.

Why? It is not needed for the majority and those that do need it seem to
have coped very well with multi threading and multiple cores for a long
while so far.

 

[tm]

There are a lot of very good C90 implementations   There are a few
partial implementations of C99.    Most were C90+  now we are (over a
decade on ) starting to get C99- compilers.

C99 just went in the wrong direction.
C is often used as "portable assembler". Many other
languages use C as base (to implement interpreters,
compilers and runtime libraries). Some compilers even
generate C instead of machine code. To support this
areas C could add features like:

- portable threading support.
- exception handling (with the possibility to switch it
off).
- possibility to check integer overflow, but keeping
the current behaviour, if desired. When overflow
checking is part of the language it is possible to
support it with no overhead when the hardware has
overflow trap).
- Move some Posix functions like reading directories
to the C standard.
- Support for closures (AFAIK gcc already supports them).
- Hints for the probability of conditions (gcc already
supports this feature). This way the programmer can
help to optimize a program.


Greetings Thomas Mertes

--
Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.

 

[jacob navia]

Le 13/01/11 13:42, tm a écrit :

C99 just went in the wrong direction.
True

C is often used as "portable assembler". Many other
languages use C as base (to implement interpreters,
compilers and runtime libraries). Some compilers even
generate C instead of machine code. To support this
areas C could add features like:

- portable threading support.

lcc-win gives you access to threads provided by the OS. I am
doubtful if all the code written for pthreads or windows
threads will be rewritten to cater for yet another standard

- exception handling (with the possibility to switch it
off).

lcc-win provides you that. I have been proposing that
since 8 or more years to comp.std.c. No answer.

- possibility to check integer overflow, but keeping
the current behaviour, if desired. When overflow
checking is part of the language it is possible to
support it with no overhead when the hardware has
overflow trap).

lcc-win implements that. I have been proposing that for eight years too.
No answer.

- Move some Posix functions like reading directories
to the C standard.

Yes, that would be a good idea.

- Support for closures (AFAIK gcc already supports them).

Why you need that?
Can you give an example?

- Hints for the probability of conditions (gcc already
supports this feature). This way the programmer can
help to optimize a program.

I do not think that a language standard can go so far in compiler
internals.

 

[TonyMc]

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

"For a gaol can give you a goal"
-- "Mad Man Moon", from "Trick of the Tail" by Genesis

 

[Ben Bacarisse]

Le 13/01/11 13:42, tm a écrit :

AFAIK Apple has a version of gcc that does this, but it's not in gcc
itself.

Why you need that?
Can you give an example?

You have one yourself. In the documentation for your container library,
you implement mapcar. Look at the huge amount of "machinery" you need
in C to do this (including a static object that will cause problems in a
threaded program). Re-write it using, say, Apple's blocks[1] and you
should see the advantage.

[1] http://arstechnica.com/apple/reviews/2009/08/mac-os-x-10-6.ars/10

 

[Rui Maciel]

Well if C is to have a future on all but the smallest single core
processors, threading should be considered, at least as an option.

What's wrong with relying on standards for threads, such as pthreads?
There is no reason to push something into a particular standard when that
very same feature is already defined by another standard.


Rui Maciel

 

[Walter Banks]

What's wrong with relying on standards for threads, such as pthreads?
There is no reason to push something into a particular standard when that
very same feature is already defined by another standard.

There is a good point here. Standards are supposed to incorporate
standard practice. Threads should reflect standard practice and
standards need a champion who understands the issues and has
the intellectual integrity to evaluate the implications of adopting
current practice.

The later is one of the reasons that standards take time. Papers
advocating technology and positions (and counter position papers
as well) need to be presented and debated by those in the field
who understand the implications. In general WG-14 has done
that quite well having a in depth debates. The diverse interests
and international nature of standards groups generally prevents
self interests from being able to dominate.


Regards,


w..

 

[Walter Banks]

lcc-win provides you that. I have been proposing that
since 8 or more years to comp.std.c. No answer.

Jacob you have often advocated good ideas. To your
credit most of your ideas are backed by practice

Standards groups work with material that is brought before
them in the form of papers and counter papers whose merits
are debated. Standards come out of those debates.

To have an impact on standards you need become involved
or find someone to advocate your ideas as part of the
standards group meetings.

Regards,


w..

 

[John Bode]

[snip]

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

Why? Should the same also hold for other related languages like, for
example, Pascal and Oberon?

C and C++ semantics diverged long enough ago that trying to line them
up again would break at least some legacy code on either side. What's
the payoff in making that change? How does it benefit anyone?

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

Again, why? They're two different languages. They happen to share a
lot of history, but in the end they have different goals and governing
philosophies. A well-written C program doesn't look or act very much
like a well-written C++ program, and for good reason.

Compatibility just for compatibility's sake doesn't make much sense.
Point to a solid *technical* reason why they should remain closely
compatible and we'll talk.

[snip]

 

[tm]

Le 13/01/11 13:42, tm a crit :

I want portable support for threads, not the threads
provided by the OS. I want that my threaded standard C
programs are portable. I don't care if it is pthreads or
something else. Probably it makes sense to take the
proposed C++ thread standard (when it is not template
or class based).

I am
doubtful if all the code written for pthreads or windows
threads will be rewritten to cater for yet another standard

So am I. The people can continue to use the OS
dependend threads. They are not standard C anyway, but
standard C threads allow future programs to be portable.

[snip]

Why you need that?
Can you give an example?

We all use closures all the time without realizing.
Examples of closures are:
The conditions of a while loop
The statements in loop bodies
The statements that are conditionally executed in
an if statement.

Closures are expressions and they might be executed
once, many times or not at all. They differ from normal
function pointers, but they can be implemented with
function pointers.

There are several programming languages that compile
to C and which support closures. Closure support in C
would make the job of this compilers easier.

In case of Seed7 I have already implemented closure
support in the Seed7 compiler. So I do not really need it,
but it would simplify many things. Probably a C compiler
would have to do similar things that the Seed7 compiler,
therefore I describe the strategy here:

First it must be decided if a function with closure
parameter is called recursively. A non-recursive function
with closure parameters can be implemented with inlining.
Recursive functions cannot be implemented this way.

Implementing closures with function pointers works this
way. A function pointer together with an environment data
structure is used. A call of the closure parameter is
compiled to calling the function (via function pointer)
and giving this function a pointer to the environment
data as parameter.

The actual closure parameter must be analyzed to find
out which local variables (and parameters) it uses.
This local variables are the environment data of the
actual closure parameter.

This is just a general concept, the devil is in the
details.

I do not think that a language standard can go so far in compiler
internals.

This is not compiler internals. It is like the register
keyword. Based on the gcc support I defined the macros
likely and unlikely. So a program can contain code like

if (unlikely((abc = malloc(sizeof(qwert))) == NULL)) {
/* out of memory */
...
} else {
/* okay */
...

The programmer has defenitely more knowledge about how
often an out of memory situation occurs. When a compiler
is not able to support this feature, it can just be ignored.


Greetings Thomas Mertes

--
Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.

 

[Seebs]

Why? It is not needed for the majority

And all the world's a VAX.

and those that do need it seem to
have coped very well with multi threading and multiple cores for a long
while so far.

That's a major portability barrier, though, for code which wants to do that.
If the language had a decent spec for it, we wouldn't have that problem.

-s

 

[Tobias Blass]

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

Is not the extern "C" { } declaration exactly that? If you have valid C code in
a C++ program and want to have C semantics? It seems strange to me to make C a
clone of C++ just to save a line of code (plus the closing brace) for C++
programmers.

 

[Ben Bacarisse]

Is not the extern "C" { } declaration exactly that? If you have valid
C code in a C++ program and want to have C semantics?

No, extern "C" just alters the details of the linage of external names.
It has no effect on the semantics of any code contained functions
defined within it.

<snip>

 

[Keith Thompson]

There are a lot of very good C90 implementations There are a few
partial implementations of C99. Most were C90+ now we are (over a
decade on ) starting to get C99- compilers.

My understanding is that there are several conforming C99
implementions. For example, Intel has claimed that their icc is
fully conforming, and I think the same claim has been made for
lcc-win; there are others (no gcc isn't one of them). (My use of
the word "claim" is not meant to cast doubt, merely to emphasize
that I haven't personally verified anything.)

I'm not disputing your main point that C99 adoption has been slow.

[...]

 

[tm]

So I am guessing you dont give a shit about efficiency for example?

You are guessing WRONG. I care about efficiency. You seem
to think something like pthreads=emulated=inefficient.
I am not a threading expert, but AFAIK Linux supports a
pthread interface for its native threads. I am NOT
interested in another emulated thread library (which
just runs on one processor). Instead I am interested in
a portable access to the real (native) threads of the OS.
There is also portabe access to the filesystem of the OS.
I see no reason why this cannot be done for threads?

How many of your apps are ported to multiple architectures?

Seed7 runs under Linux, Bsd, various Unix variants, Mac OS
and Windows. The source code of Seed7 is written in C and
can be compiled with gcc, MS visual C and the Borland C
compiler. The Seed7 compiler generates C code which is
subsequently compiled to machine code. This way Seed7
programs can be as efficient as C programs (when advanced
Seed7 features like OO with multiple dispatch are not used).
The Seed7 runtime library contains many parts that
compensate for OS and compiler differences. Seed7
supports portable interfaces for many things. See:

http://seed7.sourceforge.net/faq.htm#portable


Greetings Thomas Mertes

--
Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.

 

[Ian Collins]

In message<[email protected]>, Ian Collins<ian-
(e-mail address removed)> writes

I see you have stopped asserting no one has a conforming C99
implementation. That's a start.

C is used on 8-128 bit systems and many of them have been multi core for
a decade. Also they have had multiple threads and multi tasking with and
without an RTOS.

I know, I've used a fair few of them and I've also had to port between
almost as many threading implementations!

Why? It is not needed for the majority and those that do need it seem to
have coped very well with multi threading and multiple cores for a long
while so far.

Library support and core language support are two different beasts.
While they both support portability, some desirable features require
language support.

Do you object to the threading support in the C1x draft?

The C++ community has certainly embraced the support for threads in
C++0x as a long overdue feature for a modern programming language. I'm
really surprised people object to the additions to C.

 

[Keith Thompson]

Is not the extern "C" { } declaration exactly that? If you have
valid C code in a C++ program and want to have C semantics? It
seems strange to me to make C a clone of C++ just to save a line
of code (plus the closing brace) for C++ programmers.

No. In C++, anything surrounded by extern "C" { } is callable from C,
but the code itself is still C++ code. For example, this:

extern "C" {
int class;
}

is a syntax error in C++ (and in C, because C doesn't have extern "C").
extern "C" is a mechanism for interfacing between *separately compiled*
C and C++ code.

For more information (which isn't really topical
in comp.lang.c), see section 32 of the "C++ FAQ" at
<http://www.parashift.com/c++-faq-lite/>.

 

[Joshua Maurice]

So I am guessing you dont give a shit about efficiency for example?

How many of your apps are ported to multiple architectures?

I believe that the new C standard for threading closely follows the
new C++ standard, and vice versa. They've been in close contact. I
base the rest of my reply on my knowledge from the C++ side.

The goal has been to provide a portable interface implementable on all
hardware which support threads, including supporting obscure stuff
like data dependency loads for the crazy DEC-Alpha. This is also while
not paying for what you not use - writing the data dependency load vs
a naked load won't hurt performance on an x86.

Obviously, those who use other thread interfaces such as pthreads can
and will be able to continue to do so, but future apps will be able to
use the standard C threads interface.