Ask Bjarne Stroustrup, Inventor of C++

You can learn more about Bjarne Stroutrup here. Even though Bjarne isn't on your nightly news a lot (like never) he deserves (and gets) heavy respect from fellow programmers. If you have a question for Bjarne that he hasn't already answered on his FAQ page, please post it below. If you're a moderator, please moderate others' questions up or down, as deserved, which is just as important as actually asking questions. Tuesday afternoon (U.S. EST) we'll forward 10 selected questions to Bjarne. His answers are scheduled to appear Friday.

Comments

What do you program in besides C++?

[rambone]

What single language (besides C/C++) do you find yourself most productive in?

Java, after the hype

[rambone]

Now that the Java hype has cooled off, what is your assessment of its future?

Another Interview

[Edward Kmett]

Actually, seeing this brings to mind another 'Interview' with Bjarne that I saw a while back....

Interviewer: Well, it's been a few years since you changed the
world of software design, how does it feel, looking back?

Stroustrup: Actually, I was thinking about those days, just before
you arrived. Do you remember? Everyone was writing 'C'
and, the trouble was, they were pretty damn good at it..
Universities got pretty good at teaching it, too. They were
turning out competent - I stress the word 'competent' -
graduates at a phenomenal rate. That's what caused the
problem..

Interviewer: Problem?

Stroustrup: Yes, problem. Remember when everyone wrote Cobol?

Interviewer: Of course, I did too

Stroustrup: Well, in the beginning, these guys were like
demi-gods. Their salaries were high, and they were treated
like royalty..

Interviewer: Those were the days, eh?

Stroustrup: Right. So what happened? IBM got sick of it, and
invested millions in training programmers, till they were a
dime a dozen..

Interviewer: That's why I got out. Salaries dropped within a year,
to the point where being a journalist actually paid better..

Stroustrup: Exactly. Well, the same happened with 'C' programmers..

Interviewer: I see, but what's the point?

Stroustrup: Well, one day, when I was sitting in my office, I
thought of this little scheme, which would redress the
balance a little. I thought 'I wonder what would happen, if
there were a language so complicated, so difficult to learn,
that nobody would ever be able to swamp the market with
programmers? Actually, I got some of the ideas from X10,
you know, X windows. That was such a bitch of a graphics
system, that it only just ran on those Sun 3/60 things..
They had all the ingredients for what I wanted. A really
ridiculously complex syntax, obscure functions, and
pseudo-OO structure. Even now, nobody writes raw X-windows
code. Motif is the only way to go if you want to retain
your sanity..

Interviewer: You're kidding...?

Stroustrup: Not a bit of it. In fact, there was another problem..
Unix was written in 'C', which meant that any 'C' programmer
could very easily become a systems programmer. Remember
what a mainframe systems programmer used to earn?

Interviewer: You bet I do, that's what I used to do..

Stroustrup: OK, so this new language had to divorce itself from
Unix, by hiding all the system calls that bound the two
together so nicely. This would enable guys who only knew
about DOS to earn a decent living too..

Interviewer: I don't believe you said that....

Stroustrup: Well, it's been long enough, now, and I believe most
people have figured out for themselves that C++ is a waste
of time but, I must say, it's taken them a lot longer than I
thought it would..

Interviewer: So how exactly did you do it?

Stroustrup: It was only supposed to be a joke, I never thought
people would take the book seriously. Anyone with half a
brain can see that object-oriented programming is
counter-intuitive, illogical and inefficient..

Interviewer: What?

Stroustrup: And as for 're-useable code' - when did you ever hear
of a company re-using its code?

Interviewer: Well, never, actually, but....

Stroustrup: There you are then. Mind you, a few tried, in the
early days. There was this Oregon company - Mentor
Graphics, I think they were called - really caught a cold
trying to rewrite everything in C++ in about '90 or '91. I
felt sorry for them really, but I thought people would learn
from their mistakes..

Interviewer: Obviously, they didn't?

Stroustrup: Not in the slightest. Trouble is, most companies
hush-up all their major blunders, and explaining a $30
million loss to the shareholders would have been difficult..
Give them their due, though, they made it work in the end..

Interviewer: They did? Well, there you are then, it proves O-O
works..

Stroustrup: Well, almost. The executable was so huge, it took
five minutes to load, on an HP workstation, with 128MB of
RAM. Then it ran like treacle. Actually, I thought this
would be a major stumbling-block, and I'd get found out
within a week, but nobody cared. Sun and HP were only too
glad to sell enormously powerful boxes, with huge resources
just to run trivial programs. You know, when we had our
first C++ compiler, at AT&T, I compiled 'Hello World', and
couldn't believe the size of the executable. 2.1MB

Interviewer: What? Well, compilers have come a long way, since
then..

Stroustrup: They have? Try it on the latest version of g++ - you
won't get much change out of half a megabyte. Also, there
are several quite recent examples for you, from all over the
world. British Telecom had a major disaster on their hands
but, luckily, managed to scrap the whole thing and start
again. They were luckier than Australian Telecom. Now I
hear that Siemens is building a dinosaur, and getting more
and more worried as the size of the hardware gets bigger, to
accommodate the executables. Isn't multiple inheritance a
joy?

Interviewer: Yes, but C++ is basically a sound language..

Stroustrup: You really believe that, don't you? Have you ever sat
down and worked on a C++ project? Here's what happens:
First, I've put in enough pitfalls to make sure that only
the most trivial projects will work first time. Take
operator overloading. At the end of the project, almost
every module has it, usually, because guys feel they really
should do it, as it was in their training course. The same
operator then means something totally different in every
module. Try pulling that lot together, when you have a
hundred or so modules. And as for data hiding. God, I
sometimes can't help laughing when I hear about the problems
companies have making their modules talk to each other. I
think the word 'synergistic' was specially invented to twist
the knife in a project manager's ribs..

Interviewer: I have to say, I'm beginning to be quite appalled at
all this. You say you did it to raise programmers'
salaries? That's obscene..

Stroustrup: Not really. Everyone has a choice. I didn't expect
the thing to get so much out of hand. Anyway, I basically
succeeded. C++ is dying off now, but programmers still get
high salaries - especially those poor devils who have to
maintain all this crap. You do realise, it's impossible to
maintain a large C++ software module if you didn't actually
write it?

Interviewer: How come?

Stroustrup: You are out of touch, aren't you? Remember the typedef?

Interviewer: Yes, of course..

Stroustrup: Remember how long it took to grope through the header
files only to find that 'RoofRaised' was a double precision
number? Well, imagine how long it takes to find all the
implicit typedefs in all the Classes in a major project..

Interviewer: So how do you reckon you've succeeded?

Stroustrup: Remember the length of the average-sized 'C' project?
About 6 months. Not nearly long enough for a guy with a
wife and kids to earn enough to have a decent standard of
living. Take the same project, design it in C++ and what do
you get? I'll tell you. One to two years. Isn't that
great? All that job security, just through one mistake of
judgement. And another thing. The universities haven't
been teaching 'C' for such a long time, there's now a
shortage of decent 'C' programmers. Especially those who
know anything about Unix systems programming. How many guys
would know what to do with 'malloc', when they've used 'new'
all these years - and never bothered to check the return
code. In fact, most C++ programmers throw away their return
codes. Whatever happened to good ol' '-1'? At least you
knew you had an error, without bogging the thing down in all
that 'throw' 'catch' 'try' stuff..

Interviewer: But, surely, inheritance does save a lot of time?

Stroustrup: Does it? Have you ever noticed the difference between
a 'C' project plan, and a C++ project plan? The planning
stage for a C++ project is three times as long. Precisely
to make sure that everything which should be inherited is,
and what shouldn't isn't. Then, they still get it wrong..
Whoever heard of memory leaks in a 'C' program? Now finding
them is a major industry. Most companies give up, and send
the product out, knowing it leaks like a sieve, simply to
avoid the expense of tracking them all down..

Interviewer: There are tools.....

Stroustrup: Most of which were written in C++..

Interviewer: If we publish this, you'll probably get lynched, you
do realise that?

Stroustrup: I doubt it. As I said, C++ is way past its peak now,
and no company in its right mind would start a C++ project
without a pilot trial. That should convince them that it's
the road to disaster. If not, they deserve all they get..
You know, I tried to convince Dennis Ritchie to rewrite Unix
in C++..

Interviewer: Oh my God. What did he say?

Stroustrup: Well, luckily, he has a good sense of humor. I think
both he and Brian figured out what I was doing, in the early
days, but never let on. He said he'd help me write a C++
version of DOS, if I was interested..

Interviewer: Were you?

Stroustrup: Actually, I did write DOS in C++, I'll give you a demo
when we're through. I have it running on a Sparc 20 in the
computer room. Goes like a rocket on 4 CPU's, and only
takes up 70 megs of disk..

Interviewer: What's it like on a PC?

Stroustrup: Now you're kidding. Haven't you ever seen Windows '95?
I think of that as my biggest success. Nearly blew the game
before I was ready, though..

Interviewer: You know, that idea of a Unix++ has really got me
thinking. Somewhere out there, there's a guy going to try
it..

Stroustrup: Not after they read this interview..

Interviewer: I'm sorry, but I don't see us being able to publish
any of this..

Stroustrup: But it's the story of the century. I only want to be
remembered by my fellow programmers, for what I've done for
them. You know how much a C++ guy can get these days?

Interviewer: Last I heard, a really top guy is worth $70 - $80 an
hour..

Stroustrup: See? And I bet he earns it. Keeping track of all the
gotchas I put into C++ is no easy job. And, as I said
before, every C++ programmer feels bound by some mystic
promise to use every damn element of the language on every
project. Actually, that really annoys me sometimes, even
though it serves my original purpose. I almost like the
language after all this time..

Interviewer: You mean you didn't before?

Stroustrup: Hated it. It even looks clumsy, don't you agree? But
when the book royalties started to come in... well, you get
the picture..

Interviewer: Just a minute. What about references? You must
admit, you improved on 'C' pointers..

Stroustrup: Hmm. I've always wondered about that. Originally, I
thought I had. Then, one day I was discussing this with a
guy who'd written C++ from the beginning. He said he could
never remember whether his variables were referenced or
dereferenced, so he always used pointers. He said the
little asterisk always reminded him..

Interviewer: Well, at this point, I usually say 'thank you very
much' but it hardly seems adequate..

Stroustrup: Promise me you'll publish this. My conscience is
getting the better of me these days..

Interviewer: I'll let you know, but I think I know what my editor
will say..

Stroustrup: Who'd believe it anyway? Although, can you send me a
copy of that tape?

Interviewer: I can do that..

Re:Another Interview

[ucblockhead]

Well versed in programming languages but not particularly well-versed in real world programming. There is a reason while languages like C, C++ and perl are successful. It is a) because they don't tell you what you shouldn't do and b) do what you want them to do quickly. Changing C++ to meet most of that guy's criticisms would either mean keeping programmers from doing what they want to, or would make the language less efficient.

There is a reason why "academic" languages rarely make it out of acadamia. I remember the PC world in 1986. Pascal made it to the PC first. There is a reason that C became the language of choice on the PC rather than Pascal. It is because it is a practical language, not a language that follows what computer science professors think a language ought to do.

Standardized name mangling

[f5426]

Will/should name mangling be standardized so different implementations can coexist ?

Has OO run out of steam?

[rambone]

After twenty some years, its obvious that object-oriented programming is not a panacea. What are your thoughts on the future of the OO paradigm? What other paradigms do you see challenging it?

Re:Has OO run out of steam?

[dsplat]

After twenty some years, its obvious that object-oriented programming is not a panacea.

While I can't speak for him, I don't think Bjarne Stroustrup ever said that OO was a panacea. I'll speak for myself instead and give some of my own opinions on it.

I use OO in C++ regularly these days. However, because of the nature of the projects I have worked on, I have also worked with procedural code: legacy C code, a reporting language, shell scripts. I have also played a bit with generic programming. My conclusion is that the best paradigm for any problem is the one that leads to the simplest solution. OO is best when it elegantly expresses the problem domain.

I've seen some wonderfully elegant OO C++ code. I've written some good OO C++ code. And I have seen some truly awful inheritance hierarchies that seemed nearly bottomless, with methods inherited from ancestral classes 10 or 12 steps up the tree.

Back in the mid-80's I was told by an interviewer that I should give up my plans to become a programmer because 4th Generation Languages would make programmers obsolete. A decade and a half later, I am still writing code. The hard part is rarely the expression of the design in code. That is a skill, and an important one, but if it were the hard part of programming, then 4GLs might have made us obsolete. The hard part is analyzing the problem domain and designing the solution. C++ and OO are two tools for achieving the goal of working code and, judging solely from the amount of code written using them and their longevity, good ones.

Now, has OO run out of steam? No, not really. A more specific question might be: Now that a large number of programmers have been using OO for a while, or trying to, what have we learned about when OO is useful and when other methodologies are more appropriate?

Re:Has OO run out of steam?

[Arandir]

"Problems in software design are not solved by abstracting things away from the implementer. It amounts to hiding the dust under the carpet."

And excellent argument for abandoning C and sticking with assembly :-)

But you're missing the whole point of OO. If you have a problem that lends itself to OO abstractions, then it makes every bit of sense to use OO. Like it or not, every programmer uses abstractions. I mean, you not programming with just bytes still, are you? Thankfully, we now have bytes, chars, ints, uints, floats, and bools, as well as strings, arrays, sets, enums and structs. And there are a lot of problem sets that are easier to abstract to objects than to algorithms.

As a case in point, take a look at X programming and widgets. Qt is C++, and even though GTK+ is written in vanilla C, it still uses OO like abstractions. That's because it makes *sense* to think of widgets as objects. A pushbutton is more than just an area in memory 30-40 bytes long. If you need to make a toggle button, it makes more sense to start with a pushbutton than to rewrite every bit of pushbutton code from scratch.

I struggled for years with C. But with C++, I was more productive than ever after only three months. That's because C was a metaphorical hammer that made every problem look like an algorithm. But C++ gives me more choices in how I can break a problem down. With C++ I can choose between algorithm-oriented or object-oriented methodologies.

Re:Has OO run out of steam?

[Daniel]

One other place where object-orientation is particularly useful is in user interfaces; in your average interface (especially GUIs, but curses interfaces can have this too) you have absolutely TONS of places where you want to do objectey things.
Now, it's not necessarily object-orientation done in the C++/Java style (as a random example, GTK+'s signals don't map well at all onto that object framework) but it is almost always object-oriented to some degree.

Daniel

Re:Has OO run out of steam?

[Arandir]

"type differences? Sure, no problem with overloading in C++, but..."

C++ is much more strongly typed than C. Consider the following sample C program

main() {
char mid_initial;
int is_okay;
float your_wage;
if (mid_initial) {
printf("the result is %d", your_wage/is_okay);
}
return;
}

C++ for systems programming

[ajs]

C has long been the UNIX-world's systems programming language, and still remains that way. I know you don't like to compare C++ to other languages, so I'll just ask if you feel that there are any core reasons why C++ either does not make a good systems prgramming language or failed to capture the interest of the systems C programmers.

Re:C++ for systems programming

[sterwill]

My definition of "systems programming" includes the very lowest levels (right at task scheduling, resource management, interrupt services), all the way up to applications. Surely C++ has been used to write Windows applications, but I've never heard that it comprises most of the operating system proper.

The original poster asks a good question: is C++ more efficient for those lower-level things (things that would form an operating system kernel, or microkernel servers) than traditional languages (C and architecture assembly)?

--

Re:C++ for systems programming

[gorilla]

Doesn't this imply a bad design for COM, rather than anything about C++?

I've written Unix daemons in C, Pascal, Modula2, Perl and even Fortran.

Generally the Unix model of system calls works well in most languages, though some system calls are awkward in some lanaguages (select for example is hard in languages which can't do bit twiddling). I think that expecting people to program in their choice of languages is a good thing, and that os designers & implementers should make it as painless as possible.

Re:C++ for systems programming

[Tet]

Surely C++ has been used to write Windows applications, but I've never heard that it comprises most of the operating system proper.

Actually, as I understand it, Windows, BeOS and countless numbers of research OSes have been written in C++. As for whether it's a good idea or not, I don't know enough about it to have a valid opinion. Search the Linux-Kernel mailing list archives to see some of the arguments for and against using C++ for the Linux kernel.

Re:C++ for systems programming

[ajs]

is C++ more efficient for those lower-level things

Actually, the problem with C++ for systems programming is not efficiency (though there may or may not be problems there). The real doozy is that in C++ it is not only possible, but fairly well accepted practice to make it hard to tell what is being done by the most innocent seeming operations.

Take for example:


void foo() {
bar tmp;
}


Does that do anything? Well, it could. It could do a whole hell of a lot, in fact.

What about foo a = 0; foo b = a; ? How many memory coppies and/or allocations go on there? You have no way of knowing without looking at the implimentation of foo. Some of it you can tell just by looking at the method prototypes in the class being referenced, but those, in my experience, have not been the norm.

I use C when I need predictability. I use Perl when I want high-level. I use C++ when I need unpredictable low-level. :-(

Re:C++ for systems programming

[ajs]

COM = Component Object Model.

It is an inherently object-oriented technology so it should surprise no one that that it doesn't work well with a non object-oriented language.

Check out GNOME's component system (called Bonobo) for an example of a very reasonable object-oriented component system written in C.

And of course, because it's written in C, there are language bindings for C++, Perl, Python, Eiffel, ADA, Guile (scheme), Objective C and a few others that are not as well supported.

Compare this to the leading C++ based component system for UNIX systems (KDE) which has language bindings for C++. There were Perl and Python bindings once, but the last time I checked they were not being maintained (e.g. the links from the KDE site were broken). But even if we accept the two "phantom" bindings for KDE, that's it.

The problem is that C++ requires the programmer to bend his or her programming to the language design so completely that writing bindings for other languages can be a very daunting task. The C++ bindings for Gtk+ (gtk--) took a couple of weeks to create, and over the months that they have been around have become a very rich library that C++ programmers can feel comfortable with.

Of course, this results from solid design which is something that a lot of C and C++ libraries lack.

What would you do differently?

[spiralx]

If you could go back to when you designed C++, what would you change and why?

Re:What would you do differently?

[GnrcMan]

In Design and Evolution of C++ he gives very specific reasons why garbage collection is optional.

That is absolutely the book to read before asking Bjarne questions. (Yes, I realize this is not practical for everyone). It's a great book to read since it not only goes into some of the finer points of the C++ language, but it discusses the reasons behind the design decisions. Its an excellent book.

Casey

--GnrcMan--

Programing in the future

[Ibag]

What do you see as the next big thing in programing languages? Is there anything left to do except make the languages closer to english? Also, what current languages do you see as still being around in the future (as in 10 or maybe even 20 years down the road)? What accounts for this longevity?

Ibag

That's not the real interview!

[Marvin_OScribbley]

From the FAQ page:

Did you really give an interview to IEEE?
in which you confessed that C++ was deliberately created as an awful language for writing unmaintainable code to increase programmers' salaries?

Of course not. Read the real IEEE interview.


The real interview is here:

http://www.research.att.com/~bs/ieee_interview.h tml

Re:That's not the real interview!

[Accipiter]

That's why the original poster had the word "interview" singled out to imply sarcasm.

-- Give him Head? Be a Beacon?

Re:That's not the real interview!

[Roblimo]

Bjarne says he still gets e-mail about that fake interview. Not that it's in his FAQ. He's not humor-impaired, okay? I almost put in a link to it myself, but figured someone else would post it. ;-)

- Robin

Why no templated typedefs?

[Venomous Louse]

Well, this is weird. Just the guy I wanted to talk to this morning!

It would occasionally be handy to have typedef templates (or template typedefs?! help!), something like this:


template< class T >
typedef bool (* func)( const T &r );


. . . but that doesn't seem to be legal. I don't recall seeing anything about this issue in The Design and Evolution of C++. So what's the deal?

Question...

[MrHat]

I (and maybe most of "us") know you solely through your creation of the C++ language and your assistance in authoring the ANSI standard for said language.

Aside from this one (albeit major) project, what do you work on from day to day? What projects are you currently involved in? Do you have any more language definitions/standards in the pipeline?


43rd Law of Computing: Anything that can go wr

Re:Question...

[zorgon]

I second this question: More specifically, is there going to be a new creation from you such as a (C++)++ ?

"C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do it blows your whole leg off."

Two Questions

[Greyfox]

1) Did you design C++ because you thought programming was getting too easy and therefore a programmer could not demand the salary they once could when programming was done in machine language?

2) How would a language like Objective C, which is more Smalltalk like in design, stack up against C++?

Multiple inheritance

[MosesJones]

Three linked questionsquestions

1) Do you think that multiple inheritance is a requirement for a true OO Language

2) When designing a system with multiple inheritance what do you see as the pitfalls to avoid, especially when it comes to maintainability.

2) Do you know of anyway to simplifying the readability of multiple inheritance to enable first time users to do less damange.

Questions

[Edward Kmett]

Is there any hope for the introduction of constrained templates? Right now using templates is an exercise in willpower for the programmer. I know that constrained genericity went before the committee when templates were first introduced, but has there been any thought to revisiting that decision?

Another item that has gained a lot of momentum in the Eiffel community is Design by Contract, for which I would love to see a standardized approach in C++, but I doubt I'll ever see it.

Lastly, Bjarne, you were quoted once as saying 'When (not if) reference counting becomes available in C++ that it would be optional' (in a book on object oriented programming languages of which I cannot find on amazon at the moment to post the ISBN). Has much progress been made on the front of making reference counted objects available? Or has your thinking changed since you were quoted?

A quick question (ha!)

[jd]

C++ is an Object-Based, rather than a "pure" (in a Software Engineering sense) Object-Oriented language. However, it's still centered around the notion of objects, rather than procedures.

However, all existing processors are procedural, and there is no real concept of an OO CPU.

Do you feel that OO languages, such as C++, will result in OO systems, at the hardware level, or will it always be easier to confine OO thinking to the abstract, using extremely complex compilers to translate between OO and procedural paradigms?

Re:A quick question (ha!)

[Christopher H]

jd wrote:
> all existing processors are procedural

I would argue that existing processors are not innately procedural. Most support a 'state machine' style of programming even more directly. Nearly all instruction set architectures support efficient call stacks, which I guess you could consider a "procedural" feature, but C++ uses these processor facilities just as effectively as C does. A 'tuned for C++ chip' might trim a cycle or two from a virtual function call, but those are already cheap on existing architectures.

Unless you're suggesting hardware GC, heap management, or persistence, I believe that current processor architectures are well suited to stack-heavy OO languages like C++.

Digression:
with all that said, I remember reading about an object-oriented CPU designed by Linn ("Rekursiv"?), back in a mid-80s Byte magazine. It had hardware support for persistence, 40-bit 'object identifiers' rather than pointers, and was apparently used in a production system.

C++: too much?

[roystgnr]

The biggest complaint I hear about C++ (and agree with myself, depending on whose code I'm reading), is that it gives you enough rope to hang yourself, your company, and your close family.

Unfortunately, while it's easy to give a language new features without harming backwards compatibility, it's a lot harder to take things out. Are there any features that, in hindsight, you wouldn't have put into C++ to begin with? Are there particular features (templates keep coming to mind) that you would advise inexperienced programmers to avoid?

The 41-year old virgin wants to know...

[Anonymous Coward]

If I learn C++, will it make girls like me?

The future, simplicity and funtional programming

[Mr T]

Where do you see programming and languages going? C++ and Perl are both very rich in feature and complex and they seem to be running on less steam than some other more simple lanaguages right now, Java and Python seem to be the darlings. It seems like schools are all teaching java right now and C++ is becoming less of a resume feature than it was a few years back. Do you see a trend towards simplicity? Do you see programming becoming a a divided discipline (IS programming and then system programming, or something along those lines) with CS majors doing the heavy lifting with C++ and IS or non-CS type people doing other stuff with java or cool or something else that is much easier to learn.

Another question, how do you see funtional programming playing a role in the future? Do you think functional programming is an acadmeic fad or a niche market for special purposes like Ada is used for?

Is it done? Proprietary extensions.

[ucblockhead]

Over the course of the last ten years, we've seen some fairly significant changes in C++. Things like the addition of exception handling, templates, the standard template library. Do you think that things have now settled down, or will we see similar changes over the next ten years?

Also, as a Windows programmer, I spend much of my time grappling with imperfect implementations and proprietary versions of classes. As an example, most Windows programs seem to use the Microsoft specific CString rather than the standard std::string operator for strings. This can cause problems because of the poor way Microsoft has implemented their versions of some of these classes. Is this a problem that will continue to plague us, or do you see all vendors moving towards better support for the standards instead of proprietary APIs?

The FAQ list

[Tim Behrendsen]

I already see a lot of questions being asked that are already on the FAQ list, so here's a handy list, with links:

• How do you pronounce "Bjarne Stroustrup?"
• Can I ask you a question?
• What is the best book to learn C++ from?
• How long does it take to learn C++?

• Knowing C is a prerequisite for learning C++, right?
• Should I learn Smalltalk before C++ to become a real OO programmer?
• How do I start learning C++?
• Will you help me with my homework?

• Where can I get a free C++ compiler?
• You are Swedish?
• What's the best way to improve my C++ programs?
• Does it matter which programming language I use?

• Did the ANSI/ISO standards committee spoil C++?
• When will we have a C++ standard?
• Where can I get a machine-readable version of the standard?
• Are there any features you'd like to remove from C++?

• When will we have a new ARM?
• When will you publish a 4th edition of "The C++ Programming Language"?
• Should I buy the "Special Edition" of "The C++ Programming Language"?
• Is ``int* p;'' right or is ``int *p;'' right?
• What C++ compiler do you recommend? Which libraries?

• Is Java the language you would have designed if you didn't have to be compatible with C?
• Do you really recommend Ada over C++ for larger projects?
• Would you compare C++ to "some language"?
• Others do compare their languages to C++; doesn't that annoy you?

• You won't compare C++ to other languages, but you write diatribes about C++?
• C is better than C++ for small projects, right?
• Is C a subset of C++?
• What is the difference between C and C++?

• When was C++ invented?
• Why did you invent C++?
• Why doesn't C++ have garbage collection?
• Why is the code generated for the "Hello world" program ten times larger for C++ than for C?

• What do you think of EC++?
• C++ got its Object-Oriented concepts from Smalltalk?
• Is C++ an Object-Oriented language?
• Did you really say that?

• Did you really give an interview to IEEE?
• Why is the language called C++?
• Is the number of C++ users still doubling every year?
• What are you working on now?

--

Evolution of Programming

[dmccarty]

In the past, we've seen radical changes to codebases, especially in the x86 world. Basic to Pascal, Pascal to C, and C to C++. However, things have (IMO) stalled there. C is still widely prevelant in its portability and especially in embedded systems. And Java has failed to really take hold like everyone thought (or hyped) it would.

With that said, I wonder if you think that with C++ we've reached a stage where a vast set of computing algorithms has been predetermined and the programming model itself has been honed to a fine edge, or do you think that the future holds a bright spot for some new--or existing, such as Perl or Python scripting--language to enter the scene and change programming as we know it again?

-Daniel.

Extensions to C++

[Tronster]

Do you feel that 3rd party extensions to C++, such as Microsoft's ATL "attribute" constuct ( www.geocities.com/~chrisbe/Attribu tes.htm ), add or detract from the language, and why?

--

Standards and De Facto Standards

[chromatic]

What are your thoughts on languages and the standardization process? Looking at how long it took for C (and C++) to have standards set by ANSI/ISO, and how the most popular implementations are still so very incomplete (MSVC++, even GCC in some ways), one might ask, "Why bother?" Sun might be thinking something similar with Java.

Is it worth the time and the trouble to be able to create and to point at a sort of Platonic ideal while the rest of the world is chasing a poorly realized reflection of that ideal? What are the benefits of handing over the design of a language to the standards organizations instead of pushing forward with the design yourself (see Python, or Perl, or PHP for successes of the latter)?

--

C++ complexity vs. OOP simplicity

[hanwen]

[Sorry for the potential inflammatory matter in this question].

How do you relate the complexity of current C++ with the much-touted simplicity of Object Oriented Programming?

Longer explanation:

Over the years, the C++ implementation has ballooned; If I recall correctly, your book the C++PL has more than doubled in size. C++ has become a very large and complicated language, and I doubt whether there are any individuals (besides you, that is) that know the entire definition by heart, let alone teams of programmers.

This means that it is not practical to use C++ fully in any project, and one also has to set strict guidelines for a project what features to use and which not. Seen, in this light, it is doubtful whether C++ has made writing software more manageable. So I think, that as tool for writing better software more efficiently, C++ is a failure.

C++'s evolution was motivated by a few mottos (you don't pay for what you don't use, C compatibility, etc.), and seen in this light, C++ is a success. Do you think that these mottos need reconsideration?

Re:C++ complexity vs. OOP simplicity

[ucblockhead]

If you are looking at C++, take a look at java first. Because you can comprehend it..

That's just because you have more time to read the manuals while waiting for your application to run.

Eiffel and other languages

[barleyguy]

I realize that you like to avoid comparing C++ to other languages. However, how do you feel about the Eiffel language, and more specifically, what is your reaction to the negativity the Eiffel community seems to show towards C++? Have you ever met any of the founding fathers of other languages, such as Bertrand Meyer of Eiffel or the Sun Java people? If so, was it a positive experience?

Read _The Design and Evolution of C++_

[Venomous Louse]

The original poster asks a good question: is C++ more efficient for those lower-level things (things that would form an operating system kernel, or microkernel servers) than traditional languages (C and architecture assembly)?

Stroustrup's The Design and Evolution of C++ is a fun read, and it addresses that question. The intent was apparently that C++ would be as close as possible to the efficiency of C, and in fact that was something of a litmus test for new features: "Can we do this efficiently enough that C programmers won't make fun of us?" I myself don't know enough about that low-level stuff to be able to comment on the details. YMMV, etc. etc.

Dude, Scandinavian Battle to the Death!

[Anonymous Coward]

Okay, in a battle to the death between Linus Torvalds and Bjarne Stroustrup, who would win?

The C++ Programming Language and K&R

[Tet]

You say of The C++ Programming Language:

this book focuses on concepts and techniques and goes to some pain to be complete and precise.

In my view one of the greatest strengths of C is K&R, particularly the second edition. In addition to being both complete and precise, it manages to be concise at the same time. One of my major criticisms of your book was that it's unnecessarily wordy. In particular, it takes far too long to get to the first code examples. Having flicked through the 3rd edition in bookshops, it appears to be noticably better in this respect than my version. Was this a deliberate decision on your part, and if so, what prompted it?

How should compiler vendors implement templates?

[egnor]

Templates are one of the most powerful features of C++, and the standard library uses them extensively. However, they're very difficult to implement using the object file/linker system most compilers work with. Most current compiler implementations offer a set of more or less distasteful hacks, each of which has problems (long compilation times, large intermediate files, large output files, complex and fragile "repositories" that parallel the object files).

For example, the GNU C Compiler's FAQ includes an entry detailing the available workarounds. Other compilers are similar (in fact, the GCC FAQ entry makes reference to other implementations).

A number of development shops I've worked in have avoided templates precisely because of these problems, despite their benefits. Code reusability suffers as a result.

Presumably you didn't have this sorry state of affairs in mind when you were working on the specification. What did you imagine people would do? Abandon object files in favor of some other incremental-compilation scheme? (If so, what?) Are there any compilers that get this "right" in your estimation? In retrospect, would you have done anything differently to encourage compiler vendors to do the "right thing"?

Re:If true, this would have happened years ago

[jd]

Actually, the whole Processor-In-Memory philosophy would allow OO to make sense in hardware, as you could attach one processor to one object.

OO has had limited success, IMHO, because it's very difficult to have one foot in two different paradigms. Compilers aren't fitted with 7-league boots. But, to move into an OO paradigm requires the hardware to be structured to suit OO thinking.

In a traditional, central CPU, you have a data-stream going in, giving instructions and data. That's fine, for functional thinking, because it's a linear process. OO thinking isn't.

Processor-In-Memory would allow you to attach a processor to each object, allowing each object to be run independently. You can regard each object as being a seperate computer, almost, with each method being equivalent of a daemon. Your interface is simply how the "sockets" have been set up.

Done =THIS= way, your compiler doesn't try and linearise the logic. Rather, the compiler would compile each object seperately, and allow the processors within the memory to handle each object as a distinct unit.

If you'd be able to do it all over

[jilles]

.. and would ignore backwards compatibility with C, would the resulting language resemble C++? It seems to me (I mainly do Java) that a lot of language features in C++ are less then optimal and heavily biased to performance rather than usability. Templates come to mind but also such things as macros (eeeww).

I hope you won't put this question aside like you do with most question asking you to compare C++ with <fill in your language here>. While I imagine that the latter type of question must have become a boring one for you, the fact remains that C++ is now more than 20 years old and other languages might exist that address some domains at which C++ was once targeted, better. So rather than asking you to do that I would like you to describe what a modern language should be able to do compared to C++.

Re:If you'd be able to do it all over

[jilles]

Right now Java does not have templates. However there is a proposal to add parametrized classes to the language. Probably this feature will at some time be added to the language. From what I've understood SUN puts the following requirements on such an extension: it should be backwards compatible (both source and bytecode) and it should be usefull enough to justify the added language complexity.
As I understood, the template feature in C++ is far from perfect. In fact SUN would probably opt out on a similar to C++ template feature in Java.

Re:If you'd be able to do it all over

[jilles]

From this I conclude that the only purpose for macros is to cover up for language deficiencies. That is, you generally solve things with it that were apparently not easy to fix using pure C++.

Re:If you'd be able to do it all over

[TummyX]

bah, NOT. macros have an extremely useful purpose, and can do things functions can't normally do. You can like reduce the size of code by putting stuff in macros that can't be put in functions (eg. they use variables from your own function).

There are useful macros ...a few from windows that come to mind are MAKEDWORD, MAKEWORD, MAX, MIN and the unicode/ascii conversion macros A2W, W2A, A2T, T2W etc.

All reduce code, and is fast. I mean, who the hell would write a function to construct a DWORD from two WORDs - or a function to check MAX and MIN? You either have to resort to a function, or *ugh* maunally do it every time you need to.

MACROs ARE GOOD if you use them properly.

Something that comes to mind (that can't be done the same way with a function) is a macro i use when threading.

BEGIN_SYNCHRONIZED(x) and END_SYNCHRONIZED(x).
Basically I created a synchronization class, and the macros did the try/catch/finally part for me (making sure that the critical section was released if an exception occured). It reduced code bloat, and increased readablility. And it wouldn't take a genious to work out what the macros did after looking at the definitions for like a few seconds.

#define MAX(x, y) ((x > y) ? x : y)

mmm macros :P

Re:If you'd be able to do it all over

[jilles]

"All reduce code, and is fast. I mean, who the hell would write a function to construct a DWORD from two WORDs - or a function to check MAX and MIN? You either have to resort to a function, or *ugh* maunally do it every time you need to. "

What's against using a function? You can let it inline if performance is an issue. Functions are typechecked an checked for syntax errors. Macros are not type checked or syntax checked (at least not until the're expanded by the preprocessor after which it is no longer possible to pinpoint their location in the sourcecode).

Contrary to what you are thinking I think this way of using macros illustrates exactly the main problem with using macros. You make your code unreadable by using macros (where you could have used fucntions instead). You break encapsulation by letting your macros use private variables (why the hell did you make them private anyway). And finally you use them to prevent copy/paste style reuse (which makes me wonder if you could design your code to be more reusable).

Macros are a nightmare if you have to do maintenance on code. The fact that they are usefull in C++ only shows that pure C++ is too limited for ordinary use, which BTW was the reason for asking the guy who created C++ what he thinks is missing from the language or could be done better.

Re:If you'd be able to do it all over

[TummyX]

How exactly does using a macro become more difficult to read than using a function?

Explain.

Compilers

[Zorikin]

Even if you won't recommend a compiler, will you at least tell us which ones you use? How do you decide which compiler is right for a specific purpose? What do you see as the strengths and weaknesses of the various compilers?

C++ Implementations

[schani]

How do you feel about the fact the fact that there is not one C++ compiler in existance that implements the whole C++ standard?

bye
schani

Could you point me at those classes?

[rambone]

I'd love to check them out if just for interest.

Re:C++ a heap of crap

[bero-rh]

C++ is the shittiest language ever Really? If you had said "C++ isn't good for system programming", I might agree, but what's wrong with C++ for GUI programming? Have a look at, for example, the KDE source - it's C++, it's readable, it works and it's reasonably fast. If you look at other UIs written in plain C, say GTK/GNOME, you'll notice that many of them actually reinvent some C++ ways. (Yes, I know the difference, but GTK_WIDGET_NEW(a); really isn't much different from QWidget a();). Which language would you pick for creating a GUI? (And why?)

What comes after C++?

[zCyl]

I'm quite fond of C++, but obviously it will eventually be replaced by something much greater. As an established language expert, what elements do you think will be found in the next great language? And are there any existing languages that you think are close to this level?

Reaction toward C++ bashing?

[Junks Jerzey]

Even among programmers who use C++ on a daily basis, there seems to be no shortage of people willing to express varying degrees of distaste for C++. This is similar to the popular dislike among some programmers for Microsoft Windows, in that the loud and frequent negativity doesn't have much of an effect on overall popularity. Do all the jokes and complaints about C++ bother you at all?

Also: Why no "realloc( )" for new[]/delete[]?

[Venomous Louse]

Something like operator renew[] would be useful. I often still use malloc()/free() because I get to use realloc() with those. Still, if I've got an array of class instances, I'm S.O.L. Granted, operator renew[] would be inefficient and it would require copy constructors on everything, but C++ generally assumes that the programmer has enough sense to come in out of the rain. There are other "caveat user" things in the language already: Take for example pure virtual functions, which a naïve programmer is perfectly free to call in a base class constructor. This would just be another one of those (though you might say there are too many booby-traps already :)

Certainly one could approach this by overloading operator new[] and operator delete[] and writing an operator_renew() function template using placement new /placement delete , but that would be tedious and goofy. You'd have to write your own allocator.

Biggest misfeatures, surprise wins?

[Tom7]

During the design phase, it's difficult to forsee all the issues that will occur in the final implementations (and when the language is put to use).

What were the biggest misfeatures of C++ (things which added little useful functionality but which make compiler implementation/use/efficiency more nightmarish?)

On the other hand, what restrictions or concessions turned out to have surprising wins in the same categories?

Metaobject Protocol for C++

[nonya]

I've been playing around with OpenC++, C++ with a metaobject protocol and I find opening up the compiler in controlled ways like this to be very powerful - and more than just an academic toy. It would allow me to extend C++ in interesting ways to include Delegation (useful for the "Decorator" pattern) and multi-dispatch (useful for the "Visitor" pattern) - along with other interesting extensions (before/after methods, persistance, etc.). I know you considered and rejected both of these features in C++ (if I remember from "Design and Evolution of C++" you rejected Delegation because users found it confusing and you rejected multi-dispatch because it required too complex a linker[1]). I am not questioning your rejection of these features, but I would be interested in your option of a metaobject protocol for C++, which would allow me to add features like these to C++ so it is a closer to my designs. Did you consider a metaobject protocol for C++, and if you did why did you rejected it (too immature? too hard to maintain code? not useful enough to justify the complexity to the language?)

-Scott
nonya_cpp_question@yahoo.com

[1] I should mention my version of Multi-Dispatch doesn't solve the linker problem, it requires you call a function at the start of a program to initialize some tables of pointers to member functions.

I think it should be obvious

[Greyfox]

That girls don't like C++. So what programming language is most likely to get you some?

References not visible in calling context

[Signail11]

Why was the decision made not have have references visible as parameters in the calling context of a function call?

Re:References not visible in calling context

[Signail11]

No, it doesn't.
1) void foo( Bar bar );
2) void foo( const Bar& bar );

foo in 1 and foo in 2 cannot be overloaded because their formal parameters types are identical. This is not a problem; no compiler can reasonably disambiguate the function calls at compile time or even run time for that matter. What I'm thinking of is that there is no way to tell whether an arbitrary function call (ie. foo(x)) is passing a value or passing by reference by examining the context of the point at which the call is made.

Hey...

[Greyfox]

Sounds like one for MTV's Celebrity Deathmatch. Lets throw Bill Gates in there, too. I'm sure that given the design goals of C++ (Higher salaries for programmers) Bjarne can't be too happy with Visual C++...

The Question one should ask then is

[Raindeer]

What is your opinion on this fake interview?

Smaller & Cleaner

[SEE]

You said, in "The Design and Evolution of C++" (p. 207), "Within C++, there is a much smaller and cleaner language struggling to get out."

Do you still beleive this? If so, is it likely that such a language shall be created within the forseeable future?

Steven E. Ehrbar

Re:Smalltalk - dead for a reason

[Greyfox]

Funny, that doesn't seem to be doing much to stop Java...

What do you think of TMP?

[Davorama]

What do you think of template meta programming? Do you consider it a boon, enabling clever programmers to do outrageously cool things like the Blitz project? Or is any benefit derived from it's use washed away by the obscure, nearly unreadable code it takes to implement it?

Questions for Bjarne

[scherrey]

I was introduced to the C++ language in 1989 on the BIX online service by you and Greg Comeau whereupon the both of you set out to demonstrate (and finally convinced me) that this OO stuff wasn't just a fad and that C++ was a language that could efficiently implement it. This was during the time when Computer Language magazine had there "Language of the Month" feature article so languages had a tendency to come and go quickly back then.

As I recall, the two major goals that you stressed were a) to build a language that could get a handle on these huge projects that C was having difficulties with and b) to provide a balance of features and efficiency so that a developer should have to pay for features he doesn't use.

From my own experience using C++ in an extreme variety of projects (including very cramped embedded systems and large, multi-platform enterprise systems), there's no doubt that the great progress has been made on the first goal and that the second might have been fully achieved.

The biggest disappointment to me, however, has been the lack of ability to fully replace plain-old-C in system level development which is an area that stands to gain the most from the language's abstraction features and your stated goals of the language. I understand that early on, it would have been impossible to define standard ABI's since implementation techniques for things such as virtual method and inheritence resolution were very experimental. Now that a full decade has gone by and a surprisingly strong standard has been produced, these differences in implementations are more contrived than based on architectural considerations.

Presently the Open Source movement is growing wildly in popularity in commercial and non-commercial segments of the industry. Unfortunately, C++ cannot be used to provide linkable API's without either downgrading to severaly limiting C-based linkage or forcing everyone to use the same compiler that wants to call your library because of non-standard representations of structures and calling conventions.

Do you think that standardized application binary interfaces should be a priority time now? If so, what should be the mechanism used to define these interfaces (defacto vs. formal standards, etc), who should do it, and what can be done to encourage this development?

Beyond this issue, what are your personal priorities and hopes for the C++ language now?

Hmmm, right . . .

[Venomous Louse]

. . . and the STL probably does it with placement new/delete and writing their own allocator. In fat, I seem to recall that placement new and placement delete were added at least partially to keep Stepanov happy . . .

I guess the implications may well be weirder than I think they are, but it still seems kinda constricting. One question is this: Is it guaranteed that a pointer to item zero in a vector<foo> is in fact a pointer to a contiguous block of memory holding an array of foo? People still have to interact with old C libraries, and people can (and do) derive classes from old prehistoric structs. If I've got a vector of foo, and some function expects a pointer to an array of a struct from which foo is derived (with no additional data members -- I wasn't born yesterday :), where does that leave me? Stroustrup 3 ed 16.3 is not helpful. If std::vector does, in fact, guarantee the above, I'll be a happy camper. I'd also stop and think next time I called erase() on one of 'em :)

Re:Hmmm, right . . .

[Venomous Louse]

I can't see how to implment it with the time-complexity requiremnts demanded without it being an array (plus a little bookkeeping).

Yeah, I can't think of anything either (not that I'm an algorithm guru by any means). Still, I'm down with the idea that the interface should be guaranteed, but not the implementation.

why don't you take the SGI STL vector class, rename it, and use it.

Uhhh, good question :)

Computer Security and Language Design

[Effugas]

Bjarne:

First, let me take this opportunity to thank you for offering the Slashdot community this chance to interview you. It is highly appreciated!

As I'm sure you're well aware, computer security has risen to the forefront of risks involved with online business(even beyond "nonexistent paying customers"!). From the external risks of network protocol weaknesses to the internal failure of insufficient buffer overflow prevention mechanisms, the number of "weakest links" available to fall against a determined attacker can be quite staggering.

In fact, an attacker is often not necessary to make code fall flat on its face--as many computer users can attest to, software written under several software paradigms falls apart in the face of extended but ultimately normal usage.

My question for you is, as a well respected language designer and programmer, what can we as a community do to deal with these sibling demons of instability and insecurity? Should we adopt languages such as Ada, which place breathtaking amounts of protections into the compile-time phase? Do we move towards the model of simplicity advocated by Schneier, well aware of the exponential increase in unpredictable interactions? Should we worry about the prevalence of interpreted languages as a vector for in-band attacks? What should we be doing that we aren't?

In short, Bjarne...Where To, Fearless Leader?

Yours Truly,

Dan Kaminsky
DoxPara Research
http://www.doxpara.com

very important question...

[hemos.]

Do you think that articles by Jon Katz are retarding America's youth?

Perl, Visual Basic, Python, Tcl...

[jabbo]

Assuming that C/C++ is going to remain the One True Systems Programming Language for a long time, I have a question that is purely opinion-based but cries out for your personal opinion as the designer of C++. What scripting language do you feel most closely matches C++ in spirit and implementation? Do you use any of them yourself, to hack together prototypes over larger bodies of code? Do you feel that any of them are advancing the practice of programming in general?

I noticed in Kernighan & Pike's latest book ("The Practice Of Programming" I believe it is... I gave a copy to a coworker whom I enjoyed sharing a project with) that they give several examples in Perl and Awk, in addition to C, C++, and Java. (I'm going to ignore Java for the time being; I have written plenty of Java code but I feel more confident that C/C++ will run where I want and need it to, plus it's easier to integrate with existing libraries IMHO). What are your feelings on this trend, as evidenced in my application arena by such projects as the mod_perl API to Apache and the AOLserver Tcl API? It may be unnecessary for me to note that Perl seems to be closest to C++ in the way it allows great flexibility (and lets you "blow your whole leg off" ;-)), but you would certainly be a better judge than I!

I looked through your FAQ and didn't find anything resmbling this question; the folks at Reliable Software convinced me that the STL offers most if not all of the functionality of Perl to a C++-only programmer, but in my experience it wasn't really an apples-to-apples comparison (nothing beats Perl for text processing, for example). Nonetheless I'm sure that you have some insight as to how well a pure-C++ vs. scripting-and-systems-programming approach scales in large projects.

Anyways, that's all. OOP seems to make my life easier, but user-centered design and rapid prototyping (or just rapid programming) tools like Perl are equally important to getting things out the door. I wondered what you thought of this phenomenon and which tools you select for your work.

Older compilers

[jesser]

There are a variety of old C++ implementations floating around on the web and on CDs. I do not recommend an old C++ compiler for learning C++ or for new production use. There is little gained by fighting your way through bugs that have been fixed years ago or limitations that have been lifted years ago by the standard committee.

IMO Borland 3.0 is still one of the best compilers out there. It doesn't have a whole lot of proprietary commands, it has very readable help files, and it's fast. Newer compilers do stupid things like automatically initializing ints to 0, making it extremely hard to port to other compilers (you get a compiler error if you try to use clrscr() on microsoft, but your program is totally screwed if you accidentally use the initialize-to-0 "feature" of msvc 6 and try to run it on msvc 5.)

--

Future of safety and fault isolation in C++?

[jetson123]

Empirically, large C++-based software systems and component software (including COM/VBX/...) still frequently crash with pointer errors. Even more worrisome are problems where software faults in one module cause incorrect results in another module without actually causing a runtime error.

Unlike Ada or Java, C++ currently has no facilities that allow a programmer or software engineer to ensure that a fault (e.g. a pointer error) in one component does not cause errors in another component (the facilities that C++ has are advisory).

The traditional answer has been to use better overall software engineering and design. But that does not work in a world in which components come from various different sources with different standards and coding conventions.

Java has many problems, but it does have a commitment to runtime safety and fault isolation. And Java's promise really works out in practice: we can combine dozens of independently developed components and trace any software faults to specific components reliably. We'd like to have the safety and decomposability of Java with the efficiency and control of C++, but given the choice, safety and decomposability usually win out for day-to-day applications for us.

So, what does the future hold for C++ runtime safety and fault isolation? Will future C++ standards mandate more facilities than exist right now? If not, how do you think C++ can survive in a world where software is composed of hundreds of independently developed components?

bigger standard library

[posinaga]

Why not to include a bigger 'operating system abstraction' in the C++ standard library? This is the way to get into the true 'component software development process'. Currently if I want to get some C++ library that do need networking it HAS to relly on another library that do networking and that surelly will depend on a specified OS... I cannot find first order components for C++; they are all second or third order; and we know what this kind of things imply... plataform dependecy. Why not to include, let say, POSIX for example into the C++ standard library? I know, C++ is intended to run on the smaller computer ever build, but it was also C and the 'file' abstraction that days was also a big step. I think it is time to expand the standard library; we need to relly on a bigger 'operating system abstraction' to let the component stuff emerge; as I see it's happenning in the Java world.

Why Is There a CPAN but No CCAN?

[Chris Siegler]

That was the title of an op-ed posted at DDJ a couple years ago.

CPAN is a collection of free, downloadable modules that can be use'd in your Perl programs. It's a wonderful resource and the true strength of Perl. Code gets written once and used and tested by many. Over time the modules just get better tested and more robust. Everybody wins.

Why doesn't an equivalent CCAN (Comprehensive C++ Archive Network) exist if C++ truly is reusable?

C++ for work, C for play

[Chris Siegler]

OpenSource programmers can write code in whatever language they want. Consequently, they write a lot of C, Perl, and Python. But with some notable exceptions, they don't write C++.

Contrast that with the lanuages programmers use at work, which are primarily C++ and Java.

It can't be entirely explained by the size of the programs written either. And as your FAQ says in the section C is better than C++ for small projects, right?, you believe that any C program can be better written in C++.

So why the disparity then?

Re:C++ for work, C for play

[Animats]

This may reflect the fact that the open-source tools for C++ aren't very good. gcc isn't up to the current C++ standard. Even gnu indent doesn't parse C++.

Template-Orientation vs Object-Orientation

[VonKruel]

Parameterized types (templates) and OO are two rather different ways of writing generic code. With templates you re-use an external interface (e.g. copy constructor, assignment operator, etc. in the STL). With OO, polymorphism (via dynamic binding) is exploited to achieve re-use.

Templates have these advantages:

• compile-time type safety
• performance (no dynamic binding - function calls can often be expanded inline, avoiding a function call altogether)

OO has these advantages:

• simpler programming - you can get some extremely long compiler errors when working with templates
• less code bloat
• it seems unfortunate for so much code to be in header files instead of .cpp files (circular #include's can be fun)

The craziness over template-orientation seems counter-productive to me. Templates are a great feature of C++ and they are the only reasonable way to solve some problems in C++. However, many now seem to think they should be used to solve every problem. I agree that compile-time type safety is a Good Thing, but are we making an intelligent decision given that:

• dynamic_cast allows safe downward casting in an inheritance hierarchy
• Moore's law is still going strong : most people writing application software really do not need to obsessively count CPU cycles any more - choosing the right algorithms is more important than an O(1) improvement. Was it Knuth who said "premature optimization is the root of all evil."?

CPU cycles are becoming more and more plentiful whereas talented designers and programmers are not. Template-orientation seems to make the wrong trade-off. I know that TO and OO can be used together in one program, but they are very different ways of achieving re-use. When should one be favoured over the other?

Two questions

[XenonOfArcticus]

Let me say that while I don't think any language is perfect, and C++ certainly isn't, I use it heavily on a daily basis, and I can't imagine being without it.

I look forward to any successor languages and tools, as I'm painfully aware that our choice of language greatly impacts the techniques and results we are capable of framing.

I have a number of years experience of becoming comfortable with the core features of C++ (and some more esoteric bits). I've avoided common use of templates/exceptions because of portability and implementation fears. I think my first question has sort of been alluded to already, but I'm going to restate it in my words in case I'm misinterpreting others questions:

• I have found virtual functions and large amounts of multiple inheritance to be very helpful in designing diverse categories of objects that often need to be operated on (in many ways) by callers who need not (and hope not to) know the exact type/class of the objects they manipulate. Our current solution with a base class with many virtual functions makes the task delightfully simple for the callers, at the expense of increased storage for the virtual function pointers. I find a desire for a technique of funneling multiple methods through a single base class virtual function and then dispatching them from there in the derived objects. (Eg: Windows MFC message crackers, Amiga MUI method dispatchers, possibly Objective C if I understand it correctly.) Obviously like most OO techniques, you can implement this yourself without support from the language, but as C++ itself has proved, OO techniques are much easier and more robust when the language/compiler supports them.

  Do you feel this is a significant enough technique that it would be considered for future languages (C++ derived or not), or is there a good way to accomplish this in C++ now?

• You say in your FAQ that you are "looking for fundamental ways of improving the tools and techniques we use to build large real-world systems." Do you foresee a move away from the plain flat-text files, text makefiles, dumb text preprocessor includes, text parsing and the errors/ambiguities it entails, towards a smarter edit/build environment capable of more intelligently managing code/files, minimizing recompiles, easier incremental compiles, etc? As much as I like the flexibility of being able to manipulate flat-text source with a wealth of editors and tools, are we holding ourselves back by doing so?

Keep up the good work.

Should C++ be the basis for Universal Syntax?

[forkspoon]

How do you feel about C++'s development into a template for a universal syntax for other languages? Is it appropriate to continue using C++ as a guide for other languages? Java, JavaScript, Perl, and many other languages have parts or are comprised almost entirely from C++ syntax. Should this trend continue? Thanks, Travis forkspoon@hotmail.com

Natural Language Languages

[__aaedhn419]

Modern computer languages seem to have smaller lexicons and more abstraction - making them easier to learn. In the future, a voice controlled editor and an advanced language could allow computer programs to be written in limited natural english*.

In other words, a computer program could be written to be understood by any English* speaker, with hopefully decreased training time and improved teamwork.

Do you foresee any possible use for a "natural" programming language?

*English is my first choice since I speak it; other people may differ.

C++ and Education

[Herbmaster]

It seems to me that a lot of the programmers who prefer C++ do so mainly because C++ is what they were exposed to in school, rather than other programming languages and other systems of OO programming. The reason I've learned C++ (rather than simply C) is because my university decided that C++ would be a good language to teach students in the process of teaching computer science. This is an interesting choice, to say the least. Besides all the difficulty of the strict memory management required by C, many introductory computer science students struggle with C++'s implementation of templates and operator overloading - two programming models which seem to complicate the language a lot without adding much in the way of new functionality or useful structure.

Where do you see C++ in relation to education and it's role as a student of computer science's first programming language?

Why?

[Kythorn]

In the name of God, WHY? For the love of all that we hold sacred and holy, WHY?!?

Garbage collection?

[David A. Madore]

One of the the features that C++ can be said to lack, as a high-level language, is a garbage collector. Or rather, it's not so much that no collector exists (the Hans Boehm conservative C/C++ garbage collector is one, after all) but the fact that it isn't well integrated in the C/C++ API.

Do you regret this? Do you think someday we'll have a decent programming language with a garbage collector (i.e. one which is well integrated in the language and not just an add-on)? Java might have been just that only its eficiency (notably that of the GC) was terrible: do you think that was a necessity or just a consequence of the wrong decisions being made?

C++ Not so OO

[Coward Anonymous]

Was there no way to avoid having private members (data and methods) of a class in the main definition of a class?
One of the ideas of OO is information hiding and encapsulation of implementation details.
Private data members declared in a class definition used by external objects runs counter to these OO concepts. Other objects are supposed to be "blind" to the inner workings of the object and yet see private methods and data members.
IMHO it is also a major hassle in the earlier stages of a new project or new additions to a project, when changes in the inner workings of classes are frequent.
I realize that part of the problem is the need to know the size of the object for memory allocation purposes.
Did you think of this contradiction when designing C++ and were there any attempts at solving it?

future library

[Greg_Girty]

Do you want to see anything added to the standard C++ library that is not already there? (For example, a standard set of design patterns.)

Along the same lines, do you think sockets and graphics should be standardized as part of a language?

Java -> x86

[Chris Siegler]

Most programmers that I know prefer Java, the programming language, over C++. What they dislike about Java is the VM and bytecodes slowing everything down. Hence my question

Will ahead-of-time Java compilers, like GCJ for instance, eventually be able to produce machine code comparable in speed to compiled C++?

The problem I see so far is that on the Java side there is the problem of making exceptions faster, which are notorious for slowing down C++ code. And Java has to deal with garbage collection, which you say in your FAQ can be added to C++. Yet, despite its obvious benefits, nobody seem to do.

Tools and techniques to build large real-world...

[randomshiznat]

In your FAQ, you say that you are working on "fundamental ways of improving the tools and techniques we use to build large real-world systems."

That's been on your FAQ for at least 3 years now. What can you tell us about this work? What have you found?

The Future. No more reinventing?

[Ektanoor]

You are one of those who "reinvented" a language. And you made a fundamental move by giving macro-assembler C style the true aspects of a language. In one way you were not alone. Somehow your move was made in a time when several languages tried to turn "objective" or "procedural". It was a great move that gave programming languages a property of high flexibility.

Than there was a big gap. And suddenly we had Java. However there was nothing fundamentally new on it. Theoretically I mean.

What do you think about this? Have we reached a theoretical limit in the technological bounds of modern computing? Have "theoretical" programmists lost their "inspiration". Or have we reached "Finis Terra" of the programming sciences?

Re:Embrace and Extend

[Arandir]

Embrace and Extend. It's what condemn Microsoft for doing. Embrace a standard, then extend it so no one else can use it without you.

Yet this is precisely what glibc is doing. It's taking a language and library that is firmly standardized, then adding its own extensions, so that developers end up being locked into the GNU toolset. I tried to compile a program that other day on Solaris. It failed miserably because it depended upon GNU extensions to the "standard" C library. Sure I can load up glibc to run it, but why should I when I've got a perfectly capable and standardized libc? GNU libc tries to be everything including the kitchen sink (sound familiar?).

GNU would do everyone a lot better if they kept their extensions separate from the standard.

Performance issues with C++ objects

[CodeShark]

I have read that the processor overhead associated with objects keeps C++ from being "speed competitive" with tightly coded C or more especially with Fortran.

What is your opinion on this alleged "speed penalty", and do you think future versions of the language and/or compiler technology will be able to reduce or eliminate it?

Comments on Werther and Conway's C++ resyntaxed?

[King Babar]

C and C++ share a declaration syntax that, I think it is fair to say, is an acquired taste at best. Damian Conway, an OO programming researcher in Australia has published papers on a Modest proposal to resyntax C++ with a graduate student of his, B. M. Werther.

The result was a language with C++'s semantics (at that time) and a much cleaner syntax. Which, of course, went nowhere. Do you have any comments on SPECS itself or any other attempts to improve what might be called the "human factors" aspects of the C++ language?

Re:Who cares? GC doesn't belong in C++.

[Y]

making garbage collection standeard in C++ would be that it would reduce the language a bit by forinstance forbidding typecasts between pointers and integers

You lost me there. Why would garbage collection prohibit that?

At the basic machine level, everything in the computer's memory is just bits. As such, a garbage collector, without having some sort of memory markup, cannot tell if a memory address holds a value or a pointer to another address. One of the better forms of garbage collection is copy collection, which just reaches the memory currently being used - all other memory is ignored. It does this by following pointers. I believe Java implements this form of GC. If the garbage collector can't tell if a memory address holds a pointer or a value (as is the case with C++, which will allow all kinds of crazy casts), it can't know if the data it's looking at is needed or not.

As it is, garbage collection in C++ can only be conservative, which collects iff there is no doubt that freeing that particular memory address is a safe operation. Naturally, this is much less efficient than only accessing memory in use.

There is a saying, "Objects die young." Most objects that are instantiated are only there for the duration of a function call. Assuming this to be generally true, copy collection is very efficient, because it won't have to access most of the instantiated objects. Hand allocation/deallocation requires that you touch every piece of allocated memory. Saying that hand allocation/deallocation runs more efficiently than GC only holds true for conservative collectors. More formally put, GC runs in O(memory in use) and only runs when memory runs out. This is multiplication by a constant, so it is still O(memory in use). Hand (de)allocation runs in O(allocated memory). If memory in use = allocated memory, than you can't free anything anyway.

The power of pointers is its weakness. You can't guarantee object integrity when you can randomly write to the memory holding the object.

And if you can't guarantee object integrity, you can't guarantee good garbage collection. GC really doesn't belong in C++.

- Y

Re:Schools also taught Pascal. Where is it now?

[Mr T]

You're correct, java in implementation is flawed, but so is C++. Perl and Python are exceptions simply because there is no choice in implementation. Presumably java will settle down some, maybe it won't.

I meant the language itself. Java, as a language, is dramatically more simple than C++. It's stunning. Not to be defamatory, but python is the same way compared to perl. Both python and java are getting lot's of attention and hype right now. Perl and C++ have a lot in common in that they've evolved over years and lot's of new things have been added to them while trying to remain backwardly compatible. There is a lot to learn to know "all of C++" or "all of perl"

From the CPPHA HQ

[Kaufmann]

From the headquarters of the C++-Haters Association...

Seriously. Like many of the posters so far, I program in C++ every day. Unlike many of those, I _really_ hate it. It's probably a question of cultural differences: I was raised on Lisp, and, even though I'm not really religious about it, I still find C++ to be, all in all, an enormous kluge.

I really do wish I could move to another language, but unfortunately, the Lab standardised on C/C++/Fortran some ten years before I got hired, and I don't really have a say about it.

So the point of the matter is: what can you, Bjarne, do for me, Kaufmann? Can you at least post a memo saying something like: "To the Mgmt. and J. Clueless PHB: C++ is _not_ a god-send. Not _all_ programming should be done in C++. Alternative language research _should_ be encouraged. Sincerely, - The Bell Labs gang"

Thanks for the time,

-- Rafael Kaufmann, CPPHA member

(Note to moderators: not a flame, not a troll.)

What would you change about C++ now?

[jjohn]

Given the rise of such quirky languages like Perl and Python, which both use weaker typing, automatically garbage collect and provide associative arrays, would you add or remove any features from C++? Would you provide for more robust string handling?

But it never got moderated down!

[CoughDropAddict]

Java, after the hype (Score:6, Interesting)
...
Moderation Totals:Interesting=6, Total=6.

C++ acceptance over C

[JordanH]

This is a question almost certainly better suited for others, but, unfortunately, those others aren't being interviewed. Fortunately, I believe you probably have some perspective on it.

From your FAQ, it appears you have strong opinions on the relative merits of C vs. C++ for most applications. I quote, in particular:

• C is better than C++ for small projects, right?

  Not in my opinion. I never saw a project for which C was better than C++ for any reason but the lack of a good C++ compiler.

Do you have any idea why C++ was rejected as the implementation language by the most experienced C programmers, those folks now at lucent.com (Dennis Ritchie, Rob Pike, et al), for their most visible projects, Plan 9 and Inferno?

Surely, these people had access to a good C++ compiler.

If I may have a follow up, but closely related, question. Was the division of the Bell Labs Research staff between Lucent and AT&T related to a division of opinions concerning C and C++?

-Jordan Henderson

Debugging C++

[MattV]

While I find the flexibility and power of C++ to make it the best overall tool for my programming, I often find that when I get something wrong, the error is almost impossible to find.

What could be done to reduce the incidence of errors and improve the debuggability of C++ code, either through changes to the language, restricting the developer's freedoms, or by improvement of available tools.

Context: I have moved to Linux development from NT, and *really* miss BoundsChecker!

Re:What about Kaffe?

[chandoni]

And of course, some of us are very interested in getting compiled Java (i.e. gcj/libjava, part of the gcc project) to work. I have contributed to this project in the past, with the hope of someday maintaining 1 set of Java libraries which I can either run in a JVM like Sun's or kaffe (for portability) or compile for my platform (for speed).

So, I would rephrase the question to something more like " JVM issues aside, what do you think of the future of Java as a language?"

JMC

Its not about OO vs. procedural

[rambone]

there are other paradigms...one that has been convincingly applied is to use a robust high performance platform based on an open standard (like Apache), and use easy to understand extension languages to extend the platform through a known interface.

Re:Its not about OO vs. procedural

[rambone]

well, at the very least there is functional programming.

Unfortunately, I don't see Eiffel hitting it big

[rambone]

Its not a technology issue - its a marketing issue. Eiffel is not only poorly marketed, but there aren't any major open source Eiffel-based projects that would spur developers to learn more about it. For at least another three years, C is king, as much as it chaps me to admit it.

What are you trying to do?

[DragonHawk]

This means that it is not practical to use C++ fully in any project ...

Well, what are you trying to do? Are you trying to make sure you use every last feature of a given system, or are you simply trying to get the job done?

C++ is very complex. So are Unix, and Common LISP, and X11, and countless other systems. However, you don't have to use all of a system's features in order to use that system. Use what you need to get your job done to satisfaction.

Larry Wall (the creator of Perl) has said, "A Perl script is 'correct' if it gets the job done before your boss fires you." There is a lesson there: Don't get so caught up on the tools that you forget that the tools are there to help you do your job. The same applies to C++.

This has been a public service message from DragonHawk. ;-)

Choosing languages

[DragonHawk]

OpenSource programmers can write code in whatever language they want. Consequently, they write a lot of C, Perl, and Python. But with some notable exceptions, they don't write C++.

I'm not entirely sure your assertion (that C++ is significantly less used for OSS then other languages) is correct. KDE comes to mind.

But, for the purpose of discussion, let us accept it as given.

Contrast that with the lanuages programmers use at work, which are primarily C++ and Java.

You've got a number of factors here.

The biggest concern for software maintenance is what system is already in use. If you've got a program written in language XYZ, then you continue to use XYZ. Look at the large number of COBOL programs still in use today for proof of this.

If you're (re)implementing from scratch, the biggest concern is: What is available to use? For many systems, the answer is C, because C is still far more universal and "settled" then C++ is. This doesn't mean C++ is bad, it just means C has been around longer.

Follow that up with: Who is making the decisions?

For a corporate project, it is the managers. Managers look at studies, benchmarks, and marketing info (lots of that), and decide which language is "the best". Unfortunately, many managers assume "newest" equals "best". This leads to Java, C++ and such being used, not because they are or are not better then alternatives, but because they are currently popular and getting attention. This leads to a network effect where more "new" software is written for C++, giving the impression that C++ is even better.

Note that I'm not asserting that C/C++/Java/whatever is better then C/C++/Java/whatever. I'm simply saying that quality is not the only consideration to PHBs.

Now, look at your typical OSS project. It is coordinated by a few people, maybe just one. They are going to pick the language they are most familiar with. This means C is chosen a lot, simply because it has been around longer, so they know it better.

As far as Perl and Python go, they are predominately scripting languages, and generally don't target the same problem space as C++. (Yes, I know that is an over-generalization, but as such things go, it isn't that far off).

Just my 1/4 of a byte. ;-)

Re:Choosing languages

[Chris Siegler]

>I'm not entirely sure your assertion (that C++ is >significantly less used for OSS then other >languages) is correct. KDE comes to mind.

Here's my Perl program for checking the library dependencies on my system (RedHat 6.0 mostly)

#!/usr/bin/perl
sub deps {
$r_array = shift;
foreach $file (@$r_array) {
my $deps = `ldd $file`;
my @libs = $deps =~ m/(\S+) => /g;
foreach my $lib (@libs) {
$solib{$lib}++;
push @$lib, $file;
}
}
}
sub bycount {
$solib{$b} $solib{$a};
}

foreach $dir (@ARGV) {
opendir DH, $dir;
@programs = grep -x, map "$dir/$_", readdir DH;
deps(\@programs);
closedir DH;
}
foreach $so (sort bycount keys %solib) {
print "$so $solib{$so}\n";
print "@$so\n\n";
}

This is what I get:
libc.so.6 1318
/bin/mktemp ...

libstdc++-libc6.1-1.so.2 44
/usr/bin/addftinfo /usr/bin/eqn /usr/bin/geqn ...

That's 1318 programs linked to the C library and 44 to C++. In addition, those 44 C++ programs are really just groff, xpdf, and my jikes compiler.

Re:Choosing languages

[Chris Siegler]

Oops, lost the spaceship operator :-)

sub bycount {
$solib{$b} <=> $solib{$a};
}

Be aware: The above is not Jeff "Hemos" Bates

[DragonHawk]

I think the troll in question is actually kind of funny, so I don't think the moderation is inappropriate, but I want to make sure all involved realize that the above comment was posted by "Hemos.", not "Hemos". Not the period (.) at the end of the poster's handle.

I, for one, think it would be desirable

[DragonHawk]

Standardized name mangling is not sufficient nor desirable.

You've obviously never tried to get two different C++ libraries to play nice together. I, for one, would really love it if things were standardized such that these problems went away.

Now, perhaps standardized name mangling isn't feasible. That may be. It would also be unfortunate, as it means C++ is effectively useless when it comes to creating reusable software on current shared library implementations. :-(

C++ evolving in wrong direction

[wowbagger]

I've been earning my pay using C++ for about ten years now, and in general the language has been what I needed. Thank you for making many things much easier.

However, I have watched with great dismay the direction in which the language and its libraries are going, with the addition of internationalization to the streams library. As an embedded systems programmer, the fat now associated with I18N makes the streams library completely unusable in my environment. IMHO, I18N belongs in the GUI layer, not the streams layer.

That said, I'd like to ask why more useful (to systems programmers) constructs like guaranteed size types (int16, unsigned int32, etc.), XINU structures (bigendian on littleendian and vis-versa), and forced structure layouts (the _packed attribute) were not added, while all this facet crap was added. I thought you designed C++ as a systems language!

MODERATOERS: NOTICE THE "."

[Dacta]

Maybe it is a little funny, but it is still a troll.

Read The FAQ

[DragonHawk]

Your question is answered here.

*Not* there (was: Re:Read The FAQ)

[David A. Madore]

Hello??? Where do you see this? It's not because my question has ``garbage collection'' in it as well as another question in the FAQ that they are identical — or, in fact, any more than remotely similar.

plan9 v's linux - sm511451450357

[goon]

• nice
• link (The story of the Linux kernel By) about kernel dev., contrasting linux and plan9.

C++ in a Java world

[Judah Diament]

With the popularity and features of Java constantly growing, where do you see C++ holding its ground and fiting in 5 years from now?

There's a world of languages outside of C/C++/Java

[Convergence]

A few things I've noticed throughout this discussion is almost ignorance of newer languages and language ideas.. Do not forget that the average software engineering development takes 18 YEARS to be put into widespread use.

OO has been with us since 1980. Its only in the mid-90's that its become big. Similarily, the new language ideas that have been developed relatively recently (functional programming--haskell, sml-nj, ocaml) will be the languages of the future in another 10 years.

In these languages..Here I will refer to SML-NJ, as I am most familiar with its type system, they are strongly typed. Polymorphic; lists are TRULY polymorphic, Unlike templates, there's no code duplication. They are also extremely strongly typed. In actuality they have an order of magnitude more typing information than C++ has, except that I don't care because the compiler itself intelligently infers all of that typing information fully automatically. Functions are truly first-order values. They may be 'created' at runtime (via partial application or closures), stored, passed around, and anything else.

SML is also much more understandable and more consise. It also has a module system that's extremely careful. You cannot even compile a program that violates the module system. As a language, the specification is well under 100 pages of carefully formalized mathematics.. (Though a careful analysis of SML shows that there are 'dusty corners' in the specification. My research right now deals with specifying a language so explicitly that an automated theorem proving system can prove the 'correctness' of the language specification. If anyone's interested in the tools I'm using, www.twelf.org.)

As far as consiceness and modularity: Remember the law of software engineering, half the number of lines of code means 5x easier to analyse, debug, and maintain.

As for the other languages, haskell has an even more versatile type system than SML-NJ has, I think its powerful enough to handle most of the typing characteristics of OO programming. OCaml is another language in this group.

While its still true that none of these languages are ready for prime time yet, I suspect that derivatives from them (like ML-2000) may be the language of the future; the languages that everyone will be calling the pancea in 10 years.

Given that it will probably be at least a decade or two until the next 'big thing' comes out, what things currently in the pipeline do you think will be big? Will it be the strongly typed functional languages? Will it be the a Java-style IDE where people don't think of a program as a set of linear text files but rather as a collection of objects and methods?

Another way of asking the same question, what abstractions do you feel will be the ones exploited in the future? Will the IDE abstract away the textual or linear representations of the code? Will typing, interfaces, and modularity be used to abstract away the objects implementing an interface? Will we finally have a good application programming language which completely abstracts away the ideas of bits, bytes, pointers?

Or, should I shut up because I've been around 'academic' language designers too much, who don't know how to make a language that the majority would accept?

More like this

[Venomous Louse]

The type T2 in the case below need not and should not be fixed when the class template is instantiated. You might want to call the functions that use it three different times, with three different T2 types. That's the only reason to bother parameterizing the type in the first place.

What would be gained here is defining the callback type once, out in the open. As the language presently stands, this code can be written, but it would be ugly, as we see in the example.

template<class T>
class container {
template<class T2>
typedef bool (* callback)( const T &r, const userdata &ud );

// for each contained item, call the callback and pass it a
// reference to the current item and a reference to userdata
// This is nice but illegal.
template<class T3>
void traverse( const T3 &userdata, callback<T3> cb );

// This is why it would be *really* nice to have the typedef;
// we may want it more than once.
template<class T3>
void traverse_reverse( const T3 &userdata, callback<T3> cb );

// This legal code is what I'd like to avoid
template<class T3>
void traverse_ugly( const T3 &userdata,
bool (* callback)( const T &, const T3 & ) );
};


The question really is, "is this ugly enough to make it worth anybody's while to add a feature to the language?" I suspect that the answer is "no", since it'd be merely a convenience which would add no functionality.

A couple questions...

[grappler]

1.Write a C++ program incorporating the following nested loop:

for ( i = 1; i = 5 ; i++)
{
for ( j = 1; j = 5; j++)
cout '*';
cout endl;
}

What is the output of the program?

2.Modify the program so that the output looks like the following:

******
*****
****
***
**
*

3.For EC make the following with a single asterisk in nested for loops

*
***
*****
*******
*********
*******
*****
***
*

--
grappler

Re:How do you sleep at night, Bjarne?

[Dr. Sp0ng]

C++ is to C as Lung Cancer is to Lung.

Hahahahahahaha that's one of the funnier things I've read in awhile. It's going straight into my .signature file :-)

Matt

"Software is like sex- the best is for free"
-Linus Torvalds

Re:If true, this would have happened years ago

[jd]

What I'm envisaging is something like this. Each "object" would exist as a virtual computer. Each method on that object would exist as a daemon within that computer.

By having a P-I-M architecture, you could actually have one physical CPU per virtual computer.

You avoid the stack problem by having one queue per method per object. This allows you to have as many queues as you like, and thus as many threads as you like pushing data onto those queues, without any side-effects.

The "ideal" arrangement would be to have one processor per method, and a cluster of processors sharing data to comprise one object. This would be the most parallel form of OO programming you could do. By using P-I-M, your communication overheads are minimised, so that wouldn't be a real issue. (It would be a serious bottleneck, if using traditional Von Neumann or Turing architectures.)

Programmers would also be forced to think about the code more, as such a design makes it impossible to rely on timing quirks. Either you =know= an operation has been performed, or you don't. If you don't, you can't rely on guesswork to say that it should have been performed. You'd be forced to either structure the program to ensure that a method had to have completed and signalled back, OR to have some kind of semaphore to find out.

Either way, you'd have a VERY fast program, as you would be using the OO paradigm to parallelise the tasks, and using a massive array of processors to distribute the work.

Sorry if someone asked this ... too many comments

[karb]

You have said that backwards compatibility (to the extent C++ provides) with C was a must.

Now, however, as opposed to back then, you are quite an important figure in programming languages and the computing field as a whole. You advocate using C *only* if a platform does not provide a working C++ compiler.

Have you considered making another language with all all the features of C++, without the backwards compatibility to C? While there would be more of a learning curve, you certainly have the importance to be taken very seriously, and a tighter language could possibly result.

Hey, that's slick.

[Venomous Louse]

One problem I can see, though, is that if each of the blocks can have > 1 T instance in it, what happens when you start erasing? Oh. Never mind: You just keep track and reuse 'em. Placement new, placement delete. No problem. Uhh, wait a minute . . . you'd have to be writing your own allocator, or something very much like it. One way or another, you've got to be keeping track of the gaps in those blocks. That'll be a pain in the ass. Why not just allocate each T instance separately with new? In that case, it's an option that's available with the normal std::vector; that's usually how I use them. If I need to worry about keeping something sorted, I generally use std::map anyhow. I get the feeling I'm missing at least part of your point here, but I'm enjoying it anyway :)

Now, the problem that is left over, is the problem of taking a pointer to *(vec.begin()) and passing it to a C function that expects an array of T. That ain't gonna work.

Additionally, this vector impl may be a lifesaver if the space taken up by the objects you wish to put in the vector comes perilously close to exhausing your virtual memory.

Errr . . . how so?

(btw -- re: your other post in this subthread: Didn't I mention something about copy constructors? I don't see a need for the move thing, unless you could gain serious efficiency with it. Anything you're storing in a std:: container needs a copy constructor anyway, right? Requiring a copy constructor is nothing new.

---------------
Disclaimer: AFAIK, IIRC, YMMV, IANALL (I Am Not A Language Lawyer), u.s.w.