Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Interview with Mr Stroustrup

Reply
Thread Tools

Interview with Mr Stroustrup

 
 
Ian Collins
Guest
Posts: n/a
 
      01-16-2011
On 01/14/11 03:41 PM, Rui Maciel wrote:
> Ian Collins wrote:
>
>> Library support and core language support are two different beasts.
>> While they both support portability, some desirable features require
>> language support.

>
> 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.
>
>
>> Do you object to the threading support in the C1x draft?

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

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

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


Again, you miss the point.

--
Ian Collins
 
Reply With Quote
 
 
 
 
Joshua Maurice
Guest
Posts: n/a
 
      01-16-2011
On Jan 13, 6:41*pm, Rui Maciel <(E-Mail Removed)> wrote:
> Ian Collins wrote:
> > 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.

>
> 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.
 
Reply With Quote
 
 
 
 
Sebastian
Guest
Posts: n/a
 
      01-16-2011
On 16 Jan., 09:35, Joshua Maurice wrote:
>
> 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
 
Reply With Quote
 
Marcin Grzegorczyk
Guest
Posts: n/a
 
      01-16-2011
Keith Thompson wrote:
> http://www.velocityreviews.com/forums/(E-Mail Removed) writes:
>>[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.
--
Marcin Grzegorczyk
 
Reply With Quote
 
Niklas Holsti
Guest
Posts: n/a
 
      01-16-2011
Sebastian wrote:
> On 16 Jan., 09:35, Joshua Maurice wrote:
>> 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?


Hans-J. Boehm discussed the question in his 2004 paper "Threads Cannot
be Implemented as a Library",
http://www.hpl.hp.com/techreports/20...-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.

--
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
. @ .
 
Reply With Quote
 
Joshua Maurice
Guest
Posts: n/a
 
      01-16-2011
On Jan 16, 6:20*am, Sebastian <(E-Mail Removed)> wrote:
> On 16 Jan., 09:35, Joshua Maurice wrote:
>
>
>
> > 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.


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.
 
Reply With Quote
 
Joshua Maurice
Guest
Posts: n/a
 
      01-16-2011
On Jan 16, 7:01*am, Niklas Holsti <(E-Mail Removed)>
wrote:
> Sebastian wrote:
> > On 16 Jan., 09:35, Joshua Maurice wrote:
> >> 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?

>
> Hans-J. Boehm discussed the question in his 2004 paper "Threads Cannot
> be Implemented as a Library",http://www.hpl.hp.com/techreports/20...-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.
 
Reply With Quote
 
Chris H
Guest
Posts: n/a
 
      01-16-2011
In message <(E-Mail Removed)>, Keith Thompson <kst-
(E-Mail Removed)> writes
>Chris H <(E-Mail Removed)> writes:
>[...]
>> 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 Hills Staffs England /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/



 
Reply With Quote
 
Chris H
Guest
Posts: n/a
 
      01-16-2011
In message <(E-Mail Removed)
s.com>, tm <(E-Mail Removed)> writes
>On 15 Jan., 11:18, Chris H <(E-Mail Removed)> 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.


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.

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

>
>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 Hills Staffs England /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/



 
Reply With Quote
 
Chris H
Guest
Posts: n/a
 
      01-16-2011
In message <igsu3k$v2t$(E-Mail Removed)-september.org>, BartC
<(E-Mail Removed)> writes
>"tm" <(E-Mail Removed)> wrote in message
>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.



--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/



 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
ASP Interview Questions ASP Interview Questions reema ASP General 0 08-26-2008 11:57 AM
.NET Interview Question, C#, ASP.NET Interview Questions dotnetuncle Javascript 0 10-30-2007 03:08 PM
Interview with Stroustrup, Leaked. Russell Wood C++ 13 05-25-2006 07:45 PM
The Annotated C++ Language Standard by Koenig & Stroustrup???? Steven T. Hatton C++ 6 04-12-2004 06:05 AM
How would Mr. Stroustrup implement his solution to 12.7[2] Oplec C++ 26 10-24-2003 01:39 AM



Advertisments