Velocity Reviews - Computer Hardware Reviews

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

Reply
Thread Tools

Interview with Mr Stroustrup

 
 
Uno
Guest
Posts: n/a
 
      01-17-2011
On 1/11/2011 4:29 PM, Keith Thompson wrote:

> 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
 
Reply With Quote
 
 
 
 
Uno
Guest
Posts: n/a
 
      01-17-2011
On 1/13/2011 6:49 PM, James Kuyper wrote:
> 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)
--
Uno
 
Reply With Quote
 
 
 
 
Chris H
Guest
Posts: n/a
 
      01-17-2011
In message <(E-Mail Removed)>, Uno <(E-Mail Removed)>
writes
>On 1/11/2011 4:29 PM, Keith Thompson wrote:
>
>> 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.


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.



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



 
Reply With Quote
 
Joshua Maurice
Guest
Posts: n/a
 
      01-17-2011
On Jan 16, 11:52*pm, Uno <(E-Mail Removed)> wrote:
> On 1/11/2011 4:29 PM, Keith Thompson wrote:
>
> > 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?


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.
 
Reply With Quote
 
Rui Maciel
Guest
Posts: n/a
 
      01-17-2011
Joshua Maurice wrote:

> 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-lit....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/20...-2004-209.html
 
Reply With Quote
 
Rui Maciel
Guest
Posts: n/a
 
      01-17-2011
Joshua Maurice wrote:

> 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
 
Reply With Quote
 
Chris H
Guest
Posts: n/a
 
      01-17-2011
In message <(E-Mail Removed)>, Uno <(E-Mail Removed)>
writes
>On 1/11/2011 4:29 PM, Keith Thompson wrote:
>
>> 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?


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

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



 
Reply With Quote
 
Joshua Maurice
Guest
Posts: n/a
 
      01-17-2011
On Jan 17, 4:10*am, Rui Maciel <(E-Mail Removed)> wrote:
> Joshua Maurice wrote:
> > 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.


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.

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


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.

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


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.
 
Reply With Quote
 
Rui Maciel
Guest
Posts: n/a
 
      01-17-2011
Joshua Maurice wrote:

> On Jan 17, 4:10 am, Rui Maciel <(E-Mail Removed)> wrote:


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


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.


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


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
 
Reply With Quote
 
tm
Guest
Posts: n/a
 
      01-17-2011
On 16 Jan., 17:49, Chris H <(E-Mail Removed)> wrote:
> 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.


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


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