Beta
×

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

Thank you!

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

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

Bjarne Stroustrup On Concepts, C++0x

ScuttleMonkey posted more than 5 years ago | from the down-and-out-but-not-over dept.

Programming 346

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

cancel ×

346 comments

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

Really Unfortunate Initials (4, Funny)

eldavojohn (898314) | more than 5 years ago | (#28987789)

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 (5, Insightful)

Desler (1608317) | more than 5 years ago | (#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:Really Unfortunate Initials (2, Funny)

Anonymous Coward | more than 5 years ago | (#28988173)

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

Re:Really Unfortunate Initials (1, Insightful)

Anonymous Coward | more than 5 years ago | (#28988209)

WAIT A MINUTE THERE BUDDY!! Python is the best language ever! It will solve all your problems and take over the world tommorrow!!!

How dare you say ... oh ... wait, you were saying Python is that language.

Yeah, python is cool, isn't it?

Re:Really Unfortunate Initials (3, Insightful)

Desler (1608317) | more than 5 years ago | (#28988253)

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:Really Unfortunate Initials (1, Insightful)

eldavojohn (898314) | more than 5 years ago | (#28988335)

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?

Very well. They don't out and out say that exact phrase but I'm sick of languages being marketed to me like an automobile. Here are a few after a bit of Googling. I don't really have time to dig more up:

Larry Wall of Perl: "Perl is designed to give you several ways to do anything, so consider picking the most readable one. " - From the Perl Man Pages

Yukihiro Matsumoto of Ruby: "Why should you switch to Ruby? If you are happy with Perl or Python, you don't have to. But if you do feel there must be a better language, Ruby may be your language of choice." and then "I believe people want to express themselves when they program. They don't want to fight with the language. Programming languages must feel natural to programmers." From an interview [linuxdevcenter.com] . It's hard not to roll my eyes when I hear about the latest flavor of the month. Ruby's marketed as 'the most natural.'

From Sun's about Java page [java.com] they claim, "Write powerful and efficient applications for mobile phones, remote processors, low-cost consumer products, and practically any other device with a digital heartbeat." As one of their reasons developers choose Java.

I'm surprised you aren't sick of languages being marketed to you as silver bullets that can solve all your problems. That's really all I see these days. No more are people considering a multitude of languages to be a toolbox you use to solve all kinds of problems but instead you see languages like Java being marketed for inappropriate things. It's like the inventor of C#, Anders Hejlsberg said, "The dream is to have a single programming model." I just don't believe that's a realistic dream.

If I were in their shoes, I would explicitly say what the language is but also explicitly say what it is not. As someone who's tried to do video analysis in Java, I've been down the "should not" path and wasted my time.

Re:Really Unfortunate Initials (5, Insightful)

Desler (1608317) | more than 5 years ago | (#28988511)

What are those people supposed to say about their language? That it sucks? That user's shouldn't use it? None of those quotes imply anything that you are claiming. Those are just snippets telling people what the positives of using their languages is. In the case of Ruby the maintainer even says that if you are happy with Perl or Python that you shouldn't switch to Ruby. That's hardly a claim of "my language is the solution to all your problems and it's going to take over the world".

Re:Really Unfortunate Initials (0)

Anonymous Coward | more than 5 years ago | (#28988579)

What are those people supposed to say about their language?

Read the last sentence of his post. You also quoted the Ruby quote out of context. The following sentence says it all what he is thinking. It's actually pretty snobby.

What are they supposed to say (4, Insightful)

codegen (103601) | more than 5 years ago | (#28988909)

They are supposed to make the claim against the area for which their language is most appropriate. Although to be fair, it is often the people who are marketing the self-help books that tend to be the most vocal advocates of a particular language. I remember picking up an early O'Reilly book on Perl in a bookstore and reading the introduction and putting it back on the shelf in disgust because of the zealousness of the advocacy in the introduction.

I have also been down the "should not" path on several languages much to my chagrin. Fortunately, I've paid the price allowing me to spare my students the pain.

Re:Really Unfortunate Initials (1)

GooberToo (74388) | more than 5 years ago | (#28988999)

Larry Wall of Perl: "Perl is designed to give you several ways to do anything, so consider picking the most readable one. " - From the Perl Man Pages

Isn't that statement a backhanded way for Larry to tell people to use just about any language other than Perl?

Re:Really Unfortunate Initials (2, Insightful)

Anonymous Coward | more than 5 years ago | (#28989067)

Wow. Calling out Matz of all language maintainers as one with a "rah rah" mentality really shows that you have no clue at all what you are talking about. I've read most of his posts on the Ruby mailing list throughout the past 9 years and I don't think you could find a worse example. At least pick someone like David Heinemeier Hansson -- the creator of Ruby on Rails and one of the most annoying self-marketers I've encountered in software development.

Re:Really Unfortunate Initials (3, Insightful)

Anonymous Coward | more than 5 years ago | (#28989119)

Larry Wall of Perl: "Perl is designed to give you several ways to do anything, so consider picking the most readable one. " - From the Perl Man Pages

Wait, wait, wait. You're seriously citing THAT as an example of (quoting from the GGP)

"Rah rah! My language/tool/design-philosophy/whatever is the solution to all your problems and will take over the world tomorrow."

?

The other examples are actually quite similar; Ruby says, in essence, "we think Ruby is good", and Java says, in essence, "Java is good". Nothing wrong with that - certainly it's not saying anything about other languages. In fact, in Ruby's case, it's explicitely said that if other languages work for you, then by all means continue using them.

But Perl? You're even crazier there. Larry isn't even saying "Perl is good"; in fact, his quote could just as well have come from someone who does NOT like Perl but still wants to give some useful advice (advice that, one might add, is applicable to just about EVERY programming language).

If that's your idea of "rah rah take over the world!", then you must be from Bizarro World - you're not even wrong.

Re:Really Unfortunate Initials (0)

Anonymous Coward | more than 5 years ago | (#28989167)

I think that the simplest language to write AND maintain while still providing acceptable performance is the one to use.

Re:Really Unfortunate Initials (4, Informative)

shutdown -p now (807394) | more than 5 years ago | (#28988491)

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:Really Unfortunate Initials (1, Offtopic)

tepples (727027) | more than 5 years ago | (#28988607)

Donkey Kong [...] Bull Shit

Bertrand Meyer and his Eiffel programming language is another example.

Let me guess: Bowel Movement?

Re:Really Unfortunate Initials (2, Funny)

rumith (983060) | more than 5 years ago | (#28987933)

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

Re:Really Unfortunate Initials (1)

lapinmalin (1400199) | more than 5 years ago | (#28988103)

i think Stroustrup is actually a dinosaur.

Re:Really Unfortunate Initials (1)

halivar (535827) | more than 5 years ago | (#28988749)

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

Re:Really Unfortunate Initials (1)

osu-neko (2604) | more than 5 years ago | (#28989077)

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

Everybody who plays WoW plays too much WoW. (Now if you'll excuse me, I need to go earn another 2400g to buy new mounts for all my toons that now qualify thanks to patch 3.2...)

The C+- Language (5, Funny)

Anonymous Coward | more than 5 years ago | (#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]

C++0x? (0, Troll)

clone53421 (1310749) | more than 5 years ago | (#28987915)

What the hell? Do I have to RTFA to find out what C++0x is supposed to mean?

Re:C++0x? (5, Informative)

betterunixthanunix (980855) | more than 5 years ago | (#28987945)

No you need to calm down and thing about the previous designations of C and C++ standards: C++98, C99, etc. C++0x was intended to be a C++ standard released between 2000 and 2009; at this point, it looks like it is actually going to be released in 2010, and we'll all be calling it C++10.

Re:C++0x? (-1, Flamebait)

Desler (1608317) | more than 5 years ago | (#28987967)

C++0x was intended to be a C++ standard released between 2000 and 2009; at this point, it looks like it is actually going to be released in 2010, and we'll all be calling it C++10.

No, we'll all just be calling it a joke because that's what this whole farce is.

Re:C++0x? (0, Offtopic)

Desler (1608317) | more than 5 years ago | (#28988047)

A flamebait mod? Seriously? Have that mod not been following what has been going on in committee with respect to this new revision? The whole entire process has been a joke for years.

Re:C++0x? (1, Troll)

Threni (635302) | more than 5 years ago | (#28988505)

If there isn't a standard now, there's never going to be one! Really, you'd think the guy's time would be better spent fixing memory leaks and buffer overruns...

Re:C++0x? (1)

clone53421 (1310749) | more than 5 years ago | (#28987975)

ogood, I didn't. :D

Re:C++0x? (0)

Anonymous Coward | more than 5 years ago | (#28988165)

Actually, I think it's going to be called C++0A.

C++0x0A (2, Funny)

jDeepbeep (913892) | more than 5 years ago | (#28988767)

and we'll all be calling it C++10.

I, for one, will be calling it C++0x0A.

Re:C++0x? (0, Redundant)

larry bagina (561269) | more than 5 years ago | (#28987973)

Language standards often include the 2 digit year. C89. Fortran77. The x in c++0x was a placeholder for the year it would eventually be approved.

Re:C++0x? (1)

Dareth (47614) | more than 5 years ago | (#28988385)

That was a really optimistic placeholder. I can hardly wait for C++21XX to come out! Hopefully it won't be just the final version of C++0x. *wink*

Re:C++0x? (4, Informative)

Trepidity (597) | more than 5 years ago | (#28987995)

It's named in parallel with language-revision names like Fortran77 and C99, that use the base language plus the last two digits of their revision year. When the process started years ago, though, they didn't know what year it would finish, but expected it to be in the 200x decade, hence "0x". So, C++0x. Now that the finalization has slipped past 2009, it's C++1x. When it actually comes out, it will have a year with no 'x', like C++10 or C++11.

Re:C++0x? (0)

Anonymous Coward | more than 5 years ago | (#28988119)

What the hell? Do I have to RTFA to find out what C++0x is supposed to mean?

More than one penis?

--
flag@whitehouse.gov

Re:C++0x? (1)

Anonymous CowHardon (1605679) | more than 5 years ago | (#28988975)

Probably. Makes you wonder why there are so few female programmers, doesn't it?

Re:C++0x? (0)

Anonymous Coward | more than 5 years ago | (#28988265)

*sigh*, this got modded all the way down to -1?

Okay, look. This was not supposed to be a troll post. It was an honest question, I got several good responses, and I'm a little surprised that at three people thought it was troll... or maybe they didn't read the comment and just modded it down because of the title. I don't know.

Maybe the mods thought my question was obvious, but it would have been nice to have the summary actually tell what C++0x meant.

Re:C++0x? (1)

shutdown -p now (807394) | more than 5 years ago | (#28988533)

What the hell? Do I have to RTFA to find out what C++0x is supposed to mean?

If you don't know what it means, then most likely TFA is of no interest or concern to you, anyway.

Re:C++0x? (1)

clone53421 (1310749) | more than 5 years ago | (#28988561)

Yeah... which is why I didn't want to read it. I only R'dTFS in the curious hope that it would explain what C++0x meant, and it didn't. Hence my frustration...

meh, it doesn't really matter.

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

morgan_greywolf (835522) | more than 5 years ago | (#28987951)

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

Re:Why not just do duck typing? (1)

EsbenMoseHansen (731150) | more than 5 years ago | (#28988121)

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? (1, Insightful)

Anonymous Coward | more than 5 years ago | (#28988675)

Sigh, someday I will get a language which satisfies my quite reasonable list of requirements for a decent language.

Like this [lolcode.com] ?

Re:Why not just do duck typing? (4, Insightful)

metamatic (202216) | more than 5 years ago | (#28989095)

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.

Re:Why not just do duck typing? (0)

Anonymous Coward | more than 5 years ago | (#28988139)

LOL

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

smallfries (601545) | more than 5 years ago | (#28988155)

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 (4, Informative)

tepples (727027) | more than 5 years ago | (#28988891)

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 (4, Informative)

EvanED (569694) | more than 5 years ago | (#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:Why not just do duck typing? (1)

spiffmastercow (1001386) | more than 5 years ago | (#28988451)

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:Why not just do duck typing? (1)

EvanED (569694) | more than 5 years ago | (#28988945)

Neither duck typing nor introspection requires variable-sized structs.

Re:Why not just do duck typing? (2, Informative)

EvanED (569694) | more than 5 years ago | (#28988913)

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 fundamental reason for relying on statically checked interfaces was that I was -- as I still am [at least 1994] -- firmly convinced that a program composed out of statically type-checked parts is more likely to faithfully express a well-thought-out design than a program relying on weakly-typed interfaces or dynamically-checked interfaces."

Re:Why not just do duck typing? (0)

Abcd1234 (188840) | more than 5 years ago | (#28989087)

Templates are what Python calls 'duck typing'. ("If it looks like a duck and quacks like a duck...")

First, what you young bucks like to call 'duck typing', as cutesy as that sounds, the computing science world calls 'dynamic dispatch'. And it's hardly a new concept (see Smalltalk for a classic example). But, hey, what's old is new and shiny again, right?

Second, dynamic dispatch specifically happens at runtime. Templates, on the other hand, are realized at compile time, as are any method calls made against a templated class. As such, the two concepts are entirely different, both from a conceptual and an implementation standpoint.

Whooooooo Cares++? (-1, Troll)

littlewink (996298) | more than 5 years ago | (#28987957)

C++ is a disaster.

No need to dramatize (4, Interesting)

loufoque (1400831) | more than 5 years ago | (#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:No need to dramatize (0, Redundant)

EsbenMoseHansen (731150) | more than 5 years ago | (#28988135)

While I love the concept of concepts (sorry!), I too feel that leaving them out is for the best. Let us see an implementation first... like we have for lambdas, e.g.

Re:No need to dramatize (1)

EsbenMoseHansen (731150) | more than 5 years ago | (#28988705)

Actually, it would seem that the is an implementation, a fork of gcc. Well.

Re:No need to dramatize (1)

Suiggy (1544213) | more than 5 years ago | (#28988449)

Agreed. I don't understand why people are using the removal of concepts from C++0x as some sort of signal that C++ is now dead or not worth it anymore. There's a lot more to C++0x than just concepts, concepts was only one of a few dozen of new language and library features.

Re:BIG need to dramatize (5, Interesting)

rockmuelle (575982) | more than 5 years ago | (#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)).

Re:BIG need to dramatize (1)

Timothy Brownawell (627747) | more than 5 years ago | (#28989073)

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 experiment. My stated estimate is that that will take on the order of five years, but that it will happen.", I'm thinking that concepts being delayed (not killed) means they'll actually be significantly better that they would have been without being kicked out of this particular revision of the standard.

Script Language Kiddies (0)

Anonymous Coward | more than 5 years ago | (#28989029)

It's Slashdot.

95 percent of the posts are going to be from script language kiddies who have never written a single line of commercial quality production code on a medium to large scale product.

The feature C++ REALLY needs. (1, Interesting)

fish_in_the_c (577259) | more than 5 years ago | (#28988079)

If any one feature could ensure the continuation of C++ as a language it would be a standardized GUI library.
( i know I know, platform problems, implementation , the venders oppose it).

but when it comes right down to it. If C++ had a set of GUI libraries that were part of the standard and could be counted on to be in every compiler ( even if they didn't always look the quite the same). It would go a long way to providing something most developers need and want that can't be found in a lot of languages.

Re:The feature C++ REALLY needs. (1)

Desler (1608317) | more than 5 years ago | (#28988125)

but when it comes right down to it. If C++ had a set of GUI libraries that were part of the standard and could be counted on to be in every compiler ( even if they didn't always look the quite the same). It would go a long way to providing something most developers need and want that can't be found in a lot of languages.

What developers are out their complaining about C++ not having language native GUI libraries? Secondly, unless this would be done in the way Qt does it currently by using the native rendering engine of the platform, this is just a waste of time. What the world doesn't need is a bunch of C++ programs that are written that look alien on every platform it runs on like Java Apps do (yes Java 6 fixes this in quite a few ways but they still don't look entirely like native apps).

Re:The feature C++ REALLY needs. (1)

thetoadwarrior (1268702) | more than 5 years ago | (#28988843)

Java looks close enough these days and, to be honest, I don't think people should be that bother about making boring GUIs that are 100% identical to all other GUIs.

Plus, if people wanted that then themes for various programs (and the OS itself) wouldn't be so popular.

Re:The feature C++ REALLY needs. (0, Troll)

TheRealMindChild (743925) | more than 5 years ago | (#28988227)

If C++ had a set of GUI libraries that were part of the standard and could be counted on to be in every compiler...

Hate to bust your bubble there sonny, but the new C++ specification has ALL SORTS of crap that won't translate to a lot of platforms. For instance, multithreading will be built into the language... but what about something like DOS where there is no threads? Or something that uses bazaar threading mechanisms like protothreads/contiki?

Re:The feature C++ REALLY needs. (1)

Desler (1608317) | more than 5 years ago | (#28988295)

but what about something like DOS where there is no threads?

I think the bigger obstacle would be the lack of a compiler for C++0x for DOS. Until you get over that bigger hump first, your question is moot.

Re:The feature C++ REALLY needs. (1)

TheRealMindChild (743925) | more than 5 years ago | (#28988313)

That is sort of the point... you now CAN'T have a compliant C++0x compiler for DOS... or anything else that doesn't mesh with these new "additions"

Re:The feature C++ REALLY needs. (0)

Anonymous Coward | more than 5 years ago | (#28988367)

Sure you could. The complexity would be greater though as you'd have to create (and maintain) a runtime environment along with that compiler in order to support stuff like threading. My guess is that there would simply not be enough demand for DOS support to justify the effort required. Anyone doing anything is DOS these days is likely to be doing embedded work, and the vast majority of people who have moved beyond the limits of what DOS can do have already moved to Linux or some proprietary platform or other.

Re:The feature C++ REALLY needs. (1)

Desler (1608317) | more than 5 years ago | (#28988563)

That is sort of the point... you now CAN'T have a compliant C++0x compiler for DOS...

IT doesn't really matter since no one is going to create one anyway. Your entire scenario is completely moot.

Re:The feature C++ REALLY needs. (1)

thetoadwarrior (1268702) | more than 5 years ago | (#28988869)

OH NOES, there goes my new DOS project.

Re:The feature C++ REALLY needs. (1)

gnud (934243) | more than 5 years ago | (#28988823)

Well, any c++0x runtime library for DOS would now have to do its own threads. Not impossible - but it makes it less likely any DOS c++0x compiler will emerge.

Re:The feature C++ REALLY needs. (1)

betterunixthanunix (980855) | more than 5 years ago | (#28988353)

You might as well have made the same argument about a standardize iostreams library -- after all, what about platforms that use record based IO?

Nothing will work on 100% of platforms. For platforms that have no multithreading support, the code should just enter an error state (or throw an exception) if an attempt to spawn a new thread is made. For platforms that have unusual thread models...too bad, find a way to make those models fit into what the C++ standard calls for, or just don't support that particular feature and throw an exception when a program tries to use it. The C++ standard is meant to work for the general case, and the general case is neither DOS nor protothreads.

Re:The feature C++ REALLY needs. (1)

tepples (727027) | more than 5 years ago | (#28989041)

You might as well have made the same argument about a standardize iostreams library -- after all, what about platforms that use record based IO?

Each line of a text file is a record. In most popular operating systems for workstations and servers, the record separator '\n' becomes a fixed sequence of bytes when it is written to a text file (e.g. {0x0D, 0x0A} on Windows or {0x0A} on *Linux, *BSD, or Mac OS X or {0x0D} on ProDOS or classic Mac OS). In others, each record starts with a length in bytes (e.g. non-stream text files in VMS or STR# resources in classic Mac OS). Or are you talking about systems where all records of all files are fixed-length?

Re:The feature C++ REALLY needs. (0)

Anonymous Coward | more than 5 years ago | (#28988391)

>bazaar threading mechanisms

do you buy them at the souk?

or would that be too bizarre?

Re:The feature C++ REALLY needs. (2, Informative)

Anonymous Coward | more than 5 years ago | (#28988637)

Qt 4.5 has been released LGPL. As long as you link to the Qt's dynamic libraries, you can completely close the rest of your app. Qt has become the standard cross-platform GUI framework for C++.

Re:The feature C++ REALLY needs. (1)

Fujisawa Sensei (207127) | more than 5 years ago | (#28988867)

If C++ had a set of GUI libraries that were part of the standard and could be counted on to be in every compiler... Hate to bust your bubble there sonny, but the new C++ specification has ALL SORTS of crap that won't translate to a lot of platforms. For instance, multithreading will be built into the language... but what about something like DOS where there is no threads? Or something that uses bazaar threading mechanisms like protothreads/contiki?

What about the Altair 8800? We have to make sure the new C++ spec supports it too!

Re:The feature C++ REALLY needs. (1)

Palshife (60519) | more than 5 years ago | (#28989055)

Your DOS C++ runtime would need to support threads. I imagine you'd have to write a scheduler that ran them sequentially rather than concurrently. Your performance wouldn't be as good as it would be on a multitasking OS, but that's sort of the point.

At any rate, it doesn't mean that you can't implement the language, it just means that the language can't teach your OS new tricks.

Re:The feature C++ REALLY needs. (1)

GooberToo (74388) | more than 5 years ago | (#28989065)

but what about something like DOS where there is no threads?

Hate to burst your bubble, but threads can be supported on DOS. I've even created thread implementations on DOS. Now then, exactly how threads workand their exact implementation details may or may not come as a surprise, but threads can be implemented on DOS.

Re:The feature C++ REALLY needs. (2, Insightful)

betterunixthanunix (980855) | more than 5 years ago | (#28988231)

The main reason for not making GUI part of the standard is that there are already plenty of GUI libraries for C++, and nobody on the standards committee will be able to agree on which one should be used. This is in contrast with, say, file-based IO, which is implemented in roughly the same way on all platforms.

There are plenty of features that I would say are a lot more important than a GUI framework. A standard way to convert C style FILE pointers into an iostream would be a great feature, one that several vendors already implement as extensions. Even a standard way to open a network connection and represent it as an iostream would be a good thing to have, with the heavy focus on network applications these days. Also, move allocators out of the template argument list for containers, and representing them as class members instead -- if ever there was a perfect case for preferring composition, it is this. Also, improved i18n/l10n support (C++ is better than C in this regard, but there is a lot that remains to be done).

Re:The feature C++ REALLY needs. (0)

superdana (1211758) | more than 5 years ago | (#28988547)

If any one feature could ensure the continuation of C++ as a language

I see what you did there.

Re:The feature C++ REALLY needs. (5, Insightful)

MikeBabcock (65886) | more than 5 years ago | (#28988619)

What on earth does a GUI have to do with a language? A GUI belongs in the C++ specification about as much as Java belongs in the kernel.

Each has its place and is used when necessary and shouldn't be forced into a place it doesn't belong for convenience.

Re:The feature C++ REALLY needs. (1)

Trepidity (597) | more than 5 years ago | (#28989123)

There's a trend towards language platforms, rather than merely languages, which has some pros and cons. I do think that, for example, it'd be nice if C++ had network sockets in the standard library. Yes, it's strictly speaking an OS feature, but it's close enough to standardized that you can provide a portable abstraction layer in the standard library, which would simplify a lot of things. I agree, though, that a GUI is probably not really in that category.

C+++=1 (0)

Anonymous Coward | more than 5 years ago | (#28988095)

Stupid name, it should be

C+++=1
or is equiv
C+=2

C++0X is a syntax error!

Maybe the vendors don't want C++... (-1, Troll)

tjstork (137384) | more than 5 years ago | (#28988193)

I would be willing to bet that some vendors that make more than one language are probably not too crazy about doing more with an open language like C++. Not that I would make any association with a large software vendor founded in the 1970s that leveraged a pretty good BASIC interpreter into operating system and tools dominance... but

Concepts are not too different from the way generics work in C#. If garbage collection and concepts had found their way into C++, one wonders how much the pendulum might have shifted back towards C++ from other languages, since C++ is really the only major language with a real standards process behind it...

as it is, I think C++ is pretty much dead as it is, and its' probably going to have to be up to gcc to just grab the bull by the horns and implement new features by fiat and create a defacto standard.

Re:Maybe the vendors don't want C++... (3, Informative)

beuges (613130) | more than 5 years ago | (#28988317)

Do you realise that most of the guts of Windows is actually written in C++? And that the secretary of the C++ Standards Committe, Herb Sutter, works for Microsoft?
Are you even a C++ developer at all?

Re:Maybe the vendors don't want C++... (1)

oldhack (1037484) | more than 5 years ago | (#28988693)

Yeah, legacy is a bitch.

Re:Maybe the vendors don't want C++... (0)

Anonymous Coward | more than 5 years ago | (#28988825)

They wouldn't be continuing to actively develop Visual C++ and implement new C++0x features if they were going to drop C++.

Re:Maybe the vendors don't want C++... (2, Interesting)

Desler (1608317) | more than 5 years ago | (#28988333)

I would be willing to bet that some vendors that make more than one language are probably not too crazy about doing more with an open language like C++. Not that I would make any association with a large software vendor founded in the 1970s that leveraged a pretty good BASIC interpreter into operating system and tools dominance... but

Yeah, Microsoft is so uninterested in C++ that for the Visual C++ 2010 release that they've added in a whole bunch of new features including partial support for this new standard.

Re:Maybe the vendors don't want C++... (1)

Desler (1608317) | more than 5 years ago | (#28988361)

Oh, and that's not even getting to the fact that Microsoft still uses C++ extensively throughout it's products. Yes, clearly that is a sign of a company that isn't crazy about C++ anymore.

Re:Maybe the vendors don't want C++... (1)

Tony Hoyle (11698) | more than 5 years ago | (#28989143)

Yet they released Visual Studio 2008 with a showstopper bug that stopped large C++ projects being compiled (it barfed about being unable to read the pdb file halfway through, then just gave up).

They've made it that unless you #define a load of stuff to switch the crap off or start using proprietary Windows extensions none of your code will compile without warnings.

They deprecated huge chunks of both the C and C++ standards without asking any of the standards committees.

Oh, and they *still* haven't caught up with C99.

Re:Maybe the vendors don't want C++... (2, Insightful)

goose-incarnated (1145029) | more than 5 years ago | (#28988443)

as it is, I think C++ is pretty much dead as it is, and its' probably going to have to be up to gcc to just grab the bull by the horns and implement new features by fiat and create a defacto standard.

Well, that's how it used to be - the standards committee generally checks what all the major implementations implement that isn't specified by the standard, and then try to get the common non-standard parts into the next standard. Basically - see what the industry is doing, and if they all seem to agree then standardise it.

Re:Maybe the vendors don't want C++... (4, Insightful)

godrik (1287354) | more than 5 years ago | (#28988519)

C++ is far from dead in all piece of code that need performances. Intel released a C++ library called TBB to use multi-core architecture a few years ago. They do not believe it is dead. Parallel programming framework such as cilk stoped using C to use C++ to gain templates.

Don't get me wrong, for most task people don't care about the performance provided by a low level language and thus don't need it. It is even harmful to use C++ if you are not going to do it properly.

Re:Maybe the vendors don't want C++... (2, Informative)

Suiggy (1544213) | more than 5 years ago | (#28988599)

And let's not forget Intel C++. Intel hates C++0x so much that they decided to add the following C++0x features in Intel C++ 11.0 which has been available since November 2008: - Empty macro arguments - Variadic macros - Type long long - Trailing comma in enum definition - Concatenation of mixed-width string literals - Extended friend declarations - Use of ">>" to close two template argument lists - Relaxed rules for use of "typename" - Relaxed rules for disambiguation using the "template" keyword - Copy constructor does not need to be callable on direct reference - Binding to class rvalue - "extern template" to suppress instantiation of an entity - "auto" type specifier - decltype operator - static_assert - compliant __func__ - lambda expressions

Uncluttered article (print = easy to read) (4, Informative)

noidentity (188756) | more than 5 years ago | (#28988269)

Uncluttered article [devx.com] , without any extra crap and multiple pages. Printable = readable.

Dynamic allocation and data types. (1)

Eravnrekaree (467752) | more than 5 years ago | (#28988413)

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 of the tie() interface on Perl, that whenever an object goes out of scope or something is stored into it, a callback is triggered where a plugin can handle the desired features. This would allow greater flexibility. These objects would be aware of the data type of the data stored in them, like ASCII or binary integer. If it were used in an arithmatic operation, a certain callback could be triggered provided by the objects controller object, which could convert the value from ASCII into binary required by arithmatic operator. Perhaps even a seperate set of string operators should be considered as well.

Re:Dynamic allocation and data types. (1)

Desler (1608317) | more than 5 years ago | (#28988633)

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

The future 10 years ago! [wikipedia.org]

Concepts aren't enough! (5, Funny)

Stuntmonkey (557875) | more than 5 years ago | (#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! (4, Insightful)

shutdown -p now (807394) | more than 5 years ago | (#28988803)

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:Concepts aren't enough! (2, Informative)

cptdondo (59460) | more than 5 years ago | (#28988819)

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.

Re:Concepts aren't enough! (1)

Timothy Brownawell (627747) | more than 5 years ago | (#28988841)

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.

Re:Concepts aren't enough! (1, Funny)

Anonymous Coward | more than 5 years ago | (#28989149)

Pfft, you lack vision. We need a meta-language, where you program what you want programmed.

fnord (snippets) (1)

Timothy Brownawell (627747) | more than 5 years ago | (#28988553)

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 flawed "concepts" part of the standard.

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?

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.

So perhaps the conclusion is that concepts were doomed to fail because they try to fix so many things at once, by transforming C++ into an almost new language? After all, the whole notion of templates is a bit problematic in C++â"what the programmer writes or reads is quite different from the actual (unseen) code that the compiler generates and parses when it processes a template instance.

No. 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. [...] I do not think that templates are "a bit problematic." For starters, they are not macros. Programmers should no more worry about the transformations a compiler performs on template code to produce executable code than they do about the transformations compilers do for non-template code to produce executable code

In March 2009, several months after the acceptance of Concepts into the WD, Howard Hinnant was the first to ask: "What is the risk in requiring Joe Coder to be concept-aware? What is the benefit?" It's surprising that these questions hadn't arisen much earlier during the design process. Doesn't that indicate the committee should have more checks and balances, especially when it comes to adding a new feature that is as pervasive as concepts?

I suspect some members of the committee will seriously resent those questions and consider them proof of ignorance or ill will. [...] The committee operates according to ISO rules. Those are quite ponderous and biased in favor of not upsetting status quo. [...] I don't think we need more formal "checks and balances." If anything, the balance may have tilted too far toward caution for the long-term good of the language.

However, the committee has no similar "field research lab" for core language features. Consequently, pervasive core language features might be incorporated into the WD without sufficient experience and testing. That's what happened with concepts I believe. Would a "staging core C++" organization be feasible and useful?

You are wrong in your characterization of what happened to concepts. In that case, we did have a "staging lab." It was conceptGCC, the people working on concepts (mostly at Indiana and Texas A&M universities), and the people trying to use concepts in libraries (many from Boost).

know I'm going to get a lot of flak for this but I'm starting to sense a Concepts déjà vu with rvalue references. Initially, rvalue references were meant to be transparent for most users but that's no longer the case. Joe Coder will probably have to know what a move constructor is; that function overloading rules have changed;

I object to the "Joe Coder" moniker. At best, it is patronizing. Realistically we are all "Joe Coder" outside our little comfort zones.

It's no secret that I've never been fond of concepts. However, I can understand and perhaps put up with the concept and requires keywords in C++. They seem pretty intuitive. Why do we need concept maps and axioms? To me they look like theoretical academic exercises that complicate the language unnecessarily. Of course they may have some useful applications, but wouldn't it have been better to start with just the bare minimum and extend concepts cautiously?

Sigh! The exercise is not to minimize the number of keywords. The need revolves around the support of generic programming. To be useful, "concepts" must formalize and support current successful practice. To be successful, concepts must completely support current successful practice. Otherwise, we'll get a messy mix of constrained and unconstrained templates. To be successful, concepts must support a quick transition from "conventional unconstrained" template use to "concepts-based constrained" template use. This, by the way, was one reason I raised concerns about "usability" of the pre-Frankfurt concept design.

In your recent DDJ article, you wrote: "'Concepts' were to have been the central new feature in C++0x." Others described them as the "defining feature" of C++0x (N2893). And yet, after the decision to remove concepts, I have the impression that certain committee members downplay their importance in C++0x.

My full quote is: [snip] That's significantly different from the impression you get from just the initial sentence: [...] Also, I personally wouldn't call concepts "the defining feature" because I don't know what it would mean for a single feature to be "defining" for a language. I suspect that for most people, the most important new feature of C++0x is standard support for concurrency.

The "design by committee" approach, which some critiques claim was applied in the case of concepts, is often a recipe for a failure. My favorite example is export [...]. Why not restrict the committee's charter to standardizing existing, proven practice? After all, that's how we got STLâ"and that approach would probably expedite the C++0x standardization process.

I doubt that many would have considered STL "existing, proven practice" in 1996. [...] If you think you have a quick and/or simple alternative to "design by committee" that does not involve either significant funding or corporate control, you are almost certainly wrong. In WG21, we try to minimize the effects of "design by committee" by having most design done by individuals "off line" and leaving larger groups to "polish" the resulting designs. Sometimes, that works. John Spicer mentioned export in Frankfurt and so did I (and soâ"I suspectâ"did others). It is a popular source of examples of all kind of things. However, I do not see a way to derive a single simple morality tale from that. I mentioned export as a lesson not to try to straddle a pair of technical alternatives, but for the need to make clear design decisions.

The last sentence is very interesting. [...] I presume that lesson from both cases is that such compromises aren't successful. Is that correct?

Yes, the mistake with export was to create a compromise design that supported both the inclusion model and the separate compilation model of template instantiation. Please note that (contrary to your question and to what many people believe) variants of both models were in industrial use.

Programmers constantly complain that badly-needed features (garbage collection, reflection, GUI) never make it into C++, whereas too much emphasis is put on features that seem academic and esoteric. Is C++ at a dead-end as some of these commenters claim?

One problem is that there is no agreement as to what constitutes a "badly-needed feature" and some of the loudest voices are in no mood to discuss: They think they know. I'm personally in favor of some suitable flavor of GC, and C++0x does provide a GC ABI. Sadly, I have no hope for a standard GUI because there are too many proprietary ones out there, and too many powerful organizations prefer their own GUI as a lock-in mechanism over any potential standard. My suspicion is that "academic and esoteric" is usually just FUD meaning "something I don't have in some other language that I like." I remember when class hierarchies and virtual functions were popular targets for such claims. There has never been a shortage of claims that C++ was a dead endâ"often by people busily imitating it.

Let's talk about the future. What's going to happen now? Will concepts be added by hook or by crook to the language (say in the form of a Technical Report), or has the time come to shelve concepts for now and focus on features that Joe and Siddhartha Coders would like to see in C++? Has the removal of concepts set a precedent for further radical changes in the WD?

Wow, that's quite a set of leading/biased questions. [...] I don't see further major changes coming along for this round of standardization. C++0x will deliver major improvements to the C++ community, and some parts are already available from GCC, Microsoft, and others. It will feel like a new language. [...] Secondly, C++ simply cannot follow every fad. To be useful, it must evolve slowly and compatibly. [...] Thirdly, many people will try to find a good and proper way to get conceptsâ"in some form or otherâ"into C++. Nobody plans to get concepts "by hook or by crook;" that's not the way C++ standardization works.

So overall, you're optimistic about the future of C++?

As ever, I'm cautiously optimistic. [...] I'm quite happy to see C++ "just" support a few million programmers well, and dominate large areas of software infrastructure and advanced applications development.

Concepts and design by contract (1)

afidel (530433) | more than 5 years ago | (#28988683)

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 (4, Insightful)

Logic and Reason (952833) | more than 5 years ago | (#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 (4, Interesting)

Animats (122034) | more than 5 years ago | (#28989075)

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.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?