Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
Programming IT Technology

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."
This discussion has been archived. No new comments can be posted.

Bjarne Stroustrup Reveals All On C++

Comments Filter:
  • by Anonymous Coward on Wednesday June 25, 2008 @09:39AM (#23933695)

    C++ is a woman?! I didn't see this coming.

  • Normal Read (Score:5, Informative)

    by MoonlightSeraphim ( 1253752 ) on Wednesday June 25, 2008 @09:41AM (#23933719)
    Print Version of the same article http://www.computerworld.com.au/index.php/id;408408016;fp;16;fpid;1;pf;1 [computerworld.com.au]
  • Interesting Read (Score:5, Informative)

    by dreamchaser ( 49529 ) on Wednesday June 25, 2008 @09:42AM (#23933737) Homepage Journal

    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!

    • by morgan_greywolf ( 835522 ) * on Wednesday June 25, 2008 @09:47AM (#23933821) Homepage Journal

      RTFA for once, you lazy clods!
      Hey! I'm illiterate, you insensitive clod!
    • Re:Interesting Read (Score:5, Interesting)

      by afidel ( 530433 ) on Wednesday June 25, 2008 @10:03AM (#23934053)
      I was kind of interested in the comment that C++ required a proper compiler rather than just a pre-processor macro package. From the fog of my memory I remember many of the early commercial C++ offerings being mostly a pre-processor package, were those really just C with Classes compilers rather than true C++ ones?
      • Re:Interesting Read (Score:4, Informative)

        by c ( 8461 ) <beauregardcp@gmail.com> on Wednesday June 25, 2008 @11:25AM (#23935449)

        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)

          For the record, the first C++ compiler that compiled directly to native code was Zortech C++ (which beget Symantec C++, which beget Digital Mars C++). Its author, Walter Bright, is the guy behind D programming language [digitalmars.com].
      • by hey! ( 33014 )

        From the fog of my memory I remember many of the early commercial C++ offerings being mostly a pre-processor package, were those really just C with Classes compilers rather than true C++ ones?

        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

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

    • The name (Score:2, Funny)

      by Anonymous Coward

      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)

    I needed a tool for designing and implementing a distributed version of the Unix kernel. At the time, 1979, no such tool existed. I needed something that could express the structure of a program, deal directly with hardware, and be sufficiently efficient and sufficiently portable for serious systems programming.
    I take it Bjarne hasn't used KDE.

    (C'mon KDE guys, it's funny. Laugh.)

  • yawn (Score:4, Insightful)

    by Anonymous Coward on Wednesday June 25, 2008 @09:51AM (#23933881)

    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)

      by gbjbaanb ( 229885 )

      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)

        by shutdown -p now ( 807394 ) on Wednesday June 25, 2008 @02:51PM (#23938775) Journal

        All languages have "implementation details" and various gotchas.
        It's true, but some have more, and others have less, and C++ is on the "a fucking lot" end of the spectrum. Of all the languages I know, the only one that has more (mostly because it covers a lot more ground) is Common Lisp.
    • Re: (Score:3, Insightful)

      by Chemisor ( 97276 )

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

        by Anonymous Coward

        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)

          by Samrobb ( 12731 )

          For example, if you declare even one virtual member function, you HAVE to declare your destructor virtual.

          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)

          by Plutonite ( 999141 ) on Wednesday June 25, 2008 @06:03PM (#23941679)

          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)

        by clickety6 ( 141178 )

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

          by iMaple ( 769378 ) *

          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)

          by larry bagina ( 561269 ) on Wednesday June 25, 2008 @12:13PM (#23936237) Journal
          Why don't you ride the bus? You wouldn't need to even think about steering at all!
        • Re: (Score:3, Funny)

          by Rocky ( 56404 )

          Be careful - you should Turn Left. Turning right may make you dissolve into little fat monsters.

        • Re: (Score:3, Insightful)

          by Chemisor ( 97276 )

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

          by ultranova ( 717540 ) on Wednesday June 25, 2008 @06:31PM (#23942047)

          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?

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

  • by OglinTatas ( 710589 ) on Wednesday June 25, 2008 @09:53AM (#23933901)

    in an 8 page interview? I feel like a sucker for buying the 900 page book [amazon.com]

  • And ... (Score:4, Informative)

    by LizardKing ( 5245 ) on Wednesday June 25, 2008 @10:02AM (#23934037)

    ... for an equally partisan view from another perspective, the C++ FAQ [yosefk.com].

    • Re: (Score:3, Informative)

      by Kamineko ( 851857 )
      In case anybody got confused, that's FQA above, not FAQ. This is FAQ: http://www.parashift.com/c++-faq-lite/index.html [parashift.com]
    • 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)

      by Anonymous Coward on Wednesday June 25, 2008 @11:17AM (#23935333)

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

    • by Anonymous Brave Guy ( 457657 ) on Wednesday June 25, 2008 @11:36AM (#23935635)

      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.

  • by wiredog ( 43288 ) on Wednesday June 25, 2008 @10:02AM (#23934043) Journal

    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.

  • by Anonymous Admin ( 304403 ) on Wednesday June 25, 2008 @10:11AM (#23934189)

    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)

      by Anonymous Coward

      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

      • by GeckoX ( 259575 )

        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.

      • by Mongoose Disciple ( 722373 ) on Wednesday June 25, 2008 @11:40AM (#23935675)

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

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

        • by lefticus ( 5620 ) on Wednesday June 25, 2008 @12:21PM (#23936383) Homepage

          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)

          by jamesswift ( 1184223 )

          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

  • by Anonymous Coward on Wednesday June 25, 2008 @10:15AM (#23934253)

    and of course what all good code-writers should think about when using the language he created
    Let me guess. "How am I going to shoot myself in the foot today?"
  • Language stability (Score:3, Interesting)

    by Yetihehe ( 971185 ) on Wednesday June 25, 2008 @10:24AM (#23934391)

    I wrote C++ code 20 years ago that still runs today and I'm confident that it will still compile and run 20 years from now.
    Funny thing, I tried to use some c++ code, but after one day and correcting about 300 errors (about 20 different TYPES of errors) I gave up and scraped the code (this was Object-Oriented RayTracer from Nicholas Wilt).
    • Re: (Score:3, Insightful)

      by LizardKing ( 5245 )

      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.

      • by nuzak ( 959558 )

        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.

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

    by s31523 ( 926314 ) on Wednesday June 25, 2008 @10:24AM (#23934395)

    Everybody agreed that semantically ++C would have been even better, but I thought that would create too many problems for non-geeks.
    Um, how many non-geeks know anything about programming languages... Why worry about them.
    • by Creepy ( 93888 )

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

  • by SuperKendall ( 25149 ) on Wednesday June 25, 2008 @10:33AM (#23934585)

    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.

  • by Animats ( 122034 ) on Wednesday June 25, 2008 @11:07AM (#23935139) Homepage

    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.

    • by PhrostyMcByte ( 589271 ) <phrosty@gmail.com> on Wednesday June 25, 2008 @11:39AM (#23935669) Homepage

      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)

      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.

      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

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

    • by EvanED ( 569694 )

      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

  • by UnknownSoldier ( 67820 ) on Wednesday June 25, 2008 @11:13AM (#23935263)

    * 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

    • by PhrostyMcByte ( 589271 ) <phrosty@gmail.com> on Wednesday June 25, 2008 @11:32AM (#23935535) Homepage

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

    • by Eponymous Bastard ( 1143615 ) on Wednesday June 25, 2008 @11:47AM (#23935795)

      Most of your complaints seem aimed at C and not C++. Let's see:

      * No standardized pragmas

      You want standardized *compiler extensions*?

      They standardized the extension mechanism. That sounds good for a start, but I don't see how you could go farther.

      * Macros after-thought and not type safe
      C compatibility, basically deprecated now as they also affect everything, including members, variables, anything that gets #included, etc.

      * No 24, and 32 bit (unicode) chars
      wchar exists, toghether with I/O stuff, though I'm not sure about the encoding type. You can even declare streams and strings for any character type you build.

      * 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...
      C compatibility. I believe they are inheriting the new types from C99 too.
      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

      * No distinction between typedefs and aliases
      What on earth is an alias? Are you talking about C's struct namespace? (one of the few things that C++ doesn't inherit)

      * Inconsistent left-to-right declarations
      Inconsistent in what sense?

      * Compilers still limited to ASCII source
      C++ has included trigraphs for over ten years now, which allow an editor to insert any unicode character and still store everything in ASCII for compatibility. Compilers don't even need to support unicode for things to just work. The editor just has to interpret the trigraphs and paint them on screen as the appropriate character.

      I've never used them though.

      * No binary constant prefix (even octal has one?!)
      I've never met anyone who actually worked in binary. Hex is close enough and less error-prone. Octal probably got included for a) C compatibility and b) People did use to work in octal (see file access permissions)

      * No standard way to assign NaN, +Inf, -Inf to floating point constants at compile time
      Would you like a quite or signaling NaN?

      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)

      by Bazer ( 760541 )

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

      by mkcmkc ( 197982 ) on Wednesday June 25, 2008 @12:02PM (#23936057)
      25 years later there's still not a !@#^%^&$ single compiler that implements the entire language correctly. We're all waiting for Godot...
    • ... +Inf, -Inf...

      Everything has its limits, you know.

  • Sand-bagger (Score:4, Funny)

    by blueforce ( 192332 ) <[moc.liamg] [ta] [leagannalc]> on Wednesday June 25, 2008 @11:36AM (#23935625) Homepage Journal

    Bjarne Stroustrup Reveals All On C++

    You mean... He's been holding back?

  • by idiot900 ( 166952 ) * on Wednesday June 25, 2008 @11:50AM (#23935867)

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

  • by frank_adrian314159 ( 469671 ) on Wednesday June 25, 2008 @02:00PM (#23938005) Homepage

    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.

  • by saccade.com ( 771661 ) on Wednesday June 25, 2008 @04:30PM (#23940427) Homepage Journal
    At a corporate event a few years ago, I found myself seated across from Mr. Stroustrup. I asked him what debugger he used for his own development.

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

  • by EMB Numbers ( 934125 ) on Wednesday June 25, 2008 @04:49PM (#23940739)

    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.

FORTUNE'S FUN FACTS TO KNOW AND TELL: A black panther is really a leopard that has a solid black coat rather then a spotted one.

Working...