Interview with Mr Stroustrup

[Uno]

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

You'd think by now they may have golfed together or something. Do you
know everyone on both committees? In combinatorics, that would be
called a politician.

All of C's and half of C++'s?

 

[Uno]

On 01/12/2011 04:52 PM, sandeep wrote:
...

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

This program contains two modules and one shared header. It's very
carefully designed to make many different points in a program that is as
small as possible. I make no claim that this represents good programming
practice:

shared.h:
=========
#ifndef SHARED_H
#define SHARED_H

extern char tag;
extern int enumer[2];

typedef void voidvoid(void);

int Cnmtyp(void);
int Cfunc(voidvoid*);

#endif

First module:
=============
#ifdef __cplusplus
extern "C" {
#endif

#include "shared.h"

char tag = 0;

static int hidden(voidvoid *pfunc)
{
(*pfunc)();
tag = sizeof 'C' == sizeof(int);
return Cnmtyp() && enumer[0] && enumer[1];
}

int Cfunc(voidvoid* pfunc)
{
struct tag
{
enum { enumer, other } in;
int integer;
} out;

out.integer = sizeof(tag) == 1 && sizeof(enumer) == sizeof out.in;

return hidden(pfunc) && out.integer;
}

#ifdef __cplusplus
}
#endif

Second module:
==============
#ifdef __cplusplus
extern "C" {
#endif

#include "shared.h"

int enumer[2] = {0, 1};

static void Cppname_Cpptype(void)
{
enumer[0] = sizeof 'C' == 1;
return;
}

#ifdef __cplusplus
}
#endif

int Cnmtyp(void)
{
struct tag
{
enum { enumer, other } in;
int integer;
} out;

out.integer = sizeof(enumer) == 2 * sizeof(int);

return out.integer && sizeof(tag) == sizeof out;
}

static voidvoid Cppname_Ctype;

static void Cppname_Ctype(void) {
Cppname_Cpptype();
}

int main(void) {
return Cfunc(&Cppname_Ctype) && tag;
}

Both modules contain syntactically valid code: according to C99, C++98,
and C++03, together they constitute strictly conforming C code, and
well-formed C++ code. The behavior of code containing __cplusplus is
technically undefined under C90, but for most (all?) fully conforming
C90 compilers, the behavior is exactly as if it were not a reserved
identifier, and not a pre-#defined macro. For any such C90 compiler, the
only code that would otherwise constitute a syntax error will be dropped
by the #if's.

You can compile both modules in C, or both in C++; the resulting
executables are guaranteed by the relevant standards to exit with a
failure status, for quite different reasons in each case. If you compile
the first module in C, and the second in C++, and the two compilers are
compatible, then the modules can be linked together; in that case, the
executable will exit with success status. Unfortunately, if you do it
the other way around, they cannot be linked.

Why does it matter which language is used for each module? Because three
of the comparison operators are guaranteed to have a different value,
depending upon whether the module is compiled as C or C++. The other two
comparisons will have the same value in both languages only in the
unlikely event that sizeof(int)==1. I'll leave it as an exercise for the
reader to figure out why these statements are true.

Please note that, while this code is VERY contrived, it depends upon
very deep principles of the two languages. For every single comparison
operator in the above code, guaranteeing that it would be true in both
languages would break a lot of code in one of the two languages.

So, if you want the semantics of this program to be the same in both
languages, what should they be?

That's a very interesting read, james. I wish I had ubuntu so that I
could let the source and the respective compilers inform me, but I doubt
that you misrepresent the facts.

So we know that OP's above-stated intention MUST fail.

I came to C by way of microsoft and c++, and I think of the native
idioms being better in most situations, but you mind your p's and q's
when you're going to talk to the other in a standard way.

In this event, there is only what Jack Klein told me on my first
crosspost to comp.lang.c++:

extern 'C' {tja)

 

[Chris H]

You'd think by now they may have golfed together or something. Do you
know everyone on both committees? In combinatorics, that would be
called a politician.

There are quite a few on both ISO panels but C and C++ are separate
languages and they tend to be used in different markets.

 

[Joshua Maurice]

You'd think by now they may have golfed together or something.  Do you
know everyone on both committees?  In combinatorics, that would be
called a politician.

All of C's and half of C++'s?

I forget what I have read, or where I read it. I think that it was
James Kanze who said on comp.lang.c++ that they are in close contact,
though I honestly am not sure.

Also, that was pretty harsh there. Did I do something to offend you?
In which case, I'm sorry.

 

[Rui Maciel]

I don't think I'm understanding some of the nuance of your argument.
Do you really think that using pthreads in C++ code isn't practicable?
In my experience, it's almost trivial to do so - it's as easy in C++
as it is in C. To which hoops are you referring?

It depends on what you define as being practicable. Some may believe it
is practicable to be forced to use function wrappers in order to create a
thread but others, particularly C++ purists, may believe that constitutes
a set of hoops that they are forced to jump through just to get stuff to
work. This consequence of relying on pthreads to handle threading in C++
is so commonplace that it made it's way into some FAQs, such as:

http://www.parashift.com/c++-faq-lite/pointers-to-members.html#faq-33.2

Therefore, it is only natural that a set of the C++ community invests some
time and effort to develop a threading API which is more C++-friendly,
which provides features such as the ability to freely use some C++ idioms
without being forced to resort to nasty hacks.

I want to emphasize what Ian has said else-thread that if the library
in question has serious restrictions on the language and on code
generation of a compiler, then that ought to be in the language
standard. It's not like we're proposing to throw process spawning,
GUI, or other "library" stuff into the language standard. Threading in
practice cannot be implemented as a library. It must have core
compiler/language support.

Threading has been implemented up until now without anyone being forced to
impose any explicit behaviour on programming languages that didn't
explicitly supported threading, such as C and C++. That means that any
claim that "threading in practice cannot be implemented as a library" is
patently false.

Adding to this, and following Niklas Holsti's reference to Hans-J. Boehm's
report "Threads Cannot be Implemented as a Library"[1], it is claimed that
"library-based approaches to concurrency" are "appropriate for perhaps 98%
of uses", while some of the proposed changes are "currently only
appropriate for a small fraction of multi-threaded code". So, from that
report, the issue which is being discussed is essentially: is there any
technical justification to bloat the standard of a programming language
just to cover that 2% of uses where, according to some people, a library
approach may or may not be the most appropriate?

If this wasn't enough, once we read the cases presented to demonstrate the
2% where the "library-based approach to concurrency" may not be the most
appropriate, we understand that in essence those cases originate in a
failure on behalf of the programmer to acknowledge and respect the
principles defined in the pthreads standard. Other than that, the
proposed changes would only benefit a small fraction of corner cases, and
only in performance issues. This trade-off is at least very debatable.

So, considering all this, why do people push for such a fundamental change
to the language when this issue is essentially being posed as a solution
in search of a problem?


Rui Maciel



[1] http://www.hpl.hp.com/techreports/2004/HPL-2004-209.html

 

[Rui Maciel]

Technically, you can put threading in a separate standard. I'm not
arguing you can't. POSIX pthreads is an example proving that you can
have it in separate standards.

More importantly, the pthreads standard is an international standard which
is already in place. So in the end it isn't even a matter of having to
create a standard to handle that: it is only a matter of simply
acknowledging and following tried and true standards which have been in
place for the last 15 years or so.

I think I was making two points there.

First, you need the compiler to understand threads in order to do non-
broken code generation. It's not even a matter of performance. You
need some guarantees from the compiler to use threads.

Not necessarily. The issues which have been presented as the reasons to
impose support for threads on the C standard are essentially memory access
and performance. Up until now, what has been defined as issues regarding
memory access essentially refer to corner cases where principles defined
in the pthreads standard are neglected. In fact, a set of those corner
cases are presented although they never led to any failure. Other than
that, the performance issue is being presented as the perceived cost of
using mutex locks, which are based on measurements performed on systems
based on Pentium 4 processors.

A compiler, if
it doesn't know about threads, could generate code that is broken in a
threading situation. Obviously, you can write a compiler the quick
way, and get bad performance, or you can write it better and get
better code generation with threading.

Again, the only cases where the so called "library approach to
concurrency" has been claimed to fail are cases where the principles
defined in the pthreads standard have been ignored. A new standard is not
a solution to a problem which is caused by ignoring current standards.

Second, IMHO, threading is such a complicated and inherent part of a
threaded language that it ought to go in language the standard.

I'm yet to see a single reason that justifices forcing threading into the
standard of the C programming language. Claiming that it is complicated
is also not a valid reason to do so.

The
entire abstract machine model changes. You need to change the
definition of sequence point. It just seems so much more tied to the
execution model than say.. a GUI library, or a math library.

If there was a campaign to force a GUI API into the C standard then things
would be a whole lot worse than they are.

Regarding threading in C, again, this push to force threading into the C
standard sounds like a solution in search of a problem.


Rui Maciel

 

[Chris H]

You'd think by now they may have golfed together or something. Do you
know everyone on both committees?

Actually a couple of people who are involved with both ISO-WG's have
posted to this very thread.......

 

[Joshua Maurice]

More importantly, the pthreads standard is an international standard which
is already in place.  So in the end it isn't even a matter of having to
create a standard to handle that: it is only a matter of simply
acknowledging and following tried and true standards which have been in
place for the last 15 years or so.

Which is quite informally specified, might I even say badly. It's
flawed in several subtle but important ways. However, as you said else-
post in a snipped section, I can agree that it does suffice for ~98%
of threading usage.

Still, I find it quite irritating having to convince people that "no,
you aren't guaranteed by any standard that volatile will do anything
useful", especially when they start invoking inline assembly like they
think they know something. I agree that POSIX pthreads suffices for
~98% of current usage, but for the very important other ~2%, it's the
wild west with people basically guessing and relying on undocumented
guarantees.

Also, why hasn't POSIX pthreads included read, write, and data
dependency barriers? Yes ~98% of the code doesn't need it, but the
other ~2% does, like the Linux kernel, and other high performance
threading code.

Not necessarily.  The issues which have been presented as the reasons to
impose support for threads on the C standard are essentially memory access
and performance.  Up until now, what has been defined as issues regarding
memory access essentially refer to corner cases where principles defined
in the pthreads standard are neglected.  In fact, a set of those corner
cases are presented although they never led to any failure.  Other than
that, the performance issue is being presented as the perceived cost of
using mutex locks, which are based on measurements performed on systems
based on Pentium 4 processors.

As I think Hans Boehm has said, this isn't how it works in practice. A
compiler compiling threading code must be thread aware to some extent.
You won't get correct code generation from an optimizing compiler
otherwise, except by luck. In practice, all compilers implementing
pthreads are aware of what optimizations and transformations are
acceptable and which are not. Let me emphasize that choice of wording
- the compiler, linker, etc., implement POSIX pthreads, not a
library.

Again, the only cases where the so called "library approach to
concurrency" has been claimed to fail are cases where the principles
defined in the pthreads standard have been ignored.  A new standard is not
a solution to a problem which is caused by ignoring current standards.


I'm yet to see a single reason that justifices forcing threading into the
standard of the C programming language.  Claiming that it is complicated
is also not a valid reason to do so.


If there was a campaign to force a GUI API into the C standard then things
would be a whole lot worse than they are.

Regarding threading in C, again, this push to force threading into the C
standard sounds like a solution in search of a problem.

As you didn't reply specifically to what I felt was an important
point, let me repeat it. The C standard is made in terms of an
abstract machine which has but one thread of execution. The POSIX
pthread standard doesn't simply add on to another standard like a GUI
library might - it actually rewrites and takes precedence over parts
of the C standard. Threading changes the very nature of the abstract
machine from a single threaded one to a multi threaded one.

Judging from your other replies, I don't think that you'll find that a
compelling reason to put it in the C standard, but I do want to
clarify at least that I think this is a rather important distinction
which separates threading from nearly all other real life (third
party) libraries and third party standards.

 

[Rui Maciel]

Which is quite informally specified, might I even say badly. It's
flawed in several subtle but important ways. However, as you said else-
post in a snipped section, I can agree that it does suffice for ~98%
of threading usage.

Still, I find it quite irritating having to convince people that "no,
you aren't guaranteed by any standard that volatile will do anything
useful", especially when they start invoking inline assembly like they
think they know something. I agree that POSIX pthreads suffices for
~98% of current usage, but for the very important other ~2%, it's the
wild west with people basically guessing and relying on undocumented
guarantees.

Also, why hasn't POSIX pthreads included read, write, and data
dependency barriers? Yes ~98% of the code doesn't need it, but the
other ~2% does, like the Linux kernel, and other high performance
threading code.

Without delving into details about what the pthreads standard defines and
doesn't define, it is important to state that if what motivates this
campaign to force threads into the C standard is the idea that the current
pthreads standard fails to define behavior which is seen by some as being
important then it's clear that the problem would lie in the pthreads
standard and not in the C standard. Therefore, it would be far more
productive, and far less intrusive, to simply call for an update of the
pthreads standard. After all, it isn't possible to fix the perceived
shortcomings of an international standard by creating a new, parallel
international standard that covers the exact same subject. This issue is
even less justifiable if the proposed changes only cover corner cases
which are pretty much irrelevant.

As I think Hans Boehm has said, this isn't how it works in practice. A
compiler compiling threading code must be thread aware to some extent.
You won't get correct code generation from an optimizing compiler
otherwise, except by luck. In practice, all compilers implementing
pthreads are aware of what optimizations and transformations are
acceptable and which are not. Let me emphasize that choice of wording
- the compiler, linker, etc., implement POSIX pthreads, not a
library.

The case presented by Hans Boehm in his "Threads Cannot be Implemented as
a Library" technical report (which he then states that, yes, threads sure
can be implemented as a library at least for 98% of the cases) to justify
tweaking C compilers to generate thread-aware code essentially refers to,
if I'm not mistaken, essentially two issues: obscure race conditions
caused by a failure to employ mutexes and the expensive nature of mutexes.
The issue with race conditions was divided in two distinct issues: the
ability of some C compilers to rearrange/translate instructions, which may
cause race conditions in un-mutexed parts of the code which are subjected
to concurrent read/write operations (a no-no to begin with), and non-
atomic read/write accesses to memory which, again, the access isn't
managed by a mutex (another no-no).

So, from the issues being raised, it is clear that the problem doesn't lie
with pthreads, it lies in the inability to implement basic, fundamental
pthreads principles. After all, there is a very good reason why pthreads
has been successfully employed in the real world for over 15 years and
there is a good reason why the 2% of cases which are being used to justify
a overhaul of the C programming language either never happened (as it is
stated in the TR) or are simply based on the failure to correctly use
pthreads.

As you didn't reply specifically to what I felt was an important
point, let me repeat it. The C standard is made in terms of an
abstract machine which has but one thread of execution. The POSIX
pthread standard doesn't simply add on to another standard like a GUI
library might - it actually rewrites and takes precedence over parts
of the C standard. Threading changes the very nature of the abstract
machine from a single threaded one to a multi threaded one.

Judging from your other replies, I don't think that you'll find that a
compelling reason to put it in the C standard, but I do want to
clarify at least that I think this is a rather important distinction
which separates threading from nearly all other real life (third
party) libraries and third party standards.

The issue which must be discussed is the practical and real world
implications of forcing threading into the C standard. No one would deny
a change, even a profound one, which could undeniably improve the
language, even if it had it's drawback. Yet, in this case, even the
proponents of such a change only manage to point out as reasons to impose
such as fundamental change a couple of corner cases which, quite bluntly
(and based on the examples which were provided), are caused by a failure
to implement basic phtreads principles.

Knowing that, if we also take into account the complexity (or bloat,
whatever you may call it) that this change would impose on the
specification of the C programming language, essencially to bring nothing
relevant to the table, then one has to wonder where is the technical
justification to impose such a fundamental change.


Rui Maciel

 

[tm]

In message <[email protected]

On 15 Jan., 11:18, Chris H <[email protected]> wrote:

Windows, Mac OSX, Linux, Bsd and Unix combined
probably cover 99% of the PC, Workstation and
Minicomputer market. As others already pointed out VMS
is dying and even IBM is moving towards Unix/Linux.

[snip]

Your 99% market is less than 4% of the world market that uses c.

Seed7 does not address the market that uses C.
OTOH I have information that some have experimented with
Seed7 for embedded stuff...

As I already said:
I use C as target language for compiled Seed7 programs.
As such I am interested in C features that are helpful
for machine generated C programs. I am not interested
in higher level features like VLAs, type inference, etc.
Instead I am interested in portable lower level features
that the current C standard cannot provide. The Seed7
compiler (and other compilers which generate C code) can
provide many features, but for some features support from
C is needed. One C feature that would be helpful is:

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

It would be possible to improve the Seed7 to C compiler
such that integer overflow raises an exception. But the
code would probably not be very efficient. Therefore I
would prefer when it is possible to build upon a C
(standard) feature.

You may be able to afford to work for free but few people can these
days.

You seem to missunderstand. I work as freelancer and I
am paid for my work. And I really need the money because
I have a family with three childen. The development for
Seed7 is done in my free time. So I think: When I can
manage to write open source software for free most
computer professionals should be able to do so.


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.

 

[Chris H]

In message <[email protected]

You seem to missunderstand. I work as freelancer and I
am paid for my work. And I really need the money because
I have a family with three childen. The development for
Seed7 is done in my free time.

That is your choice. I have other things to do with my free time.

So I think: When I can
manage to write open source software for free most
computer professionals should be able to do so.

Why?

 

[jacob navia]

Le 17/01/11 20:31, Rui Maciel a écrit :

Knowing that, if we also take into account the complexity (or bloat,
whatever you may call it) that this change would impose on the
specification of the C programming language, essencially to bring nothing
relevant to the table, then one has to wonder where is the technical
justification to impose such a fundamental change.

There is no technical justification.

Mcrosoft corp doesn't like pthreads. Period.

The standards committee then, will publish a new standard that could be
accepted by microsoft.

Standards are just politics+money, technical issues are not really
important.

 

[Ian Collins]

Le 17/01/11 20:31, Rui Maciel a écrit :

There is no technical justification.

Mcrosoft corp doesn't like pthreads. Period.

The standards committee then, will publish a new standard that could be
accepted by microsoft.

Standards are just politics+money, technical issues are not really
important.

That's a very jaded view.

I haven't read the WG14 papers, but that does not appear to be the case
with WG21 (C++).

 

[Ian Collins]

There are quite a few on both ISO panels but C and C++ are separate
languages and they tend to be used in different markets.

But they do overlap and maintaining compatibility where they do is
sensible. For example see:

http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2010/n3137.html

"C and C++ Liaison: Compatibility for Atomics"

 

[Rui Maciel]

That's a very jaded view.

I don't know if that's the case with the new C standard. Nonetheless,
there is a fair share of standards out there who include absurdities which
were a product of political bickering. In the computing world, the sham
which was OOXML's standardization process along with all the corruption
that went with it is still fresh in many people's minds. In other areas,
such as CEN's Eurocode family of building codes, there are also a hand
full of such examples. For example, EN 1993-1 includes a couple of
versions of the same formula to evaluate the exact same type of structural
resistance that end up doing the exact same thing simply because, if I'm
not mistaken, the German and French representatives refused to adopt a
verification method other than the one they proposed. As a consequence,
EN 1993-1 essencially includes the same formula twice (minus som minor
details) due to nothing more than political bickering.

So, unfortunately this sort of stuff happens too frequently. And then we,
the ones who have an interest in following those standards, get to suffer
the result of those SNAFUs for years to follow.


Rui Maciel