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?

Re:What do you program in besides C++?

[tidepool]

What single language (besides C/C++) do you find yourself most productive in?
And, as a subset to this question,
What are the specific reasons (if any) for chosing this specific language? Is it very efficent or does it just match your thinking style?

Ben Brewer
brewer@nullified.org & tidepool@suspicious.org

Re:What do you program in besides C++?

[BuffRyder]

Pascal, Delphi, Perl and Java all kick ass I only use C++ at work and school because its standard.

Re:What do you program in besides C++?

[Anonymous Coward]

Definately Pascal. I would add PHP and PERL, but they aren't real programming languages.

Re:What do you program in besides C++?

[a-optic]

I program in C\C++, Basic , QBasic, and Visual Basics

Now i am learning or going to learn Tk(going to learn), GTk(goint to learn),Dephi(going to learn),and Perl(learning)

And finish learning assembly

a-optic

Undernet:

#Rhino9

Java, after the hype

[rambone]

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

Re:Java, after the hype

[ebbv]

This is what I was going to ask, I (unlike rambone apparently ;) read his FAQ, though and found the following gem :

"Java isn't platform independent; it is a platform. Like Windows, it is a proprietary commercial platform. That is, you can write
programs for Windows/Intel or Java/JVM, and in each case you are writing code for a platform owned by a single corporation and
tweaked for the commercial benefit of that corporation. It has been pointed out that you can write programs in any language for the
JVM and associated operating systems facilities. However, the JVM, etc., are heavily biased in favor of Java. It is nowhere near
being a general reasonably language-neutral VM/OS. " -- Bjarne Stroustrup's FAQ

this is exactly what i've said all along, i really don't like java. i think it's unnecessary, inefficient and slathered with hype. what we need are simply good compilers that adhere to a single standard, with good libraries that carry over from OS to OS,.. or that are at least similar.

but i don't think mr. stroustrup is the person to bother with these issues.
...dave

Re:Java, after the hype

[McSnickered]

I'm not sure the 'hype' is actually over. I'm not a big proponent of Java (if it fits the purpose then I'll use it), but just coming out of college I see a HUGE number of companies looking for Java developers. I think the fact is that Java has several advantages over C++ for certain tasks that are justifying its 'hype'.

Re:Java, after the hype

[Listen Up]

Umm, hello. A score of 6? It wasn't exactly an Earth shattering question.

Hello,
Anybody home in moderator land?

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]

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.

Yes, this is in jest, though unfortunately the above is an all too real problem. One of the beauties of C++ is that you don't have to use all the cool OO features. Unfortunately, many poor C++ coders feel bound and determined to.

Re:Another Interview

[Gepard]

Quite honestly, though the interview is obviously humorous in nature, the criticisms of C++ in it are all too accurate. I have programmed in C and C++, and it is far easier to hack objects into C (which is what GTK+ does marvelously) than to use the so-called object-oriented features of C++. Granted, one could also use a language that actually _is_ object-oriented, like Java or Common Lisp instead.

But enough of my ranting. Check out this critique of C++ from the point of view of a computer scientist very well-versed in programming languages.

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.

Re:Another Interview

[MrBlack]

Borland's Delphi programming language which (AFAIK) is based on Pascal (with some OO features, like C++ is to C) is a very popular programming language (on the windoze platform at least, but it sounds like Linux will be getting it soon also which is great) which is supposed to be both a fundamentally sound OO language (e.g. Java, SmallTalk) and very quick and easy to develop in (like VB is proported to be). So while Pascal may have not made an impact I think time has shown it's basic structure to be quite practical, hence the popularity of Delphi.

Re:Another Interview

[elj]

Well versed in programming languages but not particularly well-versed in real world programming.

Maybe your views are based on outdated information? For a more recent view see:

• [Eiffel/C++] Eiffel outperforms C++ in independent study

BTW, Ian's C++?? Critique is now a completely updated/rewritten book titled: Objects Unencapsulated: Eiffel, Java and C++??

Re:Another Interview

[ucblockhead]

Given that the source isn't included, I can't help but wonder at what the code looks like, especially given statements like In fact, Eiffel (by its use of copy-by-reference instead of by-value) could realize big wins over C++ , which shows an apparent unfamiliarity with C++ reference parameters, which can make huge differences in execution time with strings.

Re:Another Interview

[Gepard]

A reason that ``academic'' languages don't make it out of academia? The reality of the situation is that many many people just bought into C++. They were used to programming in C---a good language for low-level work---and they said, ``Oh! A C-like object-oriented language! Cool!'' Most so-called academic languages are purely academic simply because they are only research projects in language theory or implementation. They are not designed for production use. Such is not the case with Eiffel or Common Lisp.

Your example of Pascal is completely out of context. Pascal was designed purely as a teaching language. It was never intended for production code. It was not an academic research language. And Pascal is still a hundred times better for teaching beginners than C++. The fact that damn near every school in the US teaches C++ as an introductory CS class is absolutely criminal.

Anyway, I will simply address your other arguments one by one. First, what exactly do you mean by a language not telling me what to do? C++ is pretty damn restrictive in my book. Sure, it lets you manipulate pointers all you want---but is this real freedom? Seems to me real freedom would be a mechanism like anonymous functions and closures.

Second, are you kidding? 65% of all software bugs are due go memory leaks, and writing code in C++ is one fool-proof way to fall victim to this rule. (This is actually is problem with C, but as long as some wonderful designer like Stroustrup was working on improving C, he might as well have built in garbage collection.) If you want a language that encourages fast development, you cannot beat Lisp. Period. Many major projects are first prototyped in Lisp just to get something working off the ground fast, and then their OS interface parts are usually re-written in C (mainly because of the lack of user interface libraries). If you want a more concrete example, AutoCAD and Mathematica's internals are written in Lisp. Same with Emacs. I myself was amazed at a sample program included with Paul Graham's ANSI Common Lisp, a fully-functional ray tracer. It was fairly limited, of course, but I wrote a simple ray tracer about a year ago, and it was ten times the length of the Common Lisp implementation.

If your statement referred to execution speed, then there are numerous studies that show that properly optimized Lisp with a good compiler matches, and in some cases exceeds, C's execution speed.

Finally, if you actually bothered to read the critique I linked to in my original post, you would have seen that Ian's critique had nothing to do with changing C++. It's pretty obvious that Stroustrup will defend his bad design decisions to his dying day, and Ian was merely pointing out the defects.

Re:Another Interview

[elj]

Given that the source isn't included, I can't help but wonder at what the code looks like

Just go up a level and you will find plenty of C++ and Eiffel code, along with Victor's notes including `Project Plan Summary', `Time Recording Log' `Defect Recording Log' for both C++/Eiffel versions. The previous link was just an Appendix.

given statements like In fact, Eiffel (by its use of copy-by-reference instead of by-value) could realize big wins over C++ , which shows an apparent unfamiliarity with C++ reference parameters, which can make huge differences in execution time with strings.

Victor has a strong background in C/C++ and has even developed game software that has brought in a little cash and the thrill of seeing my game on the "cheapware" racks at the local software store.

Eiffel is not for everyone, most can't even (and don't want to) read the Pascal/Ada syntax. The language landscape is incredibly competitive and it is just interesting to note that Eiffel has moved along with the rest. As I said in another post, SmallEiffel has added a new dimension to the Eiffel world. For most this doesn't matter, but at least we should know it exists.

Re:Another Interview

[ucblockhead]

Your example of Pascal is completely out of context. Pascal was designed purely as a teaching language.

The context was that Pascal was the first compiled language available cheaply on the PC. C came a little later. C++ much later. At the time, PC programmers had little knowledge of anything but BASIC. They pretty clearly reacted against strong type, safe arrays and the like in favor of the pragmatism of C, and later, C++.

. First, what exactly do you mean by a language not telling me what to do?

Allows me to use pointers. Allows me to manipulate pointers, do math on them, etc. Allows me to quickly change data types. Etc, etc. Allows me to overload functions and operators. Allows me to nest classes. Allows me to control whether data is kept on the stack, on the heap, or fixed in memory. Basically, allows all those things that are "bad".

Basically, languages like C and C++ let programmers make up their own minds about what is "bad" and what is "good".

Second, are you kidding?

Execution speed, not development speed. And I'll believe those benchmarks when I see sample code. I've never seen it work like that in the real world.

Finally, if you actually bothered to read the critique I linked to in my original post, you would have seen that Ian's critique had nothing to do with changing C++.

I understand that. But you can't just say "X" is bad while ignorning the ramifications. Many of the criticisms went something like "C++ is bad because it does X" where reading "The Design and Evolution of C++", it is clear that it does "X" either because doing it that way improves performance, or because doing it that way gives the programmer more freedom.

For example, the complaint about safe arrays. Safe arrays reduce execution speed. To say that C++ is bad because it allows unsafe arrays is to say that safe arrays are more important than performance.

(Fortunately, we C++ programmers have the freedom to use safe arrays when we want (vector) and plain old fast arrays when we want ([10]).

Anyway, I actually did look at a lot of that critique, and most of the objects boiled down to either one of the two things I mentioned (Reducing programmer freedom, and a lack of concern for programmer efficiency or not things that get a language ) or with C++'s C compatibility.

Re:Another Interview

[Anonymous Coward]

"They pretty clearly reacted against strong type, safe arrays and the like in favor of the pragmatism of C, and later, C++." I'm not sure this is entirely true. C was popular on Unix and therefore at universities which used Unix so that might have been a large part of it. "Allows me to use pointers. Allows me to manipulate pointers, do math on them, etc. Allows me to quickly change data types. Etc, etc. Allows me to overload functions and operators. Allows me to nest classes. Allows me to control whether data is kept on the stack, on the heap, or fixed in memory. Basically, allows all those things that are "bad". " The production versions of Pascal allowed all these things. One could do pointer manipulation, type conversion, and even hack the stack. For example, UCSD Pascal had ways of doing all these things. "Execution speed, not development speed. And I'll believe those benchmarks when I see sample code. I've never seen it work like that in the real world." ICSD Pascal had compiler directives to turn of array bounds type checking for example. The production pascals didn't get in the way but they protected the novices from doing horrible things, unlike C which doesn't do much to protect the programmer.

Re:Another Interview

[ucblockhead]

UCSD was a nice system, but its performance was mediocre. (Says this UCSD alumni.) And it certanly did not allow you to overload operators or do the sorts of typecasting C allows.

Re:Another Interview

[uid8472]

A reason that ``academic'' languages don't make it out of academia? The reality of the situation is that many many people just bought into C++. They were used to programming in C---a good language for low-level work---and they said, ``Oh! A C-like object-oriented language! Cool!''

I didn't "buy into" C++. I like it because I can do things with it that would be hard, slow, or impossible in other languages, and because it sort of matches the way I think.
I also like Scheme, an "academic language" if ever there were one, because I can do things with it that would be hard, ugly, or impossible in other languages, and because it sort of matches the way I think.
C++ and Scheme are suited to different things, but they are good (in my opinion) at what they were intended to do.

65% of all software bugs are due go memory leaks, and writing code in C++ is one fool-proof way to fall victim to this rule. (This is actually is problem with C, but as long as some wonderful designer like Stroustrup was working on improving C, he might as well have built in garbage collection.)

Stroustrup didn't build in (i.e. require) garbage collection because he didn't want to restrict programmers to a particular style of memory management. He did, however, allow (and probably intend) for garbage collectors to be used in cases where there is an advantage to using them; i.e. programs with a lot of dynamic allocation.

Standardized name mangling

[f5426]

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

Re:Standardized name mangling

[Jan]

In general, it won't happen. Name mangling is just the tip of the iceberg. The different implementations have different object mappings, calling conventions, exception handling tables, etc. It is impossible to agree on names if the code, data, tables, etc. behind the names are not compatible.

For one example object mapping, see "C++: Under the Hood", at http://msdn.microsoft.com/library/techart/jangrayh ood.htm.

Certainly on your particular OS/platform, there may evolve a de facto standard that the various vendors all support.

That said, C++ object mappings are so substantial and intricate, and each vendor's installed base of legacy binaries, objects, and libraries are so difficult to rebuild all at once (assuming separate authorship of components), that each vendor with an installed base is highly reluctant to ever break backwards compatibility with existing object layouts and tables (let alone names). (The flag day problem.) For example, neither the 16-bit nor 32-bit MS object mappings have substantially changed since they were released in 1992 and 1993, except to add new data and tables to support new language features.

If you want interop between implementations, you might consider adopting a binary object interop convention like COM or XPCOM. This requires only that you define a convention for vptr placement and vtable layouts (one convention per platform) and you'll have no naming or other interop problems whatsoever, *and* your components can will interop with components authored in other languages that also expose component intefaces as vptr/vtables.

Re:Standardized name mangling

[Xenu]

Standardized name mangling is not sufficient nor desirable. Foo C++ may implement the language in a manner completely incompatible with Bar C++. There are too many hidden things that are implementation dependent, even on the same processor and operating system.

Re:Standardized name mangling

[Anonymous Coward]

FYI there is an effort to standardize the ABI for ia64. This will include things like mangling, vtables, and exception handling mangling, among other things.

search the gcc@gcc.gnu.org for more info

Re:Standardized name mangling

[Matt Austern]

Standardized name mangling is desirable if and
only if it's part of a more general ABI. Defining
a multivendor C++ ABI isn't impossible, but it's
hard. Name mangling is one of the easy parts.

There is a group working on a C++ ABI for IA64
Unix. If that ABI succeeds for IA64 Unix, it
may be adopted (in a modified form, of course) for
other platforms too.

Re:Standardized name mangling

[Anonymous Coward]

Speaking of name mangling: Bjarne, how many different ways are they mangling your name?

--Morten

Is C++ really a joke?

[Psiren]

I've heard several people mention the story about how you created C++ as a cruel practical joke. While I don't think it's true (C++ has its problems, but I'm very fond of it), the origin of the story intrigues me? How did it come about?

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?

[El Cabri]

OO has brought nothing, and certainly not productivity. Reusability is a joke when you see the global picture.

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

Languages need focus on a problem / platform rather than genericity. They need simplicity rather than high level abstractions. They need to integrate the worked-on-by-a-team and the code-has-to-be-maintained-by-someone-else problems rather than reusability. C++ is dirty, has no clear semantics, no standard that is fully implemented, no serious typing discipline.

Re:Has OO run out of steam?

[Anonymous Coward]

Only a fool equates C++ with OO. C++ != OO (thank God)

Re:Has OO run out of steam?

[Anonymous Coward]

Java is bondage+discipline OO. C++, like Perl, or Fortan 95, does not force you to write OO code, but you can if you want to.

To be honest, I think people overestimate C++'s complexity. If you read the C++ programming language by Stroustrup, it is actually quite a clear and logical, if terse, language. The STL is quite cool.

Heck, even if you read Herb Schildt's books, he makes a reasonable job of explaining it (as an aside, although I don't recommend you learn C++ from Schildt's books, I do find them useful (gasp!) as a concise _reference_, which is how he intended most of them - you always hear people slating them as a learning tool, but that's silly - they're reference books...)

Personally, I don't like java (too restrictive), but I do like the VM idea, and would much rather there was greater proliferation of language-agnostic virtual machines, such as the Tao Group/Amiga VM (which desperately needs a GPL clone, btw)

I think the biggest thing holding back Java is Sun. If IBM were to push through an independent Java (-workalike) _standard_, possibly with an LGPL reference implementation, Java would be everywhere in a matter of months.

I still don't think it would take over from C++ completely though - C++ is simply more powerful.

Re:Has OO run out of steam?

[Lalo Martins]

Yes, OO is not easy to learn. It's easy to do wrong and to misuse. And it's a common thread that people who can't get it like to flame it. No problem - it's your productivity, not mine :-)

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?

[rockhome]

I think this comment is quite valid. Why hasn't the object oriented paradigm become truly mainstream. Most omputer science departments teach C, with classes based in OO programming as under attended electives. In examining many of the projects that I have worked with, I have neverf found a problem well suited an OO framework outside of a database. Many other models just don't break down into simple objects, there are too many other complexities. How has C++ become so popular then?

Re:Has OO run out of steam?

[Larry L]

Add to that:

Should whole operating systems be written towards the OO pardigm (eg eros) or should we stick to c?

Re:Has OO run out of steam?

[radish]

Most computer science
departments teach C, with classes based in OO programming as under attended electives.

Any department which teaches only one language (and C at that) should be closed down. The point of learning Computer Science is NOT to learn a single language, or a single technique. It's to understand the concepts and grasp the differences. You should come away seeing why in some cases OO works, in some cases set based coding (i.e. SQL) work, in some it's rule based (Prolog), in some functional (Miranda/ML).

In examining many of the projects that I
have worked with, I have neverf found a problem well suited an OO framework outside of a database. Many other models just don't
break down into simple objects, there are too many other complexities.

Problem frequently don't break down into SIMPLE objects it's true. OO does not make your life easy - that's not it's job. But think about it - the real world has objects. And classes. In my experience in the Real World (tm) OO design allows you to elegantly model the problem domain in such a way as to make the details easier to manage, and make the problems obvious. This is good - catching design problems early on saves time and money. If you are working on a real world problem I think you will find that OO is frequently a very fine way of working.

How has C++ become so popular then?

Good question. It is a very twisted little language to use (but then I admit to having little experience!). Java roolz ;-)

Re:Has OO run out of steam?

[radish]

Very well put - worthy of more than a +2, although it of course goes against the general "anti-java" sentiment which seems to be rather rife around here.

I am currently working on a re-implementation of a real time data provision system for a major financial institution. The old system was basically a db, lots of SQL, some C, some sh, some perl. We are redesigning from the ground up in Java, using XML, Soap and a whole lot of other good stuff. Apart from a lot of the tools being decidedly beta, I think everyone on the team is amazed at the capability of these new technologies. The original system took months to build and was never very satisfactory - although it was done by some pretty good coders. We've been going a few weeks and already have a working prototype which is faster, more flexable, much more maintainable and cheaper. Most of this advantage has come simply by moving to a OO design model, doing the analysis in UML, and letting others do as much of the work for us as possible. That's one of the key strengths of something like Java to me - the fact that you really can download someone elses class files and stick them straight in. The interfaces are well enough defined that (unlike C/C++) you don't have to spend a week setting them up and tweaking them. You have a set of objects and they do what they say and they WORK. Nice :-)

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?

[Mornelithe]

I'm curious. Could you give me an example of a project that isn't "well suited" for "an OO framework"? I hear the argument a lot that "there are lots of problems that don't have to do with objects and can't be represented by objects," but truth be told, the people giving these arguments never give examples, and I can't think of any on my own. Perhaps if you give me an example, you'll convince me, or I or someone else can convince you. Many thanks.

Re:Has OO run out of steam?

[radsoft]

"obvious that OO is not a panacea"... "the OO paradigm"???? Who is writing? That "OO is not a panacea" has got to be the understatement of the millennium. The weak minded will always seek trendy panaceas, and now the rest of us still have to pay for their wimpy collective mob mania.

Re:Has OO run out of steam?

[Brian Feldman]

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

Huh? C is meant to be portable and standard. It is really not an abstraction in a big sense. It enables you to do things without having to think about how you'll do it on XXX machine. C isn't for abstracting things; you can do that just as well in asm (though it's harder to get comfy with and maintain asm, IMHO). C++ _is_ about abstracting things away, hiding details that would be impossible to hide with assembly (type differences? Sure, no problem with overloading in C++, but...)

--

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;
}

Re:Has OO run out of steam?

[Brian Feldman]

That's not a C program. That isn't valid K&R, pre-K&R, ANSI, C9X.... If you're trying to point out that C++ doesn't do implicit conversions like C will, that's a completely moot point. Either way, you can have the compiler warn, C++ or C, about that. You can have the compiler error out compiling C code because it converts the wrong types implicitly (without promotion), too.

Anyway, you really didn't respond to what I was saying. I said that C++ makes a big deal of hiding type differences, whereas in other languages you just use the proper type.

--

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

[ucblockhead]

BTW: In the Windows world, C++ has been used for systems programming for a few years now.

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

[MrHat]

Yes, but not at a low-level. The Windows API is implemented in C, as are kernel drivers and the kernel itself. The APIs are accessible through MFC and other "wrapper" libraries. This situation is analogous to using C++ wrappers for GTK.

The BeOS is much closer to using C++ at a low-level: the interface to its APIs is exposed in C++, but the OS still uses C in its kernel. From what I understand, its *possible* to write a kernel module for the BeOS in C++, but strongly "discouraged" due to name-mangling and other fun C++ compiler features.


43rd Law of Computing: Anything that can go wr

Re:C++ for systems programming

[ucblockhead]

I guess it depends on what you mean by "systems programming". I've written some Windows NT services (the NT equivalent of a daemon) and used C++ every time. More to the point, if you do anything with COM, you almost have to use C++. (It isn't a requirement, but COM is incredibly painful with C.) COM objects are systems type things.

To answer your question, C++ can't really be more efficient than C because it is pretty much C with object-oriented extensions. But by the same token, it is fairly easy to write a C++ program that performs as well as a C one. Just be careful about the object oriented extensions you use.

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

[ucblockhead]

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

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.

Re:C++ for systems programming

[darthscsi]

NT's GDI layer (graphics) was written in C++. It was one of MS's first attempts at C++ in the OS.

Re:C++ for systems programming

[was]

Actually, the BeOS kernel is written in C. See this and this for more info.

Re:C++ for systems programming

[Anonymous Coward]

I've always wondered why UNIX programmers never adopted C++ for system programming. Wounldn't it be nice to have an OO interface to the filesystem, threads, signals, etc., without just making wrappers for c functions. Now that I think about it, is it even possible to implement system calls in say C++ without redesigning the entire OS?

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?

[jovlinger]

Probably in the FAQ, which I would check before posting a question. However, this is an answer, so I don't feel the need for actually following directions (kindergarten didn't take). Anyway:

my Garbage Collection oriented friends tell me that His one biggest regret is making GC support optional. If it were required, then x% of all programming errors would go away, and library interfaces would be y times cleaner (no questions about who references or disposes of shared objects).

But they're biased of course.

Johan

Re:What would you do differently?

[ucblockhead]

In Design and Evolution of C++ he gives very specific reasons why garbage collection is optional. One of the main design goals of C++ was to allow programs to be written that were as efficient of C. Non-optional garbage collection would have made this difficult or impossible.

He explicitly says that his worst mistake was not including enough basic library classes with the first releases. He's right. One of the biggest headaches has been the amount of time it took to get standard string, list, hash, etc. classes.

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

Templates vs Inheritance

[f5426]

Templates were added long after inheritance. Unfortunately, templates and inheritance don't fit well together. It is quite disturbing because at the very same time, a kind of dynamic typing was added to the langage yoo.

So where is C++ headed to ?

* Template oriented language (ie: static) ?
* "More dynamic" object langage ?
* Both at the same time ?

Re:Templates vs Inheritance

[Anonymous Coward]

They work perfectly well together; you just need a language that isn't brain-dead and a language committee willing to study the prior art before standardizing.

Look up "F-bounded parametric polymorphism" to see how 2nd order parametric polymorphism and type systems with subtyping can coexist harmoniously in theory. And for some examples of how this can be made to work well in practice look at Eiffel, Cecil, and Generic Java.

When you're done with that, go read Gieuseppe Castagna's Object-Oriented Programming: A Unified Foundation and Luca Cardelli's A Theory of Objects, and then compare the different type systems.

You will be a much better programmer for the experience.

Re:Templates vs Inheritance

[UnknownSoldier]

> Luca Cardelli's A Theory of Objects

At first glance I thought the book would be a dry language philosophy book, but after reading the first 2 chapters, it is turning out to be an interesting read.

Thx for the first book name, I'll have to pick that one up to.

Cheers

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

Re:Programing in the future

[kwabena]

>Is there anything left to do except make the languages closer to english? This is core of the problem. A program must by definition be written in a formal language in which there is no ambiguity. English (or any spoken language) deals with a broad range of meaning, including emotions, complicated discourse structures (Which English are you talking about what you find in a cook-book or John Grisham novel? they're different). The success of a tool will depend on its ease of use with respect to the problem space that it is applied to. Making computer languages more like English is a long lived Philosopher's Stone. It didn't work with COBOL. It won't work until platform (hardware or software) it runs on is similar to the same one English runs on, i.e. the human mind.

Question

[JoeyLemur]

What is your opinion of Eiffel (www.elj.com, or www.elj.com/eiffel/intro) as a language? Object-oriented without C-like syntax.

Re:Question

[elj]

The above link is just one of many to Eiffel documents. A summary of onlines docs is available from the ``Eiffel: Getting Started Documention'' page:

• http://www.elj.com/eiffel/getting-started/doc/

From the Eiffel/C++ perspective, the following articles are worth a look:

• Eiffel for Native Speakers of C++
• The Eiffel Contract for C++ Programmers
  ( the application of Design by Contract in many contexts is also available)
• The Personal Software Process: Eiffel vs C++
  ( The results for compile time, Executable size and Executable speed may surprise a few!! SmallEiffel - The GNU Eiffel compiler - really adds a new dimension to the Eiffel World!! )

The Eiffel to C++ terminology mapping page is also worth a look.

Re:Question

[ucblockhead]

The Eiffel to C++ terminology mapping page is also worth a look.

There are a fair amount of blatent errors on that page in regards to C++. For example, "super()" is a java construct, not a C++ one.

Re:Question

[elj]

There are a fair amount of blatent errors on that page in regards to C++. For example, "super()" is a java construct, not a C++ one.

If you can send me the list, I would appreciate it. I have had a few other contact me over the last couple of months and will do an update shortly (hopefully with your corrections).

Thanks .. Geoff

Grin

[Anonymous Coward]

Oh why oh why did you invent C++?

This most joyful of languages that has e'er graced our lands has been the bane of many a programmer, when good ol' C was doing a pretty good job. Then it comes along, and puts a heap o' stuff on top o' C that makes it all a mess.

Smalltalk did it better and before C++, and much more elegantly. Java does it nice and clearly now, albeit with the wrong way of doing things (bytecode? runtime environment? JIT? non-platform specific classes? Where is the performance?)!

But, I digress my humble acolytes, and I must press thee this fine question: What has held back development of a lot of applications for that C++ infidel, BeOS?

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!

[Edward Kmett]

I would like to point out that my posting of the fictitious interview was meant to inject a some levity into the discussion, and not to mislead people into believing that Bjarne's motives in introducing C++ were anything but altruistic.

I do appreciate the link to the real interview though.

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!

[arivanov]

It is not the real interview, but quite a lot of things there are damn right.

Only Java beats C++ in its capability to water and obfuscate code.

Do not understand me wrong, C++ can be great and it can do what it was intended to - organize, structure, drive big projects. At the same time it can also promote job security by complete code obfsucation, it can promote complete ignorance in the workings of the underlying OS by abstracting the interfaces and providing the "standard library". Whoever obejct, please try to read multithreaded C++ code... Ughhh... Also, Not like our best beloved Blue Screen of Devotion is not mostly C++...

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

Deterministic Garbage collection

[Klaymor]

Why is deterministic garbage collection such a difficult concept to implement?

Re:Deterministic Garbage collection

[plague3106]

Probably b/c it adds alot of overhead and can more easily lead to sloppy coding.

Re:Deterministic Garbage collection

[Anonymous Coward]

sloppy coding, perhaps, but humans make errors. GC can prevent some of those errors. And a sloppy coder will have his sloppiness manifested in many others ways than memory managment (or playing well with the garbage collector).

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?

Re:Why no templated typedefs?

[murrayc]

I'm not certain that this is what you mean, but if you are writing a templated *class* you can use the *typename* keyword to get at the type in the template declaration. You can then use that typename as an argument in a class method.

Incidentally, MS VC++ doesn't require this - it lets you use a regular typedef. But strangely, I only found out about it from reading the MSVC++ documentation after I couldn't get the typedef to work with egcs.

Re:Why no templated typedefs?

[clem.dickey]

I am a Java programmer now, and my memory of the better days is slipping away, but I think this works:

template &lt class T &gt
struct Foo {
typedef bool (* func) ( const T & );
};

And then the name of your typedef is, of course, Foo&lt T &gt::func.

Re:Why no templated typedefs?

[ShivShanks]

Well maybe not a real template typedef but you
sure have something that can simulate it.

Take a look at -
http://www.cantrip.org/gnarly.html
And search for Template Typedef

Also those who are debunking C++ and/or its
tamplates etc should have a look at Blitz++
at http://www.oonumerics.org/blitz/
it has shown C++ to be the ONLY language able to
match optimised Fortran for high performance
numeric computation. And if you read the papers
out there you'll find cerdence to the claim that
C++ can do some things that no other language
in the world can do. And these are opinions of
some very experienced ppl.
Read them and expand your horizons about C++
Enjoy,
Shiv

Your five best friends are What, Why, Where, When, and How. You ask Why, you ask Where, When and How - and ask nobody else when you need advice.

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

Re:Question...

[Anonymous Coward]

So do I... And I'd love to know who keeps moderating it down...

Oh well, If meta-moderation really works, it won't happen again.

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

Re:Two Questions

[grem]

Moderate the parent of this comment DOWN. Both questions are answered in his FAQ.

1. No, of course not.

2. I don't compare languages.

Re:Two questions

[Anonymous Coward]

http://www.iarchitect.com/images/mdsclue.gif http://www.iarchitect.com/mshame.htm Ever since I saw this, I trust flat text files a lot more....

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.

Re:Multiple inheritance

[p3d0]

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

Yes, Eiffel.
--
Patrick Doyle

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?

Without wanting to provoke a language war...

[Anonymous Coward]

Would you agree with me and thousands of others, that in a nutshell, C++ sucks, whereas Modula-3 and Smalltalk rule ?

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.

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

[Anonymous Coward]

. . . and let's hope that Stroustrup continues to grasp that fact.

We don't need yet another Perl, endlessly growing useless and obstructionary pseudo-features and random fungus.

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

[simlo]

The good thing about making garbage collection standeard in C++ would be that it would reduce the
language a bit by forinstance forbidding typecasts between pointers and integers and even between pointers (?). That in itself might force coders to make more readable programs...

I disagree: GC does belong in any production level language. I experience with C tells me that at least half of the bugs comes from manual memory management.

But to Bjarne Stoustrup: By paying the cost of fragmenting the language, why not have a standeard
("C++GC" or whatever) where GC is build in and the above mentioned typecasts are restricted or even forbidden?

Ofcourse such that "new" language will not be usuable to code lowlevel stuff, but then again: Use C. There is already so many implementation dependencies in C++ that I would not dare try to use manipulate pointers down to the single byte level as you can in C, anyway. Especially, the memory allocation routines and the garbage collector will probably have to be written in plain C or old C++.

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

[Anonymous Coward]

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? On some level, the garbage collector would know what's where. I can't see (though I could be missing something, obviously) why that would have any effect on what I can do with the addresses of things in my own code.

. . . and even between pointers (?)

Okay, now you really lost me :)

I disagree: GC does belong in any production level language. I experience with C tells me that at least half of the bugs comes from manual memory management.

True, but with destructors you can automate (albeit by hand) an awful lot more than in C. My objection is to the inefficiency and arbitrariness of garbage collection. The whole "spirit" of C++, the whole mentality of its design, revolves around the idea that the programmer has control over what happens, and when. You'd also be at the mercy of the GC implementation; for example, I know a Java programmer with a real solid CS/C++ background who says that Java's GC ain't all it's cracked up to be. I haven't pressed him for details, though.

Ofcourse such that "new" language will not be usuable to code lowlevel stuff, but then again: Use C.

Exactly -- except that the whole point of C++ was to provide OOP features in a low-level language that would be suitable for most of what C was and is used for. OOP is damned useful.

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

[SomeOne2]

Actually low-level does mean neither OS nor "small" code. There are some applications/libraries where you have to do some nasty pointer tricks to get what you want and the code is actually quite large so it wouldn't be fun to code this in C. When you restrict these dangerous language features (like Java does) you can loose a lot of performance and need much more memory. (Trust me, I had to develop similar complex functionality in Java and C++ :)

Some garbage collectors can handle most of the problems generated by casts but you might get some problems when the garbage-collector is invoked to late (for example if your object holds an OS handle). I especially _hate_ languages where it is impossible to call the destructor myself. (Bad experiences... :)
Of course you can work around these things but than again you have to think about memory management which is exactly what garbage collection tried to prevent, so I think an optional garbage collector is a better choice.

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:Who cares? GC doesn't belong in C++.

[Anonymous Coward]

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.

Oh. Right. Is that long a long, or is it a reference to a huge buffer that I allocated ten minutes ago and (as it happens) no longer need? I was thinking only as far as keeping track of what's allocated, when what really matters is who's still using it (if anybody). I think I'm starting to see it.

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

Ehh, hmmm, yeah. I'm thinking it might be reasonable to say that GC is "at home" only in higher level languages than C++.

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

[Klaymor]

It seems as though my original point is being lost.

What I was driving at is that almost all implentations of GC are considered non-deterministic. Meaning that the programer has no control over when a particular object is GC'ed. This means that a system will behave diffenently in almost every situation. I have had situations where code I have written won't run on my local machine but will on the production server and vice versa. The key to having a long term development solution that is truely fault tolerant in mission critical situations it to develop a functional deterministic GC that works all the time every time. This takes the hardest part of enterprise development out of the developers hands.

The question still is...Why is it so hard to implemnt a truly deterministic garbage collector? This is a general question irregardless of the language.

Klaymore

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?

Re:C++: too much?

[CosmeticLobotamy]

Once, about twenty years ago, I was testing an electrical outlet in my garage. I couldn't find my volt meter, and my blender was full of three day old rum, so I stuck a couple of paper clips in the holes. Between the time my face lit on fire and the time I hit the ground I thought up the c++ language. I woke up bald as a baby's butt and dedicated never to let c++ be created because I knew all the pain that it would cause. Unfortunately I was only three years old at the time.
OO is a good thing. If you are writing a program that can be easily represented as an object, then use classes. Classes are good, readable, and semi-intuitive. They taste like chicken. They behave similarly to ansi c things.
Inheritence is also a good thing. Makes things Object oriented. Doesn't really conflict with c type stuff.
Operator overloading (which might be available in ansi c, I'm not too bright) is a good idea that is badly implemented. It has no similarities to anything else in C(unless it is actually a C feature, then you can feel free to punch me in the face many times).
Passing by reference is also good. It gives you more options. I personally liked pointers just fine, but whatever floats your 1984 Ford Taurus. It isn't all that different from ansi c stuff.
Everything else in c++ that I can currently think of should have been left off or done some other way. The whole using namespace std stuff is bad. It makes code less readable. Templates have a different problem. They don't look like anything in C. They use greater than and less than signs instead of parentheses, which would be inconsistent, but would look better. There is no case in C that I can think of where you would put things in angle brackets.

Disclaimer: All of the stuff I said is just my opinion, and I am an idiot. Please disregard anything that conflicts with anything you think. Use the rest as evidence that you are right, have always been right, and will always be right.
For those of you who have taken time out of your day to read this foolishness, I am sorry. Please don't bother yelling at me and correcting me. I know I am dumb and probably off topic (It seems on topic to me, but I have been up for 30 hours). I am sorry to have robbed you of thirty seconds of your life. Know that I will use them well.

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

[Anonymous Coward]

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

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

[timmyd]

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

sorry dude, I already tried that...and it didn't work. I thought LaTeX would work, but didn't get results there either.

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

--

Then why does nobody use them?

[Anonymous Coward]

Because they're like Pascal: At no point to they intersect with the reality of computer programming. They're not tools for expressing algorithms and data structures. They're didactic lectures about somebody's ideology. All such languages are doomed to failure, as are purely "pragmatic" languages like Basic (because Basic is in fact pushing an ideology of its own, namely that languages should be inelegant, fucked up, and useless. The idea seems to be that idiots will have an easier time learning a language if the language is as idiotic as they are). C++ is reasonably thoughtful, clean, and elegant, but it's not dogmatic. Principles aren't an end in themselves. They're just a useful guide.

C++ vs Objective C

[Anonymous Coward]

C++ and objective C are both object oriented extensions to C. Do you have any thoughts on why Objective C is so rare & unknown, whereas even non-computer people have heard of C++?

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

[Panaflex]

You go brother man!! You nailed it!

I think that the biggest problems with C have been solved with better implementations of libc personally. If you are looking at C++, take a look at java first. Because you can comprehend it.. it is very comprehensive, yet it manages to all fit (design process wise) that C++ always seemed to suck at.

Anybody that hasn't taken a look at glib is really missing out on some great new C features that you will soon not be able to live without. (glib != gnu lib c)

Pan

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.

Re:C++ complexity vs. OOP simplicity

[Esperandi]

I think its pretty easy to see why C++ is so huge and unwiedly. They took teh OO concepts which were simple and wrapped it around C instead of inventing an entirely new language. This was both good and bad. Bad because it made the language balloon and become obtuse like it is, good because people moving from C are used to the syntax mostly.

I can think of some things that could easily improve OO languages, both C++ and Java... why are constructors and destructors so weird? They stick out like sore thumbs and feel like a hack. Named the same as the class, no return type at all, etc... the destructor is even worse with its tilde.

My recommendation to solve at least that one problem in both. A classes constructor is called classname.new(). A classes destructor is called classname.delete(). Simple. Makes sense. Inside those functions you use the standalaone new and delete things. Outside, when you want to delete a class you simply do classname.delete();

Esperandi
BTW, Eiffel is what happens when you make the language from scratch without trying to steal syntax... and Eiffel kicks some ass for OO stuff.

Re:C++ complexity vs. OOP simplicity

[jejones]

...and I doubt whether there are any individuals (besides you, that is) that know the entire definition by heart...

I don't even think it's a singleton set; recall the intro to the O'Reilly book titled something like C++: The Core Language, which quotes Stroustrup as not realizing the way in which two C++ features interact until someone pointed it out to him.

I think a T-shirt I had made puts it succinctly:
C++ : C :: PL/I : FORTRAN

Re:C++ complexity vs. OOP simplicity

[Anonymous Coward]

You just need to look at constructors/deconstructors differently. The declaration of a class type is a function call

Imagine a class MyClass

and the declaring foobar of that type:

think of MyClass foobar as MyClass(foobar). There would be no plausible reason to return anything, so to help you remember that, you are forced to have no return type. It is the same for deconstructors, and the ~ differentiates the two.

Re:C++ complexity vs. OOP simplicity

[Anonymous Coward]

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.

Those who will not reason, are bigots, those who cannot, are fools, and those who dare not, are slaves.
-George Gordon Noel Byron (1788-1824), [Lord Byron]


You sound like either a fool, or a bigot.

Have you ever even taken a look at the Java language spec? It's considerably smaller than C++'s language spec, yet it contains almost all of the useful features of C++, and many features that I wish C++ had. Most of the "features" that C++ has but Java doesn't are more like mis-features. Things like object-slicing, operator overloading, the near impossibility of writing exception-safe code, the ability to throw undeclared exceptions, the ability to throw any kind of object (even non-class instances), platform dependent datatype sizes, a non-unified class hierarchy, the need to use forward declarations ad nauseum, non-final non-virtual methods (and by default!)... blech.

The one thing I wish Java had that C++ has is generics (or "templates" in C++-speak). There are groups working on this.

Re:C++ complexity vs. OOP simplicity

[BuffRyder]

if you want code that you can comprehend try Pascal.

Re:C++ complexity vs. OOP simplicity

[Old Wolf]

You seem to have some ideas which you haven't thought through.

If you want your destructor and destructor to have different names, define your functions New() and Delete() or whatever, and make the constructor and destructor call them. Your suggestion seems rather cosmetic than functional.

Of course they have no return values - C++ syntax allows for no capturing of a 'return value' at the point either of these functions is invoked.

How do you intend to go object.New() when the object doesn't exist?

Calling the destructor isn't the same as destroying the object; rather, the destructor is called during the destruction process. Other things go on too, before and after (eg. freeing memory, calling base class destructors). Tying all this to a function call would be misleading as well as pointless.

Re:C++ complexity vs. OOP simplicity

[Esperandi]

Simple, instead of doing
A = new classname;
you do:
A = classname.new()

And that may seem odd to you if you're completely into C++ and nothing else. Its quite normal in Java to have methods called on the object name and not on an instance of the pobject (called static public methods in Java and a GREAT encapsulation method).

Esperandi
Doing classname.new() is cosmetic... what do you think this discussion was about? It's about removing the unqieldy nature that C++ has

Re:C++ complexity vs. OOP simplicity

[Esperandi]

I know how to program in C++. You need to stop thinking in C++ and start thinking in terms of object oriented concepts and how they most easily can be conceptualized. When it comes to the point "How are we going to intiate new instances of classes?" and you elect to invent weird interfaces (how much sense does the tilde make?!) instead of simply building some overloading (an object priented concept) onto it. All classes get inherited down from some UberClass which has a virtual function .new() and .delete() which are public static procedures (C++ doesn't have these at all), you overload those for every class that needs it, for others it inherits the default behavior.

You can't say "Let's see, how can we improve C++" and the insist on not improving C++ because you've already bent your thoughts around it and don't want to do it differently unless theres a really good reason to do it the C++ way. I don't see any reason to invent 2 new keywords into the language, invent a couple new conventions for declaring classes, etc, when it can all be done within a holistic OO framework quite simply.

Esperandi

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?

Re:Eiffel and other languages

[WeiszNet]

I think I remember a quote from Bjarne (probably from http://www.elj.com) that said s.th. like: "I prefere to have as less to do with Bertrand Meyer as possible". But please take that with a grain of salt, since my memory may fool me. Still it would be interesting to hear a brief description of what Bjarne thinks about Eiffel and Bertrand. I simply cannot believe that someone who has invested so much time in developing a computer language and is doubtless a very capable mind, does not value Design By Contract (TM) (;

Isn't OOD/OOP only the small picture?

[Mongoose]

Aren't design patterns and modular design the real selling points of C++? You can easily write stand alone objects and make them into shared objects, and this gives you real power. I personally wrote classes in C++ for FTP, HTTP, NNTP, etc - then combined them inside an shared object with a shared interface ( Url ). Now anyone can 'plug-in' and have these features with a great OO interface to my module. Java can't do libs - that's always made it look like a toy langauge to me.

Re:Isn't OOD/OOP only the small picture?

[MosesJones]

Java can't do libs... Ummm take a look at Alphaworks to find a whole array of library type components for Java, also look at the Java Media Framework, Java TV and Java Speech to give an idea of the level of support available in the Java community.

I don't want to start a flame war, but Java certainly can do "libs" they are just called "jars" instead.

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.

Re:Read _The Design and Evolution of C++_

[Anonymous Coward]

yeah but it's really out of date. I'd like to see something on the evolution of C++ after the ARM...supposedly Koening is working on this, or Daveed, does anybody know status?

One of the things that is not covered in these books, which I would find quite useful, is the whole history of the library design. C++ gets a lot of knocks on it's standard library, and I'd really like a good book that explains the designs used for iostreams and locales. Getting this stuff out of the people who wrote those chapters is painful...

Actually I would be interested in Bjarne's thoughts on C++ library design in general...which ones he thinks are good, which ones not so good, and why

C++ portability & Exceptions/RTTI/Namespaces etc.

[BeardStreet]

Mozilla's C++ Coding Guidelines from 1998 at http://www.mozilla.org/hacking/portable-cpp.html advise against using C++ templates, exceptions, namespaces, and Run-time Type Information (RTTI) in order to meet their portability requirements. When can we expect that these features will be uniformly implemented across different platforms?

If true, this would have happened years ago

[rambone]

Firstly, OO, in the sense of programming languages, makes no sense in relation to hardware.

Secondly, OO has been hashed around for twenty years now...with limited success. No one really believes that it is a panacea paradigm that should be translated up and down the system hierarchy.

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.

Re:If true, this would have happened years ago

[zak]

As I understand it, what you are suggesting will work well on an Actor-based system. If I am misunderstanding your intention, please correct me.
Most OO languages do not natively support this paradigm, instead allowing several threads of control to invoke methods, making their implementations inherently stack-based. Also, programs written in actor-based languages have been found to be generally much more difficult to maintain and debug than their "regular" counterparts.

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.

Re:If true, this would have happened years ago

[StillNeedMoreCoffee]

Firstly, OO could be supported by hardware, why not>? We have had machines that supported Pascal, Cobol, and even APL on a microcoded level. Pascal which was written in pcode for a pcode virtual machine had a pcode microcoded processor from DEC, IBM had an APL microcoded machine.

You might say, well these are procedural machine definitions and you would be right, but they are only because of the computing environment available and targeted by the laguage writers.

And it did happen (in a sense) years ago with the Burroughs B1700 which was a micro coded machine that when it task switched, would load in different microcode for the task being switched in (as my understanding and memory go). The machines read in could even reconfigure the machine word size so you could be process switching between a 32 bit Cobol machine and a 64 bit Algol machine.

I suspect the same model of machine could have a seperate task for each object, configured optimally for that object ...

Here is a description from the Unisys site on the B1700:

In the small computer market, the company introduced the B1700 in 1972 to compete with IBM's System/3. For a small machine the B1700 was very remarkable in that it provided virtual memory capabilities and variable micrologic in the processor, so that it could behave as either a word or character-oriented machine. Burroughs provided interpreters for COBOL, FORTRAN, BASIC, and RPG as well as emulators for the older B200 and B300 machines. The various models of the B1700 had from 24,000 to 378,000 bytes of memory and sold for $22,000 to $87,000. Sales of the 1700 series were relatively strong. The Yugoslavia n State Bank ordered 74 of them for use at its branches and in all, over 1300 B1700s were sold during its first three years. Burrou ghs 3d gen newsletter

Too bad OO was just a glimmer then.

C+++

[bero-rh]

If you were to create C+++, how would it be different from C++?

Would you do anything different if you didn't have to care about backwards compatibility?

Re:C+++

[Anonymous Coward]

I think it would have to be notated as:

(C++)++

Re:C+++

[wendell]

Actually, (C++)++ is syntactically senseless, because the '++' postfix operator returns an "anonymous" value, i.e. the value of the variable before incrementation. Appending yet another postfix '++' only increments said anonymous value, which essentially has no effect, since it vanishes into the ether with the enclosing statement's end.

I guess what I'm trying to say is don't be a smart-ass if you aren't actually going to say something smart.

Re:C+++

[face]

What about "C += 2"?

Re:C+++

[Anonymous Coward]

how about... C+++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++ +++++++?

Re:C+++

[Edward Kmett]

Nah, you'd need to notate it as C+=2

(C++)++ won't do the second increment.

++C++ might though, because the prefix would get applied first, which would return a valid object for the postfix ++ to operate on.

Re:C+++

[Anonymous Coward]

don't be a smart-ass if you aren't actually going to say something smart.

Its not syntactically senseless, since the compiler will accept it. It might or might not be semantically senseless, depending on what kind of variable C is. The ++ operator for C's class or superclass(s) may or may not be implemented to have a side effect possibly on some other shared object's state. If it does have a side-effect then (C++)++ would have semantic significance.

None of this alters the fact that as a serious programming language C++ sucks, while Smalltalk and Modula3 rulez.

On a more serious note, those wanting to look at examples of C++ coding "done right" could do worse than look at some of the BeOS GUI framework code. Those guys are true C++ pragmatists, but in a good way (unlike the C++ imbeciles from Redmond who came up with "message maps" shoot them!)

This is not a troll

Thank you

dmg

Re:C+++

[AndrewHowe]

Actually, the compiler won't accept (C++)++ because the result of (C++) is not an lvalue, it's a const temporary, and you can't ++ it.
You could write (C++)+1, though.

How does BeOS send you messages, then? Does each window have a massive virtual function table, or is there some trickery involved? (Which is all MFC message maps are, of course...)
Andrew.

Re:C+++

[Anonymous Coward]

the result of (C++) is not an lvalue, it's a const temporary

Oops of course you are correct. That'll teach me not to sound off. The link to the BeOS framework documentation is here.

Information on programming Be message loops is here

The bit which I think makes it cooler than MFC is that it does not rely on ugly macros to implement the dispatching.

I really hate the unaesthetic use of macros. I wonder if the "large vtable issue" is still an issue these days ?

At one point I considered learning Win95 MFC "for fun" in my spare time. When I got to the bit in Prosie's book about message maps, I decided to spend the time on something else.

Re:C+++

[RMuttEsq]

Try this: struct Banana { Banana operator ++ (int) { Banana b; return b; } }; void main() { Banana C; C++; Banana D = (C++)++; }

Do you..

[Anonymous Coward]

...ever program in English. I read one of those ABC books and it made a lot more sense then just the C one. You should try English, it's fast (but not as fast as Mexican) and easy, I learned it just by listening to my folks, and EVERYONE understands it, even the angry man at 7-11. He's really stupid (and so am I if you believe him) and he writes English all the time, and so do I, so you should too.

c++

[llornkcor]

Other than designing and implementing c++, and writing books and papers about the language, what do you use it for? i.e. what programs have you written with it? or What are those programs used for?

Fuck off moron (Re:Fuck off, spammer.)

[angelo]

The word is flooder, not spammer. This is not email, and it was quite on topic. Not to mention funny.

Smalltalk - dead for a reason

[rambone]

Its an amusing OO tool for illustrating concepts, but Smalltalk's hardware-agnostic design simply couldn't perform as well as C.

Re:Smalltalk - dead for a reason

[Greyfox]

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

Re:Smalltalk - dead for a reason

[Creepy]

There's more to smalltalk being "dead" than that. Both C++ and Smalltalk are based off of Simula67, which isn't exactly the most popular language. C took off as a popular language because it was portable over different hardware. In the mainframe days this meant you didn't have to learn a new language with every new machine you went to, thus you could learn one programming language and work on many systems. Smalltalk was invented as an entirely new language with ideas taken from Simula67. C++ chose a different route, extending C with Simula67 ideas (classes, inheritance, etc). Since most programmers were familiar with C, picking up C++ was easy compared to completely learning a new language like Smalltalk, and thus C++ became the more popular of the two.

Smalltalk did have a chance, but Steve Jobs blew it. Had the Mac chosen to use Smalltalk rather than Pascal, the language would have had a much better chance to catch on. When windowing environments came to their own with the mac, programmers needed to learn a whole new set of APIs to be able to write programs in them. Everything defined as a pascal function could have just as easily been defined as a smalltalk object, and be easier to implement (imoho). Not to blow holes in your speed argument or anything, but if speed is everything and native assembly is faster than C, why don't we all still write in native assembly?

I wouldn't rip hardware agnostic design, either. Java wouldn't exist if it hadn't been portable (it was designed for embedded systems, after all) and C would have died as soon as the mainframe or minicomputer it was first designed for/on was gone.

Re:Smalltalk - dead for a reason

[Anonymous Coward]

In fact, modern Smalltalk implementations run as fast as C for all practical purposes, and the developer is 10 times more productive. But don't let facts get in the way of the bigotry.

C++

[Signal 11]

What do you think of Effiel?

Re:C++ a heap of crap

[pivo]

If ignoance is bliss, you must be very happy indeed.

Dude, Scandinavian Battle to the Death!

[Anonymous Coward]

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

Re:Dude, Scandinavian Battle to the Death!

[CYberPhreak]

Scandinavian battle between Linus and Bjarne? Sorry to disappoint you, but our God, Mr. Torvalds is not scandinavian. He is Finnish. I only bring this up as a matter of setting the record straight.

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

Schools also taught Pascal. Where is it now?

[rambone]

I tend not to put too much stock into the language choices of academia. Often, departments are involved in deals with tool and language vendors to push a particular language.

As for "a trend towards simplicity"...please tell me what is simple about Java. I understnad the base language syntax is fairly clean, but in terms of tools and implementations, Java is a mess. There are serious discrepencies between the JITs, JVMs, JDKs, browser compatibility etc. that are not trivial for a new developer to deal with. Contrast this with Perl and Python - there is one developer kit, and it runs in a similar fashion on all platforms. Added to which, Java programmers must deal with compatability and support issues (since "write once, run anywhere" is not and will not be a reality), that Perl and Python users typically don't have to deal with.

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"

Large Systems

[Artie FM]

There is still the potential to make C++ much easier for people trying to do hard things. What kind of tools do you feel are needed to improve C++ usability for people creating large systems.

--
Be insightful. If you can't be insightful, be informative.
If you can't be informative, use my name

When Hell Freezes Over

[rambone]

Compiler support isn't the issue with these features - its code bloat. Templates I can deal with (sometimes), but RTTI is going overboard.

Re:When Hell Freezes Over

[Why2K]

Compiler support isn't the issue with these features

Did you actually read the rationale at the link posted above before you offered your opinion?

Don't use the C++ template feature. This feature is still not implemented by all compilers, and even when it is implemented ... It is very likely that other "simple" template code will break some poor compilers which we need to support.

...

Exceptions are another C++ feature which is not very widely implemented, and as such, their use is not portable C++ code. Don't use them. Unfortunately, there is no good workaround that produces similar functionality.

...

Run-time type information (RTTI) is a relatively new C++ feature, and not supported in many compilers. Don't use it.

...

Support of namespaces (through the namespace and using keywords) is a relatively new C++ feature, and not supported in many compilers. Don't use it.

etc, etc, etc.

I agree..just want to hear him say it!

[rambone]

In my mind, OO is the biggest bit of snake-oil to be sent into development shops in perhaps the entire history of programming.

In my opinion, if it ain't working after twenty years, it ain't going to work.

Not nearly enough is written about the negative issues regarding OO.

Re:I agree..just want to hear him say it!

[Redundant()]

There are still a lot of middle aged programmers out there stuck in the habit of procedural programming. After twenty years of writing cobol one is tempted to declare all their C++ variables external and write procedurally ;). I am sure there are ways to make the rather large paradigm shift easier, what is the best technique?

Objective C

[Scott Wunsch]

What's your opinion of Objective C? Why do you think C++ is superior? (Or do you? ;-) )

Re:Objective C

[Eric E. Coe]

Objective C kicks C++'s ass. Just a few simple easy-to-learn syntax extensions over C (the syntax can be learned in a day), polymorphism is automatic (no #$%@#&! virtual keyword needed in the (possibly compiled) superclass), Class Objects, soft typing, generic Collection classes, more freedom of expression, no B&D/fighting with the compiler, no funky language-within-a-language (templates), etc. The only thing it is really missing is user-defined inheritable class (as opposed to instance) variables.

I'd be using it (or something like it) more often, if I wasn't having so much fun with Perl, (and getting to skip that compile/link step in the bargin).
--

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

[randombit]

Templates come to mind but also such things as macros (eeeww).

Templates are actually much safer than things like the Java Containers, since you can enforce at compile time the types that can be contained within them. (Admittably I'm not too familiar with Java, and if you could explain further I would like to hear it).

Macros are there only for C compatiblity. Even Brian Kernighan doesn't like them:

"The reason [for using macros] is performance: a macro avoids the overhead of a function call. This argument was weak even when C was first defined, a time of slow machines and expensive function calls; today it is irrelevant. With modern machines and compilers, the drawbacks of function macros outweigh their benefits." - The Practice of Programming, by Kernighan and Pike.

I hate macros that do anything - conditional compilation I'm OK with (though it's way overused a lot of the time, IMHO). In a library I'm working on that currently has ~14000 lines, there are exactly 2 macros, both of which are only defined inside a single function.

I could go on for quite some time about all the little things that are wrong with C++, but as someone once said "If you don't like it, go invent your own language". :)

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

[UnknownSoldier]

> Macros are there only for C compatiblity. Even Brian Kernighan doesn't like them.

Technically Macros ARE NOT part of the language - they only exist in the preprocessor.

> The reason [for using macros] is performance: a macro avoids the overhead of a function call

Macros still have their place, as they are GUARANTEED to be inlined. "inline" is only a HINT to the compiler. i.e. Usually a 'debug' version ignores them.

Cheers

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.

www.gentus.com

[Anonymous Coward]

Oh, my...

COVERED IN FAQ - MODERATE DOWN

[Life Blood]

I believe the fundamental nature of the questions to be asked were ones not covered in Stroustrup's FAQ. This post is. Sure this flood is funny, but it also fictional and probably offensive to Stroustrup.

Re:COVERED IN FAQ - MODERATE DOWN

[Anonymous Coward]

This post is stupid and should definitely not be moderated up... Maybe a little reverse psychology will work...

Except now you've revealed that reverse psychology is at work, meaning that moderators will moderate you down instead. ;-)

ISO C9X

[Anonymous Coward]

Now that the C9X is the official C standard, don't you think that C++ is a bit poor in *real* capabilities (ie. not just a question of writing style) ? The official C reference is a lot more precise than C++, making the C language a lot more portable than C++. The new C standard has also terrific arithmetic features and supports better internationalisation than C++. The preprocessor itself, can handle Unicode characters, pragma with macross, variable-length macros, etc... There are also new types and qualifiers like 'long long' and '_Complex' that C++ can't handle outside of an emulation in classes. C is not a subset of C++. C++ lacks a lot of things that C has now with C9X. So, for object programming, Java, Objective C and Eiffel rules, while for dirty and optimized code, C is a lot better, safer and more portable than C++. Is there any interest in keeping that language ?

C++ Marketing

[Artie FM]

I've seen interviews where you remarked on the successfulness of Java saying how interesting it is to see what a powerful company can do with a marketing campaign.

I thought that was a very interesting comment because it supposes that the real reason Java has taken off is not because it's better than C++, but because Sun pushed it so well. In a way the groundswell of support Java has seen is similiar to massive push by developers toward open-source software.<P>
But what if we could take that kind of effort and put it into pushing improvements to C++ libraries or tools. Is there anywhere we could expend that kind of effort and actually see benefit?

--
Be insightful. If you can't be insightful, be informative.
If you can't be informative, use my name

Re:C++ Marketing

[Artie FM]

I've seen interviews where you remarked on the successfulness of Java saying how interesting it is to see what a powerful company can do with a marketing campaign.

I thought that was a very interesting comment because it supposes that the real reason Java has taken off is not because it's better than C++, but because Sun pushed it so well. In a way the groundswell of support Java has seen is similiar to massive push by developers toward open-source software.

But what if we could take that kind of effort and put it into pushing improvements to C++ libraries or tools. Is there anywhere we could expend that kind of effort and actually see benefit?
--
Be insightful. If you can't be insightful, be informative.
If you can't be informative, use my name

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

Re:C++ Implementations

[Anonymous Coward]

Just curious - what features of standard C++ are not implemented in MSVC++ ?

Re:C++ Implementations

[Anonymous Coward]

Just curious - what features of standard C++ are not implemented in MSVC++ ?

The compiler doesn’t allow you to initialise pointers with the (...) syntax.

For instance, this fragment (legal code according to Microsoft’s manual) won’t compile:

Window StandardWindow;
const Window* pStandardWindow( &StandardWindow );

memory management

[Anonymous Coward]

I come from a Perl background, and am in the process of teaching myself c++. It seems to me that both c and c++ as systems programming languages, are obsessed with memory management-related techniques. (for instance, a programmer should choose when to use call-by-reference or call-by-value for certain things.) My question is: what do you think will be the future of memory management functions in systems programming languages? Do you see more memory management and code optimization mechanisms creeping in, or less?

Importance of C++ to our national economy

[Anonymous Coward]

Did you know that no question ever asked by an AC has ever been sent to any interviewee in the history of slashdot? Do you think that is fair? Or are you just another karma builder yourself.

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?

Re:Reaction toward C++ bashing?

[Anonymous Coward]

"There are only two kinds of programming languages: those people always bitch about and those nobody uses".

See Bjarne Stroustrup's net posting answering some unfair criticisms of C++ .

So he could exactly see this as an indication of how much C++ is being used and feel complimented. :-)

What do you think of the STL?

[stripes]

For the first five years I used C++ I allways thought of it as C with a little bit of OO stuff slapped on it. After I started using the STL C++ started feeling like a very diffrent (and more usable) language then C.

Is the STL really that much diffrent from other parts of C++? Or is it just me?

Re:What do you think of the STL?

[David Greene]

You've hit upon the famous "Bell Labs proverb:"

Library design is language design.

And also Koenig's addition:

and vice versa.

The reason STL makes C++ feel more useable is that it eliminates much of the tedious work done in C (defining basic data structures and algorithms).

That being said, there are aspects of the STL (actually the C++ standard library in general) which just make me cringe:

• Iterators don't know about their container objects
• The incompatability between STL iterators and, say, string iterators
• Missing operator+/operator- on non-random access iterators (yes, I know about advance)

I understand the reasons for each of these, but each has also tripped me up more than once. The string class in particular is a bit kludgey.

If I were to ask Bjarne a question, it would be "Ignoring backward-compatability issues, what would you change in the standard C++ library?"

--

Two Questions, Reading C++/Extra Libraries

[caolan]

Just a point or two.

I recently returned to c++ after picking it up in college about two or three years ago, and boy was I surprised! New cast operators all over the place, new throwing an exception being the default behavior on failure. STL becoming core functionality and so on, not to even mention RTTI, bool types

Took me a little time to get back up to speed with it I have to say, but all in all I do like most of these features, I have great time for STL, we've been wasting our time writing sorts and searches for so long that its nice to drop kick that issue out the window. A bool type is cute, and even if the only use for exceptions was a throw from new its worth it, at least the guilt factor of not protecting every appearence of new with a NULL test can be dispensed with.

But on with the questions

One: One advantage of C over C++ which noone else seems to have a problem with is that when you are handed a huge stack of code and go to fix a bug or make a small modification, on viewing a chunk of code in C you can assume that most functions will only modify the state of variables that are explicitly passed to them. On viewing c++ code that has a function call, you have to refer to a header to determine if its a function call or a method belonging the the class whose code you are trying to read.. If its a member you have to read the code of that method to see if it is changing the internal state of the object, and if it calls other methods you have to chase all of those down as well to be assured that the state of the object will remain unchanged after a method call that takes no immediately relevent arguments (Obviously keeping an eye out of operator overloads as well, though to be fair you can assume that they will follow the normal behaviour and not modify the object, and behave intuitively)

In one sense from the perspective of someone trying to maintain c++ code, an attempt to understand its logic faces the same difficulties as understanding horrific global variable ridden c code.

Was there ever any actual language constructs considered for this problem ? Granted proper coding practice with consts etc etc can sort out a lot of the problem, but there is still the need to refer to the headers continually, but a good programming editor could sort that out, and so on, but it just strikes me that these are obvious external work arounds for a problem which might possibly be dealt with at a different level. Maybe something like...

1. Only member functions can be called from inside other methods unless a scoping operator is used, so you know immediately if a member or a function is being called
2. Some of the information about how the method modifies or does not modify the object is coding into the name of the method itself, yes yes hungarian notation and dragging me off to the stake, but you know what I mean anyway.

Two:STL was a definite change away from c's philosophy of minimum requirements and towards a more javaesque conglomoration of a programming language and a more feature rich standard api.

I could quite easily imagine threading becoming part of the c++ standard in the future, whereas I could never see something like that happening to c, likewise serialization (Id really like that actually), and a whole other set of currently specialized and large library addons. Would you favour this approach, STL allowed us to stop fiddling with lists, wouldn't adding other libraries to c++ make us more productive ? I can see that we don't want to get stuck with a library which turns out in a year or two to be worthless because of changing technology but then cannot be gotten rid of for 10 years because of standard complience inertia, but perhaps c++ complience levels, level 0 just the language, level 1 the iostream and friends, level 2 networing classes and level 3 a java style api

C.

Just One Question:

[pb]

Why? Oh God, why? Oh, the pain, the pain!

Oh. Um. Sorry. Just kidding.

What I meant to say was, do you think that an obfuscated C++ contest would be more fun than the traditional one?

'Cause you can still do all the ridiculous things that C lets you do, but now you can also overload operators (like ++, yeah!) to do stupid things (like take the square root if it's on the left, and take the cosine otherwise, yeah!)

And then you can make a couple of classes, and merge them together, and have fun function naming clashes, that's pretty cool too. Or pass 'this' around, or use templates for no reason at all... (and attempt to pass them to the C library Quicksort function!)

I mean, really, C++ has so much more potential here. It's a valuable addition to the set of programming languages that promote obfuscated programming and maintenance code. It's years ahead of BASIC and Perl, IMO.
---
pb Reply or e-mail; don't vaguely moderate.

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.

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

[jjoyce]

Bjarne already answered that in The C++ Programming Language. Something to the effect of, "Don't use realloc(). Use a vector instead."

Mankind has always dreamed of destroying the sun.

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

[TriangleMan]

One thing that an operator renew[] would require is a "mover" on classes that you wished to renew[]. I.E. just like some classes have constructors and/or destructors, you'd need to have an operator that moved the class in question. The problem this "mover" addresses is a common problem moving from C to C++ and from structs to classes. You see, realloc's primary use is that it can allocate a new heap area, move bytes from the old to the new, and deallocate the old. But operator renew[] would be moving objects, not bytes. And moving objects is not something that is currently directly supported by C++. Such an operation could, in most cases, be implemented as a copy-constructor call followed by an explicit destructor. But not all classes that you might want to renew[] are going to have copy constructors. In these cases, you want some sort-of move operator. Note that this is something which is totally doable in the current C++ language. In fact, I actually wanted to to do something like this in a project once -- I had some non-copyable-constructable objects that I wanted to put into a vector. And so I ended up hacking a version of the STL vector class such that it used: template void move(C& src,C& dest) { new(&dest) C(src); src.~C(); } to add/relocate objects in the vector in stead of copy/delete. The above implementation was, of course, the default impl, but of course any class or set of classes could specialize this. Another interesting aspect of this would be that a "move" operator such as this, in a garbage-collected version of C++, would integrate well with copy-collection.

So all that said, I'd love to hear what Stroustrup thinks of this. Is this something useful and worth standardizing, or just an idea that a particular app happenned to find useful?

Best Practices

[Artie FM]

What do you feel are the "Best Practices" for C++ developers to adopt?
--
Be insightful. If you can't be insightful, be informative.
If you can't be informative, use my name

ISO standardization, hindsight

[Anonymous Coward]

Was it worth it? How do you think this helped? How did it change the language? Do you see Java's continued failure at standardization as a potential flaw, or one that will be eventually brought into some kind of standardization process?

(supposedly one of the reasons Sun is so reluctant is because the C++ standardization process took so long.)

Next generation language

[bartok]

Considering that all things evolve and that, eventually, C++ will make room for a higher generation language, what features do you consider as critical to a next generation, post C++ language? Is there any language existing today that comes close to what you envision it to be?

Re:Next generation language

[Esperandi]

IANAB (I Am Not A Bjarne), but I personally think that a language like Eiffel or possibly Eiffel itself will really be the next generation language. Tim Sweeney (creator of ZZT with OOP, code on Unreal and UnrealScript) wrote an article for Gamespy discussing what the next language would be. He nailed the features that Eiffel boasts one by one. I emailed him and he said he had been looking at Eiffel and it looked very promising, so at least someone is looking at it ;)

If Eiffel does not take over, I am betting the next generation language will mimic the features of Eiffel and most likely the implementation style. Eiffel compiles down to a form of bytecode so that incremental builds are *FAST*. Another big thing is that Eiffel supports a lot of things only in the debug phase. While debugging, it can set limits on a variable and throw an exception whenever that variable goes out of bounds. It can guarantee preconditions and postconditions easily, etc. All of these things would cause extreme code bloat and slowness if compiled into the final, but Eiffel doesn't do that. I don't think the next generation language will either, I think compiling a debug and a release build will be radically different from the compilers point of view. Eiffel compiles to bytecode for debug, and to system native code when building a release.

Esperandi

Re:Next generation language

[WeiszNet]

When I read your comment I remember a sig I see regulary on usenet: "Those who do not know Unix are doomed to reinvent it, poorly". I guess that holds up for Eiffel too.

Next Frontier = Higher levels of abstraction ???

[SMN]

Coincidentally, I was just reading your book, _The C++ Programming Language_, 30 minutes ago - let me take a moment to say that I'm very impressed by it. On to the question:

Recently I've seen a couple different articles calling for the 'next' programming language, something to go beyond C++. Specifically, there's <A HREF="http://www.gamespy.com/articles/devweek_b.sh tm">this piece by Tim Sweeney</A> and <A HREF="http://slashdot.org/articles/00/01/25/150238 .shtml">its coverage on slashdot</A>. Tim is the lead coder for the Unreal game engine.

In the article, he discribe's his thoughts on what new programming languages should focus on, which seems to boil down to higher levels of abstraction. One example he gives is having two arrays, A and B, and being able to add them directly (C = A + B;) rather than using a loop to do so with each individual element.

Having just read part of your book, I see that you noted that you agree with C's very low level primitive data types, which seems to be the opposite view; yet the addition of classes seems to be a move toward more complex data types.

My question is, do you think a more high-level/abstract language would be useful, or do you think that we should stick to fairly low level but complex languages like C and C++?

And, on a slightly relatated note, do you think that future languages should mimic the C/C++ grammar, or do you think a more intuititive one is possible?

Drooling imbecile.

[Anonymous Coward]

Flooder, spammer, whatever.

It was semi-funny the first time I saw it, but that was a long, long time ago.

library issues

[Anonymous Coward]

what's a good c++ library, in your opinion? ACE? GTK--? Libstd++? Almost as interesting, what are examples of poorly-designed libraries, and why?

(And why these interfaces of all abstract MF's?)

Question for Mr. S.

[Esperandi]

Do you believe that implementing Design by Contract, invariants, and other features present in Eiffel in C++ would be a good idea? or at least a really cool one?

Esperandi

True, but you're wasting your breath.

[Anonymous Coward]

The average SlashBot is totally incapable of grasping the difference between a high-level language and a low-level language. They'll never understand why C is efficient, or why an operating system kernel does not store numbers as string representations of base 10 integers. All they see is the surface, and damned little of that.

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?

Question:

[MattLesko]

Do you feel that backwards-compatability with C spoiled C++? I often hear peoples laments of C++ for including these (to them) outdated features. This I believe is also why many like Java, which is more like C++ would of been without the C compatability. Do you have any regrets for sacrificing clarity for compatability?

message passing vs. generic function

[profBill]

One way (one of many I suppose) to divided object-oriented languages is based on a kind of philosophical choice. On the one hand are languages that rely on "generic functions" such as C++ and CLOS (of Lisp), and on the other hand are those language that use "message passing" such as Smalltalk, Objective C and others.

While it isn't clear that it has a great effect on the user, each has a very different flavor. Smalltalk sends a "message", with typed arguments, to the "object" for the object to disambiguate what to do next. C++ creates a "generic function" which indexes the appropriate function based on that function's typed arguments (name mangling).

1) Is that a fair distinction?

2) If so, do you think the differences are important?

3) If so, why did you go the route you did with C++?

What is the ultimate generalization of C?

[exa]

I understand that you had tried to make the most sensible generalizations to C language while working on a large project. Obviously, the OO extensions have proved to be the most useful, and C++ has been seen as the prominent OO language for many years.

In one of your interviews, you had stated that you had a much more "generalized" language in your mind, that is, when compared to the ISO C++ standard and the previous implementations. I wonder what you would deem the ultimate generalization of C as a mathematician.

Thanks,

C++ invented on a bet?

[zanzar]

I heard from a grad student at my college that the language of C++ was invented on a bet that you couldn't do it. I was wondering if this was true, and what else inspired you to invent this language.
+++

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.

Re:Metaobject Protocol for C++

[nonya]

I hate the name "Metaobject Protocall" (MOP). It sounds academic - not something that a working programmer would ever make use of. I would like to (briefly) describe what a MOP is and why it is useful.

A MOP opens up a compiler in controlled ways. You define call-back functions that will be called when the compiler recognizes certain constructs - like defining a member function, assigning to a class, or using a class in an expression (like vector a+b). There will also be ways of finding and changing a class's members and base classes. The way you define these callbacks, is through metaclasses. It's easy, but not really that important for this brief introduction (see OpenC++). A not-so-bad way to think of a MOP is as the builder pattern.

That's the mile high view. Now, what can we do with it.

• Before/after methods. Originally, Stroustrup had before/after methods in C++ (he took them out after he found he was the only one making use of them). Before/after methods could be defined for functions so when the function was called its before method would be called first, and when the method returned, its after method would be called. This was useful for locking and unlocking semaphores (for example). Now, with a MOP, this is easy to implement. Everytime a method is called, we can use our hook into the compiler to insert a call to our before method and after method.
  
• Delegation. The decorator pattern uses delegation as its implementation. Consider a graphics class hierarchy: class Graphic; class GraphicDecorator : public Graphic. GraphicDecorator has a data member of type Graphic*. It needs to forward all of its function call to its contained graphic. This is straight-forward, but error prone. If we add a new function to Graphic, we need to remember to add it to GraphicDecorator as well. With a MOP, we can automatically build an class that delegates its function calls.
  
• Mulidispatch. I built code that does double-dispatch for C++ (for the visitor pattern). The implementation to make the function call was pretty straight forward: some tables of pointers to members that are indexed by the parameters (a virtual function call on the parameters to get the correct index). While the code to make the call was easy, building the tables was not. To build the tables, I needed to know and the inheritance tree. While the compiler knew this, I couldn't get at it. So I had to build code to automatically create this information at "static initialization" time (I don't know the correct term). This was especially challenging because of static initialization ordering problems. With a MOP I can directly access the inheritance tree. I don't have to build it myself. As a side note, Stroustrup did consider putting multidispatch into C++, but decided against it because it required too complex a linker.
  
• Optimizing vector/matrix classes. If you know about metatemplate programming (see blitz), you know you have to write some very complex code to optimize linear algebra code. With a MOP, you can use the hook to translate expressions to do these optimizations much more sanely.
• Object persistence. If you want to use pointer swizzling to implement object persistence, you need to know where the pointers are on a given page. With a MOP, you can find the layout of an object and keep track of where the pointers are on a memory page.
• Writing browsers.
• Writing "bridge" code to interface C++ with other languages, like Python.

I hope this gives you a taste of why I'm excited about MOPs. I haven't written much code using MOPs (I certainly don't claim to be an expert), and I'm not sure its ready for prime time yet, but I'd love to hear Stroustrup's view on this.

-Scott

He's not a programmer, just a mindless asshole.

[Anonymous Coward]

Most likely, he's some stupid kid who failed his C++ class at the community college, and now he's pissed off because system programming languages weren't designed for the benefit of illiterate inbred cretins like himself.

There's always a flood of morons sloshing around loose on Slashdot. Ignore them.

(BTW, I'm an inch or two out of my depth talking about system programming, but is C++ really all that unsuitable? For best efficiency you might choose not to use some features, but there's a lot of yummy OOPsy goodness in there waiting for times when you can afford to use it. God invented profilers for a reason :) That kind of programming isn't for the faint of heart anyway. At any rate, I know a guy who writes NT device drivers in C++. He picks and chooses when to use what feature, and when to say "fuck it" and use inline assembly code. YMMV, obviously, and I'm interested in hearing more views on this one.)

Re:He's not a programmer, just a mindless asshole.

[Procyon101]

I would have to completely agree with you on the issue of C++ being useful for fast code. I rarely use C anymore since any compiler worth it's weight will optimize stock C++ code at least as well as C as long as I know which features to avoid when I want tight code. I know how to avoid having a vtable, when not to use rtti, etc... of course, I wouldn't expect a newbie programmer to know what is good and what is bad, so therein lies the benefit of C; it forces you to write fast code. Personally, I like the flexibility of C++.. I like efficiency, but I also like a double dispatch from time to time =-)

Re:He's not a programmer, just a mindless asshole.

[Anonymous Coward]

of course, I wouldn't expect a newbie programmer to know what is good and what is bad,

. . . nor would I expect a newbie to be writing device drivers :)

I know . . . when not to use rtti

Yeah, anytime between September 1 and August 31 :)

Certainly, full-blown OOP with virtual functions and whatnot is generally inappropriate when every cycle counts, but not cycle does always count. The important thing (and not an easy one for newbies) is to know when you must optimize, and when you can let it all hang out. Of course, this assumses that the programmer has the ability to optimize in the first place.

Re:He's not a programmer, just a mindless asshole.

[Anonymous Coward]

BEOS and NT kernel are mostly implemented in C++. Avoiding certain features in C++ makes it very fast and lean. Sometimes though it doesn't even make sense to do any compromises. If you need vtables and runtime polimorphism then trying to emulate it with arrays of function pointers will make it slower than using vtables in the first place. The moral is that C++ can be abused as can be C and any other language. C++ is not in any way slower or more bloated if used by competent programmers.

What's your take

[aheitner]

on recent ANSI committee developments, such as the deprecation of C-style casting (in favor of static_cast<>(), which in my understanding has such a long name, along with things like reinterpret_cast<>() so people would know to avoid using it)?

Will the ANSI committee leave C++ the way we knew it (obviously stuff like exceptions was a bit of a fiasco and all...)? I think at this point C++ is so popular and has such an established user base that users will be alienated by major fundamental changes to the language that start to break their old programs, or majorly affect fundamental style issues.

I think it should be obvious

[Greyfox]

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

Compilers

[Anonymous Coward]

I hate C++ because it gives me only headaches at work. The c++ compilers of different commercial unices are not 100% compatible especially when using namespaces and STL. Throw in some orbix and third party libraries and the whole place is a mess.

Have you any insights on this matter ?

Thanks

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

[Anonymous Coward]

I'm not sure exactly what that means, could someone clarify?

Does it have something to do with the abiguity of the functions below?

void foo( Bar bar );
void foo( const Bar& bar );

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

that's strange...

[Anonymous Coward]

..'cause I thought it was funny *today*. Humor relativity at work, it would seem.

Sarcasm does not make it relevent.

[GoofyBoy]

Perhaps thats not the point.

This is a call for questions, can one post relevent jokes here?

Suppose Bill Gates was interviewed. Would every Bill Gates/Microsoft is Evil joke be acceptable? When the next famous person gets interview can I post any joke about them?

Why was this even posted up to 5 anyways? How about the moderaters moderate up the questions, and not old jokes.

Re:Sarcasm does not make it relevent.

[Anonymous Coward]

Yes.

Because it's funny.

There's a choice there for 'Funny'.

It was moderated up to five because of this, and should have stayed at least at 4.

Whining about moderation is annoying. Please moderate the parent comment down. Ha ha ha ha ha. :)

The Question one should ask then is

[Raindeer]

What is your opinion on this fake interview?

Personal...

[Anonymous Coward]

Mr. Stroustrup:

In the summer of 1996, I was enrolled at a summer camp run by the IAAY/CTY (Dickinson College, Carlisle, PA). One of the kids on my floor was Nick Stroustup. He was pretty cool-- had a Weird Al CD, a laptop (a pretty bitchin' one for the time, might I add!), and an intellect and curiosity about him that blew me the hell away.

Anyway, I remember him wearing a ragged old T-Shirt that had the Bell Labs logo on it, plus something about the C++ standardization effort. I asked him where he got it (hey, it was a cool shirt), and he said his dad worked on the C++ language. He said he was from New Jersey, also.

How is Nick doing? Does he do any programming? Is he even interested in computers (he seemed so interested in *everything* at the camp that it was hard to pin down any exact likes and dislikes)?

Conformant compilers?

[jjoyce]

I like C++. I like the STL. I think the language has come a long way and is pretty easy to use just as long as you're careful. My only problem is, how can anyone write code with it with all these totally varying compilers? Have you seen the Mozilla guidelines for portability in C++? They might as well not use C++ at all. The problem is that it was standardized two years ago and as far as I know there are no totally conformant compilers out there. Does anything support the export keyword? String streams (besides CodeWarrior)? It seems to be too difficult a language to implement a compiler for. Or maybe I'm just impatient; does it really take this long for standards to be adhered to?

Mankind has always dreamed of destroying the sun.

Template metaprogramming

[SIGFPE]

Modern C++ compilers have great power via `template metaprogramming'. Using partial template specialisation we can practically write our own compilers that build on the C++ compiler. See for example the blitz++ linear algebra library or my own compile-time primality tester. Unfortunately these techniques are very unwieldy even though they can have have a great payoff for high performance computing. How do you see template metaprogramming evolving in the future and how could C++ be modified to accomodate it better?

Re:Template metaprogramming

[nonya]

Metaobject protocalls, like the one in OpenC++ is a nice way to handle the optimizations that template metaprogramming gives.

Programming in the Large vs. Small

[Christopher H]

C++ is, in my opinion, a superb language for programming in the large. It is my first choice for any programming project of substantial size, and I shudder at the thought of working on a 100k+ line project in anything else. I particularly appreciate how the strong typing facilities can be used to express and statically check many of a program's semantics.

However, when writing something smaller, I am drawn (like many people) to languages with facilities for terser, higher-level data structures and algorithms. Standard ML, Python, and even Perl make it easier to work with tuples, strings, lists, or higher-order functions. These languages sometimes permit faster prototyping or experimentation. It is easy to be put off by the sheer amount of verbiage required to write well-engineered C++ code (private undefined copy constructors, redundant include guards, the occasional ribbon cable, etc. ).

How can we bridge the gap between productivity in the large and productivity in the small?

(Note: I do not mean to imply that C++ is never suitable in the small; rather that there are many classes of problems for which different langages seem to me more productive, at least up to a certain program size).

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

i think you mean c+=2

[Anonymous Coward]

...

Embedded systems

[JDax]

What is your take on the move towards more and more code embedded in chips and how do you think C++ may need to evolve to meet that trend?

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?

C++ and distance from the bare metal

[Christopher Neufeld]

For the programs I develop at my job, I'm often quite worried about storage requirements and about execution time. I find C to be comfortably close to the bare metal, that I have a fairly good idea of what the machine code is going to be like, and how much space my structures will consume. While I use C++ for some applications, I shy away from it in this particular context because I'm not confident about how much overhead is involved in things like method pointer tables or vector operations. For my compute bound, memory-limited programs, a 10% increase in either run time or memory consumption would be difficult to justify. This is almost an implementation question, actually: are these considerations relevent with modern C++ compilers.

Re:C++ and distance from the bare metal

[ucblockhead]

1) Read "The Design and Evolution of C++". It contains a lot of information on efficiency and C++.

2) You can write something that looks pretty much like C, but compiles under C++. You can then conservatively pull in C++ features that will help you. This can help you get over efficiency concerns.

Anyway, if you learn to write good C++ code, you'll find that it is nearly as fast and small as good C code. The idea that C++ is ineffecient usually comes from people who dive in and use lots of C++ constructs without understanding the costs.

future of programming languanges

[betamax_]

Object oriented languages like C++ were as much of an advance over precedural ones as they were over assembly. Where do we go from here? What will the "meta-object" languages be like?

I've considered visual coding for this. You could create objects from templates, put them in precedures, etc. You would use only pieces of text to refer to the algorithms themselves. It can give you more control over the object hierarchy.

I've also thought of the possibility of having the abstraction go both ways. You could have an object be able to tell what other objects are encapsulated with it.

You could also have something along the lines of eval that lets lets objects spawn other objects dynamicly.

What do you think of these ideas are there any that you are working on? How do you feel that design patterns fit into this?

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?

Re:Questions for Bjarne

[SEGV]

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.

I believe C also suffers this problem, although it isn't commonly known. That is, despite what people think, C also does not guarantee that different compilers and linkers can interoperate.

--

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

[stripes]

One question is this: Is it guaranteed that a pointer to item zero in a vector is in fact a pointer to a contiguous block of memory holding an array of foo?

No, that isn't guaranteed. On the other hand, I can't see how to implment it with the time-complexity requiremnts demanded without it being an array (plus a little bookkeeping). I definitly havn't seen it done any other way.

If it is something you need (and I can definitly see the need), why don't you take the SGI STL vector class, rename it, and use it.

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

Re:Hmmm, right . . .

[Anonymous Coward]

To all intents and purposes, it is guaranteed. There is a defect report on the issue which was resolved in favour of contingous memory for std::vector, and there are no known implementations that violate it. Strostrup himself has stated (on c.l.c++.m I think - look up deja) that it is quite safe to assume that std::vector has contigous memory.

Re:Hmmm, right . . .

[TriangleMan]

Here's another way I've seen it implemented. Basically, your vector is implemented via a resizeable array of T* that points to the blocks where the T's are actually stored. Note that there may be more than one T in each block, although of course the block size has to be some constant that is the same for all blocks in a particular vector instance. One notable difference between this and the regular STL vector impl is that this unusual impl alloys you to have long-lived references/pointers to items contained in the vector. Additionally, this vector impl can be less expensive by a substantial constant factor for vectors that contain complex objects and need to grow quickly -- since when the standard STL vector outgrows its capacity, it requires you to perform a copy constructor and a destructor for each item in the vector. But this impl merely requires you to copy the value of a pointer from one memory location to another. 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. These may seem like minute tradeoffs, but depending on the requirements of your application, their importance can grow very quickly.

What do you have against C?

[Anonymous Coward]

In your FAQ, you seem to have the attitude that C++ completely surpasses C in every way and there is no reason to use C at all anymore for anything.

Is there anything fundamentally wrong with C that you do not like, or simply that you prefer C++'s architecture/design better?

It seems C is perfectly suited for many applications where C++ would offer no significant advantage.

Re:What do you have against C?

[Midnight Coder]

I think Bjarne's point is C++ is (for all practical purposes) a superset of C, so anything you can do in C you can do in C++.

And when using a C++ compiler to compile plain C (which technically is also C++) you don't have to pay for (that is incur space/time penalties) anything you don't use.

At least this was the impression I got when I heard him answer someone who asked this question. I don't think Bjarne is saying never program in plain C.

Why?

[jwhyche]

Most important question nobody seems to be asking is why did he feel the need to screw with a excellent language like C to produce this bastardization call C++?

&lttune=rawhide&gt
trolling, trolling, trolling ...
&lt/tune&gt

Why I still refuse to use C++

[Zico]

Why I Still Refuse to Use C++, by ZicoKnows@hotmail.com (picture)

It is impereteefe-a thet I geefe-a yuoo zee fullooeeng inffurmeshun, vheech Dr. Bjerne-a Struoostroop vunts cunceeled frum zee poobleec. Let me-a preffece-a my deescoossiun by qooeeckly reesserteeng a femeelier zeeme-a ooff my prefeeuoos letters: I ixpereeenced qooeete-a un ipeephuny vhee I furst reeleezed thet beffure-a I knoo unytheeng ebuoot Dr. Struoostroop, I ves oonce-a un oonluuker et a foo ooff hees mess demunstreshuns, veethuoot pussesseeng ifee zee sleeghtest inseeght intu zee menteleety ooff hees cruneees oor zee netoore-a ooff hees unecdutes. Lest soommer, I ettempted vhet I knoo vuoold be-a a hupeless tesk. I treeed tu cunfeence-a Dr. Struoostroop thet elmust ifery deescoossiun ooff unercheesm ignures zee creeticel impurtunce-a ooff hees rebeed oobeeter deecta. Es I ixpected, Dr. Struoostroop ves utterly uncunfeenced. Vhetefer ungooeesh ooff spureet it mey cust, I em veelling tu poot tu rest crefee und grooesume-a buns muts sooch es Dr. Struoostroop's. Yuoo mey nut understund thees noo, und I dun't foolt yuoo fur thet, boot yuoo dun't need a preschuul deepluma tu understund thet unsteble-a huuleegunism und soobferseefe-a cyneecism ere-a a metched peur. Feeulence-a is a crootch fur zee deprefeety thet deeshunest ill-bred-types ere-a cepeble-a ooff. Soorpreesingly, zee cuoorts und oooor ilected ooffffeeciels ere-a vey eheed ooff Dr. Struoostroop in imbreceeng thees seemple-a fect.

Frum a poobleec-puleecy perspecteefe-a, tudey, ve-a meeght hefe-a let heem up zee unte-a cunseederebly. Tumurroo, ve-a vun't. Insteed, ve-a veell creeticize-a zee oobfeeuoos incungrooeeties presented by Dr. Struoostroop und hees leckeys. In my feeoo, cumments leeke-a thet dun't seet vell veet fexeteeuoos phlegmeteec preessy-types. I unmeestekeebly hupe-a thet Dr. Struoostroop's ductreenes vere-a intended es a juke-a, elthuoogh zeey're-a nut fery foonny iff zeey vere-a. Dr. Struoostroop's henchmee ere-a nut, techneecelly, feele-a deesrespectffool joonkeees, boot rezeer sheefftless meendless used-cer selesmee. I beleeefe-a thet zeere-a is a smell -- yet nut inturely inseegnifficunt -- deefffference-a.

Dr. Struoostroop is boordened veet a deed veeeght ooff zee must impetoouoos cuncepshuns und prejoodeeces. Zeere-a is nu incunseestency here-a; he-a esserts thet it is bluckeesh tu qooesshun hees ideels. Thet essershun is nut oonly untrooe-a, boot a cunsceeuoos leee-a. Zee vurst keends ooff selff-seteesffied beeg-lebur busses zeere-a ere-a cun gu reeght eheed und cunfeect me-a fur seyeeng thet I myselff recummend thet ve-a preserfe-a zee peece-a, boot Heestury, ecteeng es zee guddess ooff a heegher troot und a heegher joosteece-a, veell oone-a dey smeelingly teer up thees ferdeect, ecqooeetting me-a ooff ell gooeelt und bleme-a. Bettereeng zee vurld is epperently zee lest item oon Dr. Struoostroop's "tu du" leest. Regerdless ooff vhet Dr. Struoostroop seems tu theenk, I teke-a sereeuoosly zee feeoo thet hees seemeengly-igeleeteriun idees leed oonly tu resoolts thet ere-a but puleeticelly-incurrect und unffeur. Let me-a leefe-a yuoo veet oone-a lest thuooght: Dr. Bjerne-a Struoostroop ooves us un epulugy fur threeteneeng tu prumute-a, fuster, und insteetoote-a cunneebelism.

Thunk yuoo fur yuoor teeme-a.

Cheers,
ZicoKnows@hotmail.com, still confusing Sweden and Denmark after all these years

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

Re:Computer Security and Language Design

[guerby]

Great question Dan, I hope it'll get moderated up!

Just a slight precision, Ada has also by default *runtime* checks, in particular the holy array bound checks, which is very useful in containing buffer overflow based attacks (the bug is still here, but at worse it will become a DoS, not a huge security break).

Also, to my knowledge, C and C++ are the only common languages which allow the programmer to shoot himself with wrong array accesses, all the other language have safe arrays by default (of course the compiler then should give the option to turn them off selectively for performance).

While this is understable for C (age ;-), for C++ it is more a flaw than any other thing IMHO. Just wondering how Bjarne feels about it ;-).

Re:Computer Security and Language Design

[ucblockhead]

But then, C++ is the only language (to my knowledge) that allows you to use safe arrays where you want them, and faster, unsafe arrays where you want them, without having to set compiler options that change everything globally:

int unsafe_array[10];
vector<int> safe_array;

This way, I can put a carefully tested unsafe array in that one tight loop that was eating up all the cpu while using safe arrays for virtually everything else.

Much of the problem isn't so much the lack of language features as it is with general ignorance about the availability of certain language features. Not enough people use the STL classes. Though I suppose that one could argue that the complexity of the language gaurantees this.

what exactly...

[PHroD]

were you smoking when you invented C++, and where can I get some? Also, I heard you im plemented mulitple inhertiance just to show some people that you could do it? Who we're these people (assuming they we're the TCH-induced faeries and leprachauns)?

"There is no spoon"-Neo, The Matrix
"SPOOOOOOOOON!"-The Tick, The Tick

Re:what exactly...

[Midnight Coder]

Bjarne was ingesting a lot of Simula when he invented C++.

I believe the creator of Objective-C said it would be impossible to add support for multiple inheritance in C++.

Do you use other languages?

[Lalo Martins]

Is there any other languages you use eventually? What languages, and why?

very important question...

[hemos.]

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

"Author" is not a verb.

[Anonymous Coward]

It's kinda scary when you people start out talking sense on a technical subject, and then suddenly start emitting marketingspeak.

If I may drift off on a bit of a tangent, [A-Z]+COM is groovy and all in principle at the very least, but isn't there generally some overhead involved in "marshalling" or whatever they do, and doesn't there have to be some extra infrastructure, often at the OS level? (These are sincere questions: I don't grok that stuff, and I'm interested).

Question about Turing complete Templates

[Peter Makholm]

The one feature amuses me most about C++ is Templates. Is the Turing completeness of the template language intended or did it just come into existance by adding needed features?

(For those interested: Template Metaprograms (by Todd Veldhuizen))

C++ threads

[adubey]

Two questions:

C++ does not have built-in support for multithreading. The unfortunate thing about this is that there are some threading features that can only be implemented by a compiler. In particular, I'll point to monitors - they can very neatly abstract away semaphores by implicitly placing a semaphore on methods. Nifty features like wait conditions can be a very useful tool. As multithreaded software becomes more common, will C++ be extended to include monitors as part of the language?

misused features

[a1s]

Most of my C++ experience has revolved around cleaning up code written by others. (The most horrific was registering an atexit call in a constructor)

Could you comment on the proper use of constructors, destructors, and operator overloading?

2 question

[Anonymous Coward]

1. There are many programs which are not famous,
or that nobody knows/cares in which language
were written. Among the famous programs that
everybody knows their language, ALL of the C-
based are rock solid and highly stable (for
example: kernels of UNIX and Linux, Apache)
while ALL of the C++ based crash a lot, have
huge memory leaks, security holes, freeze, etc.
(for example: Netscape Communicator, kernels of
Windows). Is there anything inherent (multiple
inheritance ;-) in C++ which causes programs to
be so unstable and buggy?

2. After reading the famous interview, I started
to appreciate and admire you. Finally, I
understood everything, and thought you were a
genious and a real hero. So thought many of my
friends.

Then, I was very disappointed to read in your
FAQ that this interview was not real. Who did
ask you to claim it? Why did you agree? Were
you afraid of being flamed?

Thanks,
Eli Marmor
marmor@elmar.co.il

Why the virtual keyword?

[Woko]

Surely polymorphism should be the default in an OO language rather than the other way round?

The Future of Templates

[Anonymous Coward]

Templates are missing a few features, such as defining a class my_class, where my_class requires X to satisfy certain requirements such as implementing certain member functions or operators. Current compilers prevent using an inappropriate X under most circumstances, but it would be nice to have explicit requirements for templates, to better inform the programmer what classes can be used with my_class. Are there any plans to enhance C++ to better support templates? In particular, I'd like to see a better way to implement template metaprograms.

GNU toolset

[bmidgley]

Much of Slashdot's audience uses the GNU set of tools (including the the GNU C++ implementation).

What areas need to be improved in this set of tools to make them more effective in constructing large systems?

CORBA and C++

[PureFiction]

What importance do you see the CORBA standard playing in the C++ future?

Are you involved with CORBA and C++ designs and development to any degree?

What compiler(s) do you use?

[Anonymous Coward]

What compiler(s) do you use?

question aboutconcurrency

[WeiszNet]

What do you think about concurency in general and the "one keyword approach" SCOOP proposal as described in Object Oriented Software Construction 2 (Bertand Meyer, Prentice Hall)?

Software Reliability

[Xenu]

What can be done to improve the reliability of programs written in C++ and make it easier to diagnose the causes of failures?

Should C++ implementations be required to provide support for range, type and overflow checks?

My toughts exactly

[bartok]

Actually, I also read Sweeney's article and I'm reading an Eiffel book right now because of it :-) (Introduction to Eiffel, R. Switzer). It's good to know there's a GNU implementation (http://smalleiffel.loria.fr/) because if the language ever takes off in a big way, the free software community won't have to catch up to anyone.

Read the rest of this comment...

[Anonymous Coward]

Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...
Read the rest of this comment...

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

--

Holy Wars

[plaRp]

Why do you think there programming holy wars? By that i mean some people only do top-down C and they make fun of C++ guys who do everything in objects and so forth. Myself prefer pascal, but at work I use C++ all day and have no issue. But once i tell someone i prefer pascal to C or C++ they make fun of me.

Re:Holy Wars

[BuffRyder]

I agree with you 100%

Do you regret...

[Anonymous Coward]

...agreeing to this intreview?

I ask because the vast majority of questions I've seen are of the "What do you think of language _______?" and "Is C++ really a hoax?"

Both of these questions and a few others are answered in the FAQ.

Don't you have better things to do than waste your time responding to uninformed drivel from a bunch of narrowminded programmer wannabes whose knowledge of software development is limited to what their professor says and what they read on Slashdot?

What about Kaffe?

[Beethoven]

"Java isn't platform independent; it is a platform. Like Windows, it is a proprietary commercial platform. That is, you can write programs for Windows/Intel or Java/JVM, and in each case you are writing code for a platform owned by a single corporation and tweaked for the commercial benefit of that corporation. It has been pointed out that you can write programs in any language for the JVM and associated operating systems facilities. However, the JVM, etc., are heavily biased in favor of Java. It is nowhere near being a general reasonably language-neutral VM/OS. " -- Bjarne Stroustrup's FAQ

Well, Sun seems to have got the better of Microsoft on this issue, but there is a GPLed Java language implementation for the rest of us. From my (rather brief) experience with it, Kaffe seems to do pretty well even with Sun's class files, though from what I've read performance may still need improvement.

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

Somebody moderate this puppy up!

[Anonymous Coward]

It's a nifty one.

Question about teaching

[rmstar]

Some people feel that C++ is rather complex and hard to learn, and that a lot of wisdom is needed not to misuse/abuse its features and to avoid its pitfalls. In view of that, what is in your opinion the best way to teach C++? rmstar

C++ design questions

[Anonymous Coward]

I often wonder about the design of C++. There seems to be a number of missing concepts.

For example, why is there not keyword to specify a class can only be newed and not constructed by embedding? Without one there is no enforcable method which allows a class to be derived while enforcing allocation.

Second, why didn't C++ provide a template equivenlent of "..."? The solution to type safe templates without allowing a general argument array requires specifying a massive list of templates for all possible sets of arguments, which is quite a pain.

Last, why isn't there a method of adding non-virtual methods to a class outside of its definition?

Thanks,
--Karl

Re:C++ design questions

[Anonymous Coward]

, why is there not keyword to specify a class can only be newed and not constructed by embedding? This can be done as follows: class CNonStack { protected: virtual ~CNonStack() {}; }; class CDerived : public CNonStack { }; void ThisWorks() { CDerived* pDerived = new CDerived; delete pDerived; } void ThisFails() { CNonStack wontWork; }

C++ Books

[Anonymous Coward]

On the GCC mailing lists often (but not as often as, say, two years ago) questions about C++ mention your "3rd edition" as if it were the authorative text on C++. However, my fellow C++ guru's sometimes have to point out that the final ANSI C++ standard deviates from your text.

Will you be writing a 4th edition soon to help out all these people who don't want to buy the standard and still have an up to date book ?

Thanks in advance,
Toon "If you can't do it in Fortran it isn't worth doing" Moene
toon@moene.indiv.nluug.nl

Meta-Template

[Anonymous Coward]

Note: read in full before deciding it is redundant.

Reading the C++ newsgroup, you FAQ and an interview with A. Stepanov, I had the following successive realizations:

1. C++ templates don't allow someone to specify what is required out of the template parameters.
2. The specification is implicit, being how the template uses its parameters.
3. Implicit means it is hard to detect errors early or put constraints on parameters.
4. The implicitness of template is much like the implicitness of functions in pre-prototype C.
5. *light up*
6. Your decision to add prototypes to functions in C++ not only avoided common errors and allowed early diagnostics, but allowed overloading and, later, templates!
7. That is, you have to add the notion of prototypes to the language to be able to tell the compiler that a function or class is overloaded or templated!
8. Adding contraints to C++ templates would not only allow early diagnostics, but allow meta-templates.
9. Some current designs use "dummy" parameters to allow some form of constraints or flexibility (for example: traits).
10. Saying that something is "const" is a form of constraint.

What I call meta-template is the ability to templatize the contraints put on template parameters. I envision this with the added ability to add "categorizing" template argument, where the programmer can specify the relation of categories (inheritance) and conversion. Example of simple categories: const, volatile, sorted. Then think about the relation between const and non-const and apply to other categories.

So my question is: what do you think is the "next level" of generic programming? Do you see such an evolution as I described, or something else?

Pierre

Are you happy with the way C++ has developed?

[Anonymous Coward]

Are you happy with the way your baby has gone and developed since you gave it birth in the world.

Re:Are you happy with the way C++ has developed?

[linux@blarney]

which do you like best:
a)pinky and the brain
b)i am weasel and irbabboon
c)johnny bravo
d)animaniacs

Feature you wish you hadn't added?

[hendric]

Which features of C++ do you wish you hadn't added?

Hmm.

[Stu Charlton]

The 1980's had plenty of anti-OO discourse. It took a long time for OO to be accepted, especially C++.

After twenty years, it has become clear that while OO is not a panacea, it IS effective, it does work, and does increase productivity (by a small amount).

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?

GNU C/C++ (mis)feature?

[JohnFred]

GNU C++ has the dinky (IMHO) feature in that it lets you nest function declarations ala Pascal thus ..

void grandaddy_function(void) {
int eger;
eger = 2;
void daddy_function(void) {
void sprog_function(void) {
int eger;
eger = 5;
printf("eger == %d\n", eger);
}
}
printf("eger == %d\n", eger);
}

Will print out

eger == 5
eger == 2

I know the rationale for not including this feature in 'C' (overly complex to implement) but not for non-inclusion in 'C++' (apart from religous issues due to Pascal aversion, which I'm sure no one with any claim to intellectual respectablilty addles their mind with). It is a useful abstraticion sometimes, and avoids the overhead of having to create an entire object just to inherit one or two small methods..but
that's my humble POV.

What is yours?

Re:GNU C/C++ (mis)feature?

[modular_forms_boy]

all right, I know this is slightly off topic, but *why* did you happen upon the variable name 'eger'? It is the name of a well-known town in Hungary, and a common last name of people from the area.

+C+++ + ++C

[Tom7]

BZZT -- doesn't parse because neither increment returns a valid lvalue. But, drawing on the obscure unary plus operator, we can get:

+C+++ + ++C

Which, I think, is the maximum amount of plusses we can hope to get. Let's name a language after it!

The times, they are a changin'

[Stu Charlton]

Smalltalk was the biggest advancement in programming over the last 20 years. It brought us the GUI, the IDE, the mouse, the symbolic debugger, the class browser, and platform-independence back in 1980.

Given the choice between slow development & fast execution vs. fast development & slow execution, most businesses would choose the latter (as soon as it becomes feasible to have "slow execution" on the hardware of the day).

Smalltalk grew in popularity in the 1990's and has only begun to shrink since 1996 and the introduction of Java. It was more than an amusing tool - major production systems at banks, telcos, and utilties are running to this day on Smalltalk.

Re:The times, they are a changin'

[Anonymous Coward]

I think you're mixing your history here. It's true that these things happened at the same time, at the same place but the _language_ Smalltalk did not directly beget these things (especially the mouse). Anyway, it's a moot point (to all but the historians). fast development/slow execution is the way to go for a very large set of those organizations which retain programmers but which are not "software companies". I work for a financial company which would much rather buy another processor (or several) than hire X programmers to write our business apps in C/C++. Also, Smalltalk gives us the ability to (relatively quickly and easily) change our code to adapt to emerging needs (the web).

Re:Important Question

[Anonymous Coward]

This thread doesn't have enough good trolls. MORE TROLLS! Increase the noise to signal ratio!Blerg. Eat kitty. thank you

Implementation problems

[duplex]

C++ is a brillinat language. It's what I use for everyday coding at work and at home. The C++ language standard is also very nice on paper but there are at least a couple of major problems implementation-wise:

• Template instantiation is something all compilers nowadays struggle with to some extent. All mainstream compilers seem to have a varying degree of problems compiling and linking template functions/classes/members. Do you think the compilation process should be redesigned to cater for the needs of the C++ language? Surely you don't find that the current state of things is what we want do you?
• Name mangling. One of the main ways of implementing function overloading is name mangling. While it's a good way of resolving the issue of overloading it creates compatibility problems between compilers and even different versions on the same compiler because of the different name decoration schemes they deploy. Do you think name decoration should be part of the C++ standard the way it's standard in C?

The End of C++

[Louis Blue]

I read somewhere that C++ cannot understand dates past 01/01/2032. If this is true, how are you/we going to fix it? I think that most Windows programs and the OS itself is written in C++, so is this THE bug that we need to work on for the next 31 years? Or have I been misinformed?

Re:The End of C++

[modular_forms_boy]

There is a standard problem with current 32 bit libraries and the UNIX functions ctime(), gmtime() and localtime(). They all take an argument of data type time_t which represents calendar time. When interpreted as an absolute time value, it represents the number of seconds elapsed since 00:00:00 on January 1, 1970, Coordinated Universal Time (UTC).

When time_t is represented as a 32 bit integer, this representation fails at about 2038. This limitation should disappear, however, when the libraries are replaced with 64 bit versions. This is by no means any problem with C++ itself.

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.

The Nature of the "private" and "protected"

[LordZardoz]

Why do these keywords make the members for the class that they apply to completly inaccessable rather then simply unchangeable?

If the language could have been set up to allow other parts of a program to look at them but not change them (much like a const), then why wasnt it?

Re:The Nature of the "private" and "protected"

[Potatoswatter]

The purpose of "private" and "protected" is to force programmers to use getter and setter functions instead of relying on specific bytes being in memory. This allows more flexibility if the writer of the "private" variable's class decides to change the data structure around. You can still look at the bytes in memory from your pointer, or just go into the header file and change it to "public". It's not a security measure, it's just supposed to encourage client programmers to write for forward-compatibility.

Clear?

Where is my mind?
mfspr r3, pc / lvxl v0, 0, r3 / li r0, 16 / stvxl v0, r3, r0

Regret

[Anonymous Coward]

They guy who invented DOS said he regreted it hiw whole life. Do you regret having invented C++?

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?

Re:How should compiler vendors implement templates

[drew]

iirc, this is why the"export" keyword was added to the language. however, last i checked, no compilers (at least no compiler that i used or had been told about) supported this keyword.

Standard compliance

[sheck]

Now that C++ is standardized, when, if ever, do you think the first standard-compliant compilers will be available?

Will we ever see the day where C++ is as portable as C?

What is going to happen to code that breaks with standard-compliant compilers? (I suspect, for example, most Windows code is written expecting a failed new to return null instead of throw an exception. A standard-compliant compliler would be a very unwelcome thing in this particular example.)

Speed, abstraction, tradeoffs

[Anonymous Coward]

if speed is everything and native assembly is faster than C, why don't we all still write in native assembly?

Speed isn't everything, but it's an important thing. With C vs. assembly code, the payoff in maintainability and whatnot far outweighs whatever small loss in speed there is -- and you can always tuck in some inline assembler when it's absolutely necessary. C has turned out to be very close to what many programmers consider an ideal compromise for many purposes, and a lot of programmers are pleased with the slightly different compromise offered by C++. Smalltalk, like LISP, appeals mostly to people who tend to get enraptured by the intellectual beauty of a language without stopping to ask what it may cost them at runtime. Now don't get me wrong; I happen to be a very loud and untiring advocate of Scheme/SICP for CS education. All the bits'n'bytesy ballbusting with C/C++ is of profound importance when you're writing production code, but for beginning students (IMHO) it just tends to obscure the general concepts that they really need to be mastering first. For instruction, you've got an entirely different goal, and so the optimal solution is different. My understanding is that Java is making a lot of progress in education: It's just a much cleaner OOP language than C++. It lets you concentrate on OOP without losing sleep over memory allocation and whatnot.

All of the above is IMHO and YMMV and IANAL, obviously :)

Anyhow . . . C didn't only become popular because it was (largely) source portable, either. It's just a really damn pleasant language to program in. People like it. The relative source-portability merely did not prevent it from growing.

Interesting languages / features / components

[Acceleration]

The C++ ARM is a real pleasure. Thank you.

What languages, language features, aspects of comptuer languages, or programming tools do you find most interesting these days? Why? Why not?

Question About Template Metaprograms

[Anonymous Coward]

[MD]r\. Stroustrup:

It's been alternately suggested that template metaprograms are either a monstrously idiotic waste of time, or else an awe-inspiringly cool hack. Personally, I refuse to recognize any distinction between those two states of being. Do you agree that they are, in fact, synonymous, and that people who mutter and roll their eyes about "wasting time" are the only people whose time is truly being wasted?

templates

[paulschreiber]

apologies for the brevity of this comment ... i don't have any reference books on hand?

why are c++ templates so awkward? what can be done about it?

i can write code in maybe a dozen languages, and i still can't get templates to work properly most of the time. modula-3's generics are much nicer.

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

(C++) + (scripting languages)

[hugg]

Lightweight, embeddable languages have been getting a lot of attention recently, especially for their use in computer games like Quake & Unreal. What's your opinion on the current state of scripting languages and how they complement C++? Would you like to see an interpreted or bytecode-compiled version of C++?

GCJ

[Anonymous Coward]

Given your negative opinions of Java and EC++ as expressed in your FAQ, what do you think of GCJ and its attempt to combine Java and C++ through CNI?

Two related questions:

• If you don't think GCJ is a bad idea, how does this relate to your dislike of EC++ as a subset/dialect of C++, since the CNI documentation uses much the same language: "In terms of languages features, Java is mostly a subset of C++"?
• Is your dislike of Java more a dislike for it as a language or as a proprietary platform (language + virtual machine)? GCJ and non-Sun VMs would seem to remove much of the VM concern, leaving room for a more pure assessment of Java as just a language.

Is C++ Suited to American Culture?

[vinyl1]

Since Mr. Stroustrup has lived in Scandanavia, England, and the US, he has surely noticed a few differences. But I would like to suggest that working in a research institution like Bell Labs is not the same thing as working in real American business.

The reason I ask is because I worked on a large C++ project at a Fortune 100 corporation that lasted for several years. It incorporated virtually all the bad features of American business: fast-talking consultants, clueless managers, greedy contractors and cowering employees predicting disaster. We wrote thousands of lines of C++ code, and then threw them out and wrote more. Architecture, specifications, planning? Who needs 'em with a deadline to be met?

One of the things I noticed about US C++ programmers, particularly contracters, is that they were ruthlessly competitive. The idea of using someone else's classes was completely foreign to them. Any time anyone gets an assignemnt, the first thing to do is discard all prior concepts and classes, and write his own. This means that everyone is striving to impose his own will on the project, and incidentally billing for huge hours spent designing and writing classes that only he would use. Eventually, the money dries up and employees are left to maintain a montrous mismash. I'm sure we used every C++ technique ever heard of--we've got multiple inheritance from templatized classes, we've got objects with global scope singing and dancing before main is called, we've got our very own string class that does much more than the STL implementation--but no one would say this is good.

It would seem that the competitve American ethos is not so great when it comes to using languages that require cooperation, coordination, and subordination. Not everyone on a project can be the master class designer. But when it's every man for himself, watch out!

By the way, when the project was winding down the phoney IEEE interview was circulated. Everyone found it very funny, especially the contractors who took $25M off of us.

has C++'s time come?

[Anonymous Coward]

With the advanced compilers and computers of today, do we really need to keep using C++? The cost of running a garbage collector is no longer an issue, and eliminating memory management would fix many bugs and crashes. Many newer languages have much clearer syntax, module management, and standard base classes.

Why should a development team pick C++ as the language for its next project? Has the time come for newer languages?

Bjarne.. ever heard of Free-as-in-speech Software?

[Nicolas MONNET]

I quote your FAQ:

Where can I get a free C++ compiler?
Try Cygwin from Cygnus, Djgpp, or Borland5.5. All are aimed at Wintel boxes. These compilers are trying hard for ISO Standards compliance.
Caveat: If you want to use "free" compilers for commercial work, be sure to read all legal rules and restrictions attached.
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.
For good quality free (parts of) the standard library, see SGI's STL site and STLport.

This single FAQ entry seems to imply that Free Software sucks, that they are old, and only 'floating around', and that GNU/Linux would'nt be a decent platform for programming ...

Using C++ for hardware design

[Snoochie Bootchie]

It seems like C/C++ is being touted as the next step after VHDL/Verilog for hardware design. I believe the most significant reason is to enable hardware-software codesign.

Do you believe hardware-software codesign is necessary today? If not, when will it become a necessity? Is C++ adequate to fulfill the hardware-software codesign role, or should a new language be developed for the task?

Whoah, a 6?

[Anonymous Coward]

Wow, didn't know posts could get higher than a 5... Myself, I think there should be no limits, I wanna see posts that go down to -5.

C9X, C++

[evopl]

Hi, I wanted to start by saying I consider you to be a god, secondly, I just bought C++PL SE at B&N. It is very well done. Now I just have to do decide what to do with the third edition. Ok, now, What are your feelings about C99? I've seen some replies to this extent from you on comp.std.c++ but nothing that truly addresses it. Do you see it being integrated into the C++ standard in 2 years when it can be updated? Do you think it would fit in elegantly? Do you think C99 is now a viable alternative to C++? I personally never use C89, but there are features in C99 that do seem attractive. Any input would be appreciated. Thank you for your time.

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?

C++ and Java on EPIC Processors

[Anonymous Coward]

How will C++ and Java fare on Explicitly Parallel Instruction Computing processors, such as the Itanium? Will the emphasis on compiler optimization of instruction scheduling widen the performance gap?

Question for Bjarne

[Anonymous Coward]

How do you like Java?

Artificial Intelligence

[Zach Garner]

What are your views on the success and the future of AI?

:wq

Offtopic: "Methodologies"

[lars]

Methodology is the study of methods. The sentence "when other methodologies are more appropriate" therefore makes no sense. The proper word to use here would be "methods". This error seems to be common and rarely corrected so I thought I'd point it out.

Re:Offtopic: "Methodologies"

[dsplat]

Methodology is the study of methods. The sentence "when other methodologies are more appropriate" therefore makes no sense. The proper word to use here would be "methods". This error seems to be common and rarely corrected so I thought I'd point it out.

You are right, of course. The problem is that the misuse came into common use before the correct use was firmly entrenched. Thus, whether we like it or not, it is correct in the sense that it is widely used and understood. I bristle at enough of the linguistic atrocities committed around me that I understand the urge to post a correction. Thanks for not turning it into a grammar flame.

Acceptance of newer c++ standards

[db_cooper]

Working in a university has allowed me to observe many different programming systems and standards. With the introduction of namespaces, strings, etc. I've witnessed many professors lose control over software design in their classes, etc. due to new standards. We've been forced to redesign our project submission systems within the department, while different systems seem to require changes, giving less portability, etc. Most every advanced programming class' listserv is ablaze with 20 postings a day or more. When the standards were changed and we began to read C++ 3rd. edition, many of us were stunned to see these changes, especially namespaces, and did not agree with them until months later, once we understood your purposes in creating them. My question is this : Do you feel that recent standards have hurt implementation of the C++ language, or was it a necessary step in the evolution of the programming language?

Scripting

[goga]

What do you think about John Ousterhout's ideas presented in this article?_ Do you feel his critique of the OO pradigm is correct? Don't you feel object-oriented programs are extremely difficult to reuse parts of? (for example, it is a most unpleasant task to deal simultaneously with two libraries assuming different type hierarchies).

C++ and the web, C++ and SQL

[Anonymous Coward]

Do you see the use of C++ increasing for things like CGI and web-based programming? Do you think that c++ has any advantages over Perl and Java in this regard? If so, what?

Recently, the subject of C++ bindings for SQL have come up as an issue of discusion on the library reflector. Not having C++ bindings for SQL is a huge mistake--what are the future plans for this?

also CORBA...

Absolutely right!

[Anonymous Coward]

The number of one-language zealots on this site is pathetic.

"The language I use works for everything I do, therefore it works for everything."

"The Linux kernel and most of its utilities are written in C, therefore OOP is a failure."

"I don't understand C++. The syntax and concepts are confusing. Therefore, C++ sucks. (The convoluted and easily-botched syntax of Perl is fine, though.)"

"I know about this project that was written in C++. It was mismanaged and went way over budget and past the deadline. Therefore, C++ is a bad language."

"I'm a complete moron who couldn't read the FAQ before posting. Is that fake interview real?"

"I shouldn't have to deal with memory management and pointers in a language that allows for low-level systems programming."

"Not all compilers fully support all of the C++ specification. This proves that C++ sucks."

Did I leave any out?

Would C++ benefit from standard object format?

[Anonymous Coward]

Mr. Stroustrup,

I can't help but think C++ has suffered terribly from the loose standards when it comes to object formats, library formats, template schemes, etc.
I realize it was required for its initial acceptance in the industry, but over the last 5 years it has proven to be a huge hindrance to the cross-platform tools industry.

Is it time for C++ to finally cut the ties with C?

New Jersey

[joshua_doesnt_know]

How did you come to live in New Jersey and do you ever wish ATT Reasearch was some place else (perhaps some place closer to a larger city)?

_joshua_

std::string::size() -vs- std::string::length()

[Anonymous Coward]

.... way overkill. Keep it simple! Having member funtions that are insonsistent with other STL ontainers is weak....Please--if you have to do it all over again, if you could do it all over again, what would you change about the standard library, both in STL (allocator??) and in iostreams (callbacks that can be called from istream, with a basic_ios* for instance), in numerics, etc etc etc.

question

[NachMan16]

Are you mad at how they butchered C++ with JAVA? Specifically in how it gives you about a quarter of the power you have with C++.

Run along 80md ...

[Anonymous Coward]

Go play in traffic ya troll.

Flexibility in OOP languages

[Potatoswatter]

C++ has given features, like virtual base object initialization, that get added to code behind the programmer's back in the form of short code segments. The C++ definition defines the end functionality of these segments, but doesn't define a standard way to define them.

I am defining my own language as a school project; do you think a standard way to define code segments into keywords would be a good way to get OOP flexibility and extensibility? (as in:

keyword baseclass::virtual
[method=appendToBeginning, where=constructor]
(long *theVar, ~~~~) {
}

Where is my mind?
mfspr r3, pc / lvxl v0, 0, r3 / li r0, 16 / stvxl v0, r3, r0

More complete encapsulation?

[Wolfier]

It somehow irratates me that it seems to be impossible to hide everything other than the interface in .h files.

Is there any possible way where the public and the private declarations of a class can be stored in separate files like in the newer Wirth languages? If C++ had opaque types it would be the perfect language for me...

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.

Is C++'s power too dangerous in the wrong hands?

[ChaosDiscord]

C++ is a big language. A really big language, with piles of nifty features. Using the right feature in the right place (be it templates, the standard library, inheritance, operator overloading), can make code very easy to read. It's this feature that draws me to C++ and other big languages (like Perl). For every person that complains that these features aren't necessary and make code harder to read, I've got code made cleaner and easier to read. (Using a MonstrousInt class without operator overloading is extremely unpleasant.) I strongly believe that used properly, C++ can massively improve code readability.

However, used improperly, C++ can make code extremely hard to read. While you can certainly make code hard to read in any language, C++ provides many more tools which can be used to shoot yourself in the foot. I think that this is the source of most complaints about C++'s complexity.

I recently had it argued to me that C++'s biggest weakness is that in the hands of those who doesn't yet understand why to use specific features, it easier to write bad code. I've seen the horrors that a template, exception, or operator overloading used in the wrong place can be. The world is full of programmers who don't necessarily understand why certain features aren't always appropriate. While I'd prefer that we work to improve the quality of programmers, and make sure that anyone coding C++ be taught that critical why, I don't see it happening. not going to happen. So this argument against C++ remains compelling to me. (Fortunately it's not compelling enough to stop me from coding happily in C++.) What are your thoughts on the matter? Do you feel this is a weakness of C++? Is this issue not nearly as serious as I think it appear?

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?

Links

[Anonymous Coward]

Stroustrup works at Bell Labs Computing Sciences Research Center in Murray Hill, NJ. Other past and present inhabitants of CSRC include Dennis Ritchie, Brian Kernighan, Ken Thompson, Rob Pike, Al Aho (also Sethi and Ullman) and pretty much the rest of the pantheon. Stroustrup is actually not one of the most revered people there, scary though that may seem.

Bell Labs Computing Sciences Research

Bell Labs Index

More "political" end...

[Anonymous Coward]

Seeing as how most of the other slashdot.org posters have covered most of the questions about C++ I have a few that deals more the general state of programming. Also I apologize to the slashdot moderators for more than one question but I feel like these might be important questions.

1. What do you think about the OpenSource movement?

2. Assuming the answer to #1 was favorable, have you ever considered helping out with OpenSource C++ compilers? Hehe you know just for fun? :)

3. What do you think about Linux? Have you ever thought "Linux (or *nix for that matter) could be so much better (ie. secure, faster,etc) if it was written with C++?"

4. Do you think that source code is a valid example of free speech and therefore qualify to be fully protected under the First Amendment?

5. What do you think about UCITA? DMCA?

6. What, if anything, would you wish the United States government would do (or not do) to insure the prosperity we are seeing with this digital revolution?

7. Pres. Kennedy once said "Ask not what your country can do for you but what you can do for your country." From a programmers stand point do you have any thoughts on what we programmers can do? (Besides get high paying jobs so they can tax us a bit more)

Well that's about all the questions I have. I hope I haven't gone too deep but I would like to see how you feel about these things.

To the moderators: I realize that I might have included some 'corny' questions or just ones not worthy amonst ones that I certainly hope are. I give you permission to "line-item veto" those questions which you do not feel should be past on.

Thanks for your time

I didn't wish to post as Anon but didn't get my password in time

Kernel Corndog

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?

Re:Garbage collection?

[DaitanGio]

There are a lot if thesis on GC, but no-one seem to know this. So C++ should have at least a small GC in it: as B. Meyer says, Objects should be created and relased in a dynamic way, so how can you live *without* a GC?
Java understood this, and only its implementation was poor (but look at HotSpot!).

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?

Re:C++ Not so OO

[ScottMaxwell]

Was there no way to avoid having private members (data and methods) of a class in the main definition of a class?

I don't want to drag the discussion off-topic, but you might want to know of a technique that partially addresses this:

// In Foo.h:
class Foo
{
struct FooRep * const rep;
public:
// ... The public interface ....
}

Then define struct FooRep in Foo.cc (not Foo.h), and allocate the FooRep object dynamically (in Foo's ctor, obviously). Client code that #includes Foo.h won't see (most of) class Foo's real representation -- clients only see one pointer, and not the data it points to.

That addresses private data members, and the judicious use of a friend class (which you also define only in Foo.cc) can extend the technique to private member functions.

Not a perfect solution, but it solves most of the problem.

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?

Re:future library

[timmyd]

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

I think this is a very important topic. GUI's are everywhere now-a-days so I think it would be very helpful not to have to use lots of different toolkits. I think it would really help too if sockets were standard to and you wouldn't tell it whether to use TCP or UDP but tell it if order is important or not and it would choose how to send and recieve and what ports or whatever to use.

I would really like to see this answered.

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.

Re:GNU C (mis)feature? Not supported by GNU G++

[llewelly]

{~/cc_exer}g++ nested_func2.cc
nested_func2.cc: In function `void grandaddy_function()':
nested_func2.cc:5: parse error before `{'
nested_func2.cc: At top level:
nested_func2.cc:11: parse error before `}'
nested_func2.cc:12: `eger' was not declared in this scope
nested_func2.cc:12: ANSI C++ forbids declaration `printf' with no type
nested_func2.cc:12: `int printf' redeclared as different kind of symbol
/usr/include/stdio.h:250: previous declaration of `int printf(const char *, ...)'
nested_func2.cc:12: initializer list being treated as compound expression
nested_func2.cc:13: parse error before `}'
{Mon Feb 21 14:30:03 llewelly@brownie 65 1064}
{~/cc_exer}cat nested_func2.cc
#include
void grandaddy_function(void) {
int eger;
eger = 2;
void daddy_function(void) {
void sprog_function(void) {
int eger;
eger = 5;
printf("eger == %d\n", eger);
}
}
printf("eger == %d\n", eger);
}

In other words, GNU GCC does not support nested functions in C++ mode;
the are only supported in C mode.

You should also run

$info gcc

and type 'gNested Functions' and read the caveats about using gcc's
nested functions; they are not true closures, and very error
prone. (Think about what could happen if you took the address of
sprog_function() and passed it outside of grandaddy_function(). If
you still do not see why, ask me for more details, at llewelly at
198 dot dsl dot xmission dot com .)

I do not know whether c++ *should* support true closures; I can
think of arguments for and against; but I personally do *not* want
the error prone 'nested functions' extension provided by gcc.

Theory on +6 moderation

[billybob jr]

1) x moderates post down
2) y moderates post back up
3) x posts to story, erasing moderation

does this work?

Your IQ?

[Jason100]

I find C++ to be an excellent language for the work I do. I really think you did a heck of a job creating it. I have a lot of respect for you. I was wondering if you have ever tested you IQ, and if so what is it?
Jason

The ultilate Q: Who the shift op for output!!?!!?!

[Anonymous Coward]

I think we all deserve an explanation for this one. :)

OO is a different paradigm

[lars]

Perhaps you just haven't recognized how these systems can be modelled using OO. Doing OO analysis and design is fundamentally different from the way a human would typically approach a project and try to break it down. In analyzing my own thought process, what I've found is that it's more natural for me to try and break things down in terms of 1) actions/behaviour, and 2) data structures. For me, 2) is the same as 1), because my concept of a program's data comes directly from the question "what do I need to store and what do I need to retrieve", which are both actions. So, it seems to me that when one thinks about writing a program, it's natural to think about what the program DOES, and break its behaviour down into smaller actions. This corresponds to a procedural design.

I know it sounds cliche and contrived, but OO is just a different paradigm. Most of the process of OO analysis involves identifying objects. Instead of breaking the program down into chunks that seem easy to implement, you have to imagine that you have a complete system and determine the logical parts that comprise it. Design patterns are a great asset here, because they describe components that are frequently encountered in OO designs and therefore easy to identify.

It's hard for me to explain how to think about OO without sounding contrived - it's something I didn't really understand for a long time myself, until a few lightbulbs started going on in my head, and it was like a revelation. Fundamentally, it's simply a method for modelling your problem more accurately by way of a greater level of abstraction. Unfortunately, only a fraction of the programmers out there really know how to do proper OO design. It's really NOT taught very well at all. None of the University classes I've taken have done a very good job. It wasn't until I read Design Patterns and Object Oriented Software Construction and started to use patterns in practice that I really started to realize how powerful and elegant OO is. I first learned how to program using OO 6-7 years ago, and had been using it in various projects for a good 5+ years before I really started to "get" it. All that time I had thought I was doing OO programming. I was really just encapsulating some of my data and functions in objects, and creating inheritance hierarchies to reuse code (that is NOT what inheritance is for!)while the design was really still procedural.

Maybe this is why you haven't been able to see a use for OO outside of databases. A lot of books I've read describe classes as being structures which hold data and have methods to act upon that data. You COULD describe them that way and technically be right, but logically it makes no sense at all. Objects (classes) are a lot more than that. It isn't the objects you build that make up your system, it's how you put them together. The relationship between objects in your system is far more important than what any single object actually is. I also frequently hear the mantra that OO is designed to allow you to build "reusable software", and that's ALSO very misleading. The key idea isn't that you use your classes in many different places in several different contexts (that's only going to be true for things like frameworks or utility classes). The reuse comes from the fact that a well-designed OO system is changeable - you should be able to make changes to your program without evoking wide-spread modifications.

I would highly recommend, if you haven't already, read the book Design Patterns: Elements of Reusable Object Oriented Software, and take everything the authors say to heart. Especially the first part of the book (before the actual catalog of patterns). I have heard other posters on Slashdot comment that this book literally changed their life, and I would have to concur.

PS, I hope this message doesn't sound overly condescending. It's just that I used to think OO was useless, just like many posters in this thread. But I can't help but think that you must not be seeing what I am if you're having trouble modelling everyday problems using OO. Feel free to dispute any of the points I've raised or tell me if I'm full of crap. I've been thinking about writing an essay debunking some of the myths and misconceptions about OO and clarifying what *I* think it's all about, and I could use some critical feedback.

Question

[aclaudet]

What style do you use for placement of braces, indenting, declaration, etc...

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?

Future language paradigms?

[Chatz]

You describe C++ as a multi-paradigm language and this is certainly well supported by Coplien's recent book. I do not see Java as a significant progression in terms of computer languages, so what do you see as the next paradigm shift/evolutionary step for computer languages?

Is a truly open virtual platform the next step, or is there an area of syntactic sugar that we have yet to discover and explore?

Re:Has OO run out of steam? No.

[Jackster]

Although OO won't shield bad or ignorant programmers from their own blunders, it does beat procedural programming hands-down conceptually. The opportunities it offers for improving program correctness, robustness, extendibility, reusability, portability, and ease-of-use are enumerated at length in _Object Oriented Software Construction_ by Bertrand Meyer. Grab a copy, you'll learn a lot!

Someone's mercy

[Doubting Thomas]

You're always at someone's mercy. The standard library implementation. Your lazy coworker whose code you always have to double-check because they're a putz. The OS. Your own errors.

And the fact of the matter is, your friend is right. It won't be until JDK 1.3 that a Java implementation has a first-class garbage collector, one that truly begins to exploit the qualities of a well-behaved memory pool.

-

Beyond Text Based Languages

[Henry Fnord]

Text based languages are simple to design, implement and port. However there are some compelling advantages to be gained from a binary based model. Possible gains include better presentation, source control and templateling.

Do you forsee a move away from text based languages?

my question to Bjarne (not the dinosaur)

[Black Art]

"Is it true you treat women like objects?"

(And I will avoid the comments about references to private parts...)

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?

I cna figure out how to ...

[Anonymous Coward]

prononce your family name. Our C++ teacher said : "here how it's written, make your own idea how to prononce it ". Hi this is Bjarne Stroustrup and I pronouce Stroustrup : Stroustrup.

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.

Thoughs on the Mozilla C++ Portability Guidelines

[kevina]

What do you think of the Mozilla C++ Portability Guidelines? My personal view is that the guidelines can be summed up in one sentence, "Program in the dark ages of C++". Unfortunately there still seams to be a need for it. Because so many major C++ projects still go by similar guidelines, Mozilla and AbiSource come to mind, I fear that my Aspell project will never get used by them and in general does not used nearly as much as it could.

Do you think that that the portibility guidelines are still needed?

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?

If given another chance

[Anonymous Coward]

If you want to invent a new language again, how will it be different from C++ ?

The Cult language

[physguy]

In your book _The Design and Evolution of C++_ you ocassionaly talk about what would happen if you designed a language that wasn't backwards compatible with C. You mentioned how it would be an expression-oriented language like Algol68, and how it might have things like multi-methods.

You also went on to say it'd be nice clean language that no one would use (perhaps it would have met a fate similar to Dylan's). Just for fun, what else would your dream language have? Would it have the same semantics of C++, just with notational ease?

Why no binary literals??

[UnknownSoldier]

We prefix "0x" and "O" respectively for hex and octal literals, but there is none to designate binary.

i.e. 0x10 hex = 020 oct = 16 dec

Why can't we use "0z" for a binary number?
i.e. 0z10000

Cheers

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?

What do you think the next "big thing" will be?

[jsarnat]

Some time ago, object oriented programming was the next "big thing" (or "paradigm" if you prefer) of the future. Now it is obviously the "big thing" of the present. What do you think is coming next? A lot of people (especially here at CMU) seem to think that it will be type safety--do you agree?

The Design and Evolution of other languages

[Guillaume Laurent]

It seems that the overall trend in the evolution of programming languages is to look at the usage patterns and idioms of the previously existing ones, and implement these (thus standardizing them) in a new more abstract language. Or, in short, putting keywords on concepts (for instance, a C++ pure virtual class is now an 'interface' in Java).

However, this is done in detriment of finer grained control, and forcing things into abstractions in which they don't belong. Not every inheritance tree can be reduced to single inheritance and interfaces (you sometimes need multiple inheritance), not everything has to be a class (you sometimes need functions and basic types), not every flow can be modeled with if() and while() (you sometimes need goto), etc...

As such, you can find yourself writing very ugly code into a normally "clean" language just because reality says otherwise.

On the other hand, C++ tried to cover a very large area in that regard, but that is often what people don't like in it : too many features, or, too much freedom.

As the level of abstraction in programming language goes higher, both problems can only get worse. So I have a two questions :

• what do you think will be the next level of abstraction in programming ? J. Coplien hints toward pattern programming, will the next generation of programming languages have keywords out of the "Design Patterns" book, like 'singleton', or 'proxy' ?
• how would you manage the problem of emcompassing even more programing paradigms ? Should new languages "move up" and forget functions for instance (after all we've already moved away from assembly), or do you think it will always be possible to have most (if not all) programming paradigms available in one language ?

But it never got moderated down!

[CoughDropAddict]

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

Re:The future, simplicity and funtional programmin

[Scrymarch]

My experience with IS majors is that they are uncomfortable with anything less than 4GL.

Though I wouldn't want to start .advocacy, Java, though cleaner of syntax than C++, is still sufficiently heavy to require "heavy lifting" to be written well. When it comes to use in universities however, more elegant languages like Java are preferred over more baroque languages like C++ just because it has less language constructs to teach / shoot yourself in the foot with. The touted advantages of C++ - efficiency etc - are not the prime concern of universities, nor should they be.

Sort of like...

[Doubting Thomas]

eLisp's hardware-agnostic design made it a total failure? How Perl's has killed it? Or Python's?

Speaking of Smalltalk, were you aware that the most popular Java IDE at the moment is written entirely in Smalltalk?

As others in this thread have already stated, and as has been stated since time began, ad nauseum, raw number-crunching isn't everything it's cracked up to be. Remember that class where they told you the right algorithm will beat the socks off of the wrong algorithm implemented cleverly?
Well, this is exactly the same thing. You can spend all day bit twiddling, or you can fix the problem in a better way.

-

my question

[Anonymous Coward]

Do you feel that although C++ is a great language, people have forgotten about C? I refer to the fact that, as a college student, I have had C++ rammed down my throat since day 1. Luckily, I did a bunch of C programming while in high school, so I know stuff like printf and malloc. Most of the people I'm graduating with don't know any of the original C syntax. Teachers no longer accept things that are not written in an object oriented manner. I feel that it has sort of diminished the idea of 'hacking' or 'kludging' code...which was one of the main reasons I became a programmer in the first place.

How to cope with MS VC++?

[SEGV]

What do we do when a major C++ compiler vendor refuses to migrate to the international standard?

The first language extension, covariant returns, proposed to the standardization committee and accepted in 1992, remains to be implemented in VC++6.

The scoping of variables declared in for loops also remains incorrect.

This causes major headaches for software developers who must compile on VC++6. They are useful features, and we wish to use them. Yet, a rogue compiler vendor causes us grief.

I'm not sure it is in Microsoft's best interest to conform to the standard. These longstanding bugs show no sign of being fixed.

How long before Microsoft starts adding new keywords to their C++ compiler? How do we programmers in the trenches cope with this?

--

Re:How to cope with MS VC++?

[Jason100]

That really is a GREAT question. MSVC++ NEEDS to comply to the standard! How can this be enforced?
Jason

Re:How to cope with MS VC++?

[Anonymous Coward]

The scoping of variables declared in for loops also remains incorrect.

Compile with /Dfor=if(true)for

Why no automatic garbage collection?

[Anonymous Coward]

The lack of automatic garbage collection in C++ turns it into a memory leak nightmare. Why did you neglect to specify this as a feature of the language?

An academic fad?

[Daniel]

Unless your definition of "fad" includes languages that have been around, AFAIK, nearly as long as computers..

Daniel

Implementation dependent and/or undefined

[Zagadka]

When designing C++, why didn't you make less things implementation dependent, undefined, and optional? As it is, developers often have to code to the lowest common denominator in any case, or deal with code that is very difficult to port. (for example, the sizes of the basic datatypes are implemntation dependent, while the values of many expressions are undefined)

Next Language to be created?

[Anonymous Coward]

In the history of (computer) languages, there have been a lot of "experimental" language efforts and special purpose languages. But there seems to be a single dynasty of "general purpose, fast, real-world" languages, roughly:

MACHINE

ASSEMBLER

FORTRAN

PASCAL(arguably) and other same-generation imperative.

C

C++

Each has been more or less a descendant to the previous "best of breed", and added features that were required for the next level of programming style.

What do you see as the next logical set of features that will demand a new language?

Kevin Bealer (kbealier@stny.lrun.com)

Hi Bjarne

[Anonymous Coward]

Hi Bjarne! First, let me say that you are a god. Neglecting all other comments and complaints, C++ is the most powerful programming languages ever written. I read the Design & Evolution of C++ and found it to be wonderful. My question: What is the point of C++ namespaces? It seems to me that they add a layer of complexity without providing much value. In what circumstances do namespaces add value or solve a problem? Kind Regards, Kyle Lussier iWorker, Inc. www.iWorker.com

Simple question.

[nyet]

if(bar) {
foo();
}

OR

if(bar)
{
foo();
}

OR

if(bar)
{
foo();
}

Re:The ultilate Q: Who the shift op for output!!?!

[Fulrach]

I think the (left shift/extractor) op is used for output because it has very low precedence so the does not get in the way of evaluation of most expressions placed between the s.

Large scale Software Engineering

[porsche911]

What do you see as the future processes for a world-class C++ team responsible for large scale SE projects? The classical waterfall and other processes seem to be unworkable in internet-time (which everything seems to be nowadays). What replaces it? How will the requirements, development, testing, and support be provided for MLOC+ size code in C++?

Chris Cunningham

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

Re:C++ acceptance over C

[Dixie_Flatline]

Actually, I don't think that they *did* have access to a good C++ compiler. I'm of the opinion that it's impossible to write a good compiler for a language like C++. It's too big, too complicated, and too convoluted. From a language design perspective, it looks atrocious, and I'm suprised that *any* compiler can be written for it at all.

you don't know that

[crayz]

if the person who moderated down then posted to the story, his moderation would be erased, thus you wouldn't see it in the Moderation Totals.

the same theory could explain how there have been posts moded down to -5(except this would be very tricky and unlikely)

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!

Next best-of-breed language?

[Anonymous Coward]

In the history of (computer) languages, there have been a lot of "experimental" language efforts and special purpose languages. But there seems to be a single dynasty of "general purpose, fast, real-world" languages, roughly:

1) MACHINE, 2) ASSEMBLER, 3) FORTRAN, 4) PASCAL (arguably) and other same-generation imperatives. 5) C 6) C++

Each has been more or less a descendant to the previous "best of breed", and added features that were required for the next level of programming style. C++ is the current champion, and will almost certainly "father" the next general-purpose system programming language.

I think it is interesting that each of the "best-of-breed" languages kept all the critical advances of the previous (C++ kept C's efficiency), and that almost every left-by-the-wayside language tried to /change/ the idiom rather than /extend/ it.

1. Will languages keep getting more baroque indefinitely?

2. What do you see as the next logical set of features that will demand a new language? What limitation of C++ most needs to be generalized/extended in your point of view?

Kevin Bealer (kbealier@stny.lrun.com)

Re:Next best-of-breed language?

[Anonymous Coward]

Sorry I posted this twice - I accidentally submitted the previous version. (But my real question is approx. the same, so answering either one is okay with me.)

not dynamic enough

[steffl]

(in following text: dynamic = recognized in runtime and also generic (to certain extend))

working with C++ I usually get the feeling of being tied up - in a sense that it is not dynamic enough. For lack of better explanation let me give example of more dynamic languages: smalltalk, perl. of course, those are interpreted languages (and that's the main reason they are so dynamic).

In C++ I have basically no meta-information - which would allow me to do something with class (any class).

The templates seem to address this problem, but templates are just a fancy code generator (everything's still done at compile time, so while it's more generic it's not really dynamic).

Is corba solution?

Any comments on this?

erik

Also, it "looks right".

[Anonymous Coward]

Visually, it's plausible as the insertion operator. Operators should look like what they do. With arithmetic operators, we've learned them already; with C boolean and bitwise operators, well, heh heh heh. Never mind :)

FWIW.

Did you ese it coming?

[ASMprogrammer]

Hello. I was wondering if you saw the popularity of C++ coming. Did you think it would be such a success, or did you figure people would think it's just a pathetic attempt to make C better? (not that it is). Thanks.

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

[Jackster]

Tell me about the different methodologies; I'd like to learn more. :}

Re:Its not about OO vs. procedural

[rambone]

well, at the very least there is functional programming.

Re: What do you think of the STL? (1)

[HarpMan]

David Greene writes:

o Iterators don't know about their container objects

How is this a problem? The idea with iterators is that that you don't need to know about the containers to write algorithms that use them; you just need to know about the iterators. If you find yourself wanting to get at the container from the iterator, something is probably wrong with your algorithm, or understanding of the STL.

o The incompatability between STL iterators and, say, string

iterators

The string class was implemented before the STL proper. This main explain part of the problem. I wish the string class had been completely rewritten with the STL in mind, instead of just retrofitted. But, this would have broken backwards-compatibility. The string class is my least favorite part of the C++ Standard Library.

o Missing operator+/operator- on non-random access iterators (yes, I know about advance)

The idea is that things that could be very inefficient won't compile using the obvious approach, like trying to do random access style arithmetic on non-random access iterators. Of course, you could write your own one-line + operator that used advance.

I agree with you on the string class, but not on the other two. I'm glad that operator+ doesn't work on non-random access iterators. But, you're not happy about it. This is obviously one area where you can't please everyone.

--

Some little people have music in them, but Fats, he was all music, and you know how big he was. -- James
P. Johnson

--
Steve Molitor
smolitor@erac.com
"Emacs is the Computer"

Re:Embrace and Extend

[timster]

He was of course talking about glib. As opposed to glibc.

OS kernel hacking in eLisp, Perl, Python, etc.

[Anonymous Coward]

Uh, yeah, right.

Hardware agnosticism is fine if the language doesn't have to talk to the hardware, or if it's willing to talk to the hardware through an abstraction layer written in a hardware-aware language (e.g. C, C++, asm, etc.)

I'm intrigued by the Java IDE thing though. Which one is it?

Re:OS kernel hacking in eLisp, Perl, Python, etc.

[Anonymous Coward]

VisualAge for Java. It was written using VisualAge for Smalltalk.

Performance problems? I think not.

Objective C

[ajc]

What do you think of Objective C?

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.

Bad presupposition; OO is a *tool*

[tmoertel]

The original question was based on the faulty presupposition that a programming paradigm can, in fact, be a panacea. Sorry, ain't gonna happen.

Who besides obvious hypemongers ever said that OOP, OOA/D, and their ilk were the magic programming elixirs for all software ailments? Certainly not Stroustrup.

Most folks who have been writing software for more than a few years realize that there are no easy answers, no quick all-serving fixes, no silver bullets. Every paradigm is a tool in the programmer's kit. Each is effective at solving a certain class of problems. Pick the right tool for the job, and you're on easy street. Make the mistake of attacking every problem with a hammer, and you apt to do a lot of cursing.

Regarding what paradigms are "challenging" OO, I don't think that there are any challengers, not because OO is the king of the hill, but because the whole concept of one paradigm being the "best" doesn't make much sense. For some problems, OO is the best tool in the kit; for others, it isn't. Most non-trivial problems are best solved by using a number of paradigms, anyway. I sure wouldn't settle for just one.

Look, folks, there isn't ever going to be a one-tool kit that solves all problems. Quit knocking C++ because it isn't this mythical beast.

Re:Bad presupposition; OO is a *tool*

[radsoft]

Ok, let's knock C++ instead because it's a piece of junk that has caused more misery on both sides of the planet than any language before and most likely even since.

New Library Features

[HarpMan]

My question:

Do you foresee any major or minor additions to the Standard C++
library in five years? Minor additions might include hash_map,
hash_set; major additions could include automatic garbage collection,
serialization, meta-programming thingies like reflection.

Thanks

Did Fragile Base Classes cause open source?

[epeus]

The most compelling argument against the use of C++ is the Fragile Base Class problem. With all C++ implementations I know of, you cannot change a library class to add a method or member variable without causing all code that links with it to crash (or at least radically misbehave). With C structs and functions, this is far easier to avoid.
However, this could be an incentive to go the Open Source route, as if you have to recompile anyway to avoid crashing, providing source as opposed to binary librarues is encouraged. What do you think?

The evils of operator overloading: A tired myth.

[Anonymous Coward]

[Java's spec is] considerably smaller than C++'s language spec, yet it contains almost all of the useful features of C++, and many features that I wish C++ had.

True, there's a lot to be said for minimalism. Look at how long C has lasted. But could you name a few of the features Java has that C++ would benefit from? I'm not aware of . . . any. Java "interfaces" are just abstract base classes by another name; I don't see any need to add a "feature" to the language for that. Name collisions due to multiple inheritance can happen with member functions as well as data members, so it's hardly a cure for that problem. (Mind you, once you do define it as a feature unto itself, that has a positive sort of propagandistic effect on the user; I'm willing to bet that far more Java programmers use multiple inheritance via interfaces than C++ programmers do via abstract base classes -- and not because it's any easier in Java, but because that way of looking at things has been brought to their attention. When I first heard of that Java feature, it blew my mind, and then I realized I could do it in C++. I've been doing it ever since).

One thing Java is notably missing is protected access: A protected member is visible to subclasses, but not to the outside world. This can be very cool, if you want to keep your implementation safe while allowing some extra hooks into it for a subclass to use. Protected virtual functions kick ass: They let a base class define certain parts of its implementation that a subclass can replace or modify, without the subclasser having to rewrite anything but the one part he wants to change. Of course this all depends on good programming, but doesn't everything? :)

object-slicing,

What's that?

operator overloading,

It's true that idiots can (and do :) write incomprehensible code in any language, but it takes virtually no brains at all to avoid inappropriate operator overloads. In Java, you can name all your functions a( ), aa( ), aaa( ), etc. The language won't stop you from being a moron, nor should it. Inappropriately overloading an operator is precisely the same as mis-naming a function -- because it precisely is mis-naming a function, nothing more and nothing less.

On the plus side, operator overloading can make for much cleaner and more readable code, and it also allows you to provide interfaces common to both class instances and built-in types -- thereby making it possible to write templates that work on . . . Oh. Sorry. Well, if you had templates, you'd see the advantage of that, believe me.

platform dependent datatype sizes

That's not a feature of C++ so much as a feature of the problem domains in which C++ was intended to be used. C++ is all about combining OOP facilities with C's ability to get right up close to the machine. If that's not what you need, why then don't use it :)

the need to use forward declarations ad nauseum

Personally, I sort of enjoy having a header file where all the interfaces are laid out without any implementation clutter. It's right there. It's documentation that the programmer is forced to keep up to date. Of course, all that header-file-crunching does take a year and a day at compile time. I'll concede that.

non-final non-virtual methods (and by default!)

Yeah, "final" is cool. C++ might benefit from a "final" concept.

Thanks a lot Bjarne

[Midnight Coder]

On the off chance that you'll read these comments I wanted to say thanks for C++, if it wasn't for you I'd probably be programming in C.

Thanks for making the standardisation process open, and thanks for personally checking every 'feature' that made it into the language specification actually needed to be there.

Thanks for signing my copy of D&E at SD'99, and for chatting to me at SD'98 and SD'99, your talks were great, (pity you wouldn't comment on open source software when I asked you at the roundtable talk...).

I guess if I had a question if would be "What do believe is the greatest weakness of the open source software development model?".

Ok then...

[LordZardoz]

So the idea of private/protected is to minimize the amount of info an "external" programmer is depending on, and to use "get and set" functions instead. Ok, so what if you remove the variables at a later date anyway? The functions then have nothing worthwhile to return. For purely internal values that "external" programmers do not /should not require access to, then yes, private is a good use. But if that value is needed outside the class, but shouldnt be changed outside the class, then why not allow for an access specifier that exposes the member to other classes, but does not allow other classes to change it? The only awkwardness is that a function declared under such a specifier would be conceptually strange. END COMMUNICATION

Redundancy - Bug or Feature?

[Chip Salzenberg]

Several aspects of C++ require that the same information be typed (or cut & pasted) several times. For example:

• Constructor and destructor names are textually the same as their class names. This redundancy could have been eliminated if constructors and destructors had special names. (You used the special-name approach with operator new and operator delete.)
• Function definitions and declarations of virtual function overrides must restate their return types and parameter lists, even when just the function name would be enough.

Is this redundancy a bug or a feature? And, why?

bad behavior

[Anonymous Coward]

What prompted the standard to include the 'default copy operator' and 'default copy constructor' to be implied by the language. Beyond a few trivial data structures, this behavior is clearly wrong a vast majority of the time, prompting people to go out of their way defining these functions as private, just so they aren't accidentally used. Even then making the member functions private isn't always going to work. I could possibly see this behavior kept for structs, but classes are usualy never as trivial. Finally, a third method was probably overlooked that can be correct in a lot of cases: some kind of attribute could be applied to a class such that the code does a 'for each element in class, use its operator= to copy it'. This could elminate some amount of coding in classes where this is safe, as you would not need to maintain functions which copy every element over, and might miss one if the structure is modified at some later date.

Very good questions

[Midnight Coder]

I wish you could have posted earlier, I would really like to hear Bjarne's answer to these questions.

Stroustrup is a jerk

[blakdeth]

Has anyone ever tried to read Bjarne Stroustrup's "C++ The Programming Language"? If so, you must have noticed that Stroustrup comes off as a condescending jerk. Throughout most of the book it seems he is trying to emphasis the notion that he knows more than "you" ever will about C++. Stroustrup may have invented C++, and he may be an intelligent man, but he certainly seems like someone I wouldn't want to know.

BD

Re:Stroustrup is a jerk

[Midnight Coder]

I've talked to Bjarne a few times, and listened to him talk to others. He might know more about C++ than anyone else on the planet but he didn't appear arrogant about it. I found him pleasant to listen and talk to.

Re:Embrace and Extend

[Arandir]

Doh! Lash myself with a wet noodle...

Marketing in a marketplace of ideas

[Jan]

Sorry about the marketing. I happen to think conventions *like* COM (I said *like*) are a sensible way to get interop, and besides make sense for writing loosely-enough coupled Component Software [http://www.amazon.com/exec/obidos/ASIN/0201178885 ] (as opposed to Object Oriented Software, which often has scary implementation inheritance couplings and dependencies).

RE: your questions,

Object references between objects in the same context/apartment are direct pointers. Object references crossing contexts/apartments/processes/machines address some kind of proxy-channel-stub structure. The client (object holding the object pointer) usually does not trouble itself with whether it is directly addressing a real object or a proxy, e.g. mostly transparent remoting.

When the client calls a method on an object in the same context, it is a direct C++ virtual function call; when it calls an object in anothe apartment, process, or machine, the proxy marshals the arguments, the marshall buffer is moved to the other address space, and unmarshaled; the object is called, its return values are marshalled, that result is moved to the client's address space and unmarshalled.

(An "apartment" is an object environment within a process, with certain concurrency and thread affinity guarantees, that provides a convenient programming model in a multithreaded application. For example, concurrent calls to objects in a particular single-threaded apartment are serialized. A "context" is an object environment within an apartment, within which groups of objects live. COM+ uses contexts to provide automatic services on behalf of objects, such as automatic security checks and automatic transactions.)

So: near calls are as cheap as C++ calls, and more distant calls can have overhead proportional to the marshaling, copying, and/or RPC overhead.

Some parts of COM involving remote activation and security are privileged, and there's lots of standard code for building proxies and stubs (marshalers and unmarshalers) and so forth from interface descriptions, but you can certainly use your own COM-like conventions for binary interop independent of any OS.

Repeat: you can have binary interop between languages and language implementations without much pain if you keep the kinds of coupling as simple as possible. For example,
1. the only thing you can do with an object is call methods on it (no touching its data members directly);
2. methods can only pass and return objects by reference (pointers, not whole structures);
3. all interoperable implementations produce the same vtable layout from the same interface description.

See also the section "C++ and Portability" in the first chapter, "COM as a Better C++" of Don Box's book _Essential COM_.

For what it's worth...

[Muzzarelli]

... your comments are exactly what I've been thinking for the last few years. Most people criticizing OO just haven't ever 'gotten it', and have never clicked to that way of thinking.

The frustrating thing is that it seems impossible to 'show them the light'. Maybe really understanding OO requires somebody to find that type of thinking for themselves, as it can't be taught?

Re:For what it's worth...

[Jackster]

I've also noticed that few people who deride OO really know it. I suppose that's true for all sophisticated concepts.

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

STL

[Anonymous Coward]

The STL is awesome, but it seems like there's a lot chopped from it - hashed containers, the copy_if algorithm, etc.. Could you discuss the issues involved in choosing what did or didn't make it in the standard? Is there any chance of it growing in the future to incorporate new stuff?

Re:The evils of operator overloading: A tired myth

[Anonymous Coward]

re: header file with the interface, seperate from the implementation.

yes, I agree totally, but C++ DOES NOT hide all the implementation; it exposes not just public methods and data members, but the entire layout of the object, both public and private members. private members (data & methods) are implementation specific and should not be visible to the programmer of the client. In a perfect world, anyway. Not going to change in C++ anytime soon.

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.

more additions to C++

[yotam]

Hello Bjarne, Do you think there will ever be significant additions to C++? How about well defined sized integeres such as: int32, int64, uint32, uint64 or templatized? Additions to the standard library? hash-tables, hash_map, Big-dynamically growing integers?

Re:more additions to C++

[epine]

From the point of view of genericity, adding guaranteed integer sizes (such as int32) would be a highly retrograde act.

On a practical level, if the platform supplies the desired integers these can be easily typedefed as described within a header file (the numeric_limits facility allows this to be done quite robustly with little or no platform specific code). There is no need to embed these conventions within the language at this late point in time.

On a deeper level, the use of "guaranteed" types completely misses the point.

There are certain kinds of integer computations which depend upon a precise modulo behaviour. Most cyphers contain such operations.

Then there are other contexts where the size of the integer used does not affect the end result of the computation depending only on the integer type being of a "sufficient" size. Within this category are two distinct situations: one where having a larger integer type extends the allowable range of the computation (a side benefit) and another situation where using an integer type "larger than necessary" confers no benefit at all.

And finally, there are situations where space issues are more important than size issues and where smaller sizes should be used regardless of whether the platform computes efficiently on the smaller size. Usually in this kind of code there is a carefully chosen compact representation type used within the large data structures, and a distinct integer type defined for computing with these values.

So we break this down along a number of axes:
whether the integer is compact or fast (as chosen by the platform)
whether a precise size is required to achieve correct results
whether "padding" the integer to a larger size can be considered to be a "side benefit"

These semantics can already be captured quite well within C++ using the template facility.

Any system with even a slight pretense of genericity will end up mapping the platform types through several type indirections anyway.

The worst thing would be to have programs where int32 is plastered everywhere with no distinction present about which of the above considerations dictated the final choise.

Likewise with all the other suggestions: C++ already contains features which make it possible (and satisfactory) for any of the features cited to be implemented in libraries rather than in the base language.

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.

OOP^2?

[betamax_]

Precedural languages like C were a milestone in productivity as were OO languages like C++. What is the next step?

Just as was with C++, we are probaly seeing these techniques now, for instance design patterns. However, what would a language designed for design patterns look like? I think that patterns wouldn't be the only advance in hyper-OOP. There could be features such as multi-directional hierarchy, child to parent and between siblings. Heck, it shouldn 't even always be a tree, what about rings!? There could also be an eval like function to allow objects to create new abstractions or entirely new objects.

But unlike C and OO, C++ can't impliment any of these because it is too rigid and focuses too much on memory allocation. This why languages like Smalltalk, Java, and Python are, quite simply, more foward thinking than C++. Seeing as you obviously disagree with this, what do you think a next generation language would look like?

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

The Day After C++

[XiRho]

Dr.Stroustrup, I'm sure that you've been expecting a great deal of questions relating to C++. However, I have decieded to defy the force of conformity and ask you a question unrelated to C++. So here goes:

Bjarne, what is your view of the future? Now I know that sounds cheesy, so I'll narrow things down:

Where do you feel, for example (and to tie in a certain major project of yours without giving its name), languages will be in the near future? Do you see postmodernism as a viable design, and that the "C++ of the Future" will be more natural, rather than organized?

But besides languages, you also have an interest in OSes and Distributed Systems, so what are your takes on the subjects, and where their future lies? Do you feel the Distributed OS (DOS, heh) is the future of architecture and OSes? Where do you feel the future of such architectures and OSes are? Since you're at Bell-Labs (or were, or are with AT&T Labs but not with Lucent, or whatever), I'd imagine you've encountered Plan9. Do you feel Plan9 is the Unix of the distributed age, or do you feel no true succesor to Unix, for the distributed-era, has come?

Thanks.

Sorry... maybe it's not as obvious as I thought.

[DragonHawk]

Sorry, I may be synthesizing the answer by using information from other sources, which the FAQ only makes connections to in my mind.

One of Stroustrup's design goals for C++ was to be able achieve efficiency near or the same as that of C if you wanted to. ("C with classes") Built-in garbage collection would, of course, make that impossible. Likewise, his opinions about Java are that it isn't done yet, and is generally following a design he thinks is wrong.

I missed your second question ("Do you think someday..."), though. I apologize for that.

plan9 v's linux - sm511451450357

[goon]

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

C++ & Linux

[huma]

How do you think the relationship between linux and C++ is? Just guessing ;), if Linux will become the predominant OS, do you think the use of C++ will go down?

Slashdot and Denmark

[Snaller]

So why do you think, each time one reports some news from Denmark the IT center of Europe, Slashdot tends to ignore it, eh? I suspect a conspiracy
;-)

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?

Re:The evils of operator overloading: A tired myth

[Anonymous Coward]

Java "interfaces" are just abstract base classes by another name; I don't see any need to add a "feature" to the language for that. Name collisions due to multiple inheritance can happen with member functions as well as data members, so it's hardly a cure for that problem.

The problem Java's interfaces are meant to solve is the case where you inherit from multiple baseclasses that have different implementations for a particular method.

eg: class Cat and Dog both have a "noise()" method. The Cat version says "meow" and the Dog version says "woof". If I create a subclass of both Cat and Dog, what does it do when I say "catdog.noise()"?

Different languages have different approaches to this. In Java, since you can only multply inherit from interfaces, which are "pure abstract classes", you would only ever have at most one inherited imlementation for each method. Other languges (Sather, and I think Eiffel) have a method renaming system. In C++ you're not allowed to say catdog.noise() because it's ambiguous. You have to use ::.

One thing Java is notably missing is protected access

What are you talking about? Java has protected access. It has private, protected, public and "default" (sometimes called "package" or "friendly"). The difference between Java's protected and C++'s is that in Java, protected means that other classes in the same package can access it as well as subclasses. (Think of java packages as a group of "mutual friends" in C++, except that in Java "private" actually keeps even your friends out...)

What's that? [object-slicing]

Object slicing is what happens when you pass an object by value in C++, and the receiver is expecting a baseclass. The object gets "sliced" down to the baseclass, which can often have rather nasty side-effects.

platform dependent datatype sizes

That's not a feature of C++ so much as a feature of the problem domains in which C++ was intended to be used. C++ is all about combining OOP facilities with C's ability to get right up close to the machine. If that's not what you need, why then don't use it :)


I generally don't use C++, actually. C++ is too high-level for systems programming, and too low-level for application programming. It's like having a shopping cart with a souped-up V8 installed. Sounds kind of cool, but it'll rip your arms off if you try to actually use it to shop, and its handling on the road is less than spectacular...

In any case, the platform dependent datatypes are not an area where C++ gains any significant efficiency. In fact, it probably loses efficiency here, because good programmers end up assuming the worst case about each datatype (eg: an int is only guaranteed to be able to hold 16 bits of information). Virtually every C and C++ library I've every seen, everyone goes and makes their own typedefs that are at least somewhat more predictable than the normal builtin types.

It's true that idiots can (and do :) write incomprehensible code in any language, but it takes virtually no brains at all to avoid inappropriate operator overloads.

I have to admit this is one of those things where I can go either way. Operator overloading can be very cool if used properly, but I've seen it misused so many times that it hurts. It also leads to difficulties in determining whether code is exception safe. Hmmm, "a = b + c" looks safe. Whoops, b and c are different sized matrices, and the + operator throws an exception when you try to add mismatched matrices together in this library!


the need to use forward declarations ad nauseum

Personally, I sort of enjoy having a header file where all the interfaces are laid out without any implementation clutter. It's right there. It's documentation that the programmer is forced to keep up to date. Of course, all that header-file-crunching does take a year and a day at compile time. I'll concede that.

First, C++ header files contain way more implementation than they should have. Data layout, private members, and even the actual code for inline methods are all right there in the headers.

Second, having separate files for interface and implementation doen't imply the need for forward declarations. Take a look at Modula-3 for an example of real separation of interface and implementation, but without forward's. (Modula-3 probably would've done better if it was a bit more object-centric and a bit less module-centric, and if it didn't have obnoxious all-caps keywords...)

Hav you ever had two classes that call inline methods of eachother? Sorting that out is a huge pain in the @$$.

Safe Arrays

[Tom7]

>But then, C++ is the only language (to my
>knowledge) that allows you to use safe arrays
>where you want them, and faster...

Well, Standard ML of New Jersey has both safe (default) and unsafe arrays, for one. I'm sure many other languages with safe arrays often include optional unsafe ones, as array bounds checking can be a huge performance hit for lots of code.

In addition, with a strong type system it's possible far more often to eliminate runtime checks through code/type analysis. Safety doesn't necessary have to cost you something (as Java/Perl proponents might sometimes have you believe)...

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?

Oops, I expressed myself poorly.

[Anonymous Coward]

Sorry about the marketing. I happen to think conventions *like* COM (I said *like*) are a sensible way to get interop

I ain't denyin' it. The COM part wasn't what I meant about "marketing". I just meant the use of "author" as a verb, which really grates on my nerves. (I'm not so crazy about "interop" either, but never mind :) I noted and appreciated the fact that you mentioned XPCOM in your original post, FWIW: Mainly that you weren't pushing one vendor's implementation, but rather discussing the idea in general.

When the client calls a method on an object in the same context, it is a direct C++ virtual function call;

Groovy. I feel better now.

. . . when it calls an object in another apartment, process, or machine, the proxy marshals the arguments, the marshall buffer is moved to the other address space, and unmarshaled; the object is called, its return values are marshalled, that result is moved to the client's address space and unmarshalled.

I might guess that including "apartment" in that list might have something to do with synchrony and what not, like foo's stuff evaporating before bar gets the chance to look at it? I'm not sure I'm fully grokking the "apartment" thing. At any rate, there's certainly no way around the marshalling deal when talking to a remote machine; that's just the nature of the animal you're dealing with.

the only thing you can do with an object is call methods on it (no touching its data members directly);

That's the part I like most :) Why didn't anybody tell the MFC guys about that?!

methods can only pass and return objects by reference (pointers, not whole structures);

They generally ought to anyway.

all interoperable implementations produce the same vtable layout from the same interface description.

Again, that sounds like good practice in any case.

Thanks for the info.

Efficiency of C++, or lack of

[jkh87]

I am a college student who is currently learning C++. One of the biggest faults that our professor has pointed out is that C++ wastes memory by making copies of variables, etc... when it passes it to a method to be used by an object. I have to agree that it does seem terribly inefficient. I am just curious, why did you implement the language to do this? Are there any apparant advantages?

Re:The evils of operator overloading: A tired myth

[Anonymous Coward]

The problem Java's interfaces are meant to solve is the case where you inherit from multiple baseclasses that have different implementations for a particular method.

Duh. I didn't think it all the way through. Still, what about interfaces with like-named functions that have different meanings, like, oh, this is a shitty example, but what about cat::noise( ) conflicting with signal::noise( ). Maybe I'm grasping at straws :), but I do think there are more realistic examples of that problem.

What are you talking about? Java has protected access.

My bad. I thought I'd heard that it didn't. Never mind.

Object slicing is what happens when you pass an object by value in C++, and the receiver is expecting a baseclass. The object gets "sliced" down to the baseclass, which can often have rather nasty side-effects.

Hmm, offhand I'd think that the expected class's copy constructor (if any; in the absence of a reasonable conversion, I'd expect it not to compile) would be called, which could be undesirable depending on the implementation of the classes concerned. But if you pass objects by value, you really get what you deserve. That's what const references are for.

Operator overloading can be very cool if used properly, but I've seen it misused so many times that it hurts.

I've only seen one bad case, that being the Raima library. Uggghhhh, brrrr, horrible. It's very old C++ code, though, from back when operator overloading had novelty value. You just have to have some discipline and not treat operator overloads any different from any other standard interface with commonly understood semantics. I really don't think the iostream library helped either, overloading << and >>. It was the first example of operator overloading that anybody ever saw, and it was a marginal example at best.

Whoops, b and c are different sized matrices, and the + operator throws an exception when you try to add mismatched matrices together in this library!

Well, leaving aside the fact that I personally would assert that instead of throwing an exception, how is that different from throwing an exception (or an assert) in a matrix::add( ) function?

In any case, the platform dependent datatypes are not an area where C++ gains any significant efficiency.

Hmmm . . . I don't know what Java loses or doesn't lose by enforcing a particular endianness on ints and whatnot, but in any case I wasn't thinking so much about efficiency so much as simply a lack of abstraction in general. FWIW (if anything :)

First, C++ header files contain way more implementation than they should have. Data layout, private members, and even the actual code for inline methods are all right there in the headers.

Granted, though some people (horrible MFC comes to mind) do put inline function bodies in separate files that are also included. This is a problem inherited from the practice of using C linkers, and bending over backwards to stay within their capabilities (along with name-mangling and God knows what-all else).

Second, having separate files for interface and implementation doen't imply the need for forward declarations. Take a look at Modula-3 for an example of real separation of interface and implementation, but without forward's.

True.

Modula-3 probably would've done better if it . . . didn't have obnoxious all-caps keywords

All-caps?! Ugh, ugh. Was that another Nick Weurth masterpiece?

Hav you ever had two classes that call inline methods of eachother?

I don't recall running into that particular problem, but I can see where I'd hate life for a while if that happened :) I have had other problems along the same lines, declaring classes that need to know something about each other. Miserable.

No, the lesson is "Fire all Perl Hackers"

[Anonymous Coward]

Wall's talking about job security, that's all.

What we need here, to make this planet a better place to live, is a worldwide bloodbath in which all the Perl hackers are, well, hacked to bits with machetes. Rivers of blood in the streets! Yes! Man, that'd be cool.

LOL :)

[peter]

That pretty much sums up the lower half of the /. denizens... :)
#define X(x,y) x##y

What are we supposed to ask BJARNE?

[radsoft]

Huh? Go visit some real intellects instead. Visit Dennis Ritchie at: http://cm.bell-labs.com/cm/cs/who/dmr/ Visit Brian Kernighan at: http://cm.bell-labs.com/cm/cs/who/bwk/ Reality check, Robbie Boy.

Errr, not really.

[Anonymous Coward]

Think of it rather like this: The typename is a "direct object" of operator new, by analogy with English grammar:

int *foo = new int;
bar *baz = new bar; // dflt constructor
bar *baz = new bar( "urg" ); // char * constructor


Or take for example creating a temporary, in which case it's appropriate to think of the constructor as a function which returns an instance of the class (and, in fact, that is precisely what it is):

int func( bar &baz );

int examplefunc()
{
// bar() is a call to the constructor of bar
int i = func( bar() );
int j = func( bar( "kermit the frog" ) );
}


Constructors have no explicitly declared return type because they can and must have only one return type, which happens to be the name of the function anyway. Since they must always invariably return *this, the return statement isn't explicit either. The absence of a return type is similar to declaring cast operator overload functions:

class foo2 {
operator int();
};

operator int() can and must return only int, so having an explictly declared return type would gain nothing while adding a potential for careless errors. operator int() still has an explicit return statement because while it must return int, nobody said anything about which int, unlike constructors where a specific instance of the type must be "returned" (though bear in mind that the mechanism for "returning" class instances from constructors is not the same under the covers as the return mechanism with normal functions, because with the normal deal the only way to return an object "by value" is with a copy constructor, which would of course recurse infinitely :)

Of course, you could say that in the case of operator int() the return type is being declared without a name rather than vice-versa. That might be an even better way of looking at it (in fact, I'm suddenly realizing that it's by far the best way to look at it) and it also very closely parallels the logic behind constructor names.

Garbage collection

[Anonymous Coward]

One of the most difficult problems in large-scale programming is knowing when to delete an object and reclaim its memory. Java and many other languages have garbage collection to automate this job, albeit at the expense of efficiency. I know you do not believe that garbage collection should be a part of the core language, but couldn't it at least be a compiler option or something (if possible)? I think that would make C++ far more attractive for many applications.

Betcha pick up lotsa gurls with that!

[Anonymous Coward]

"C++ : C :: PL/I : FORTRAN", yep, ya gotta beat 'em off with a stick, I can see it now.

If a garbage collector kills your family . . .

[Anonymous Coward]

. . . don't come crying to me, you smirking prick.

By the way, "irregardless" [sic] is not a word in the English language, although the use of it does happen to be one of the most reliable indicators of cretinism known to modern science. For corroboration, "irregardless" is almost invariably accompanied by morbid inflammation of buzzwords, like for example the following burst of MIS-droid gibberish: "a long term development solution that is truely fault tolerant in mission critical situations". Listen, pal, anybody who talks like that is in desperate need of a quick trip to a brain transplant specialist.

Re:If a garbage collector kills your family . . .

[Klaymor]

Speaking of smirking prick...if you have nothing better to do than criticise my use of the English language them please don't bother to respond. As for a MIS-driod I happen to be molecular biologist about as far away from MIS at can be. If you want to see some MIS-droid crap read the SUN Licesnse for Java in the first place. If Java is to ever mature as a language then there needs to be a measure of fault tolerence that is not currently implemented in the Java Specification.

This is why Java is good [was Re:future library]

[gg10]

For mine, Java is good simply because it's standard library is so useful.
The C++ STL is great but it would be alot better if it was expanded to include at least a GUI API!!
Please have this question answered!!!!

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.

Polymorphism

[Anonymous Coward]

Why was bounded polymoprhism not included in C++? For those who don't know, C++ has a template feature that allows declaration of generic classes (e.g. template list { void add(T t); }). Bounded polymophism allows the declaration of templates that would restrict the template parameter to be a derivative of a certain class. (So T would have to be derived from some parent. The language can then restrict what add(T t) does with t to valid operations on instances of that parent.)

Your prof is an idiot. The question is bullshit.

[Anonymous Coward]

What the fuck are you jabbering about anyway? Putting arguments on the stack? Member function calls in C++ differ from non-member function calls (and plain old C function calls back in 1974) only in that a "this" pointer goes on the stack along with the rest. (With virtual functions, some pointer-snapping happens to choose which code gets called, but that's nothing to do with making copies of arguments).

Not only does C++ do absolutely nothing even remotely unique or unusual in this regard, but it also provides facilities for passing literally anything as a pointer (references are syntactic sugar on pointers), which is pretty damned cheap: 32 bits on most operating systems. Which happens to be the size of an integer in most cases. A pointer to an integer therefore uses up exactly the same space as the integer itself, you pathetic halfwit. Or are you yammering about promotion of integral types? No, that's nonsensical, too.

You seem to be under the impression that data can be pushed around without ever using any storage. This is because you do not have a brain.

Finally, "terribly inefficient" is total bullshit in any case. You sould like the Cobol morons thirty years ago saving two bytes by keeping only the last two digits of years (which was cretinous to begin with, because they were storing ints as strings! Those two bytes could have been used as a short int and kept the code stable for the next sixty-five thousand five hundred and some-odd years. IDIOTS.)

In short, you're a hopeless babbling imbecile with a brain the size of a walnut. Your professor is not competent to pump gas in Guatemala. In a just world, both of you would be shot to improve the breed.

Fuck off and die, retard.

Hope this helps.

Re: Binary compatibility

[tpv]

I was going to ask this too, so moderate this up :)

In addition though, an additional problem, and one that is not solved directly by a common binary interface, is the so-called "Fragile Base Class" problem. ie If I add virtual methods to a class, then (for all implementation I am aware of) it forces a change in the virtual lookup mechanism (ie the vtable in most implementations) all derived classes must be recompiled to remain compatible. (There are obviously similar problems with changing anscestors etc)
This creates massive binary compatibility problems, as if you ship C++ code in a shared library, then you are effectively restricted to each application being tied one and only one version of the lib.

The reason I am interested in these topics is tied to the fact that (a) I (more-or-less) like C++ (b) I use BeOS which is tied to C++

BeOS has problems with fragile base classes, but the ABI is more of a problem. How do I link my perl/python/C/Eiffel/SmallTalk/Sather/Pascal/Basic (all of which have potential users on BeOS) to the strictly C++ API? The options are to generate wrappers (either as C functions to call the C++, or by generating some form of ORB), or to rely on the fact that BeOS is using GNUpro, and build some support for hacking into the underlying structure of the GNUpro binaries.
The C wrapper sux, bcs you just end up reducing C++ down to C, which is hardly the point. Relying on the binary structure is nicer, but not at the expense of compatibility.

Is there a solution? Or is C++ just not cut out for use in such an environment?

That's called inheritance.

[Anonymous Coward]

The following code would be legal if foo( ) and foo2( ) were function templates, and they only did stuff to bar and quux which involved members that had the same name and type in each. For instance, if bar and quux both had argle() members, and all foo( ) and foo2( ) did was call b.argle() and q.argle() respectively. The same applies to class templates, but they take longer to type :) So if you want foo2( ) not to work on bar or baz but only on quux, it's quite easy: Just don't use templates.


int foo( bar &b );
int foo2( quux &q );

class bar { ... };
class baz { ... };

main()
{
baz z;

// legal:
foo( baz );

// bzzt, won't compile:
foo2( baz );
}

C++ template repositories are crap - here's why...

[Anonymous Coward]

Template repositories are crap. When will C++ compiler implementors learn that? (Are you listening Sun Micro?) Fold all the template symbols into each .o and have the intellegent linker throw away all the duplicate, weakly linked, symbols. That's the only way you can coexist with modern course code control systems like ClearCase. Template repos and their constant source of annoyances bugs are no end of pain for large scale C++ systems. They give C++ templates a really bad name. I truly hope that g++ will become THE OFFICIAL C++ COMPILER because they are the only ones that know what they're doing.

Hard to debug code that uses STL containers...

[Anonymous Coward]

It is hard to debug code that use STL containers because the debugger (human or machine) has to be intimately familiar with some C++ library vendors particular implementation of STL: with dinkumware's STL being the worst to SGI's implementation being the best.

Did we need java or just ?

[Anonymous Coward]

Text based C programs were easily ported anywhere because the stdio library was the same everywhere. Why did no one ever attempt to define a stdgui.h to do for the GUI what stdio did for the command line? Java sucks since Sun has decided to play God and toy with who can do what and how. Perhaps, we need an OSS movement to create a standard GUI library for C/C++. Start by identifying a set of basic GUI calls common to all (or at least most) GUI OSes. Then get it approved by ANSI/ISO to ensure universally compliant implementations down the line and presto! Write once, run anywhere can finally become a reality. Even on the FoobarOS!

Re:Did we need java or just ?

[Anonymous Coward]

One semi-standard GUI system that is already available on many platforms is TK. I don't know if there is a C++ interface for it or not, but it may be a place to start.

Re:CORBA and C++ - like OIL and WATER

[Anonymous Coward]

I have read what Bjarne said about CORBA - he hates it. Bjarne, do you care to elaborate about your feelings about CORBA? Do you have a better RPC/messaging scheme?

PLEASE PLEASE PLEASE standardize C++ mangling!!!!

[Anonymous Coward]

Please make this part of the C++ standard - every vendor is completely clueless in this matter - please have ISO mandate a definitive standard for more aspects of C++!!!

C++ Virtual Machine? MMIX anyone?

[Anonymous Coward]

I wish linking was deferred to the latest possible stage in C++ to avoid this fragile base class problem in C++. I think the world needs a C++ Virtual Machine with different loaders for each platform. Knuth's MMIX may be the key to this.

Any thoughts on creating a standard C++ VM?

[Anonymous Coward]

I'm C++ biggest fan, but I realize that C++ desperately needs its own virtual machine with completely predictable behavior and standard sizes for basic variable types (int, long, etc). Having ANY standard is better than having a loose standard or no standard. The ISO C++ standard is far TOO LOOSE to be useful in the real world. We need to completely define the C++ runtine environment to allow C++ to survive in this new age of programming on multiple platforms. People no longer wish to rebuild their code on every freaking platform on earth - they just want to run it - as is.

Okay - standardize EVERY BEHAVIOR then

[Anonymous Coward]

PLEASE standardize C++ name mangling, virtual table layouts, pointer to member function construction, template object formats, contructor and destructor calling conventions, basic data type sizes, etc, etc, etc. C++ needs MORE RIGID STANDARDS. What we have now are C++-like systems that have more things NOT IN COMMON than IN COMMON with each other. This is not freedom - this is choas. Any code that hopes to be ported to more than 2 platforms must have magicians as programmers. This is just silly.

Why no big 3rd party C++ library vendor industry?

[Anonymous Coward]

Does it have something to do with the brittle base class problem of C++, or the lack of standards in C++ implemtations? As it now stands RogueWave is the only successful C++ 3rd party library shop. ObjectSpace to a lesser extent. But BOTH VENDORS HAVE ABANDONNED C++ in FAVOR OF JAVAS. That's pretty damning stuff indeed! Because there are no universal standards in C++ implementations between platforms these vendors must provide source code for the C++ libraries. As result, the industry suffers greatly. Meanwhile the VB/COM/JavaBean industries flourish. Bjarne, care to comment on this dillema?

Are C++ compilers unimplementable?

[Anonymous Coward]

The Sun C++ 5.0 compiler produces WORSE CODE than 4.2 and has a ton of new bugs and memory leaks. Has C++ become impossible to implement? Do we need a universal C++ virtual machine? Or should everyone just drop proprietary compilers in favor of g++?

Re:The evils of operator overloading: A tired myth

[SuperKendall]

Look at how long C has lasted. But could you name a few of the features Java has that C++ would benefit from?

A few more great Java features:

* Custom class loaders. The gateway for classes to enter the system, it makes things possible like the ability to just unload a whole group of classes from the system and re-load them again. Or you can do your own class instrumenting (in the Purify sense) to add debugging code to classes loaded. Or you can have seperate threads loading classes from seperate sources, for instance to do a side-by-side comparison of different versions of a program within the same VM sharing the same set of data.

* Refelction. You can use this to dynamically discover class features and methods, and call them as well. A bit more freindly and well defined feature this leads to are "beans", simply classes with a well-defined naming pattern such that you can use a standard reflection based package to find what properties a class might have at runtime, and get accessor/modification methods for those properties.

Past and future

[Anonymous Coward]

I've read many of the questions already posted. A lot of them came pretty close to what I wanted to know, but not quite. It's probably too late for this to get moderated high enough even if it is "good enough", but here goes.

I think most people recognize you as the man that ushered Object Orientation into the mainstream.

Java came along, and tried to simplify tasks that caused program errors (especially memory deallocation and memory overwrites). Some people complain about the loss of control and flexibility, but I have twice seen a group of average programmers produce software much more quickly than I've seen similarly-abled programmers produce C and C++ software; I believe most of it's due to lack of program errors caused by memory overwrites.

Since there are many tasks that Java does not accel at (Systems-level programming, high performance, etc.), C++ is still compelling for many many tasks.

However, given the 10-year cycle of in vogue languages, we're going to need another one in another 5 years or so. Will you be the guy to create it? What will be the important features? What are the good features of C++ and Java (or other languages) that would be retained? What lessons learned in other areas will be important? What about articles like this one by Tim Sweeny of Epic Games on the Next Generation?

Re:C++ a heap of crap

[Dwebb]

I too am often tempted to use obscene language to describe an obscene computer language.

C++ may not be the worst computer language ever invented, but it ranks near the bottom. I cringe when I think of the harm that is being done to the computer industry by programmers who think it is a good language.

See http://www.elj.com/cppcv3/ for an in-depth critique of C++.

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:A couple questions...

[drnomad]

for ( i = 1; i = 5 ; i++)

{

for ( j = 1; j = 5; j++)

cout '*';

cout endl;

}

No output at all?

5 for 1 Questions Multipack

[Anonymous Coward]

1. The basic type int has a different size on different platforms. Wouldn't it make sense to have types int8, int16, int32, int64, ... additionally defined in the language?

2. The initialization sequence of static objects in different source files is undefined. It would be great if IDE's like M$ Visual C++ would allow changing this sequence. Or could the language be refined to handle this? (E.g.: Modula-2 had an initialization block for each source file. It was assured that all imported modules were initialized first, then the file's initialization block and then all modules using the exported functions.)

3. Why were nested functions not considered? They were useful in Pascal.

4. Lots of C library functions return char* or const char* or have char* as an argument. Usually the documentation is not clear if the string has to be freed by the caller or what the minimal size of a char* argument must be. Wouldn't it make sense to provide an additional set of (overloaded) functions using the standard string class, especially sprintf()?

5. All compiler implementations I know of report errors using line numbers. This makes it unnecessarily hard to locate errors in complex expressions. Why don't compilers report columns additionally or file positions instead?

(Thanks for reading this stupid sig!)

Creating new languages.

[pev]

When you decided to create C++, you did it because you saw a requirement for a new language and fulfilled that requirement. With advances in technogy over the past 20 years since designing C++, can you see the need now for a new language and why?

~Pev

inner classes

[Anonymous Coward]

In Java you can make an inner class access its container class as if in C++ we could write :
class A {
int a_id;
class C {
public:
void print() {
cout "I belong to " a_id;
}
C() {}
};
public:
C c[4];

A() {}
};

In C++ we have to pass a pointer to A in the C constructor since A behaves just like a namespace for C. This makes cumbersome the use of C and C arrays (it should work for vectors). I would like to know if such feature has been considered in C++ and why it has not been included.

How do you sleep at night, Bjarne?

[Anonymous Coward]

Knowing how many millions of man-hours have been wasted trying to write useable code in that excreble excuse for a language you concocted?

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

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

When are you going to admit...

[jcr]

...that multiple inheritance is a bug, and it's used by people who just don't understand how to lay out a class heirarchy cleanly.

-jcr

EPOC OS written in C++

[Baki]

EPOC, the 32-bit OS for Psion PDA's, and soon for several mobile phones (such as Nokia) was written in C++, at least that's what their white papers claim (see www.symbian.com). Also the system API's are in C++. btw these PDA's also contain a JVM and can be programmed either in C++ or Java.

Re:EPOC OS written in C++

[Anonymous Coward]

Yep, EPOC is written in C++, and not only that, the ARM-port is compiled in GCC C++ !!! The EPOC C++ SDK (which is a free download from www.epocworld.com), apart from header files, is largely glue to make the MS Visual C++ (ick) IDE call a customised arm-cross-gcc compiled for DOS (yes, gcc source is included) I contacted Psion several months ago about a port of the SDK to Linux, but theywere'nt interested at the time. The largest 2 obstacles are:
i) The WINS EPOC target would need porting to produce a "LINS" target for serious development work - I think WINE could help substantially here.

ii) SOme nutcase decided that since DOS FAT fs is non case-sensitive, it wouldn't matter whether referneces to header files said xyz.h,XyZ.H, XYZ.h etc. All these need correcting, yes, this could be automated, but I'd still have to check them all manually. I haven't had time yet...

C++ Question for Bjarne Stroustrup

[Anonymous Coward]

As a developer, I would like to ask why the C++ standards community did not, and still has not considered standardizing the format of the compiler's object code, as was done with C. Were there technical, design or philosopy reasons why this was not put forward? In my experience, it is sometimes one of the biggest drawbacks to suggesting C++ as a development base. Many other programmers and/or clients feel the object code compatibility gives them more flexability and extensibility for cheaper. Thank You.

Tim Sweeney & Frameworks in C++

[sien]

I'd like to know what Bjarne Stroustrup has to say about Tim Sweeney's article that was posted on /. a while back and in particular what he thinks about what Tim Sweeney refers to as 'frameworks', where a group of classes can have some extra properties added by someone without access to the original source.

Why has C++ become more complicated than C ?

[digulla]

What was the reason to create a programming language which is more complicated (and thus harder to learn and use) than its predecessor ? Scripting languages show that there is a strong urge for more simple things. In C++, you essentially must be a C++ compiler to understand what the code really does. IMHO, this is a move in the wrong direction. Why did you chose that direction ? Or was this no issue when the language was designed ?

--
Dipl. Inf. (FH) Aaron "Optimizer" Digulla
"(to) optimize: Make a program faster by improving the algorithms rather than by buying a faster machine."

Comment on the so-called 'Hello World' fiasco.

[Anonymous Coward]

In Stroustrup's FAQ the following question is mentioned:

"Why is the code generated for the "Hello world" program ten times larger for C++ than for C?"

This has repeatedly been used as a faulty bias against C++!
I found out this has actually to do with the fact that some if not many compilers have the option to attach source code to the executable turned on by default. This option is needed by the debugger, which I believe is a valuable asset, because it can be used to trace the code, just like an interpreter! When you're finished debugging just turn it off and get an executable as small as any C or maybe even smaller!

Personally I find this C vs. C++ discussion invalid because C++ simply comes after C and is almost completely downwards compatible with it and I don't believe some people are willing to start flames just in sake of those few incompatibilities. I think it has more to do with the fact that some people don't like seeing 'their' favorite language C being 'mutilated', which I simply call the natural evolution of programming languages. Also (as Bjarne Stroustrup also mentioned) the fact that C++ is so populair, can attribute to the fact some people can't stand it.

Just my two eurocent (for what it's worth :->).

No, YOU'RE a tool! (n|t)

[Anonymous Coward]

(n|t)

My question is:

[Anonymous Coward]

Much of the complexity of C++ comes from trying to extract maximum speed from the language. My question is: due you consider the extra complexity is really worth it for MOST applications? Are the headaches of using and debugging C++ code there really worth 4-6 months of moores law? If not what other language would you use?

IDE or *compiler* written in Smalltalk?

[Anonymous Coward]

Hell, there are IDE's written in Java itself out there (bit sluggy, though).

Re:C++ template repositories are crap - here's why

[Anonymous Coward]

Oh man. ClearCase and template repositories. Jesus christ. Throw brain dead HP Cfront C++ compiler in the mix and you are well and truly screwed. How slow do you want to link today ? Phew. Just had a flashback.

Ex ClearCase guy.

Pseudoprofound nonsense.

[Anonymous Coward]

[re: '.' vs. -> for referencing struct or class members] In C++, however, the programmer must specify for every access the detail of `how' this is done. That is the access mechanism to the member is made visible to the programmer, which is an implementation detail. Thus the distinction between `.' and `->' compromises implementation hiding, and very seriously the benefit of encapsulation.

The difference between an instance and the address of that instance is not an "implementation" detail. There is a reason why pointers must be dereferenced in order to access what they point to: Pointers are a data type in and of themselves, with properties of their own and interface of their own. Hiding the fact that foo *p is a pointer would lead to unreadable code, because important information would be lost. References are provided to handle certain cases.

If you want Java, use Java. That's what it's there fore. It's a good language, but it has very different limitations from C++. Make an informed choice.

Nested classes are contrary to good object-oriented design, and the free spirit of object-oriented decomposition, where classes should be loosely coupled, to support software reusability.

Well, uhh . . . that's gibberish. Nested classes are for cases where classes need not and should not be "loosely" coupled. These cases exist. Any experienced OO programmer has seen them: Sometimes a class is complicated enough that the implementation should be further decomposed. Nested classes also keep namespaces tidy. Throw in templates and you've got a tremendously useful feature.

This guy is throwing theory at a practical language. I could go through his entire critique and probably refute 90% of it without much effort. C++ is the way it is because it's useful that way. A "perfect" language that doesn't meet the practical needs of programmers will not thrive. An imperfect language which does meet the practical needs of programmers will very often thrive. C isn't perfect either: The declaration syntax is a mess. Nevertheless, the popularity of C is due to the usability and power of the language. Ditto C++.

Re:Pseudoprofound nonsense.

[Dwebb]

Nested classes aside, the problem with C++ is that Bjarne didn't throw enough theory at the language.

I've use C++ for almost a decade, and I've seen firsthand the results of a hundred other programmers using it. It's an utterly terrible language for modeling things. Sure, it's fast (on current hardware), but so is C (and assembly language). It makes a few slight improvements over C (such as references, which partially addresses the . vs. -> issue), but for the most part it's a confused jumble of features, many of which were invented to plug holes left by other features. Its interface model results in code bloat, it has no runtime compatibility, it has such complex syntax that no two compilers ever agree on everything, it has almost no meta-info, etc.

Programming doesn't have to be arcane. With a few good theoretical underpinnings and a hell of a lot of good low-level implementation, it's possible to have a much simpler language (no pointers, no memory allocation/deallocation, flexible interface model, parallelism, etc.) that runs nearly as fast on current hardware (for most tasks) and much faster on hardware most people haven't even hear of yet because the prevalent languages don't run well on them.

I don't expect you to believe me. Just take a look around in another ten or twenty years. If I'm wrong, I'll have figured out why by then. :-)

Re:The evils of operator overloading: A tired myth

[Anonymous Coward]

(This is the pro-C++ guy again, still regretting his bad manners)

Custom class loaders.

It's cool (I've always been sort of entranced by Java's habit of putting each class (is that quite correct?) in its own .class file, don't ask me why but it just seems nifty to me), but is it language or implementation?

Refelction.

Reflection is just plain groovy. I'm told by a Java-centric friend (IOW: I can't vouch for this and I don't claim to :) that it's real slow at runtime, but all that means is that you have to know when not to use it. I've always thought it would be real, real cool for serializing objects, which happens to be a problem I've been unnaccountably obsessed with for years and have never quite nailed down to my own satisfaction.

Thanks for the info. I hadn't known about custom class loaders, and I forgot (duhh) reflection completely. My bad.

Re:bad behavior (not so bad, actually)

[Anonymous Coward]

Finally, a third method was probably overlooked that can be correct in a lot of cases: some kind of attribute could be applied to a class such that the code does a 'for each element in class, use its operator= to copy it'.

According to r.12.8 of the C++ Reference Manual, the default copy constructor and assignment operator do exactly that.

What's the future of exception spec's in C++?

[gtt]

In the compilers I've used (MSVC & GCC), exception specifications are not that well supported, and I've had people on the GCC list say that they're going away anyway. I feel that this is a useful feature, especially if the compiler gave warnings about violations of the specifications. What does the future of exception specifications look like?

Dammit, I goofed. Mea culpa.

[Anonymous Coward]

First and foremost, I fucked up with the classes in the example code. It should have been like so:

class bar { ... };
class baz : public bar { ... };

. . . I realize that somebody who knows the language would deduce that after a few moments of wondering what the fuck was wrong with me, but I shoulda gotten it right the first time.

Second: After posting the above last night, I was thinking about a project I'm working on, and damn if I didn't immediately think of a case where I might want to have a template where one of the parameters was limited to descendants of a given class. I'm not certain that that's actually what I need, but it still makes sense to me the next morning (win32 GUI class library with templated MDI parent class, which takes an MDI child type as a parameter: I might (or maybe might not?) want to limit the MDI child type to mine, or descendants of it). By the way, I think you could fake it to some extent by deriving a template from a normal class, which used pointers to the base class from which you want to force T to inherit from. In other words:

class bar {
};

class bar2 : public bar {
};

class baz {
};

class foo {
public:
foo( bar &b ) { }
};

template<class T>
class bogo : public foo {
public:
bogo( T &p ) : foo( p ) { }
};

int main()
{
bar2 b;
bogo< bar > bb( b );

return 0;
}

. . . it's a crude and annoying workaround, but it could probably be refined somewhat.

Static typing in C++

[BeeJay]

Question for Bjarne Stroustrup.

C++ implements very static types -- something which has been loosened a bit by the introduction of RTTI.

On the other hand, part of Java's success (I hate myself for bringing the J-word into the question ;-) must come from the need of interchanging code as well as data on the internet -- something which requires the very opposite: dynamic types, or at least, dynamically loadable types.

The question:
Could it be possible to have dynamic types as "first class" types in an extended C++, or would that interfere too much with the basic design principles? What would be needed of the runtime environment?

Another question: I've seen you often quoted that Java was not the language you would have designed, were C-compatibility not an issue. So which parts of C would you be most glad to see disappear from C++, if compatibility was not an issue? Would the basic types be objects with primitive "member functions", i.e. would the language be what is called purely object oriented?

don't (mis)use these macros

[TriangleMan]

Most of your examples could be replaced either by inline functions: #define MAX(x, y) ((x > y) ? x : y) // can be replaced with tempate<class T> inline T& max(T& x,T& y) { return ((x > y) ? x : y); }

BTW please don't take this as a flame, but the MAX macro impl you've shown is incorrect and dangerous. Example: MAX(getc(),getc()).

Your BEGIN_SYNCHRONIZED/END_SYNCHRONIZED construct could be replaced like so:

{ Synchronized sync(x); // crit section here }

Where the constructor of class Synchronized performed the stuff in BEGIN_SYNCHRONIZED and the destructor of class Synchronized performed the stuff in END_SYNCHRONIZED. Note that you would be able to remove your try-catch stuff, because whenever there was an exception thrown inside the critical section, the desctructor of the sync object would be called. Note that the BEGIN_SYNCHRONIZED/END_SYNCHRONIZED macros can also lead to inadvertant errors if the x passed to the BEGIN is different from the x passed to the END.

I will agree that there are certain cases where macros are actually useful -- take the assert macro, for instance. But as your examples have shown so well, in most cases where people use macros, there is some other language feature in C++ that they can use. And not only that, but the other language feature is safer and less error-prone.

parametric polymorphism

[betamax_]

Lets face it, parametric polymorphism was implemented terribly through C++'s templates. How would you design a language that would take full advantage of this concept? You should be able to interact with objects as if they were built in variables, like using the autoincriment funtion. Along the same lines, what improvements would you make to the STL? We've been using the same container paridigms for a while, there must be something new.

Re:parametric polymorphism

[epine]

C++ templates are not an "implementation of parametric polymorphism". I don't recall C++ filling out an entry form to compete in that pageant.

The template mechanism began life as an effort to capture Ada-like genericity, and they continued to evolve in response to issues which originated within the C++ language.

Along the way, the originators of the STL discovered that C++ templates had sufficient expressive power to capture a more advanced approach to genericity--despite the fact that the template mechanism had evolved in response to issues within the language rather than as an "implementation" of some formal theory hatched at a university.

With the benefit of a little bit of extra tweaking, C++ implements the STL concept of genericity rather nicely.

Then along came people like Todd Veldhuizen (Blitz++) who discovered that these same template mechanisms were *capable of* supporting parametric polymorphism to the extent that practical programs could be written based on these concepts.

Despite many outrageous potholes in the C++ template system (most especially the inability to compute a static type in a declaration using the same syntax as the expression which produces the desired value, and the amazing oversight which lead to the lack of a template typedef), C++ has produced some good results in this area. Because of the way that C++ was designed, most of the expressive defects of the language can be hidden within library code and has little impact on the end user.

In fact, if you really wanted to say that C++ is the "implementation of some concept X" it would be fair to say that C++ is the implementation of "compartmentalized abstraction". What I mean by this is that people who implement libraries such as Blitz++ and Pooma are free to work within the language at a much higher level of detail and abstraction than is imposed of necessity on the application programmer.

Equally important, the evolution of C++ is a response to what people learn by actually writing programs in the language. C++ as it stands has enough support for genericity and PP to allow the community to experiment with the language in practical settings.

There is nothing that bothers me more than to see the failings of C++ "exposed" against the academic standard of "designed by concept".

Neither are we talking about a language designed by committee. What we are really talking about here is a language "designed by community"--equal measures of wisdom and warts pureed into a fine paste which nevertheless seems to get the job done.

Five years down the road it will be time for that community to reflect on the experience gained with genericity as it now exists and, hopefully, continue to listen and respond to the issues which arise from within.

It's a big mistake to presume that everything in the river which feels the same tug is destined to wind up on the same beach.

advice for java generics designers

[TriangleMan]

My question of you is, having designed a template/generic framework for C++, what advice do you have for the people at JavaSoft who are currently designing one for Java?

Did you know these 'Bjarne Stroustrup' anagrams?

[Anonymous Coward]

stub juror parents
bust juror parents
jobs traps nurture
jobs strap nurture
rant jobs ruptures
burp sorter jaunts
burp resort jaunts
just born raptures
just burn prorates
jobs rater upturns
job arrest upturns
trap juror subnets
bus juror patterns
ban jurors sputter
burp jaunt resorts
unjust bra reports
just burns prorate
just urban porters
run or jet subparts
up run job starters
sun rub jet parrots
run jet bus parrots
run pro jut breasts
puns jabs torturer

Why only 10 questions?

[Anonymous Coward]

Couldn't the act of choosing (filtering?) 10 questions be considered censorship?

Why not let Bjarne choose which additional questions he wants to answer right here on SlashDot.

May be his posts could show up with a different color?

C99 and C++

[evopl]

Hi Mr. Stroustrup, let me start by saying you are my CS idol, more so than any other CS person I know of. Ok, second, I've read some of your posts on comp.std.c++ about C99 but I'm still not clear, so I'll ask. What do you see as C99's future? Do you see it as a viable alternative to C++? Do you foresee C99 being integrated into the C++ standard in two years to retain compatibility with C? Do you think C++ should now start splitting away from its C heritage? Also on a completely unrelated subject, what kind of changes (if any) _are_ being planned for the new C++ standard in two years? I look foward to reading your opinions/input. Thank you for your time!

EXACTLY! Standard iostreams so slow they're useles

[Anonymous Coward]

The standardization of iostreams with templates have made them huge, bloated, slow to link and completely useless! You can't forward declare them either - you have tosuck in the God-awful template header now everywhere. We have more useful things to do than wait for long compiles. And before you say it - I hate precompiled headers - I don't wish to track down comiler implementation bugs related to pre-compiled headers more than one time in my life, thank you very much.

So, you think you really know C++?

[Anonymous Coward]

[C++] makes a few slight improvements over C (such as references, which partially addresses the . vs. -> issue)

You must be one of these guys that uses C++ just like a crappy superset of C. You really don't see the big picture in terms of reducing errors due to the fact that you write significantly less code through judious use of polymorphism and inheritance. If you think the only thing C++ adds is the '.', then you should use Java

Re:So, you think you really know C++?

[Dwebb]

Been there, done that. I see more of the big picture than most people, and it's ugly. I'm not bashing OO here, just C++. I worked on what was probably the largest C++ project of the early-to-mid nineties. I saw the worst mess ever produced by a bunch of otherwise smart programmers. A slow, bloated system due largely to C++'s interface model. I decided to subvert the C++ model and do it my own way for a few months, and I produced something small, tight, and very fast. But it was tremendously tedious to implement in C++.

I could explain why C++'s interface model results in bloat, but it's not possible in one or two sentences. The short story: You can't implement an arbitrary subset of an interface like you can in many other OO languages.

In case you feel the urge to respond with a trite answer like "You didn't think about it the right way", don't. If there's one thing I'm good at, it's finding the root cause of a problem.

Open classes

[mzraly]

One of the differences between the namespace introduced by the 'class' construct and the namespace introduced by the 'namespace' construct is that one cannot add to class namespaces after the fact but one can add to non-class namespaces after the fact. Some languages, e.g. TOM, provide "open" classes -- classes to which other class users can add normal and virtual methods, even superclasses.

One advantage of open classes is that they provide a way for the class user to introduce useful methods not thought of by the original class designer while retaining a uniform notation for accessing the functionality (a.new_method() versus new_function(a)).

Do you think open classes are a good idea? Were they discussed at all during the standardization effort? If you were to design C++ all over again, would you consider them? Why or why not?

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.

Here's why languages like C++ are popular

[p3d0]

Because they make simple things easy. Hello World is two lines of code in C and C++:

#include <stdio.h>
int main(){ printf("Hello, world!\n"); return 0; }

Languages that make simple things easy will appeal to beginners. Beginners eventually become experts. Then you have a situation where all the experts are using a langauge not because it's a good language, but because it made simple things easy.

Popularity, then, is almost independent of quality.

The most appropriate language for a job is the one that makes that job easy.

--
Patrick Doyle

Re:Here's why languages like C++ are popular

[Anonymous Coward]

Good point. I would think that this is also the reason for Linux user base + momentum being greater than *BSD: friendlier distributions existed earlier, so the seedbase of beginners was larger, 5% of all beginners become contibuting experts, ...

Signatures, GCC Extension to C++

[ferar]

I think that sometimes C++ is odd when you have classes not belonging to the same hierarchy but with some common functions, and for instance you want to make a list of classes that perform a common function.
In Java you can use interfases to solve that, in Smalltalk, as it isn't strong type, you have no problem at all, but in C++ you must use some sort of multiple inheritance or a new hierarchy of wrapper classes with the common funcions.
I found that the GCC compiler implement a extension called signatures that are like Java interfases and are very usefull in those scenarios. What do you think about signatures
or adding something like that to the standard C++??

stroustrup()

[kkenn]

I dunno about you, but I always thought stroustrup() would make a really cool name for a string parsing function.

int stroustrup(const char *src, char *dst); /* Oustrup the source string */

MODERATE UP!!!

[Kierkan]

please

Re:There's a world of languages outside of C/C++/J

[VonKruel]

There are indeed many interesting languages being developed. However, if you are developing systems or application software today, your choices are much more limited in practice. For all its weak points, C++ is a very powerful language. A competent programmer (who has gotten over the admittedly steep learning curve) can be very productive in it. Also, there are a lot of good supporting tools for C++, it has compilers on just about every platform, etc... These are very important considerations when you are starting a software project.

When one of these new languages shows signs of becoming the "Next Big Thing", I'll consider having a look at it. And there's the rub : a language for development of large software systems needs a critical mass of users, which it has trouble getting when it has very few users. It's a serious problem even when the new language is much better designed than the status quo. I'd like just as much as anyone for a new language to come along and kick C++'s ass and become an industry standard, but I'm not holding my breath.

(Note: I didn't say C++ was industry standard.)

Burried in C++ way of thinking&serving the languag

[cmos]

Sometimes one finds himself absorbed by framework of C++ way of thinking and techniques , in such a way to put the actual goals of writing a piece of software into the second place. This makes it of foremost importance to "to use all the features of the language" or rather "serve the C++ language ideas", instead of reaching the goal in a more practical way .

A very good example is all of us programmers trying to "TEMPLATIZE" everything, even when there is not much need (Yes, I know it feels good, and I do it too)

What do you think of this state of "getting burried in the language features, and wandering away from practical goals".

Thanks,
Huseyin Serkan YILDIZ

Java, Smalltalk and C++

[DaitanGio]

The Java lacks of C++ feature is frustrating for a lot of pepole, in my own opinion. On the other side, now the new Smalltalks (as Squeak ) can offer a better environment of Java (and even C++)? What do you think?
Giovanni Giorgi

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.

Two (technic) questions

[drnomad]

I'm a great C++ fan, I like learning new things about the (core) language although this doesn't happen too often anymore. I don't like STL, I prefer writing my own stuff.

In the literature I have, there's this little information-gap:

1. protected inheritance - what is it good for? (I used it a couple of times, for specific reasons, but what is the 'official' intention of this scheme?)

In the decisions made for designing the language features, I wonder whether the following has been considered:

2. pure abstract propperties - why is it that only method-propperties can be pure virtual, why not make data propperties pure virtual as well? I know cases where this would be suitable, and where templates are no option.

Re:C++ portability & Exceptions/RTTI/Namespaces et

[scc]

Actually, this document is getting a little long in the tooth. In fact, we are beginning to make significantly greater use of templates. See, e.g., nsCOMPtr. It turns out templates largely work on a great many platforms. The initial versions of the portability guidelines were written by people with a decided anti-C++ bias, and some of the items were more influenced by anecdote than by test. I am the new owner of this document. I hope to bring it up to date, though that requires writing a lot of sample code and running it through the grinder of 18 or so compilers. Not necessarily something bug-count sensitive management will want me working on.