Bjarne Stroustrup Reveals All On C++ 371
An anonymous reader writes "Bjarne Stroustrup, the creative force behind one of the most widely used and successful programming languages — C++ — is featured in an in-depth 8-page interview where he reveals everything programmers and software engineers should know about C++; its history, what it was intended to do, where it is at now, and of course what all good code-writers should think about when using the language he created."
Oh... my... god... (Score:3, Funny)
C++ is a woman?! I didn't see this coming.
Re: (Score:2)
Sorry, but we're talking about C++ here. You may have this confused with an earlier slashdot story [slashdot.org].
Re:Oh... my... god... (Score:5, Funny)
It shouldn't be that surprising. The new operator should have given it away. After all, in C++ you can create objects (children) that consume resources and don't clean up their garbage. The secret to how it works is that C is a man.
Re: (Score:3, Funny)
Is that you, Verity Stob?
Re:Oh... my... god... (Score:5, Funny)
C++'s social life is a bit weird as well: I hear that friends have access to your privates.
Normal Read (Score:5, Informative)
Re: (Score:3, Funny)
Where is the printf() version?
Re:Normal Read (Score:4, Funny)
You mean the cout version, noob!
Interesting Read (Score:5, Informative)
It's always cool to see this kind of interview. It's even cooler when you can read it all on one page [computerworld.com.au] rather than 8.
I suggest that anyone who uses C++ or is interested in the history of programming read this. Some of it is a bit banal, like how they chose the name, but some of it is really intersting. RTFA for once, you lazy clods!
Re:Interesting Read (Score:5, Funny)
Re:Interesting Read (Score:5, Funny)
Hey! I'm illiterate, you insensitive clod!
As are most c++ programmers.
Re: (Score:3, Funny)
Oh know were not.
Re:Interesting Read (Score:5, Interesting)
Re:Interesting Read (Score:4, Informative)
Early C++ "compilers" usually did more than just macro processing, but only just; most of them were implemented in terms of translating C++ to equivalent C code and then compiling the resulting C. Not so elegant, but it allowed compiler vendors to pick the low-hanging fruit and get something on the market ASAP.
It wasn't just commercial compilers, either. g++ worked that way.
Of course, it goes without saying that these early C++ compilers sucked hard.
c.
Re: (Score:3, Informative)
Re: (Score:3, Interesting)
It's the real reason that D hasn't taken off yet. Well, that and the fact that it has 90+ (!) keywords. The guys at digital mars are doing what Sun tried to do with java; it's ours, ours, and ours alone ! Yes, there is a spec, and yes you can build compilers, but wait - not so fast. You have to let us test your stuff, or you can't call it D. And maybe pay us a little. Or at least remember us in any code that you write.
.
Whenever I go to digital mars' website, I'm reminded of my Corba days and that inst
Re:Interesting Read (Score:4, Interesting)
> Aren't you just a bit biased?
If you're gonna be pedantic, it's a lower-case 'c'.
But I'll freely admit to being biased. I've spent my time in the C++ trenches. C isn't a terribly good language, but when you shoot yourself in the foot it's usually a clean wound.
c.
Re: (Score:3, Informative)
C isn't a terribly good language, but when you shoot yourself in the foot it's usually a clean wound.
From TFA:
"C++ makes it harder to shoot yourself in the foot; but when you do, it takes off the whole leg" is sometimes quoted in a manner hostile to C++. That just shows immaturity. Every powerful tool can cause trouble if you misuse it and you have to be more careful with a powerful tool than with a less powerful one: You can do more harm (to yourself or others) with a car than with a bicycle, with a power saw than with a hand saw, etc. What I said in that quote is also true for other modern languages; for example, it is trivial to cause memory exhaustion in a Java program. Modern languages are power tools. That's a reason to treat them with respect and for programmers to approach their tasks with a professional attitude. It is not a reason to avoid them, because the low-level alternatives are worse still.
-metric
Re: (Score:2)
I don't know about many, but I used at least one that was C++ implemented mainly with the preprocessor -- if I recall, it even did templates using name mangling. It worked, but it made debugging a challenge because the debugger was basically an OK C debugger that wasn't completely up to speed on unmangling C++ symbol
It was never a preprocessor (Score:3, Interesting)
If you're thinking along the lines of a bunch of #defines making C into proto-C++ then you're completely wrong.
The early compilers produced C as a sort of "assembly language" so that it could be used on many different targets (C was widely available).
But it you looked at the C it produced you'd have a hard time relating it to the original C++ source code.
Cfront (Score:3, Insightful)
And in fact, Cfront was a compiler, not just a preprocessor; it was just a compiler that compiled C++ into C.
Re: (Score:3, Interesting)
"that's no longer possible."
Remember... This is Slashdot. Comments like these may have unintended consequences when made here.
It's, of course, possible to build a CFront-like preprocessor that converts current C++ code into C. It's not easy and the C code would probably be even less readable than what CFront wrote. It's not practical either. Or wise.
But it's certainly possible.
Re: (Score:2)
The early versions compiled C++ into C--this was a compilation, not a translation.
What's the difference?
The name (Score:2, Funny)
FTA they tried calling it C with Classes, but that didn't stick, so they asked for suggestions and got C++
I think they should have called it Class-C. Much more fun to pronounce.
Humour (Score:2, Funny)
(C'mon KDE guys, it's funny. Laugh.)
Re:Humour (Score:4, Insightful)
The pun seems to be that KDE isn't structured, efficient, portable or serious, despite being written in C++. I can't blame you for missing it, or finding it not funny.
yawn (Score:4, Insightful)
C++ is a language of a million gotchas. The moment I start having to think about implementation detail and I'm not writing an operating system or compiler, I know I'm using the wrong language.
Re: (Score:3, Insightful)
then you're going to have a hard time of programming, perhaps you'd be happier being the Boss. [urbandictionary.com]
All languages have "implementation details" and various gotchas. Look on any programming forum for any language and you'll see tips and tricks in using it. I think you're in the wrong job.
Re:yawn (Score:4, Informative)
Re: (Score:3, Insightful)
> C++ is a language of a million gotchas.
Whenever you want to use a language, you must learn it first. That's true even of Visual Basic. The reason you see those problems of yours as "gotchas" is that you don't understand how the language (and, in the case of C++, the computer) works. If you let the language shape your thoughts instead of trying to cram your crummy thoughts into C++, it would have been much easier and simpler for you.
> The moment I start having to think about implementation detail, I
Re: (Score:2, Insightful)
You evidently either (A) don't know thing one about C++ or (B) FAR FAR FAR worse, you do think you know about it.
Next time you're in a bookstore, browse through Scott Meyer's "Effective C++" books.
They're basically a huge list of comments to the effect of, "Gee, you THINK you can do X because it's perfectly legal syntax and it makes sense because you do X in other object-oriented languages, but in C++ it either fails outright or its undefined behavior in the language, so it will fail at the worst possible t
Re: (Score:3, Informative)
I don't know where you got this idea. If you have virtual member functions, you probably want a virtual destructor, but it's neither a requirement, nor a given.
From the C++ FAQ lite, read [20.7] When should my destructor be virtual? [parashift.com]
Re:yawn (Score:4, Insightful)
This is the problem with people who don't know how to appreciate C++ capabilities. Do you even know why a "virtual" declaration on a method may be useful, or what it does internally? The whole idea is that you write code that can call methods named in a base class but defined in a derivative (child), via pointers. So, if you want to keep your code clean, you just have one line like:
Parent *p = new Child();
and the rest of the "user" code stays the same. You change the one line above to change functionality of every virtual method.
Now since destructors are called implicitly most of the time, and since you OBVIOUSLY DECLARED VIRTUAL METHODS FOR A REASON, the compiler will warn you if the destructor is not virtual too, because then the object will be destructed as if it is a Parent object. It is a very valid warning, and will save you memory leaks(child objects contain more stuff to be freed..etc). It all makes sense now, see. The compiler is being nice, yes? Do you not agree that you should be blushing, after accusing the heavenly father Stroustrup of psychosis?
Advice for life in general: If you don't know how to use something, don't use it ;)
Re: (Score:3, Insightful)
>> The moment I start having to think about implementation detail, I know I'm using the wrong language.
> In other words, you don't want to know how your program really works. A fine attitude for a PHB. I suggest you switch to english.
When I'm driving my car and I turn the steering wheel right, I expect the car to run right, without having to think about exactly how all the rods and pinions and bearings and whatever are making the car turn right. Sure, I need to know that the more I turn the steerin
Re: (Score:3, Insightful)
When I'm driving my car and I turn the steering wheel right, I expect the car to run right, without having to think about exactly how all the rods and pinions and bearings and whatever are making the car turn right. Sure, I need to know that the more I turn the steering wheel, the tighter I turn, but that should be it. Why should a programming language force me to think about low level implementation details that are nothing to do with the algorithm I'm trying to write?
It is nice to know when you are driving the car that if there is snow or an oil slick or a flat your turning response would be different. You don't have to know how the steering works, but know a few things more than just rotate the wheel right are useful when you want to do anything non-trivial. And just like programming you will learn these things by experience (if u don't get into any serious crashes).
Re:yawn (Score:4, Funny)
Re: (Score:3, Funny)
Be careful - you should Turn Left. Turning right may make you dissolve into little fat monsters.
Re: (Score:3, Insightful)
> When I'm driving my car and I turn the steering wheel right, I expect the car to run right, without having to think
That's what I would expect when using your software, because that is the proper analogy to driving the car. Programming is more like designing the car, and yes, you do want to know what the steering wheel does. What if car designers just had little modules described as "this thingy makes the car turn right"? Then they would just snap the parts together and secure them with duct tape. Would
Re:yawn (Score:4, Insightful)
Because a programmer is a car designer, assembler or a mechanic, depending on his specific job description. The user of the program is analogous to the driver of a car.
If you want to be a car mechanic, you'd better learn how cars work. If you want to be a programmer, you'd better learn how programs work. You'd think this would be bloody obvious, but oh well...
Re: (Score:2)
It is used to solve the diamond problem in singletons where the base class is abstract (pure virtual), though making the base protected isn't too useful. DOM implementations with multiple inheritance where each node is created by the document object come to mind. This kind of design is used e.g. in Inkscape's Inkscape::XML::Node class.
Re: (Score:3, Insightful)
Oh, java must be crap because you can't tell, right?
It's pretty damned easy to tell what should happen. f(foo(a)); should run f on the return value of foo(a). f(a); foo(a); will depend on the specific functions involved (and whether a is passed by reference or value), so it isn't the language's fault if your example is bad. In the c++ example, the expected behavior is clear: f(a++) should be the same as f(a); a++; because it's a postfix increment. If the actual behavior doesn't match that, that's C++'s fault. Likewise, if the Java behavior doesn't match wha
everything programmers should know about C++? (Score:5, Funny)
in an 8 page interview? I feel like a sucker for buying the 900 page book [amazon.com]
Re: (Score:2, Funny)
http://www.amazon.com/gp/product/1418499757/ref=cm_rdp_product [amazon.com]
Re: (Score:3, Funny)
Yeah, he is apparently very good at refactoring.
Re: (Score:3, Funny)
Yeah, but that's 8 pages of pointers into said book ;)
And ... (Score:4, Informative)
... for an equally partisan view from another perspective, the C++ FAQ [yosefk.com].
Re: (Score:3, Informative)
Re: And... (Score:2)
The FQA. One of my favourite extended rants. I cant speak as to how accurate it is (never really have done much in C++), but there are many eye openers in there. (C++ grammar is undecideable-what?)
Re:And ... (Score:4, Insightful)
...it's largely a waste of time. The author spends an inordinate amount of time complaining that C++ prefers compile-time overhead to run-time overhead, and has no understanding that C++ is designed to have no unnecessary performance penalty relative to C. It would be nice if he did, as whatever insights the FQA author has concerning OO languages could be gleaned without wading through a few thousand lines of whining over the lack of things like garbage collection, heap compaction, run time bounds-checking, etc. He also has apparently never heard of Boost.
The FQA is "equally" partisan? (Score:5, Insightful)
I'm afraid that web site is one of those things that gets way too much attention in some on-line communities because of its controversial nature.
The reason the two sides are far from equally partisan is that Stroustrup freely admits there is another side to the debate and that C++ has its flaws, and he is making efforts to improve the situation. The FQA, on the other hand, just makes blanket statements like "For example, the lack of garbage collection makes C++ exceptions and operator overloading inherently defective", which simply isn't true (and neither are many of the statements made in the FQA under those particular headings).
If you read the comments the guy who wrote the FQA makes on forums like reddit, as well as throughout the FQA itself, it's pretty obvious that unlike Stroustrup, he has little interest in any balanced discussion on the subject. He's just out to prove the other side wrong — where "wrong" often means "not agreeing with him" — and perhaps, the cynic in me suspects, to make a reputation for himself in the process.
Favorite line... (Score:4, Funny)
programs in C++ could be simultaneously elegant ... and efficient for systems programming... Obviously, not every program can be both and many are neither
Many are neither. Ain't that the truth.
The Truth about C++ (Score:5, Funny)
On the 1st of January, 1998, Bjarne Stroustrup gave an interview to the IEEE's Computer magazine.
Naturally, the editors thought he would be giving a retrospective view of seven years of object-oriented design, using the language he created.
By the end of the interview, the interviewer got more than he had bargained for and, subsequently, the editor decided to suppress its contents, for the good of the industry, but, as with many of these things, there was a leak.
Here is a complete transcript of what was was said,unedited, and unrehearsed, so it isn't as neat as planned interviews.
You will find it interesting...
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 - re
Re: (Score:3, Interesting)
What a wonderful bit of fiction. I did find it entertaining, so thank you.
I have worked with some very good programmers, and some mediocre ones. The very good ones usually liked C++, and often preferred it when given a choice. The younger (good) ones tend to go with C# these days, though they don't bad-mouth C++.
It is always the mediocre ones who badmouth C++.
That has just been my experience, I don't know if this is true across the board, but I do encounter this a lot. Average and below-average programm
Re: (Score:2)
Er, hardly a Troll there mods. It's definitely personal opinion, (And one that I would have to agree with from personal experience), but not a troll.
Re:The Truth about C++ (Score:4, Interesting)
Nice. If you don't like C++, it must be because you're a bad programmer.
It's much harder to write C++ code that, for example, will never leak memory no matter what goes wrong than in the assorted garbage collected languages, or even vanilla C. That, I don't see how anyone could even reasonably argue.
C++ was an important step on the way to better languages (for the problems it was trying to solve -- not for everything), but that doesn't mean that given today's alternatives it should be considered good.
Being a good programmer is about being good at solving the problem at hand in a clean, maintainable way. It's not about being able to memorize the weird inconsistencies in a language or fight a better fight with a difficult language. Even for a project that has to be done close to the machine, you'll almost always get in less trouble using C. (Or, if you must, using C++ but generally ignoring the C++ features.)
Re: (Score:2)
I'm not sure why this garbage is not being collected, but honestly, C++ making it easier to leak memory than C? What are you smoking, and can I have some?
Re:The Truth about C++ (Score:5, Insightful)
Yawn.
If you don't like C++, you probably just don't understand it [emptycrate.com]. Yes, it's a complex language. However, if you use RAII (a fundamental tenant of C++) you will not. leak. memory. ever. Same arguments about C++ are used over and over again by people who don't grok the language. Is it the end-all be-all language? No. But it is darn good at what it does (performance minded system level code) with almost none of the problems C has (memory leaks and weak typing).
Re: (Score:3, Insightful)
It's much harder to write C++ code that, for example, will never leak memory no matter what goes wrong than in the assorted garbage collected languages, or even vanilla C. That, I don't see how anyone could even reasonably argue.
Probably true. But what does that tell us about general language fitness really since it's equally as easy to hog resources in a language with GC? Database connections for example.
When you absolutely need deterministic release of resources you end up having to approach the problem in a similar fashion to c++ memory management anyway.
Many people believe seem to believe GC allows you to forget about resource management when it doesn't at all.
It's a great tool for a certain class of problems but not a
"What good progammers should think" (Score:3, Funny)
Language stability (Score:3, Interesting)
Re: (Score:3, Insightful)
Stoustrup probably means the binary still runs on the now antiquated system it was originally compiled for. I very much doubt he means that the 20 year old source code still compiles with a modern compiler, as the language has changed way too much. So, Stoustrup's probably being a little bit disingenuous as usual.
Re: (Score:2)
Unless that C++ program was statically linked, it's ridiculously unlikely a 20 year old binary will still run. Even then, some kernels don't even bother supporting a.out at all.
Hell, even Windows doesn't run a good chunk of 20 year old code, especially not Vista.
Re: (Score:2)
I have C++ code from 20 years ago that is still used in the products my company sells. I imagine most C++ will work, unless some relatively obscure (for the time) features were used. Most of the language hasn't changed at all.
OK, it is somewhat "better C" than a full-on templated metaprogram.
Non Geeks (Score:3, Interesting)
Re: (Score:2)
Uh, how about
Management types (PHBs)
Book Store workers
Publishers
Librarians
You may even have issues with some file systems.
When it comes to computing, ignorance rules the masses - I'm still amazed at how many people still call / backslash (which I heard on the radio today when a DJ was giving a URL).
If you liked that, read "Design and Evolution"... (Score:3, Informative)
The interview just seems like a very brief sampling of "The Design and Evolution of C++ [amazon.com]".
Even if you do not care much about C++, it's an excellent look into the philosophy and thought that goes into language design.
Use this link to read article on one page (Score:5, Interesting)
First, read the printable version of the article on one page. [computerworld.com.au] The original version is one paragraph per page, surrounded by ads and related dreck.
There's really nothing new there. It's the usual Strostrup stuff. He's still in denial about C++ being the cause of most of the buffer overflows, system crashes, and security holes in the world.
The fundamental problem with C was the "array=pointer" concept. If array sizes were carried along with arrays, we'd have far less trouble. Even FORTRAN has conformant array parameters. That should have been fixed in C++, but it wasn't, and as a result, we had two more decades of buffer overflow problems. This isn't a performance issue, by the way; Modula 3 got it right, but Modula 3 disappeared for non-technical reasons - Compaq bought DEC and closed down the software R&D operation.
C++ is also the only language that has hiding ("abstraction") without memory safety. C has neither; almost all later languages (Java, Delphi, all the scripting languages) have both. C++ stands alone in this unsafe place. Nobody ever repeated that mistake. So subtly incorrect calls to objects can result in the object overflowing.
Yes, some of these problems can be papered over with templates. The C++ committee is full of templateheads, focused on template features that few will use and fewer will use correctly and productively. That crowd is still struggling to make auto_ptr work.
Re:Use this link to read article on one page (Score:5, Informative)
The developer should know if he'll need the size of an array or not. Which is why there is a convenient std::vector and std::tr1::array for when you do want the size. Not forcing you to carry around a size is a feature, not a bug - if you don't need the size, it's just a waste of space.
And auto_ptr is likely to be depreciated in C++0x, with unique_ptr and shared_ptr replacing it.
Re: (Score:3, Informative)
Delphi is no more memory-safe than C++ is. For that matter, Delphi actually requires you to call destructors for all objects explicitly, and woe be on you if you forget to, or, wors
Tell it like it is (Score:2)
but the intent was (and is) that a competent programmer should be able to express just about any idea directly and have it executed with minimal overheads (zero overheads compared to a C version).
Possibly the most important part of the article. non-competent programmers, go find a language more suited to your skills, preferably one with an IDE that does it all for you.
Convincing the systems programming community of the value of type checking was surprisingly hard. The idea of checking function arguments against a function declaration was fiercely resisted by many - at least until C adopted the idea from C with Classes
And today, we have script languages like this. Just shows things never change, they just go quiet before returning to fashion. (unlike bell-bottom flares which really should never return)(ask your dad)
Re: (Score:2)
And today, we have script languages like this. Just shows things never change, they just go quiet before returning to fashion.
To be fair, the non-type-checking of old C compilers (or new C compilers if you do something wrong and don't follow good conventions) is an entirely different animal than the non-type-checking of today's Python or Perl.
In the former, the function you're calling expects certain types in particular register and/or memory locations, and runs as if they are there. If it's wrong, and the
Love C++, but it still sucks... (Score:5, Informative)
* No standardized pragmas
* Macros after-thought and not type safe
* No 24, and 32 bit (unicode) chars
* Still has float / double crap, instead of being properly deprecated and f32, f64, f80 used instead
* Still has short / long crap, instead of being properly deprecated, and i8, i16, i32, i64, i128, u8, etc...
* No distinction between typedefs and aliases
* Inconsistent left-to-right declarations
* Compilers still limited to ASCII source
* No binary constant prefix (even octal has one?!)
* No standard way to assign NaN, +Inf, -Inf to floating point constants at compile time
Re:Love C++, but it still sucks... (Score:5, Informative)
* Pragmas are made specifically for non-standard compiler extensions. There can be no "standard" pragmas.
* C++0x is adding support for UTF-8, UTF-16, and UTF-32 character types and literals.
* TR1 adds cstdint which includes int32_t etc. types.
* NaN and +Inf (not -Inf, though) can be had from std::numeric_limits
alas, if those are the first complaints you think of, you haven't been using C++ long enough to really know the painful bits.
Re:Love C++, but it still sucks... (Score:5, Informative)
Most of your complaints seem aimed at C and not C++. Let's see:
* No standardized pragmas
They standardized the extension mechanism. That sounds good for a start, but I don't see how you could go farther.
* Still has short / long crap, instead of being properly deprecated, and i8, i16, i32, i64, i128, u8, etc...
Also, short/int/long give you the sizes optimized for the specific processor, so you can use that if that's what you want. You can't really deprecate them because of that
I've never used them though.
For double:
#include <limits>
const double inf = std::numeric_limits<double>::infinity ();
const double minf = -std::numeric_limits<double>::infinity ();
const double nan = -std::numeric_limits<double>::signaling_NaN();
See more here [unc.edu] for example.
There are has_infinity() and related functions to check for a type's capabilities (say, in a template)
Bitmasking (Score:3, Insightful)
Hex is close enough and less error-prone
When you're actually bitmasking, it's nice to see the bits rather than having to accumulate them in your head.
Re: (Score:2, Informative)
* No standardized pragmas
Pragmas were meant to be OS and compiler specific. If your OS or compiler doesn't provide a standard then it's the language is not at fault.
* Macros after-thought and not type safe
Macros weren't meant to be type safe. You should use templates if you need type safety.
* No 24, and 32 bit (unicode) chars
What about std::wstring and cwchar?
* Still has float / double crap, instead of being properly deprecated and f32, f64, f80 used instead * Still has short / long crap, instead of being properly deprecated, and i8, i16, i32, i64, i128, u8, etc...
Use cstdint [die.net] and cfloat [cplusplus.com]
* No distinction between typedefs and aliases * Inconsistent left-to-right declarations
I don't have much experience with those in C++ so maybe someone else should elaborate. Could you provide examples where these two would be a problem?
* Compilers still limited to ASCII source
This is true but hard-coding unicode strings is considered a no-no.
* No binary constant prefix (even octal has one?!)
This
and worst of all... (Score:4, Interesting)
Re:Love C++, but it still sucks... (Score:4, Funny)
... +Inf, -Inf...
Everything has its limits, you know.
Sand-bagger (Score:4, Funny)
Bjarne Stroustrup Reveals All On C++
You mean... He's been holding back?
Want to know more? Read the book (Score:4, Insightful)
"The Design and Evolution of C++" by Stroustrup is a must-read if you are interested in why C++ is the way it is.
After reading it, I really hated C++. It's the classic example of a project that gets ruined by too many people working on it, all with their own goals, and the book tells you exactly why this happened. C++ now is a hideously complex monstrosity that is popular because it is all things to all people, not because it is a good language.
Anyway, if you disagree with me, have a look at the book. It is a testament to Stroustrup's objectivity that I came to the conclusion I did, and that you may come to the exact opposite conclusion as me after reading it.
Anyone trying to defend C++ as a language (Score:4, Informative)
Anyone trying to defend C++ as a language should read this [yosefk.com]. And I speak as a programmer who has used C++ since cfront 1.0 was released to the world.
Useful, yes. Pragmatic, maybe. Design heavily rationalized ex post facto by its creator and its proponents, most certainly. But a well-designed programming language, it is not.
C++ Debuggers (Score:4, Funny)
His answer was along the lines of: "Oh, I never use a debugger. If something's not working right I just think about it...maybe I'll add a printf once in a while if I need to check something."
Now you know why utterly un-debuggable features like templates went into the language...
Re: (Score:3, Insightful)
That's just the point. Your code isn't the problem for you to understand. In the real world where people have to look at other people's code, you often need all the debugging help you can get.
Stroustrup is being very smug in his response here. He lives in an ivory tower, how much real-world code written by other people (to a deadline or management constraints) has he ever dealt with?
My feeling is, very little..
Stroustrup seems to say (don't use exceptions!) (Score:3, Informative)
Here is a real eye opener: Bjarne Stroustrup cited the JSF coding standard as an example of C++ usage: "Also, embedded systems programming is a major area of use and growth of C++; for example, the software for the next generation US fighter planes are in C++ (see the JSF++ coding rules on my home pages)." http://www.computerworld.com.au/index.php/id;408408016;pp;5;fp;16;fpid;1 [computerworld.com.au]
I particular like the following statement in the JSF++ coding rules that the creator of C++ holds up as an example of how to use C++:
AV Rule 208 C++ exceptions shall not be used (i.e. throw, catch and try shall not be used.)
Rationale: Tool support is not adequate at this time.
Re: (Score:2)
Re: (Score:2)
Re: (Score:3, Funny)
Inaccurate. You forgot COBOL. But that's understandable, I want to forget it, too.
Re: (Score:2)
Re: (Score:2, Insightful)
If the messages are the same, no one has any reason to see both, so scoring one out of the default view is the Right Thing. If you're pathetic enough to care about karma and this happens so often that it even matters, complain to the admins that the author of a redundant comment hasn't done anything wrong.
Re:managed code (Score:4, Interesting)
And I suppose your shop used to say "COM only", and now says "ugh, COM, who'd want to code those things up". You seem to have swallowed the Microsoft marketing man's sales spiel wholesale.
When you find out how slow some parts of .NET is (eg DB access), or how much memory it uses when you don't want it to, or how to find the object you expected to be GCd but hasn't been.. then you'll think about writing a chunk of your code in old C++.
MS did do a lot of work (pretty poor IMHO though) with C++/CLI to get some interop going between C++ and C#/VB. Poor because of the somewhat contrived bodges to the language they put in that they could have hidden behind the compiler, and also because there isn't any real interop with old unmanaged C++ except by wrapping it with a managed dll (or recompiling with the /clr flag set). Its also a poor implementation - eg STL/CLR is a lot slower than the .NET containers surprisingly.
Re: (Score:3, Insightful)
Re:useful but oh so flawed (Score:4, Informative)
Re:useful but oh so flawed (Score:4, Insightful)
Basically when you have rules you ought to (or "must" unless you want magical bugs) follow that are not enforced by the compiler, the language is flawed. Like when you oveload new but not delete and thus have incompatible memory management. Or you return a reference to a method-local (auto) string object.
It does however give rise to a market for code analysis tools that checks all the stuff the compiler will let you get away with.
But you can save the cost of these tools (or the alternative manual hunt for bugs) by using more modern and productive languages like Java or Ruby, leaving C++ for operating systems and games. And the latter is moving into other lanbguages as well, i.e. Microsofts push for C# in game development, and the widespread use of Python in e.g. EVE Online, ToonTown, Civ IV and other games.
Re:useful but oh so flawed (Score:5, Insightful)
Well, there's no doubt in my mind that C++ is a language design tour de force. The question is whether its design objectives are the right ones.
They were probably the right objectives for the place (Bell Labs) and time (1979) it was conceived.
At the time, computers were inconceivably slow by today's standards. I worked at a small developer that had a very nice AT&T 3B2-400, which had a WE32000 microprocessor, which probably ran at about 10-15MHz; a half dozen programmers shared it.
As for the place, well, it was crawling with C programmers and C libraries, doing rather complex and important systems programming. Compatibility with C and proven C libraries would have been a huge thing.
So, an efficient, object oriented version of C was probably exactly what was needed.
I think that if there was any fault, it was the attempt to meet the goals of efficiency and compatibility with a language that implemented everything that (at the time was thought to be) necessary for programming in an object oriented style. Multiple inheritance carries too much baggage when all you want to do is to guarantee objects have a certain interface. Likewise, I think operator overloading is another example of trying to do too much. Yes, it makes programmer classes "first class citizens", but it really has no demonstrable practical benefit in my opinion. In situations where you need a special purpose language, it's probably better just to create one.
Still, that's hindsight. If you really understand all the things Stroustrup was trying to do, C++ is quite awe inspiring.
Re:useful but oh so flawed (Score:4, Insightful)
I write math codes for fun and for a living. I have this discussion on an infrequent basis with a Java buddy of mine. Now granted I'm a dumb mechanical engineer and he's a smart CS major, but when I need some custom math classes that aren't provided by the language (tensors, vectors, Jacobians, Quaternions, etc.) and evaluating long math expressions, it is so much easier to view it using the native math symbols than to nest it all in member functions
Re: (Score:3, Interesting)
Of course that might depend on what the 10% is.
Re: (Score:3, Insightful)
Re:useful but oh so flawed (Score:4, Insightful)
I write code for clusters, now specifically CFD. Lots of math, lots of parallel processing. Matlab and Octave isn't gonna cut it, and you really desire the close to the metal aspects of c++.
It may be a narrow range, but there's a lot of people in this narrow range. Specifically, (mechanical/aerospace/etc.) engineers. C++ isn't sexy like Java or Python, but we do a lot of things you just can't do in Python, and can't do fast in Java.
Re: (Score:3, Insightful)
Altogether, I'd rather do the kind of work you're talking about in Matlab or Octave. Or you could do something like Beanshell -- have an interpreted language that is closely tied to the underlying language and its libraries.
Matlab (and its clones) are mostly useless in the numerous areas of math outside of a standard undergrad curriculum, even for "profiling" since the data structures aren't even in the language. It's a zillion times easier to write these in C++. This never gets mentioned on forums like this, but C++ provides the right balance of power and flexibility (especially with memory managament) for people who do specialized math/science. And even in not-so-specialized areas, sometimes objects in Matlab clones are
Re:Operator overloading... (Score:4, Interesting)
The people using C++ for engineering, mathematical, and scientific applications may be a minority, but not a tiny minority. No one has to deal with operator overloading if it is not applicable to their application. If a developer is too immature to recognize when a feature is a bad choice, then operator overloading is the least of his problems.