Interview with Mr Stroustrup

[tm]

In message <[email protected]



What about VMS, MuCos, SAFERTOS, EmbOS, Sciopta, Integrity, ThreadX,
OSE, VXWorks, QNX, CMX, eCOS, OSEK, LynxOS, Nutrino, Nucleus, PikeOS
pSOS,Velocity and many others....

How many programs are ported to all this operating systems?
Which programs are ported to this operating systems and do graphics,
use Unicode filenames, read directories, wait for milliseconds,
position the curser in a console window and read single characters
from a console window without echo?
This are things that go byond what standard C provides.
So you need operating system specific functions to do this things.

Seed7 provides driver libraries for all this things. A Seed7
program can do this things and the programmer does not need to
think about the OS used. Seed7 is not a language where you are
forced to use operating system functions for such simple tasks.
Seed7 tries to provide an OS independend platform.

You can help to port Seed7 to one of this operating systems by
writing the driver libraries.


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 15/01/11 00:45, tm a écrit :

How many programs are ported to all this operating systems?

To VMS?

I -suppose none since it is quite dead. Digital went broke and was
bought by compaq. Then compaq was bought by hp. So VMS...

MucOs is an OS for avionics controllers. Yes, it supports real
time. I think the license is around 2.5K US$, so do not
expect a huge user community

Most of the others are the same.

 

[Chris H]

In message <[email protected]

How many programs are ported to all this operating systems?

Very little.

Which programs are ported to this operating systems and do graphics,
use Unicode filenames, read directories, wait for milliseconds,
position the curser in a console window and read single characters
from a console window without echo?

They all have their own systems for the above No one will use a new
system in ISO-C. It will be yet another non implimented part fo teh
standard.

Seed7 provides driver libraries for all this things. A Seed7
program can do this things and the programmer does not need to
think about the OS used.

Inefficient. Most of those systems have the functionality already built
in. No point in duplicating it. All that does is take space, time and
power.

Seed7 is not a language where you are
forced to use operating system functions for such simple tasks.
Seed7 tries to provide an OS independend platform.

So it will work on ALL the above OS? Otherwise it is not portable. So
far it is a specialised windows/Unix system.

You can help to port Seed7 to one of this operating systems by
writing the driver libraries.

Ok. Do you want do know my consultancy rates first?

 

[Chris H]

And MacOS.

Which is essentially BSD Unix

It's pretty good going. The restriction on compilers seems to be be to
do with having to provide specific makefiles for each.

No idea. Not used a make file in years. However that is nothing to do
with the code being portable.

What does it mean exactly to write a portable application in C? Surely
you can't expect someone (especially of free software)

The free part is irrelevant.

to test on dozens on different compilers and dozens of different
architectures? Who does?

Good point. Virtually no one. SO why is there al this crap about
portability. Particularly when most of these new features are going to
be of zero use on many MCU and OS.

This was C99's great failing. Things were added that were "cool" or
"neat" etc for a *FEW* people not the majority. Hence the near zero take
up of C99.

Testing on a small number of different systems I'd have thought would
at least show it's not tied to one OS, one compiler, one architecture,
a good prerequisite for portability.

Not at all. It means it is portable across a SMALL subset. You should
not add things that are not 100% portable to all or at least the vast
majority of compilers (and OS) otherwise you get another C99.... a
standard that no one uses.

And are there any good examples of sizeable portable C apps, that do
run on *all* of those architectures and compilers you mentioned? (And
if there are, my bet is they would largely consist of a mess of
conditional code, conditional makefiles and conditional scripts.)

There are some libraries etc that do. Yes they use conditional code but
it is all Standard C. some of the things you want to add could not be
implemented in compilers for many targets.

Remember the x86 market makes up less than 5% of the MCU's out there.
IAR for example make compilers for 35 targets (not x86) of the about 60
compilers we can supply (8-64bit) non are x86 and most would not want
threading.

BTW none of the 60 odd compilers are C99. Despite the silly claims by
Jacob all they do is implement a few/some features that customers want.
IF the industrial world really wanted C99 all the commercial compilers
would have had conforming c99 compilers by December 2000. Ie eleven
years ago.

 

[Nick Keighley]

Le 15/01/11 00:45, tm a crit :



To VMS?

yes, including VMS struck me as a bit odd

I -suppose none since it is quite dead. Digital went broke and was
bought by compaq. Then compaq was bought by hp. So VMS...

there ar still VAX/VMS emulators out there.I know of an application
that runs it's compiler on such an emulator

 

[tm]

In message <[email protected]



Very little.

According to your definition this are the only portable
programs.

They all have their own systems for the above

So portable programs need to use #ifdef or other forms
of conditional code to distinguish between this different
solutions.

Inefficient.

In todays programs there are many areas were performance
is wasted. In case of Seed7 you get portable Seed7
programs at the cost of a function layer in the Seed7
runtime library.

Most of those systems have the functionality already built
in.

So you need to change your program when you move to a
different operating system. Do you consider this portable
programming? Porting a program without changing it is the
key point: It is NOT necessary to change a Seed7 program
when you move it from Windows to Linux or between other
operating systems supported by Seed7.

So it will work on ALL the above OS?

No, but on the systems I mentioned already.

Otherwise it is not portable.

With your definition almost nothing is portable.
For nontrivial programs there will ALWAYS be an OS or
compiler that does NOT support the particular program.

So far it is a specialised windows/Unix system.

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.

Ok. Do you want do know my consultancy rates first?

No. Sorry to say, but there are people I would prefer,
when I have to pay them. But I always appreciate when
programming for an opern source project is done for free.


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.

 

[BartC]

So you need to change your program when you move to a
different operating system. Do you consider this portable
programming? Porting a program without changing it is the
key point: It is NOT necessary to change a Seed7 program
when you move it from Windows to Linux or between other
operating systems supported by Seed7.

There's the portability of Seed7, and the portability of the underlying C
code.

I would guess that Seed7 does 'portable' much better than C, where sometimes
a program has trouble working on the same architecture and the same machine
(or even with the same compiler, if exactly the right options and makefile
scripts are not used; I think these do form part of an application, even if
Chris H says they don't).

But then, there is only one source of Seed7; if other people created another
implementation, working from the same language spec, it would be interesting
to see whether the portability would still hold up.

Windows, Mac OSX, Linux, Bsd and Unix combined
probably cover 99% of the PC, Workstation and
Minicomputer market.

A few years ago when I was a proper programmer, 99% of *my* market was
Windows. Such hardware was available everywhere, it was cheap, and it was
popular. And most customers already had it. If they didn't, then many
customers would simply buy whatever we said they needed.

A few odd customers with Macs apparently got on well using a Windows
emulator. To the 1% (actually nearer 0.1%) who wanted Linux versions, we
just said no. (These days the figures would be different.)

So from that point of view, it's possible to simply not care about
portability. Someone (Chris H I think) said 95% of microprocessors in the
world are not x86. But so what?

If there is an advantage in porting an application from A to B, then it will
get ported. Writing it in the first place so that it will run on A, B, C,
all the way to system Z, means it will either never get finished, or it
would cost too much, or the quality would suffer.

 

[Keith Thompson]

This was C99's great failing. Things were added that were "cool" or
"neat" etc for a *FEW* people not the majority. Hence the near zero take
up of C99.

[...]

Then why is C201X, as least as of the current draft, keeping *all*
the features that C99 added, and making only a tiny fraction of
them optional?

The Foreword to the C99 standard lists 54 changes relative to the
C90 standard (if I've counted correctly). (A few were added by
C95, and a number of them are relatively minor.) The C201X drafts
we've seen so far propose to make only 3 of them optional (complex
types, VLAs, and <tgmath.h>); everything else is still mandatory.
That doubles the number of optional features; C99 already has
__STDC_IEC_559__, __STDC_IEC_559_COMPLEX__, and __STDC_ISO_10646__.
And of course most of the standard library has been optional for
freestanding implementations since C90.

It seems to me that the mandatory subset of C201X is much closer
to C99 than it is to C90. And of course the full C201X language,
with optional features enabled, is essentially a superset of C99.

Note that gcc, for example, already implements at least two of the
three newly optional features; if the gcc maintainers choose to
fully support C201X, they'll surely continue to support at least
those optional features. I suspect that most other almost-C99
compilers are in a similar position.

VLAs can be nice, but you can do the same thing with malloc() and
free(), with a little extra bookkeeping work (and the benefit of
being able to check for allocation failures, at least theoretically).

Complex types are useful for the relatively few programs that need
them, but they're really a niche feature. I haven't checked, but
I presume there are libraries that implement complex arithmitic in
C90, at the cost of losing a lot of syntactic sugar.

I'm frankly not sure I've ever seen the point of <tgmath.h>, other
than some minor syntactic convenience. If the machinery it uses
were available to user code, that might be a different matter,
but what's so hard about writing sinf() or sinl()? Perhaps I'm
missing something.

Meanwhile, all conforming C201X compilers will support long
long, <stdint.h>, mixed declarations and statement, // comments,
restricted pointers, compound literals, designated initializers,
inline functions, and dozens of other features that don't exist
in C90.

So what's the big deal? C201X, at least in the drafts we've
seen so far, is *not* going back to C90 and starting over.

 

[lawrence.jones]

I'm frankly not sure I've ever seen the point of <tgmath.h>, other
than some minor syntactic convenience. If the machinery it uses
were available to user code, that might be a different matter,
but what's so hard about writing sinf() or sinl()? Perhaps I'm
missing something.

If you decide you need more or less precision, changing the types of the
variables automatically changes the precision of the arithmetic
operators, but not the library functions (which are typically used
almost as often as the operators), so you have to search through all
your code and manually replace them. <tgmath.h> allows the library
functions to be as versatile as the operators.

And the C1X draft finally makes a similar mechanism available to user
code.

 

[Keith Thompson]

If you decide you need more or less precision, changing the types of the
variables automatically changes the precision of the arithmetic
operators, but not the library functions (which are typically used
almost as often as the operators), so you have to search through all
your code and manually replace them. <tgmath.h> allows the library
functions to be as versatile as the operators.

Ok, that makes sense.

And the C1X draft finally makes a similar mechanism available to user
code.

Hmm. Then I wonder what's the benefit of making <tgmath.h> optional, if
the mechanism is mandatory.

 

[Ian Collins]

It's quite possible to work on the definition of a programming language in
order to better support some features desired by some developers,
including those involved in developing libraries, without being forced to
bloat the standard by incorporating any definition on how exactly those
libraries should behave.



The question which must be asked regarding pushing a definition of a
particular library into the C standard is "why?" and not "why not?". Any
addition to a programming language must be thoroughly justified, which has
not been the case.

You've completely missed my point, so I'll say it again:

While they both support portability, some desirable features require
language support.

I'm talking the core language, not the library.

(I really which the standard was in two parts, the core language and the
standard library, so one could be updated without the other!)

Apples and oranges. There was no international standard that defined an
API to handle threads in C++.

Again, you miss the point.

 

[Joshua Maurice]

Apples and oranges.  There was no international standard that defined an
API to handle threads in C++.  Adding to that, although it was possible to
handle threads with the pthreads library in a C++ program, there were
always a few issues plaguing it's use, which forced the programmer to jump
through a hand full of proverbial hoops just to make things work.  

So, unequivocally the C++ programming language needed a dedicated standard
that defined a native C++ API for threads.  

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?

Unfortunately the C++ people
failed to follow time-proven best practices on how to implement libraries
and simply made the mistake of bolting this new C++ threads standard onto
the definition of the C++ programming language.

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.

 

[Sebastian]

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.

....for what exactly? Can you be more specific? What "core language"
features do we need for "thread support"? What *is* "thread support"?
Are we talking threads, mutexes, locks, condition variables only or
does it include support for lock-free programming/atomics? If you
include the latter in "thread support" I would agree that it's
probably a better idea to implement atomics with some sort of core
language feature / "compiler magic" rather than a library-only
solution for the sake of implementability & performance.

Cheers!
SG

 

[Marcin Grzegorczyk]

[on <tgmath.h>]
And the C1X draft finally makes a similar mechanism available to user
code.

Hmm. Then I wonder what's the benefit of making <tgmath.h> optional, if
the mechanism is mandatory.

AFAIK, MISRA wanted that because of potential undefined behaviour if
you, say, pass a pointer argument (N1256 7.22, footnote 273). But with
the generic selection construct in C1X, it's easy to write <tgmath.h> in
such way that this kind of mistake is a syntactic constraint violation,
so IMHO there is no benefit. In some sense, <tgmath.h> is optional
anyway -- for freestanding implementations.

I'll be surprised if __STDC_NO_TGMATH__ makes it into C1X.

 

[Niklas Holsti]

...for what exactly? Can you be more specific?

Hans-J. Boehm discussed the question in his 2004 paper "Threads Cannot
be Implemented as a Library",
http://www.hpl.hp.com/techreports/2004/HPL-2004-209.html.

The core of Boehm's position is perhaps shown in this quote:

"Library-based approaches to concurrency normally require a very
disciplined style of synchronization by multi-threaded programs.
Although we agree that this is appropriate for perhaps 98% of uses, we
argue that it eliminates some low-level programming techniques which, in
some cases, may be essential for obtaining any performance benefit from
multiple processors. In other cases, such low-level programming
techniques can be used to improve the performance of higher-level
library primitives, and thus provide pervasive performance improvements
for a large collection of applications. Thus, although these usage rules
are highly desirable guidelines, we argue that they are inappropriate as
absolute requirements in a world in which we need to rely on
multiprocessors for performance."

Boehm says that the problems he describes are being addressed in the
memory model being defined for the C++ standard. I don't of course know
if Joshua had the same issues in mind.

 

[Joshua Maurice]

...for what exactly? Can you be more specific? What "core language"
features do we need for "thread support"? What *is* "thread support"?
Are we talking threads, mutexes, locks, condition variables only or
does it include support for lock-free programming/atomics? If you
include the latter in "thread support" I would agree that it's
probably a better idea to implement atomics with some sort of core
language feature / "compiler magic" rather than a library-only
solution for the sake of implementability & performance.

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.

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

Second, IMHO, threading is such a complicated and inherent part of a
threaded language that it ought to go in language the standard. 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.

 

[Joshua Maurice]

Hans-J. Boehm discussed the question in his 2004 paper "Threads Cannot
be Implemented as a Library",http://www.hpl.hp.com/techreports/2004/HPL-2004-209.html.

The core of Boehm's position is perhaps shown in this quote:

"Library-based approaches to concurrency normally require a very
disciplined style of synchronization by multi-threaded programs.
Although we agree that this is appropriate for perhaps 98% of uses, we
argue that it eliminates some low-level programming techniques which, in
some cases, may be essential for obtaining any performance benefit from
multiple processors. In other cases, such low-level programming
techniques can be used to improve the performance of higher-level
library primitives, and thus provide pervasive performance improvements
for a large collection of applications. Thus, although these usage rules
are highly desirable guidelines, we argue that they are inappropriate as
absolute requirements in a world in which we need to rely on
multiprocessors for performance."

Boehm says that the problems he describes are being addressed in the
memory model being defined for the C++ standard. I don't of course know
if Joshua had the same issues in mind.

Yes. Thank you. I did have those issues in mind. Exactly that. Thanks
for linking to the paper which I'm sure can describe it better than I
offhand.

 

[Chris H]

This was C99's great failing. Things were added that were "cool" or
"neat" etc for a *FEW* people not the majority. Hence the near zero take
up of C99.

[...]

Then why is C201X, as least as of the current draft, keeping *all*
the features that C99 added, and making only a tiny fraction of
them optional?

Good Question... I would suggest it is to see if they can get the
optional idea to work. If it does they can make more optional in a TC
later.

It seems to me that the mandatory subset of C201X is much closer
to C99 than it is to C90. And of course the full C201X language,
with optional features enabled, is essentially a superset of C99.

Yes. Probably.

So what's the big deal? C201X, at least in the drafts we've
seen so far, is *not* going back to C90 and starting over.

No. It won't and can't. Not Everything in C99 was bad. Most compilers
have implemented parts of C99.

 

[Chris H]

In message <[email protected]

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.

Which is about 4% of the MCU market. PC's and Workstations make up a
VERY small part of computing. The average car has more computing power
than a PC. Never mind aircraft, ships, medicals etc etc

This is why there are over a dozen other OS and RTOS out there.

Your 99% market is less than 4% of the world market that uses c.
Incidentally each PC has several processors in it. (Keyboard, network
card, hard disks, CD drives, monitor, etc)

You are looking at a VERY small market overall. This is the market the
ISO -C standard has to look at. BTW the 8 bit MCU is still the most
widely used in the world.

No. Sorry to say, but there are people I would prefer,
when I have to pay them. But I always appreciate when
programming for an opern source project is done for free.

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

 

[Chris H]

So from that point of view, it's possible to simply not care about
portability. Someone (Chris H I think) said 95% of microprocessors in the
world are not x86. But so what?

The So what is that the ISO-C standard has to cater for the Global
market... or at least 95% of it

If there is an advantage in porting an application from A to B, then it will
get ported. Writing it in the first place so that it will run on A, B, C,
all the way to system Z, means it will either never get finished, or it
would cost too much, or the quality would suffer.

Agreed and in the vast majority of the world C is rarely ported. Seed7
is only "portable" between a very small minority of Windows and Unix.
(But that is all it needs) However it is a very inefficient system.

In Embedded systems they are engineered to work with the minimum amount
of cost, hardware and power. You usually want it as small and as
efficient as possible. You don't just add more RAM as that will cost
(the chip, the CAD, the PCB manufacture, larger Power supply etc) Ok it
is only 5 USD but we are making 200,000 of them. So it has taken 1
million USD off the profit line.

Less efficient.... means more power and more heat and more weight all
important factors in many systems.