Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

As many of you guys know, concepts, C++'s approach for constraining possible types for a template argument has failed to be included in C++11.

I learned that the D programming language 2.0 has a similar feature for its generic programming. Its solution seems to me quite elegant & simple.

So my question is why C++ cannot use a similar approach.

  • The C++ concept's goal might be bigger than what D's implementation provides?
  • Or C++'s legacy prevents it from adopting such an approach?
  • Or any other?

Thanks for your answers.

p.s. To see some examples of D's generic programming power, please refer to this: http://stackoverflow.com/questions/7300298/metaprogramming-in-c-and-in-d/7303534#7303534

share|improve this question

migrated from stackoverflow.com Sep 12 '11 at 9:01

This question came from our site for professional and enthusiast programmers.

2  
This question should have been migrated to programmers.se. (I voted for that, but 3 votes were for "not constructive"). –  iammilind Sep 12 '11 at 8:38
3  
I think that the question might not be written in the most constructive way, but that there is value on it. I would love someone explaining how D manages concepts, and be able to compare it with the two main approaches that the C++ committee took on concepts before they decided to postpone the feature altogether... If this is to be closed, then it should at the very least be moved to programmers –  David Rodríguez - dribeas Sep 12 '11 at 8:46
2  
@David: I voted for reopen (and then maybe, it can be moved to programmers site) –  Nawaz Sep 12 '11 at 8:49
1  
Agree with David. I see no reason to preemptively say "non constructive" before anyone can even try to construct something. with 0 answers, the "constructiveness" is 0/0 hence indeterminate. –  Emilio Garavaglia Sep 12 '11 at 8:50
1  
@jj1: Can you provide a short explanation on D's approach for those of us that don't know the language? –  David Rodríguez - dribeas Sep 12 '11 at 9:17
show 4 more comments

5 Answers

up vote 8 down vote accepted

The Standard of C++ is a normative document, which sets rules that will remain (mostly unaffected) in the future documents. Therefore the committee has taken a very cautious approach with regard to its updates.

The additions to the standard library were somewhat easy. A number of libraries had been in Boost for a long time: it had been proved they worked.

Additions to core concepts in the language however are much more difficult to experiment with, because it first requires modifying a compiler. A C++03 feature (the export of templates) had been specified without compiler support... the result was horrid. The implementers of the EDG compiler frontend reported it as a massive task (several man years) for very little gain. No other compiler ever tried to implement it. It's not a comfortable situation.

Features like constexpr or static_assert were easy (and already emulated by libraries). Lambdas are quite well understood and implemented in a variety of other languages, there has been extensive research already, so it was mainly a matter of syntax.

On the other hand Concepts were judged too new and untried. They were barely specified in time, there had been no proof of concept... and thus they were rejected, rather than waiting for them (or making a mistake).

Why not following D ? There is no saying that it won't. The committee has encouraged people to rethink from scratch, with no urging deadline, and to try their hands at including them in a compiler to see how they interact with other features in the language. There's notably the question of separating Concepts and Concept Maps: should they be bundled as one or not ?

FYI: There is currently a branch of Clang dedicated to this experimentation, led by Larisse Voufo from the university of Indiana.

share|improve this answer
    
Minor comment: the export keyword was actually a c++98 feature (the original standardisation). The 2003 corrigendum addressed primarily library features. –  ex0du5 Sep 12 '11 at 18:21
    
@ex0du5: Right, the '03 is a minor revision of the C++98 Standard, which mostly concerned corrections. –  Matthieu M. Sep 13 '11 at 7:42
add comment

For the 2011 standard, C++ concepts were what was being worked on, and they were ultimately dropped from that standard, because they weren't "baked enough." Work continues on C++ concepts which may lead to them making it into the next standard. It could be, however, that some folks will work on a proposal for the next standard which is similar to D's template constraints. Whether that happens or not remains to be seen. As far as I know, there was no such proposal for the 2011 standard, so there was no chance for it to make it into that standard regardless of its merits, but what will or won't make it into the next standard is completely unknown at this point.

I'm not aware of any major reason why something similar to D's template constraints could not be implemented for C++, though given that C++ is generally more limited in what it can do at compile time, it might be harder to make them work quite as well as they do in D (though the introduction of stuff like constexpr certainly helps).

So really, I think that the short answer is that there's no technical reason why something similar to D's template constraints couldn't be in C++.

The question is whether such a proposal will be made for the next standard and how it will compare with whatever similar proposals are made (e.g. proposals relating to concepts). Assuming that an acceptable proposal can be made, I would fully expect that something similar to concepts or D's template constraints will make it into the next standard simply because there's a lot of desire for it. The question is whether anyone can come up with a proposal which is solid enough and "baked enough" to be acceptable.

share|improve this answer
add comment

You mean D's template constrains?

As far a I know, C++ concepts had been proposed on behalf of boost::concept. The problem, here, is that boost is a library written for C++03. C++11 has other syntax capabilities that allow to implement certain things in a different way C++03 allows (hence, boost itself can be rewritten taking advantages of the new syntax).

The standard committee dropped concepts because it will had taken too long to specify them (thus delaying again the c++11 approval). They will probably go in the next C++ release.

Meanwhile, D syntax is different then C++ and D itself retain some expression evaluation capabilities at compile time C++ cannot always have without breaking some legacy code (something D dosn't have, having it a shorter history). C++ itself now has static_assert and costexpr, that allows to improve the compile time evaluation capabilities. May be in future will reach a similar level.

share|improve this answer
add comment

Here is a QA with Herb Sutter, he talks about concepts at the 15minutes mark.

http://channel9.msdn.com/Shows/Going+Deep/Herb-Sutter-C-Questions-and-Answers

If you like that, here is another one: http://channel9.msdn.com/Shows/Going+Deep/Conversation-with-Herb-Sutter-Perspectives-on-Modern-C0x11

Now as to your question. Why not the D version? Well why use it? C++ is a very complex and stable language. Each feature needs to be selected extremely carefully, because it usually has to be supported for decades. If you look at the first C++ standard and follow the revisions, there are some deprecated features, but even those have to be still supported. So it makes sense to design concepts to 100% fit C++.

As for why it wasn't included in C++0x. Well because it was huge. The proposal was 100 pages long and very hard to implement. It was decided that this feature needs more time to mature until it is included into the standard.

share|improve this answer
add comment

Quite simply, C++ has a hell of a lot more historical baggage than D. It would be much easier to implement an awful lot of things if it wasn't for the fact that C++ has massive amounts of historical code which must continue to work correctly and as expected. D doesn't have this problem.

share|improve this answer
    
Maybe you just phrased that wrong, but the issue isn't legacy code, the issue is that any new feature will be present in the language for decades and has to be supported. That means that each new feature has to be chosen very very carefully. –  Let_Me_Be Sep 12 '11 at 13:53
    
@Let_Me_Be: Right, the issue is in the legacy code we'll have ten years down the line if we throw in concepts now. –  David Thornley Sep 12 '11 at 14:10
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.