Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Programming IT Technology

Bjarne Stroustrup On Concepts, C++0x 346

Posted by ScuttleMonkey from the down-and-out-but-not-over dept.
An anonymous reader writes "Danny Kalev has an interview with Bjarne Stroustrup about the failure of concepts, the technical issues of concepts, whether the ISO committee's days are over, and whether C++ is at a dead-end. 'I don't think that concepts were doomed to fail. Also, I don't think concepts were trying to fix many things or to transform C++ into an almost new language. They were introduced to do one thing: provide direct language support to the by-far dominant use of templates: generic programming. They were intended to allow direct expression of what people already state in comments, in design documents, and in documentation. Every well-designed template is written with a notion of what is required from its arguments. For good code, those requirements are documented (think of the standard's requirements tables). That is, today most templates are designed using an informal notion of concepts.'"
This discussion has been archived. No new comments can be posted.

Bjarne Stroustrup On Concepts, C++0x More

Bjarne Stroustrup On Concepts, C++0x

Comments Filter:

  • Really Unfortunate Initials (Score:4, Funny)

    by eldavojohn ( 898314 ) * <eldavojohn@noSpAM.gmail.com> on Friday August 07, 2009 @01:16PM (#28987789) Journal
    I enjoyed the interview but I felt the initials of the participants were really unfortunate. DK and BS? I kept reading the whole thing as:

    Donkey Kong: The specification of concepts has taken seven years. By contrast, the standardization of the entire STL took about half that time. What is so complicated about concepts?

    Bull Shit! I count the concepts work as started in 2002! I presented my first design papers in 2003! In 1994 Alex Stepanov presented a complete implementation of the STL to Andrew Koenig and me, but 2002-to-2009 and 1994-to-1998 are not comparable time lines! Alex had been working on the STL from at least 1976! ... etc.

    What's really unfortunate is that he's one of the very few language maintainers out there that isn't of the mentality "Rah rah! My language/tool/design-philosophy/whatever is the solution to all your problems and will take over the world tomorrow." (phrase lifted from the interview) Wish we had more people like you out there, Stroustrup. Also, if this isn't fixed by now, I'm sorry Slashdot couldn't even get your name right in the title to this story.

    • Re:Really Unfortunate Initials (Score:5, Insightful)

      by Desler ( 1608317 ) on Friday August 07, 2009 @01:26PM (#28987923)

      What's really unfortunate is that he's one of the very few language maintainers out there that isn't of the mentality "Rah rah! My language/tool/design-philosophy/whatever is the solution to all your problems and will take over the world tomorrow."

      Care to actually provide the names of those other language maintainers, with appropriate citations, that make such claims?

      • Re: (Score:2, Funny)

        by Anonymous Coward

        You've never seen a Python coder, have you?

        • Re: (Score:3, Insightful)

          by Desler ( 1608317 )

          You've never seen a Python coder, have you?

          He said language maintainer, not language user. Care to quote the Python language maintainer(s) making such a claim?

          • Re: (Score:2, Interesting)

            by Anonymous Coward

            What about this quote [slashdot.org] from Guido van Rossum?

      • Re:Really Unfortunate Initials (Score:5, Informative)

        by shutdown -p now ( 807394 ) on Friday August 07, 2009 @02:10PM (#28988491) Journal

        Care to actually provide the names of those other language maintainers, with appropriate citations, that make such claims?

        Few people remember this days, but Java was positioned that way back in late 1990s. I cannot find any reference because I don't remember the exact words, but I recall Scott McNealy saying something along the lines of "Now that you have Java, why would you write in anything else"?

        Bertrand Meyer and his Eiffel programming language is another example. He isn't really stating directly that it's the best thing since sliced bread, but virtually all his papers on the matter read like aggressive advertisements, praising the virtues of Eiffel, and sniding other languages because they don't "see the light" in form of design-by-contract and command-query separation (conveniently ignoring the major flaws of Eiffel such as universal generic type covariance). He also edited Wikipedia article on Eiffel to match that, got extremely offended when other people have tweaked the article to remove self-promotion, and tried to "revoke" his GFDL'd contributions (read from here [wikipedia.org] on, and check the article history, for the full story of that drama).

        • Re: (Score:2, Offtopic)

          by tepples ( 727027 )

          Donkey Kong [...] Bull Shit

          Bertrand Meyer and his Eiffel programming language is another example.

          Let me guess: Bowel Movement?

    • Re: (Score:3, Funny)

      by rumith ( 983060 )
      Assume that DK stands for Dungeon Keeper, and the tone of the interview suddenly becomes much more sinister... :)

    • Re: (Score:2)

      by halivar ( 535827 )

      I play too much WOW. I read "Blacksmither" and "Death Knight".

    • The C+- Language (Score:5, Funny)

      by Anonymous Coward on Friday August 07, 2009 @02:38PM (#28988931)

      The C+-* Language

      * pronounced "C, more or less."

      Unlike C++, C+- is a subject oriented language. Each C+- class instance known as a subject, holds hidden members, known as prejudices or undeclared preferences, which are impervious preferences, which are impervious to outside messages, as well as public members known as boasts or claims. The following C operators are overridden as shown:

      > better than
        < worse than
        >> much better than
        << forget it
        ! not on your life
        == comparable, other things being equal

      C+- is a strongly typed language based on stereotyping and self-righteous logic. The Boolean variables TRUE and FALSE (known as constants in less realistic languages) are supplemented with CREDIBLE and DUBIOUS, which are fuzzier than Zadeh's traditional fuzzy categories. All Booleans can be declared with the modifiers strong and weak. Weak implication is said to "preserve deniability" and was added at the request of the D.O.D. to ensure compatability with future versions of Ada. Well-formed falsehoods (WFFs) are assignment-compatible with all Booleans. What-if and why-not interactions are aided by the special conditional evenifnot X then Y.

      C+- supports information hiding and, among friend classes only, rumor sharing. Borrowing from the Eiffel lexicon, non-friend classes can be killed by arranging contracts. Note that friendships are intransitive, volatile, and non-Abelian.

      Single and multiple inheritance mechanisms are implemented with random mutations. Disinheritance rules are covered by a complex probate protocol. In addition to base, derrived, virtual, and abstract classes, C+- supports gut classes. In certian locales, polygamous derivations and bastard classes are permitted. Elsewhere, loose coupling between classes is illegal, so the marriage and divorce operators may be needed:

      marriage (MParent1, FParent1);
      // child classes can now be derrived
          sclass MySclass: public MParent1, FParent1
      // define MySclass
          sclass YourSclass: public MParent1, FParent2
      // illegitimate
          divorce (MParent1, FParent1);
          marriage (MParent1, FParent2);
          sclass YourSclass: public MParent1, FParent2
      // OK now

      Operator precedence rules can be suspended with the directive #pragma dwim, known as the "Do what I mean" pragma. ANSIfication will be firmly resisted. C+-'s slogan is "Be Your Own Standard."

      http://baetzler.de/humor/c_more_or_less.html [baetzler.de]

  • Why not just do duck typing? (Score:3, Interesting)

    by morgan_greywolf ( 835522 ) on Friday August 07, 2009 @01:29PM (#28987951) Homepage Journal

    Templates are what Python calls 'duck typing'. ("If it looks like a duck and quacks like a duck...") Why not just do that? You could add methods for introspection and so forth...

    • Templates are what Python calls 'duck typing'. ("If it looks like a duck and quacks like a duck...") Why not just do that? You could add methods for introspection and so forth...

      Because C++ is a statically typed language, which means that type errors are discovered at compile time. For C++, discover = kilobytes of error messages, which is one of the key things concepts would fix.

      Generic (static) programming is one of the areas where C++ is far outshines it's competitors, though heaven knows it has enough other flaws. Sigh, someday I will get a language which satisfies my quite reasonable list of requirements for a decent language.

      • Re:Why not just do duck typing? (Score:5, Insightful)

        by metamatic ( 202216 ) on Friday August 07, 2009 @02:52PM (#28989095) Homepage Journal

        Because C++ is a statically typed language, which means that type errors are discovered at compile time.

        Well, many type errors are discovered at compile time. Unfortunately, static typing tends to have the side effect of requiring more complex code, and often has to be worked around.

        Personally, I write mostly in Java and Ruby. Java is pedantically static to a level that would make C++ blush, while Ruby is completely duck typed. I've had situations where Java's pedantic nature has caught bugs before test runs, but I've also had situations where the code was 10x as long and harder to debug because of the inflexibility. I think it's highly debatable which approach is better, and the answer probably depends on the kind of problem you're solving.

        • Because C++ is a statically typed language, which means that type errors are discovered at compile time.

          Well, many type errors are discovered at compile time. Unfortunately, static typing tends to have the side effect of requiring more complex code, and often has to be worked around. Only if said checks are broken, I believe. Do you have an example? But yes, declaring your types leads to more verbose code for sure; this is one of the trade offs for static typing.

          Personally, I write mostly in Java and Ruby. Java is pedantically static to a level that would make C++ blush, while Ruby is completely duck typed. I've had situations where Java's pedantic nature has caught bugs before test runs, but I've also had situations where the code was 10x as long and harder to debug because of the inflexibility. I think it's highly debatable which approach is better, and the answer probably depends on the kind of problem you're solving.

          I myself has worked extensively in C, C++, Ruby, Perl and Java and many other languages, and of those I do like both Ruby and C++. Java feels like a straightjacket to me, and it sounds like you have the same problem. Perhaps you should try a more powerful language, such as C++?

          • Re: (Score:2, Interesting)

            by metamatic ( 202216 )

            Well, either you believe in static typing, or you don't. If you do, Java is a good choice. If you don't, Ruby is a good choice. C++, on the other hand, is static enough to be annoying, but not static enough to be safe.

            I actually much prefer Objective-C to C++. Once again, the worse solution won.

    • Re:Why not just do duck typing? (Score:5, Informative)

      by smallfries ( 601545 ) on Friday August 07, 2009 @01:45PM (#28988155) Homepage

      I don't think that they are. There is quite a good comparison on the wiki [wikipedia.org] page. The main difference that springs to mind is that duck typing in Python is dynamic (resolved at runtime), where-as the type system in C++ is static (resolved at compile-time). That makes them very different beasts.

      • Runtime vs. compile-time checking (Score:5, Informative)

        by tepples ( 727027 ) <tepplesNO@SPAMgmail.com> on Friday August 07, 2009 @02:35PM (#28988891) Homepage Journal

        The main difference that springs to mind is that duck typing in Python is dynamic (resolved at runtime), where-as the type system in C++ is static (resolved at compile-time).

        Compile-time checking has two purposes: enforce contracts between methods [wikipedia.org] and allow for optimization. I'll cover each of these in turn:

        Dynamic languages have more overhead to dispatch a method call. But then static languages have to duplicate the template code for each type that it handles. It is disputed whether the more direct dispatch outweighs the overhead of loading the duplicated instructions into the CPU's instruction cache.

        Types of arguments to methods make up part of a contract between a method and methods that call it. It's good to have a compiler that can verify some of a contract at compile time, but the halting problem implies that not all parts of all contracts can be expressed in a way that can a machine can verify. Fans of dynamic languages claim that purpose-written unit tests can verify contracts more thoroughly than a compiler's built-in checking, but fans of static languages claim that properly done static typing writes half the unit test for you.

        • Re:Runtime vs. compile-time checking (Score:4, Informative)

          by EvanED ( 569694 ) <evaned@NOspAM.gmail.com> on Friday August 07, 2009 @02:52PM (#28989093)

          It is disputed whether the more direct dispatch outweighs the overhead of loading the duplicated instructions into the CPU's instruction cache.

          Keep in mind that if you can statically determine what function is going to be called, you can potentially inline it. This is important for the stereotypical object-oriented designs where you have a lot of small functions (like getters and setters). This eliminates not just the function call overhead entirely, but will often enable other optimizations. (Of course, virtual functions make determining the function to be called hard or impossible in many cases.)

          So it's not just the increased call overhead that dynamic languages have to deal with, it's the lack of ability to perform a bunch of other optimizations as well. Given C++ templates vs. a true interpreted language, I would wager C++ templates would win virtually every time, I-cache pressure and all.

          However, not all is lost; JIT compilers start introducing a lot of the benefits from static typing back into the dynamic context once it decides to for-real compile part of the code. Once it does that, dynamic languages can pick up most of the benefits of the static language. (And my understanding is sometimes more, because the JIT compiler has some dynamic information while the static compiler has to make safe assumptions.) Of course, not all languages have true JIT compilers (e.g. Python (specifically CPython, the typical implementation) is bytecode-interpreted with no JIT compiler).

          • Re: (Score:2)

            by tepples ( 727027 )

            (Of course, virtual functions make determining the function to be called hard or impossible in many cases.)

            obj.method() has three steps:

            1. Look up obj's __vtable field.
            2. Look up method's entry point in __vtable.
            3. Call method.

            In a typical C++ implementation, __vtable is an array, and each virtual method corresponds to an element of this array indexed by a constant number. But in Python, __vtable (actually called __dict__) is an unordered map from each method names (as a string) to its entry point. Computing a string's hash value for a vtable lookup takes time, so unless you have a JIT (and CPython does not), it can s

        • As you noted, static type checking is a half measure for enforcing contract. I suppose the pluses and minuses of that can be argued until the cows come home.

      • Re: (Score:2)

        by Homburg ( 213427 )

        duck typing in Python is dynamic (resolved at runtime), where-as the type system in C++ is static (resolved at compile-time).

        It's not quite that simple. C++ templates are a Turing-complete programming language, evaluated at compile time. So "runtime" for templates is compile time. Type checking for templates is done when they are evaluated, not when they are defined, that is, at runtime (to repeat, the template runtime that happens during compilation). So they are indeed, like Python, duck typed. Concepts would have added a system for checking templates when they are defined, which would be the equivalent of a static type system

    • Because in C++ a class is basically a struct with some function pointers. If you make that struct a variable size, you break the memory allocation system.

    • Re: (Score:2, Informative)

      by EvanED ( 569694 )

      Other people have said that that breaks C++'s static typing, but what they didn't say is that static typing is one of the explicit design goals of C++.

      Some quotes from The Design and Evolution of C++:

      "The importance of static type checking was also strongly emphasized. In other words, C++ follows the Simula rather than the Smalltalk model of inheritance and type checking."

      "This delayed type-error detection [as present in Smalltalk or Python] was considered unacceptable for C++."

      "However, the most fundamenta

  • No need to dramatize (Score:5, Interesting)

    by loufoque ( 1400831 ) on Friday August 07, 2009 @01:34PM (#28988051)

    I've seen a lot of people dramatize about concepts being removed from C++0x.

    Really, it's no big deal. There are alternative solutions, like some based on SFINAE -- that has now been extended to arbitrary expressions --, that provide almost the same feature set, the same quality in error messages, and are not much harder or more verbose to write or use.

    Actually, getting rid of concepts was probably the best solution for C++0x, since they were a lot of work to implement on top of not being that well polished, not integrating that well with the rest (concepts are not types, nor are they templates, they're a whole new category of things) which would probably have led to different categories of compliance to the new standard.
    This even gives a new chance to more vital features, such as polymorphic lambdas (understand lambdas were the types of the arguments is not given and which thus exhibit parametric polymorphism), to now being reconsidered.

    • Re:BIG need to dramatize (Score:5, Interesting)

      by rockmuelle ( 575982 ) on Friday August 07, 2009 @02:32PM (#28988821)

      It is a big deal. The two most important things concepts were going to do was make generic programming in C++ (1) explicit and (2) accessible.

      Currently, generic programming in C++ is supported through a number of template meta-programming patterns and practices, most of which exist as Boost tribal knowledge - hail King Dave!* It is implicit in many library designs, but there is nothing enforcing it at the language level. If you're not familiar with the concepts of generic programming (pun intended), it's easy to mistake what's going on in the standard libraries as something else. This is especially true if your primary use of the STL is to have polymorphic container classes - you might just design a generic extension to another language that completely misses the point of generic programming (see Java Generics).

      At a more fundamental level, a lot of the power in generic programming comes from the specializations that are possible when you meet type requirements. Right now, there is no way, outside the documentation, to state requirements and possible specializations. Making this explicit in the language makes it clear to the library user what the requirements are and what specializations are available.

      This leads into the accessibility problem. Generic Programming using template meta-programming is difficult. To use it, you have to understand both the template system and generic programming. The former is defined in the standard, but the latter, as mentioned above, is tribal knowledge. By making generic programming explicit in the language, it immediately becomes accessible to a large number of developers who didn't have the time, patience, or fortitude (dealing with the Boost mailing list requires a large supply of this) to become proficient with template-based generic programming.

      As an analogy: consider object-oriented programming in C. Prior to (and even after) C++, lots of OO code was been developed in C. But, each object system was different and based on local best-practices. C++ (and Objective-C) took those practices and codified them into a language extension. As soon as that occurred, one method for OO was standardized. Developers no longer had to implement their own object systems and adhere to documented (but not language enforced) policies. And, with a standard set of rules around this flavor of OO, many other developers felt comfortable jumping in the the fray.

      Concepts in C++ should have had the same effect for Generic Programming in C++ that C++ had for Object Oriented Programming in C. The should have democratized generic programming and brought forth a renaissance in C++ library design. Instead, petty politics killed the most exciting change to C-like languages in years.

      -Chris

      *(Dave - I mean that in the nicest sense... you've done a great job with Boost (oh, we need to jam again, too)).

      • Concepts in C++ should have had the same effect for Generic Programming in C++ that C++ had for Object Oriented Programming in C. The should have democratized generic programming and brought forth a renaissance in C++ library design. Instead, petty politics killed the most exciting change to C-like languages in years.

        Given "Things could have been much worse. In particular, we could have made the seriously flawed "concepts" part of the standard." and "By building directly on the pre-Frankfurt concepts and applying modifications along the lines I suggested in "simplifying the use of concepts" we could have had something acceptable (IMO) within months, but that will not happen now. Instead, we must re-evaluate the basics of concepts and rebuild more or less from scratch (relying on the experience gained so far)â"and e

      • Re: (Score:2)

        by kigrwik ( 462930 )

        Nice explanation, especially the "OOP in C" analogy. Thanks.

      • It's only a big deal to certain programming groups and applications. The programming I do cannot use templates so generic programming is useless to me and removal of concepts is not a big deal at all.

      • Re: (Score:3, Insightful)

        by Jerry Coffin ( 824726 )

        Concepts in C++ should have had the same effect for Generic Programming in C++ that C++ had for Object Oriented Programming in C. The should have democratized generic programming and brought forth a renaissance in C++ library design. Instead, petty politics killed the most exciting change to C-like languages in years.

        I think you're overstating things a bit. It's certainly true that Concepts would have been an improvement, and would have made life a whole lot easier for a whole lot of people -- but let's fa

  • Uncluttered article (print = easy to read) (Score:5, Informative)

    by noidentity ( 188756 ) on Friday August 07, 2009 @01:53PM (#28988269)
    Uncluttered article [devx.com], without any extra crap and multiple pages. Printable = readable.

  • I believe some features that might help C++ is automatic memory allocation (where objects are automatically resized and freed when they go out of scope), and dynamic types (which automatically convert according to some rules based on the context they are used in), basically to give it the same effects as Ruby. This would be optional and avialable alongside present manual systems. It would be an interesting concept rather than just hardcoding this, instead allow it to be implemented on top of some API, sort

    • I believe some features that might help C++ is automatic memory allocation (where objects are automatically resized and freed when they go out of scope

      Even C had that.

      You mean smart pointers? About 10 minutes work to implement... and anyone who's used C++ probably has one in their arsenal somewhere.. not that I'd want them except where they can do some good.. too much overhead for general use.

      C had typing rules too. So does C++.

      henever an object goes out of scope or something is stored into it, a callback

  • Concepts aren't enough! (Score:5, Funny)

    by Stuntmonkey ( 557875 ) on Friday August 07, 2009 @02:05PM (#28988419)

    Can't we just skip "concepts", and move straightaway to "meta-concepts"? After all, a "concept" is just a concept itself, so with meta-concepts we'll be able to define "concepts" recursively. Which doesn't sound like a win, until you realize then you can redefine concepts to fit your own idiosyncratic needs. Like how in my code, the first thing I always do is overload "+" to mean "*", and vice versa. I've always liked them the other way around, not sure why. Anyway, back on point: Concepts by itself is like the 4-blade razor, a lame, stupid half-measure. The real prize, the 360-dunk-off-the-free-throw-line, is 5 blades on a razor. I move we skip "concepts" and go for the big win. Those effeminate Python dorks will have no answer to this, they'll be stunned to see just how inferior they really are. Who's with me on this?

    Broader point: I'm sick and tired of these language designers not giving us enough features. For the last 20 years I've been waiting for a language that will allow me to redefine keywords. If that too much to ask? What if I don't happen to like "for", or "while", or "return"? Do you people lack vision, or competence, or both? Second thing on my must-have list is a pre-pre-processor. I'm tired of writing all these header files all the time. I want a way to generate them programmatically, at compile time. A small embedded scripting language would do fine, just make sure it has templates and operator overloading and multiple inheritance, so I can stretch my legs and get comfy with it. Come on people, start earning your paychecks and get some of this stuff done!

    • Re:Concepts aren't enough! (Score:5, Insightful)

      by shutdown -p now ( 807394 ) on Friday August 07, 2009 @02:32PM (#28988803) Journal

      All that you want exists already, no need to wait 20 years - in fact, it was there already when you've started waiting! It's called Common Lisp.

      It's the only language I know of where you can use its macro facility (reader macros, to be specific) to fully implement another language with arbitrary complex syntax. In other words, a program written in any textual language can be a Common Lisp program if you insert a corresponding CL reader macro definition at the beginning of the code.

      Come to think of it, maybe the fact that it hasn't taken over the world yet has something to do with that...

    • Re: (Score:3, Informative)

      by cptdondo ( 59460 )

      Broader point: I'm sick and tired of these language designers not giving us enough features. For the last 20 years I've been waiting for a language that will allow me to redefine keywords. If that too much to ask? What if I don't happen to like "for", or "while", or "return"?

      Unless my memory fails me, SNOBOL4 could do this 30 years ago.

    • Second thing on my must-have list is a pre-pre-processor. I'm tired of writing all these header files all the time. I want a way to generate them programmatically, at compile time.

      That would actually be kinda cool. Have something that will take your file and pull out function declarations, pull out the public parts of your class definitions, and rewrite your classes to use the pimpl idiom to hide the private parts properly. It'd also be good to have it get rid of slicing problems, but first you'd have to be able to overload the "." operator and determine the base classes of your template parameters.

  • Which conclusions do you draw, if any, from the failure of concepts? How do you feel about this whole affair?

    You mean from the decision not to ship concepts more or less as is for C++0x? I am not of the opinion that concepts have failed. My position was that we needed only a few weeks to "fix" what in my opinion were serious usability problems. Obviously, a majority of the committee didn't agree with that timescale. [...] Things could have been much worse. In particular, we could have made the seriously f

  • Is there some reason that they couldn't have taken some of the work from Eiffel on design by contract and used it for C++0x? Eiffel already compiles to C on its way to object code so I would assume that all of the Eiffel framework stuff could be made to work in C++. Once you've programmed in a design by contract language you really miss it because almost all of the stupid class of bugs go away because they get flagged at compile time.

  • Interviewer acted like an ass (Score:5, Insightful)

    by Logic and Reason ( 952833 ) on Friday August 07, 2009 @02:36PM (#28988897)
    Kalev's questions came across as ignorant and belligerent, but Stroustrup answered all of them intelligently, thoroughly and patiently. It's good to know that there are men like Stroustrup still working hard on C++, even though I no longer do much work in it.

  • Papering over the mold (Score:5, Interesting)

    by Animats ( 122034 ) on Friday August 07, 2009 @02:49PM (#28989075) Homepage

    It's kind of sad. The C++ committee has taken the general position that the underlying defects of C++ should be papered over by making it possible to write templates that hide the problem. But the hiding never quite works; the mold always seeps through the wallpaper.

    The root of the problem is that C and C++ backed into a type system. Originally, C barely had types at all; there were ints and there were floats. Pointers and ints were almost interchangeable. Fields in structures were just offsets, and field names had to be unique across all structures. Gradually, C evolved into a strongly typed language. Sort of. "void *" was introduced as a sort of escape hatch for the type system.

    More importantly, there was never a clear distinction made between arrays and pointers. That single design decision is responsible for most of the buffer overflows in the world. We should have had syntax like

    int read(int fd, char buf[n]&, size_t n);
    to replace the old
    int read(int fd, char *buf, size_t n);

    which says nothing about the size of the array. Right there is the cause of most buffer overflows - the language doesn't properly support talking about the size of arrays.

    Part of the problem there was a major error in the original design of C++ - it didn't have "&" references. So you couldn't talk about a reference to an array; you had to use a pointer to the first element. That pointer has the type of the element, not of an array. Every time you write "char *buf" instead of "char buf[n]&", you're lying to the compiler. The cost of that lie is millions of crashes a day.

    Instead of fixing the mess underneath, C++ papered it over. Arrays were wrapped with classes in the Standard Template Library. The STL is a good thing, but it's not good enough to totally replace built-in arrays. So real-world programs remain a mixture of ambiguous built-in arrays, pointers to arrays, and STL arrays.

    Then the STL approached iteration as an extension of pointer arithmetic. For "compatibility" with C pointer arithmetic, iterators are not only unchecked, but are not explicitly bound to the collection over which they iterate. So the safety problems of C were carried over into STL arrays. This was another bad decision. Most modern languages approach iteration by providing a "do this to all that stuff" construct used for most common iteration cases. C++ does not.

    This is why I'm so critical of the C++ committee. If they'd focused on safety, instead of cool but obscure template features, software would be much better today.

    • The Java design team did focus on safety, and look where that got them.

      C++ is dangerous because it needs to be. There needs to be one high level language in the world that's like juggling operating chainsaws to code in it, because of the options that gives you.

      As the cliche has it, with great power comes great responsibility. C++ is greatly powerful. Using it correctly is a great responsibility.

      • Re:Papering over the mold (Score:4, Informative)

        by Animats ( 122034 ) on Friday August 07, 2009 @03:43PM (#28989727) Homepage

        C++ is dangerous because it needs to be. There needs to be one high level language in the world that's like juggling operating chainsaws to code in it, because of the options that gives you.

        Wrong. It's not essential that a language be unsafe to have low level constructs. Ada, Modula I/II/III, Clascal, Object Pascal, Eiffel, and other hard-compiled languages have been much safer than C++, with comparable power. You don't have to go to an interpretive environment to get safety. That's an illusion from Java, which was made interpretive because Sun wanted portability between their SPARC architecture and the competing Wintel systems.

    • More importantly, there was never a clear distinction made between arrays and pointers.

      As any semi-competent C programmer will tell you, that's a feature.

  • Fix the damned error messages. Seeing something referring to "std::vector>" when I used "vector" is bad enough. Having it at the end of a 255 character error message? Even worse.

  • C++0x (Score:4, Funny)

    by AP31R0N ( 723649 ) on Friday August 07, 2009 @03:18PM (#28989377)

    Is that some kinda of filthy ASCII art?

Slashdot Top Deals

The use of money is all the advantage there is to having money. -- B. Franklin

Close