Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Interview With Bjarne Stroustrup

Hemos posted about 11 years ago | from the talking-with-the-giants dept.

Programming 502

koval writes "artima.com has published an initial portion of interview with Bjarne Stroustrup. The scope of first part is mostly about improving the style of C++ programming and getting maximum from a language."

Sorry! There are no comments related to the filter you selected.

what kind of name is bjorn (-1, Offtopic)

Anonymous Coward | about 11 years ago | (#7199246)

no name should start with the letters "bj"

faggot (-1, Troll)

Anonymous Coward | about 11 years ago | (#7199255)

Dear Mr. Stroustrup:

Do you have sex with mares? FUCK YOU!

Java ? (0, Offtopic)

Krapangor (533950) | about 11 years ago | (#7199259)

What do you think of Java ?

Re:Java ? (1)

AKAImBatman (238306) | about 11 years ago | (#7199265)

> What do you think of Java ?

PLEASE don't ask that. The guy is a bit touchy on the subject.

MOD PARENT "Flamebait" AND "Funny" ... (-1)

Anonymous Coward | about 11 years ago | (#7199301)


(I'd do it but have no mod points, and one person
can't apply both at the same time anyway :)

Re:Java ? (1)

Drantin (569921) | about 11 years ago | (#7199318)

Err... I know topics with a title that begin "Interview with" usually mean you can ask questions to the person... but this is an interview done by another site...

Re:Java ? (0)

Anonymous Coward | about 11 years ago | (#7199393)

What do you think of Java ?

I think it suxxors.

Sincerely, B. S.

Re:Java ? (0)

Anonymous Coward | about 11 years ago | (#7199422)

Worst programming language in the histroy. Yes, I mean stupid Java

Re:Java ? (1)

cK-Gunslinger (443452) | about 11 years ago | (#7199450)

Let me answer that for you, since this is a story *about* an interview that has already taken place, not a story for gathering questions for an interview:

"I think Java is kinda nifty."

Best answer you'll get. :)

Re:Java ? (1)

mirko (198274) | about 11 years ago | (#7199526)

It lacks operators, seriously : when I had to develop my cellar for Qtopia [killefiz.de] , it saved me a huge time and code ergonomy to just use some operator to add new records to my db...

Who is Bjarne Stroustrup? (-1, Troll)

Anonymous Coward | about 11 years ago | (#7199260)

A little background information would be useful. For all I know, he could be the Swedish Chef on the Muppets.

Re:Who is Bjarne Stroustrup? (-1)

Anonymous Coward | about 11 years ago | (#7199355)

RTFI (Read The F*cking Interview)

Re:Who is Bjarne Stroustrup? (-1)

Anonymous Coward | about 11 years ago | (#7199376)

HWTSYMBNH (Hi, Welcome To Slashdot, You Must Be New Here.)

Re:Who is Bjarne Stroustrup? (1)

TheLevelHeadedOne (700023) | about 11 years ago | (#7199373)

Ever had a real programming language class?

Re:Who is Bjarne Stroustrup? (-1)

Anonymous Coward | about 11 years ago | (#7199415)

Does BASIC count?

Re:Who is Bjarne Stroustrup? (1)

Worminater (600129) | about 11 years ago | (#7199505)

Real programming class?

MOV AX, @DATA
LEA BX, DSARY
INC BX, 02
MOV AX, BNDMP
MOV CX, 10
BRD:
MOV [BX],AX
MOV AX, BNDMP
INC BX, 02
LOOP BRD


and your talkign about a REAL programming language?

Hardy har har...

I prefer
for(int x = 0, x=11, x++)
{
dsarray[x] = bndmp;
}

myself...

Re:Who is Bjarne Stroustrup? (1, Insightful)

dreamchaser (49529) | about 11 years ago | (#7199399)

Since you only got smart ass replies, here you go: Bjarne Stroustrup was the creator of C++.

Re:Who is Bjarne Stroustrup? (-1)

Anonymous Coward | about 11 years ago | (#7199431)

Thank you for your informative reply. I hope the goderators look kindly upon you and grant you good karma!

Improvements? (2, Insightful)

Eric Ass Raymond (662593) | about 11 years ago | (#7199264)

How about eliminating the buffer overflows?

Re:Improvements? (-1)

Anonymous Coward | about 11 years ago | (#7199310)

How about eliminating the buffer overflows?

You ridiculous fucktroll. Everyone knows that the real source of buffer overflows is Microsoft Visual Basic. Since that is about what 99% of all insecure Windows apps are written in. Someone needs to bash M$ over teh head with a steel dildo and let them know that buffer overflows are THEIR problem, not ours. So fuck off to you Eric Ass Gaymond!!!! I vomit upon thee!!! (and your failures)

Re:Improvements? (1)

Eric Ass Raymond (662593) | about 11 years ago | (#7199495)

Ah. A vulgar, brute-force anonymous coward troll.

Keep up the good work in the gutter, son.

Re:Improvements? (1)

swtaarrs (640506) | about 11 years ago | (#7199325)

There aren't any buffer overflows inherent in the c++ language, it's crappy programming that causes buffer overflows.

Re:Improvements? (1)

GnuVince (623231) | about 11 years ago | (#7199458)

Well then, there must be a whole lot of crappy C and C++ programmers and no crappy Java, Python, Ruby, Smalltalk, Lisp programmers.

Re:Improvements? (0)

Anonymous Coward | about 11 years ago | (#7199516)

Your lack of logic is astounding. The parent post said, in essence, "there are buffer overflows only if there are crappy programmers". From this you derive "there are no buffer overflows, so there are no crappy programmers"?? Can you say "denying the antecedent?". Good God man, grow a brain.

Re:Improvements? (1)

johnnyb (4816) | about 11 years ago | (#7199531)

What I don't understand is WHY DOESN'T ANYONE COMPILE BOEHM GC INTO THEIR PROGRAMS???????

Is that so hard? Is it too much to ask?

I mean, not only would it save bugs, it would make C++ 10000000 times easier to program in.

Re:Improvements? (1)

GnuVince (623231) | about 11 years ago | (#7199571)

Most people believe in the 40 year old myth that started with Lisp that a garbage collector makes a program slow. Of course, that isn't true anymore, but myths stick for longer than facts.

Re:Improvements? (1)

panserg (555671) | about 11 years ago | (#7199488)

Well, then how about elimating a crappy programming (by making it impossible) in C++, like it's done since the begining in Java, Python, Smalltalk, Erlang, Lisp, Prolog, ML and Haskell.

Re:Improvements? (1)

orthogonal (588627) | about 11 years ago | (#7199337)

How about eliminating the buffer overflows?

std::vector already does this. How about using it?

Re:Improvements? (1)

ultrabot (200914) | about 11 years ago | (#7199374)

std::vector already does this. How about using it?

I don't think it does. STL does very little checking in general, because it has to be blazingly fast in order to not be ignored by C++ mainstream (for which performance is everything, never mind the development costs).

Besides, a lot of people who program C++ have to program in environments ( == old compilers) where such pansy features as STL, RTTI or exceptions are not available.

Re:Improvements? (0)

Anonymous Coward | about 11 years ago | (#7199392)

I would, if the STL objects were a little easier to handle. The reason people use arrays instead of vectors, lists or even maps is because they're easy to create and manipulate; it takes very little energy to create an array of 10 "things" and then iterate through each one in a for() loop. Dealing with iterators, and the slightly bizzare (IMHO) syntax required to access the "things" inside the vector (list, map, whatever) just seems far more clunky and requires more brainpower to do something that should in reality, be as easy as using an array.

What do I know though, I've only been writing in C++ for a couple of years. I expect to get flamed for being an idiot and failing to understand some complex feature of the STL or (God forbid) templates, now.

Re:Improvements? (0)

Anonymous Coward | about 11 years ago | (#7199446)

The funny thing is, most of the features of the STL are conceptually simpler than the pointer-based way of doing things.

Unfortunately, when people are taught C++, they are first taught that subset of it which is the C programming language.

So when you finally learn about vector and so on, the tendency is to ask yourself what the point is, when you already know a perfectly good way of accomplishing the same task.

Re:Improvements? (0)

Anonymous Coward | about 11 years ago | (#7199522)


Yes. Here is your obligitory flame:

Templates and the STL are gigantic points of productivity in C++. Learn them and use them before posting again on this subject. Your meager brainpower should be spent on associating those "things" with objects. A small part of C++ is its ability to use OO. Re-read this chapter in your Dummies book, if it has one.

Now please go back to the AOL domain.

Re:Improvements? (0)

Anonymous Coward | about 11 years ago | (#7199553)

Now please go back to the AOL domain.

I see you have about as much command of the Internet as you have over the English language.

P.S: If templates & the STL are such gigantic points of productivity in C++, why were they not part of the original C++ specification?

Re:Improvements? (1)

orthogonal (588627) | about 11 years ago | (#7199533)

it takes very little energy to create an array of 10 "things"

Well, see the first reply to your post -- the STL itsn't what any is used to from C, but it is consistent once you've taken teh trouble to learn it --, and, please recall that writing safe, non-exploitable code is never going to be easy or automatic.

No offense, but if your primary criterion is "what's easiest" you probably shouldn't be writing high-risk code that processes arbitrary-length buffers which could be prone to buffer overflow. Limit yourself to less risky projects, and limit your buffers to a fixed length, and document that fixed length.

Re:Improvements? (2, Funny)

Dr. Photo (640363) | about 11 years ago | (#7199411)

std::vector already does this. How about using it?

Am I the first to think that maybe "STD vector" is possibly the worst name for a data type? ;)

Re:Improvements? (3, Funny)

orthogonal (588627) | about 11 years ago | (#7199504)

Am I the first to think that maybe "STD vector" is possibly the worst name for a data type? ;)

try:
using namespace condom ;

OOP IS FOR PUSSIES (-1, Offtopic)

Anonymous Coward | about 11 years ago | (#7199267)

Real men code in assembler.

Object Oriented Porgramming is for control freak fucks who can't keep their heads on straight. They want to categorize and classify every damn thing under the sun. Kind of like the programmer and the engineer who were asked to build a toaster by the king. The king had the programmer ass (who was n OOP zealot) put to death.

Re:OOP IS FOR PUSSIES (-1)

Anonymous Coward | about 11 years ago | (#7199435)

Uh dude, they're not mutually exclusive. I've done object-oriented programming in assembler. OOP is a mindset, not a technology.

Re:OOP IS FOR PUSSIES (1, Insightful)

ultrabot (200914) | about 11 years ago | (#7199444)

Real men code in assembler.

For very contorted definition of real men. OOP requires higher degree of abstract thought than assembler, and obviously not everyone can hack it. Assembler, Fortran and Visual Basic are for people whose brain can't handle abstraction, but rather just want to get their hands dirty doing stuff. People who would rather do than think what they are doing. Others take delight in creating abstract architectures and systems that Last.

Obviously many self-proclaimed C++ programmers belong in the assembler group, rather than the OOP group (where Python/Java/Smalltalk people dwell).

Re:OOP IS FOR PUSSIES (2, Funny)

BurKaZoiD (611246) | about 11 years ago | (#7199524)

Real men code in assembler

Since when did Steve Gibson start posting here as an Anonymous Coward?

Some people use a screwdriver, others use a butter knife. That's the beauty of programming; there are numerous tools and technologies at your disposal that will all achieve the effect (or at the very least, a semblance of the effect) you desire. Business users typically don't know the difference anyway, so it's really a matter of programmer's preference. Pick those you feel most appropriate to your project, and leave the rest.

Most people I know don't get the beauty of something like C++. It's a massively complex language. So complex, as a matter of fact, that you can create OTHER languages with it (via templates). But, like any other, tool or technology, take what you want from C++, and leave the rest behind.

How OOP helps reusability. (1)

Rimbo (139781) | about 11 years ago | (#7199530)

Probably the main reason OOP exists is that it provides a mechanism by which new code can be added to old code, without having to dig into the old code to find just the right spot to make the function call to the new code.

See, in your assembly language, if you want to add new code, you have to not only write the new code, you have to dig through your Asm to find the little tiny spot where you JSR (or whatever your opcode may be) to the new code.

In my C++/Java, I just subclass that puppy when I write the new code, and my code gets called automagically. (Well, actually via a dynamic function call table, but you knew that.)

It doesn't help so much on a small, one-man project. But once you have more than one person and more than a thousand or so lines of code, suddenly OOP gets really, really useful.

Scott Meyers (2, Funny)

CyberGarp (242942) | about 11 years ago | (#7199272)

Any language that allows for someone making a living pointing out everything one shouldn't do needs more than a face-lift.

Re:Scott Meyers (2, Funny)

gaijin99 (143693) | about 11 years ago | (#7199344)

Any language that allows for someone making a living pointing out everything one shouldn't do needs more than a face-lift.

Cute, but meaningless. Any language has features that are easily overused or abused. One of the things a programming teacher has to do with any beginning class is explain what you shouldn't do. Or at least he should be spending time on that.

C++ has problems, yes; pretty unavoidable since it was the first real object oriented language. Java has a different set of problems since it was the first language that was OO from the ground up. I'd say its time to learn from the mistakes of both, scrap 'em, and build a language with the pitfalls of neither. 'Course that's a bundle of work, and you can get along well enough in either of them, so people tend to try and patch rather than start from scratch.

The funny thing is that C still stands out as an excellent general purpose programming language. Possibly a bit akward for use in writing GUI's, but overall it still works after all these years. K&R deserve more praise than they've been getting.

Re:Scott Meyers (1)

kyrre (197103) | about 11 years ago | (#7199384)

>since it was the first real object oriented language.

Huh? What about Simula, the first object oriented language?

Re:Scott Meyers (2, Funny)

PD (9577) | about 11 years ago | (#7199462)

Or assembly. You could have any object you wanted, as long as it fit in a register.

Re:Scott Meyers (1)

Frater 219 (1455) | about 11 years ago | (#7199510)

since it was the first real object oriented language.
Huh? What about Simula, the first object oriented language?
Or what about Common Lisp, the first object-oriented language with a published standard?

It doesn't make much sense to say that any particular language was "the first real object-oriented language" because people have different religious beliefs as to what constitutes a "real" object-oriented language.

People get into hideous flamewars about that word "real" when applied to categories like "object-oriented", "functional", or "Christian". :)

Re:Scott Meyers (1)

kyrre (197103) | about 11 years ago | (#7199539)

Ole-Johan Dahl and Kristen Nygaard first published the ideas of object oriented programming. The ideas was implemented in Simula. The story [slashdot.org]

Re:Scott Meyers (2, Interesting)

CyberGarp (242942) | about 11 years ago | (#7199447)

C++ has problems, yes; pretty unavoidable since it was the first real object oriented language.

This comment alone summarizes the posters knowledge of programming languages. For a better understanding of C++, check it out on the Computer Languages History [levenez.com] website

My reply: Cute, but it unfortunately does mean something. C++ has more features that are so easily misused (not abused), that Scott Meyers wrote 3 large volumes on the subject. Other languages have similar featuers, but not in near the quantity of C++. Java has been jokingly refered to as C++--++. The "--" refers to the stripping away of all the majority of the problems that Scott Meyers addresses in his books.

PS Object Oriented is a concept adapted from functional programming languages, i.e. LISP.

Re:Scott Meyers (1)

kraut (2788) | about 11 years ago | (#7199562)

For a real understanding of C++, read Bjarne's "Design and Evolution of C++". It is truly enlightening.

Re:Scott Meyers (5, Funny)

Waffle Iron (339739) | about 11 years ago | (#7199457)

C++ has problems, yes; pretty unavoidable since it was the first real object oriented language. Java has a different set of problems since it was the first language that was OO from the ground up.

Let me guess... you work as a prior art researcher for the USPTO.

Re:Scott Meyers (0)

Anonymous Coward | about 11 years ago | (#7199506)

> C++ has problems, yes; pretty unavoidable since it was the first real object oriented language

OMG, you're so clueless.

Simula, Smalltalk, and a shitload of others predate C++.

And, C++ is not object oriented. It is inheritance based, but certainly not object oriented...

Yes! (3, Funny)

kurosawdust (654754) | about 11 years ago | (#7199273)

Oh boy! I can't get enough of Bjarne and J-Lo!

Re:Yes! (0)

jollis (691129) | about 11 years ago | (#7199297)

Gigli++! *Shivers*.

Do you feel guilty? (-1, Flamebait)

haruchai (17472) | about 11 years ago | (#7199279)

For helping to give birth to the nightmare that is C++?

Question. (-1, Troll)

Anonymous Coward | about 11 years ago | (#7199288)

Do you think that Debian gnu/linux sucks? I mean, it uses obsolete software. And no, they are NOT STABLE either, I am a Linux consultant, and I love charging debian refugees $200 an hour to move them to Mandrake!

Don't get me wrong, I love linux, and I advocate it on the desktop, because unlike the Typical Debian distrobution, on Mandrake everything "just works".

So Bjarne, do you agree that Debian sucks like me, and THOUSANDS OF OTHERS! And to debian zealots with mod points, please explain yourselfs in COMPLETE detail before moderating down, for I have an account with mod points and I WILL MOD THIS BAKC UP!

What about... (1)

Sir Haxalot (693401) | about 11 years ago | (#7199291)

Where do you see C++ going as a language?

Re:What about... (2, Interesting)

Sir Haxalot (693401) | about 11 years ago | (#7199329)

Where do you see C++ going as a language?
I think I'll just clarify that. In four or five years, what changes would you like to see happening to the language, and how realistic it is to be able to achieve those goals in that time period?

Re:What about... (-1)

Seth Finklestein (582901) | about 11 years ago | (#7199345)

This isn't a Slashdot interview where you ask questions to Bjarne. This is an interview that has already been done. Please read the articles and please die.

+1 didn't read the article (-1)

Anonymous Coward | about 11 years ago | (#7199369)

they're not asking for questions, guy.

the questions have already been asked, and answers have been given.

Re:+1 didn't read the article (1)

Sir Haxalot (693401) | about 11 years ago | (#7199381)

This [slashdot.org] and this [slashdot.org] made me thought that the questions were being asked now, d'oh! Oh well, Bjarne if you're reading this... :)

Re:+1 didn't read the article (-1)

Anonymous Coward | about 11 years ago | (#7199421)

I guess they call you Einstein for a reason...

Re:+1 didn't read the article (-1)

Anonymous Coward | about 11 years ago | (#7199455)

Yeah, he has stupid hair and works as a patent clerk.

Re:What about... (1, Funny)

Anonymous Coward | about 11 years ago | (#7199471)

C+++

Probably fake but . . . (4, Funny)

Brahmastra (685988) | about 11 years ago | (#7199309)

I agree with every word of this probably fake interview [safe-t.net]

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.

[NJW Comment: That explains everything. Most of my thesis work was in raw X-windows. :)]

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

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?

Re:Probably fake but . . . (0, Flamebait)

AKnightCowboy (608632) | about 11 years ago | (#7199367)

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?

C++ does seem to be horribly convuluted. Maybe I just have a horrible professor teaching it, but the things that are being demonstrated could've been done just as easily (if not better) using standard C. Object-oriented programming seems to be vastly overrated. Give me C or Perl anyday.

Re:Probably fake but . . . (1)

GnuVince (623231) | about 11 years ago | (#7199441)

OO in C++ is horrible. Learn OO with Ruby, Python or Squeak and you shall see the light.

Re:Probably fake but . . . (1)

aurelien (115604) | about 11 years ago | (#7199480)

Learn OO with CLOS and you shall see the candle that emits the light... (CLOS == Common Lisp Object System)

Re:Probably fake but . . . (0)

Anonymous Coward | about 11 years ago | (#7199485)

If you still think member functions are a good idea, you may like the lightweight c++ preprocessor [upatras.gr] . It adds lightweight c++ features to C.

Re:Probably fake but . . . (1)

SoTuA (683507) | about 11 years ago | (#7199434)

IIRC, it's an april's fools interview. It ranks up there as one of the best ones I've ever seen, along with Linus' April 1st discussion of who should take the role of kernel mantainer.

Of course, IMBFOS. (I Might Be Full Of Shit)

How to improve C++ (1, Insightful)

Anonymous Coward | about 11 years ago | (#7199313)

Use Unlambda instead.

C++ has become a massive boondoggle of poorly-widely-understood and often inconsistently implemented features, in which class reuse is mostly unheard of and different C++ APIs can rarely communicate well with each other natively due to a widespread failure to actually use the standard STL classes (String, Vector, etc).

It is time to throw out the bathwater. Unlambda combines a strict sense of simplicity with the full power of functional programming, allowing you, once you become familiar with a small set of idioms of the langage, to utilize the same patterns and strategies you used in OO languages such as C++ in a more direct and evocative manner, without the verbose clutter and paperwork OO languages force you into. Have you ever noticed with C++ you spend more time serving the syntax than actually planning your object heirarchies? No more. Unlambda cuts through the crap and lets you write "what you mean" in your code.

The benefits of Unlambda have been shown in multiple studies. Think: after all the time and energy you have invested in C++, can you really say it has delivered on its promises? Consider using Unlambda for your next enterprise-class project instead.

Re:How to improve C++ (1)

isj (453011) | about 11 years ago | (#7199543)

Whoever moderated that as "insightful" should probably do some research first :-)

"Unlamda - Your Functional Programming Language Nightmares Come True"
http://www.eleves.ens.fr:8080/home/madore/p rograms /unlambda/

maximum (0)

Anonymous Coward | about 11 years ago | (#7199323)

The scope of first part is mostly about improving the style of C++ programming and getting maximum from a language.

Why do you need to interview Stroustrup to learn about getting maximum from C++?

Just do #include <algorithm>

Then you can use max() and max_element() on STL objects to your heart's content.

Compilers (3, Interesting)

ultrabot (200914) | about 11 years ago | (#7199324)

Speaking of C++, is there a compiler that complies with the ISO standard already? Does anyone use it?

Re:Compilers (1)

dirtydamo (160364) | about 11 years ago | (#7199378)

As far as I know, Comeau's compiler [comeaucomputing.com] is the most standards conformant on the market. It even supports export!

Only US$50 for per copy.

The people who use Comeau's compiler are generally concerned with portability, because, as any C++ programmer knows, most compilers completely blow when it comes to standards conformance at the moment.

Re:Compilers (4, Interesting)

X (1235) | about 11 years ago | (#7199486)

as any C++ programmer knows, most compilers completely blow when it comes to standards conformance at the moment.
This is the conventional wisdom. It is (sadly) based on how things used to be. However, there has been a significant amount of progress in the last few years with regards to standards compliance. Aside from the Comeau compiler, you have Microsoft's, Intel's, IBM's, and G++. The last time I used Sun's C++ compiler, the only problems I had were with the antiquated version of the STL that they insist on using for backwards compatilibity purposes. The lastest issue of Dr. Dobbs has actually looked at this based on examples from the C++ standard, and while Borland seems to be making little progress (I don't think their compiler itself has changed in a while), most of the other vendors are rapidly approaching full compliance (although export seems to remain a mystery to everyone besides Comeau).

Re:Compilers (1)

X (1235) | about 11 years ago | (#7199429)

Actually, all of the most popular C++ compilers are getting pretty close to standards compliance (even g++ ;-). This is largely thanks to the work of The Edison Design Group [edg.com] , who license compiler front ends, and are very focused on standards compliance.

If you don't want to spend a lot of money, and you don't want to stop using the compiler that you have, I highly recommend The Comeau Compiler [comeaucomputing.com] . It is a compiler front end derived from the EDG codebase, and only costs you $50. The big downside is that your compile times will be much longer than usual, but at least you can use the export keyword to help with that a bit.

Borland!! (1)

Seekerofknowledge (134616) | about 11 years ago | (#7199575)

Borland C++ Builder 5.0 has an ANSI compliant compiler, including STL support. I'm sure 6.0 also does.

I remember that it was such a big deal that it was advertised on the box. Check it out. [borland.com]

Why did they need to interview bjarne about that? (0)

blake8087 (688462) | about 11 years ago | (#7199341)

All he did was complain about over and under object-orienting c++ code. Not sure why that's useful... My Computer Science professors do that all the time.

Re:Why did they need to interview bjarne about tha (2, Insightful)

deadlinegrunt (520160) | about 11 years ago | (#7199509)

All he did was complain about over and under object-orienting c++ code. Not sure why that's useful... My Computer Science professors do that all the time.

Being that there is a large codebase out there that breaks either one of these rules I would venture a guess that is why he commented on it. He does not believe that there is a sliver bullet to solving software problems nor does he believe that C++ is one either. It is just a language he designed to solve problems he encountered while programming.

C++ is not object oriented. It has OOP support but does not mandate it. The other extreme is that it is not C. If you find yourself falling to one of these extremes in *EVERY* coding probem then there is a high probability you just might have missed his point.

Confusion (not a Slashdot interview!) (2, Informative)

wackysootroom (243310) | about 11 years ago | (#7199352)

I see that a lot of people here are confused and posting questions for Bjarne Stroustrup. This is not a slashdot interview where people post questions for the guru and the editors pick the top 5 for the interviewee to answer. This is an interview that was done by an external website and not interviews.slashdot.org.

Re:Confusion (not a Slashdot interview!) (0)

Anonymous Coward | about 11 years ago | (#7199387)

i would say to people looking for interviews to try /.'s Interview section. Except that the link that appears on the right hand side of the /. homepage looks borked [slashdot.org]

Re:Confusion (not a Slashdot interview!) (1)

dirtydamo (160364) | about 11 years ago | (#7199414)

This is not a slashdot interview where people post questions for the guru and the editors pick the top 5 for the interviewee to answer.

Boy, and I thought people didn't RTFA. Why don't they even RTFS (summary), or how about RTFT (title)?

moron practical use of the pateNTdead eyecon0meter (-1, Troll)

Anonymous Coward | about 11 years ago | (#7199358)

asked if the hole fauxking georgewellian fuddite corepirate nazi southern baptist freemason execrable 'war', was some whoreabull excuse to ratskew the dying bullshipping industrIE, sumwon (speaking buy condition of anonymity, we call her connIE) .concluedead: lookout bullow, the daze of the phonIE ?pr? ?firm? scriptdead FraUDsters is WANing into coolapps/the abyss.

no wonder connIE prefers anonymity?

as for the armIE, there MuSt be just won mind there?

(CBS) A series of letters to hometown newspapers, purportedly written by U.S. soldiers in Iraq, contain identical language, according to the Gannett News Service. The letters praise the U.S. effort to rebuild the war-torn Mideast nation.

Gannett said it had turned up 11 identical letters from soldiers serving in Iraq with the 2nd Battalion of the 503rd Airborne Infantry Regiment. Six of the soldiers contacted by Gannett said they knew of the letters and agreed with their substance, but hadn't written them.

But another letter, purportedly written by a GI hospitalized for wounds suffered in a grenade attack, came as a surprise to Pfc. Nick Deaconson of Beckley, W.Va., according to his dad.

The soldier received a congratulatory phone call from his father, Timothy, for getting the letter published in the local newspaper.

"When I told him he wrote such a good letter, he said: 'What letter?'" Timothy Deaconson told Gannett. "This is just not his (writing) style."
---

yikes

You cannot organize this (1, Insightful)

jetkust (596906) | about 11 years ago | (#7199400)

Seriously, you can't seriously improve a language by telling people how to program with it. You also don't know if these so-called style improvements help anyone at all. This is just like Hungarian notation, where people stupidly decided they wanted to know the type of a variable by looking at its name. The C++ language is what it is. Whatever you can do with it is what it is. You can't make C++ into Java by telling people what they can't do. This is why C++ is not Java. The "problems" in its design are part of the language.

Re:You cannot organize this (1)

cK-Gunslinger (443452) | about 11 years ago | (#7199501)

Are you saying that "_f_m_computedAreaOfCircle" is not a good name for the private member floating point variable that holds the computed area of the containing circle object? =)

Re:You cannot organize this (1)

deputydink (173771) | about 11 years ago | (#7199548)

Seriously, you can't seriously improve a language by telling people how to program with it.

So true... if it wasn't we'd all be programming Visual Basic for a living.

Re:You cannot organize this (1)

ozzee (612196) | about 11 years ago | (#7199558)

Seriously, you can't seriously improve a language by telling people how to program with it.

You can write bad code in any language. I don't see how your statement and the prvious sentence can both be true unless you equate it to some individuals are capable of programming and some are not, but, at some point in time, we had to be "told" how to write programs which kind of invalidates your statement.

The other point is, there are a number of rules that you can use that if abided by will have fewer chances of error.

Maybe I missed your point.

Not worth reading (1)

Anonymous Coward | about 11 years ago | (#7199430)

Please don't waste your time reading that interview. The interviewer is asking very irrelevant questions and doesn't seem to have a clue about what the other is answering. His answers are garbage anyways, the whole discussion is about invariants. It looks long because there's 4 pages, but if they'd use a normal font, it'd fit easily on a single page... Elementary school level interview if you ask me.

it's getting slow (0)

Anonymous Coward | about 11 years ago | (#7199477)

The C++ Style Sweet Spot
A Conversation with Bjarne Stroustrup, Part I
by Bill Venners
October 13, 2003

Summary
Bjarne Stroustrup talks with Bill Venners about the perils of staying too low level and venturing too object-oriented in C++ programming style.
Bjarne Stroustrup is the designer and original implementer of C++. He is the author of numerous papers and several books, including The C++ Programming Language (Addison-Wesley, 1985-2000) and The Design and Evolution of C++ (Addison-Wesley, 1994). He took an active role in the creation of the ANSI/ISO standard for C++ and continues to work on the maintenance and revision of that standard. He is currently the College of Engineering Chair in Computer Science Professor at Texas A&M University.

On September 22, 2003, Bill Venners met with Bjarne Stroustrup at the JAOO conference in Aarhus, Denmark. In this interview, which will be published in multiple installments on Artima.com, Stroustrup gives insights into C++ best practice. In this first installment, Stroustrup describes how C++ programmers can reconsider their style of C++ use to gain maximum benefit from the language.

Climbing above C-level
Bill Venners: In an interview, you said, "The C++ community has yet to internalize the facilities offered by standard C++. By reconsidering the style of C++ use, major improvements in ease of writing, correctness, maintainability, and efficiency can be obtained." How should C++ programmers reconsider their style of C++ use?

Bjarne Stroustrup: It's always easier to say what not to do, rather than what to do, so I'll start that way. A lot of people see C++ as C with a few bits and pieces added. They write code with a lot of arrays and pointers. They tend to use new the way they used malloc. Basically, the abstraction level is low. Writing C-style code is one way to get into C++, but it's not using C++ really well.

I think a better way of approaching C++ is to use some of the standard library facilities. For example, use a vector rather than an array. A vector knows its size. An array does not. You can extend a vector's size implicitly or explicitly. To get an array of a different size, you must explicity deal with memory using realloc, malloc, memcpy, etc. Also, use inline functions rather than macros, so you don't get into the macro problems. Use a C++ string class rather than manipulating C strings directly. And if you've got a lot of casts in the code, there's something wrong. You have dropped from the level of types, a high level of abstraction, down to a level of bits and bytes. You shouldn't do that very often.

To get out of writing low level code, you needn't start writing a lot of classes. Instead, start using facilities provided in libraries. The standard library os the first and most obvious source, but there are also good libraries for things like math or systems programming. You don't have to do threading at the C level. You can use a C++ threading library. There are quite a few of them. If you want callbacks, don't use just plain C functions. Get libc++, and you'll have a proper library that deals with callbacks--callback classes, slots and signals, that kind of stuff. It's available. It's conceptually closer to what you're thinking about anyway. And you don't have to mess with error prone details.

Most of these techniques are criticized unfairly for being inefficient. The assumption is that if it is elegant, if it is higher level, it must be slow. It could be slow in a few cases, so deal with those few cases at the lower level, but start at a higher level. In some cases, you simply don't have the overhead. For example, vectors really are as fast as arrays.

Object-Orientaphilia
The other way people get into trouble is exactly the opposite. They believe that C++ should be an extremely high level language, and everything should be object-oriented. They believe that you should do everything by creating a class as part of a class hierarchy with lots of virtual functions. This is the kind of thinking that's reflected in a language like Java for instance, but a lot of things don't fit into class hierarchies. An integer shouldn't be part of a class hierarchy. It doesn't need to. It costs you to put it there. And it's very hard to do elegantly.

You can program with a lot of free-standing classes. If I want a complex number, I write a complex number. It doesn't have any virtual functions. It's not meant for derivation. You should use inheritance only when a class hierarchy makes sense from the point of view of your application, from your requirements. For a lot of graphics classes it makes perfect sense. The oldest example in the book is the shape example, which I borrowed from Simula. It makes sense to have a hierarchy of shapes or a hierarchy of windows, things like that. But for many other things you shouldn't plan for a hierarchy, because you're not going to need one.

So you can start with much simpler abstractions. Again the standard library can provide some examples: vector, string, complex number. Don't go to hierarchies until you need them. Again, one indication that you've gone too far with class hierarchies is you have to write casts all the time, casting from base classes to derived classes. In really old C++, you would do it with a C style cast, which is unsafe. In more modern C++, you use a dynamic cast, which at least is safe. But still better design usually leads you to use casting only when you get objects in from outside your program. If you get an object through input, you may not know what it is until a bit later, and then you have to cast it to the right type.

Bill Venners: What is the cost of going down either of those two paths, being to low-level or too enamored with object-orientation? What's the problem?

Bjarne Stroustrup: The problem with the C way is that if you write code C-style, you get C-style problems. You will get buffer overflows. You will get pointer problems. And you will get hard to maintain code, because you're working at a very low level. So the cost is in development time and maintenance time.

Going to the big class hierarchy is again, you write more code than you need to, and you get too much connection between different parts. I particularly dislike classes with a lot of get and set functions. That is often an indication that it shouldn't have been a class in the first place. It's just a data structure. And if it really is a data structure, make it a data structure.

Classes should enforce invariants
Bjarne Stroustrup: My rule of thumb is that you should have a real class with an interface and a hidden representation if and only if you can consider an invariant for the class.

Bill Venners: What do you mean by invariant?

Bjarne Stroustrup: What is it that makes the object a valid object? An invariant allows you to say when the object's representation when it's good and when it isn't. Take a vector as a very simple example. A vector knows that it has n elements. It has a pointer to n elements. The invariant is exactly that: the pointer points to something, and that something can hold n elements. If it holds n+1 or n-1 elements, that's a bug. If that pointer is zero, it's a bug, because it doesn't point to anything. That means it's a violation of an invariant. So you have to be able to state which objects make sense. Which are good and which are bad. And you can write the interfaces so that they maintain that invariant. That's one way of keeping track that your member functions are reasonable. It's also a way of keeping track of which operations need to be member functions. Operations that don't need to mess with the representation are better done outside the class. So that you get a clean, small interface that you can understand and maintain.

Bill Venners: So the invariant justifies the existence of a class, because the class takes the responsibility for maintaining the invariant.

Bjarne Stroustrup: That's right.

Bill Venners: The invariant is a relationship between different pieces of data in the class.

Bjarne Stroustrup: Yes. If every data can have any value, then it doesn't make much sense to have a class. Take a single data structure that has a name and an address. Any string is a good name, and any string is a good address. If that's what it is, it's a structure. Just call it a struct. Don't have anything private. Don't do anything silly like having a hidden name and address field with get_name and set_address and get_name and set_name functions. Or even worse, make a virtual base class with virtual get_name and set_name functions, and override it with the one and only representation. That's just elaboration. It's not necessary.

Bill Venners: It's not necessary because there's one and only representation. The justification is usually that if you make it a function, then you can change the representation.

Bjarne Stroustrup: Exactly, but some representations you don't change. You don't change the representation of an integer very often, of a point, of a complex number. You have to make design decisions somewhere.

And the next stage, where you go from the plain data structure to a real class with real class objects, could be that name and address again. You probably wouldn't call it name_and_address. You'll maybe call it personnel_record or mailing_address. At that stage you believe name and address are not just strings. Maybe you break the name down into first, middle, and last name strings. Or you decide the semantics should be that the one string you store really has first, middle, and last name as parts of it. You can also decide that the address really has to be a valid address. Either you validate the string, or you break the string up into first address field, second address field, city, state, country, zip code, that kind of stuff.

When you start breaking it down like that, you get into the possibilities of different representations. You can start deciding, does it really add to have private data, to have a hierarchy? Do you want a plain class with one representation to deal with, or do you want to provide an abstract interface so you can represent things in different ways? But you have to make those design decisions. You don't just randomly spew classes and functions around. And you have to have some semantics that you are defending before you start having private data.

The way the whole thing is conceived is that the constructor establishes the environment for the member functions to operate in, in other words, the constructor establishes the invariant. And since to establish the invariant you often have to acquire resources, you have the destructor to pull down the operating environment and release any resources required. Those resources can be memory, files, locks, sockets, you name it--anything that you have to get and put back afterwards.

Designing simple interfaces
Bill Venners: You said that the invariant helps you decide what goes into the interface. Could you elaborate on how? Let me attempt to restate what you said, and see if I understand it. The functions that are taking any responsibility for maintaining the invariant should be in the class.

Bjarne Stroustrup: Yes.

Bill Venners: Anything that's just using the data, but not defending the invariant, doesn't need to be in the class.

Bjarne Stroustrup: Let me give an example. There are some operations you really can't do without having direct access to the representation. If you have an operation that changes the size of a vector, then you'd better be able to make changes to the number of elements stored. You move the elements and change the size variable. If you've just got to read the size variable, well, there must be a member function for that. But there are other functions that can be built on top of existing functions. For example, given efficient element access a find function for searching in a vector is best provided as a non-member.

Another example would be a Date class, where the operations that actually change the day, month, and year have to be members. But the function that finds the next weekday, or the next Sunday, can be put on top of it. I have seen Date classes with 60 or 70 operations, because they built everything in. Things like find_next_Sunday. Functions like that don't logically belong in the class. If you build them in, they can touch the data. That means if you want to change the data layout, you have to review 60 functions, and make changes in 60 places.

Instead, if you build a relatively simple interface to a Date class, you might have five or ten member functions that are there because they are logically necessary, or for performance reasons. It's hard for me to imagine a performance reason for a Date, but in general that's an important concern. Then you get these five or ten operations, and you can build the other 50 in a supporting library. That way of thinking is fairly well accepted these days. Even in Java, you have the containers and then the supporting library of static methods.

I've been preaching this song for the better part of 20 years. But people got very keen on putting everything in classes and hierarchies. I've seen the Date problem solved by having a base class Date with some operations on it and the data protected, with utility functions provided by deriving a new class and adding the utility functions. You get really messy systems like that, and there's no reason for having the utility functions in derived classes. You want the utility functions to the side so you can combine them freely. How else to I get your utility functions and my utility functions also? The utility functions you wrote are independent from the ones I wrote, and so they should be independent in the code. If I derive from class Date, and you derive from class Date, a third person won't be able to easily use both of our utility functions, because we have built dependencies in that didn't need to be there. So you can overdo this class hierarchy stuff.

Another Interesting Interview (1)

pararox (706523) | about 11 years ago | (#7199479)

Here's another very interesting interview [pararox.com] with the C++ creator. You'll be shocked, I promise ;)

Regards,

-pararox-

From the article (3, Insightful)

Apreche (239272) | about 11 years ago | (#7199481)

Quote Bjarne Stroustrup: Yes. If every data can have any value, then it doesn't make much sense to have a class. Take a single data structure that has a name and an address. Any string is a good name, and any string is a good address. If that's what it is, it's a structure. Just call it a struct. Don't have anything private. Don't do anything silly like having a hidden name and address field with get_name and set_address and get_name and set_name functions. Or even worse, make a virtual base class with virtual get_name and set_name functions, and override it with the one and only representation. That's just elaboration. It's not necessary.

Thank You! This is the number one java peeve. Every time I just want to make a structure I've got to make a whole class. That's a whole file. That's a whole lot of extra code. In C/C++ I can make an equivalent struct in a few lines.

This is why I like python so much. I can do all the object-orientedness I want and all the proceduralness I want and they work together perfect. And everything pops out into super efficient C code and then into executable with my gcc. And if I want it cross platform I can just use jython and get workin .class files.

Re:From the article (1)

volsung (378) | about 11 years ago | (#7199537)

How are you getting super efficient C code from your python programs?

Re:From the article (1)

criquet (120814) | about 11 years ago | (#7199542)

In java, you can include private classes in the same .java file as a public class and you can also create nested classes. If you make all the data/fields in the class public and have no methods, then what you have a struct.

say what? (1)

mschoolbus (627182) | about 11 years ago | (#7199515)

...and getting maximum from a language.

Like English?

Weird guy (2, Informative)

the uNF cola (657200) | about 11 years ago | (#7199534)

I went to one of this guy's conferences on C++. I thought it'd be more in depth, but it was merely introduction to the features of C++. It does this, it does that. Neat libs like boost and the stl. Also has ACE libs for cross compatability

Well, as one may expect, someone asked about java. He got very biligerant and brief about it. "C++ is supported on N many more platforms than java." (Can't remember N). It was also the last question too, which left that "weird" sense in my mind's eye.

the article, page 1 of 4 (0, Redundant)

asdfghjklqwertyuiop (649296) | about 11 years ago | (#7199550)

Climbing above C-level


Bill Venners: In an interview, you said, "The C++ community has yet to
internalize the facilities offered by standard C++. By reconsidering the style of C++ use,
major improvements in ease of writing, correctness, maintainability, and efficiency can
be obtained." How should C++ programmers reconsider their style of C++ use?


Bjarne Stroustrup: It's always easier to say what not to do, rather than what to
do, so I'll start that way. A lot of people see C++ as C with a few bits and pieces added.
They write code with a lot of arrays and pointers. They tend to use new
the way they used malloc. Basically, the abstraction level is low. Writing
C-style code is one way to get into C++, but it's not using C++ really well.


I think a better way of approaching C++ is to use some of the standard library facilities.
For example, use a vector rather than an array. A vector knows its size. An array does
not. You can extend a vector's size implicitly or explicitly.
To get an array of a different size, you must explicity deal with
memory using realloc, malloc, memcpy, etc.
Also, use inline
functions rather than macros, so you don't get into the macro problems. Use a C++ string

class rather than manipulating C strings directly. And if you've got a lot of casts in the
code, there's something wrong. You have dropped from the level of types, a high level of
abstraction, down to a level of bits and bytes. You shouldn't do that very often.


To get out of writing low level code, you needn't start writing a lot of classes. Instead,
start using facilities provided in libraries. The standard library os the first and most
obvious source, but there are also good libraries for things like math or systems
programming. You don't have to do threading at the C level. You can use a C++
threading library. There are quite a few of them. If you want callbacks, don't use just
plain C functions. Get libc++, and you'll have a proper library that deals with
callbackscallback classes, slots and signals, that kind of stuff. It's available.
It's conceptually closer to what you're thinking about anyway. And you don't have to mess
with error prone details.


Most of these techniques are criticized unfairly for being inefficient. The assumption is
that if it is elegant, if it is higher level, it must be slow. It could be slow in a few cases, so
deal with those few cases at the lower level, but start at a higher level. In some cases, you
simply don't have the overhead. For example, vectors really are as fast as arrays.

the article, page 2 of 4 (0, Redundant)

asdfghjklqwertyuiop (649296) | about 11 years ago | (#7199573)

Object-Orientaphilia


The other way people get into trouble is exactly the opposite. They believe that C++
should be an extremely high level language, and everything should be object-oriented.
They believe that you should do everything by creating a class as part of a class hierarchy
with lots of virtual functions. This is the kind of thinking that's reflected in a language
like Java for instance, but a lot of things don't fit into class hierarchies. An integer
shouldn't be part of a class hierarchy. It doesn't need to. It costs you to put it there. And
it's very hard to do elegantly.


You can program with a lot of free-standing classes. If I want a complex number, I write
a complex number. It doesn't have any virtual functions. It's not meant for derivation.
You should use inheritance only when a class hierarchy makes sense from the point of
view of your application, from your requirements. For a lot of graphics classes it makes
perfect sense. The oldest example in the book is the shape example, which I borrowed
from Simula. It makes sense to have a hierarchy of shapes or a hierarchy of windows,
things like that. But for many other things you shouldn't plan for a hierarchy, because
you're not going to need one.


So you can start with much simpler abstractions. Again the standard library can provide
some examples: vector, string, complex number. Don't go to hierarchies until you need
them. Again, one indication that you've gone too far with class hierarchies is you have to
write casts all the time, casting from base classes to derived classes. In really old C++,
you would do it with a C style cast, which is unsafe. In more modern C++, you use a
dynamic cast, which at least is safe. But still better design usually leads you to use casting
only when you get objects in from outside your program. If you get an object through
input, you may not know what it is until a bit later, and then you have to cast it to the
right type.


Bill Venners: What is the cost of going down either of those two paths, being to
low-level or too enamored with object-orientation? What's the problem?


Bjarne Stroustrup: The problem with the C way is that if you write code C-style,
you get C-style problems. You will get buffer overflows. You will get pointer problems.
And you will get hard to maintain code, because you're working at a very low level. So
the cost is in development time and maintenance time.


Going to the big class hierarchy is again, you write more code than you need to, and you
get too much connection between different parts. I particularly dislike classes with a lot
of get and set functions. That is often an indication that it shouldn't have been a class
in the first place. It's just a data structure. And if it really is a data structure,
make it a data structure.

Highschool was... interesting with him. (-1, Troll)

Anonymous Coward | about 11 years ago | (#7199561)

I knew benard in highschool. Ole benard. Yea he was smart but... he didnt have any real skills to show the local pizzhut/computer club.

I always though of him as a bit of a circle jerker. He never had a woman or girl back then, although none of us did, feminism was all the rouge so there was really no point in trying to snag a date. I mean girls are in theory great, but when one kicks you in the balls and is all self ritious about it... well you usually beat the shit out of them with your back hand, back in the day you got thanked for holding the door... but in HS with feminazism being pumped into the girls hearts... millitant shit.

Anyway we almost always outfoxed him in Assembly, and plain new C (snuck into the UNI sometimes to play with the PDPs :D... unfortunatly it was next to the womens studies office which we trashed, alot.

Invariants and Design by Contract (1)

LeonardShelby (576365) | about 11 years ago | (#7199567)


He's discussing class invariants, and how they help one design interfaces, and how they must be maintained. But he's refused to put that into C++! For years he'd been asked about adding some form of contracting to the language, but he'd always come back with how that's not needed. (I always thought part of it was due to his hatred of Bertrand Meyer (of Eiffel fame)).

Has he now seen the error of his ways? Is contracting (in any form other than assert) going to get added to C++?
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?