On Monday, July 13th 2009 Concepts were dramatically voted out of C++0x during the C++ standards committee meeting in Frankfurt. This shocking news raises many questions and concerns. Unquestionably, these will be discussed in various forums in coming weeks and months. However, I will try to answer three burning questions here: What led to the failure of Concepts? How will the removal of Concepts affect C++0x? Will Concepts make a comeback in the near future?
The removal of Concepts paves the way to other radical changes. If Concepts could be removed, there's no reason why other "safe" features should become sacred cows. No, I'm not going to name such features but suffice it to say: the Committee Draft has plenty of features that need to be reconsidered or dropped
Вопрос к людям, которые внимательно следят за развитием C++0x: о каких-таких возможностях может идти речь?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Какой смысл добавлять в язык, а не в билиотеку STL, редко используемую возможность, которая нужна только для отладки. Здесь просто нужен нормальный компилятор. А эти костыли — к черту!
Ну так как раз создатели Boost.ConceptCheck и пытались внести концепции как в стандарт, так и в GCC.
И поимели много проблем (что неудивительно, если заглянуть в исходники GCC).
А пытались внести в язык по той простой причине, что пользоваться, как и буст.лямбдой, не особо удобно (страшные макросы) и, как и раньше, не спасает от километровых сообщений об ошибках.
_>Какой смысл добавлять в язык, а не в билиотеку STL, редко используемую возможность, которая нужна только для отладки. Здесь просто нужен нормальный компилятор. А эти костыли — к черту!
Ну, очевидно, потому что оно, как и лямбда, не реализуется по-нормальному на уровне библиотеки.
My personal opinion is that removing Concepts will speed the arrival of conforming C++0x compilers. GCC, for example, has already implemented much of C++0x, so their key developers are no longer faced with the difficult task of turning ConceptGCC into a production compiler, and can concentrate on remaining major features like lambdas.
Although Concepts would have added a lot to C++ and Boost, Concepts would also have presented major migration challenges. I'm thinking that for most Boost libraries, migration to C++0x will now be easier and less disruptive.
We need to focus on the bright side.
Здравствуйте, FR, Вы писали:
FR>Лучше бы вместо концептов сделали аналог D'шных Template Constraints http://www.digitalmars.com/d/2.0/template.html#Constraint FR>Штука гораздо более простая и вполне достаточная для решения тех же проблем что решают концепты.
Сам Уолтер Брайт признает, что они не вполне эквивалентны:
D (constraints) + (static if) + (pragma msg) can do everything that Concepts do but one thing — checking of the template body against the constraint.
Как раз то, за что борются создатели систем программирования с зависимыми типами — чтоб код, не удовлетворяющий ограничениям на тип, не компилировался.
J>Сам Уолтер Брайт признает, что они не вполне эквивалентны:
Так я и не говорю что эквивалентны, но для большинства задач достаточны, и не так сложны.
J>Как раз то, за что борются создатели систем программирования с зависимыми типами — чтоб код, не удовлетворяющий ограничениям на тип, не компилировался.
Это да, концепты шаг туда, но мне кажется что язык для полноценной подержки зависимых типов надо переписывать с нуля.
..."concepts" will not be in C++0x or its standard library. That -- in my opinion -- is a major setback for C++, but not a disaster; and some alternatives were even worse.
As one of the co-authors of the Concepts proposal, this was a particularly sad day for me. Here's my personal take on what happened.
While the Concepts proposal was not perfect (can any extension to C++ really ever be perfect?), it would have provided a very usable and helpful extension to the language, an extension that would drastically reduce the infamous error messages that current users of template libraries are plagued with.
It is a real shame that disagreement over what I viewed as an uncontroversial design point turned into the sticking point. The Concepts proposal included two kinds of Concepts, the normal (explicit) Concepts for which concept maps (think instance declarations in Haskell) specify when a class implements a concept, and auto Concepts, for which the compiler generates concept maps automatically.
It would certainly be more convenient for all concepts to be of the "auto" variety, but a major use of concepts in C++ is to provide a means to disambiguate calls to overloaded function templates, and it turns out to be extremely dangerous (silently erroneous behavior) to use auto Concepts with overloading based on template constraints. For example, the vector class has a constructor template that takes an iterator range. If the iterators are Forward Iterators, then the constructor dispatches to an algorithm that figures out the length of the range and then allocates the vector to the appropriate size before filling it in. If the iterators are Input Iterators, then the constructor dispatches to an algorithm that incrementally resizes the vector as the input range is read in. Now, if auto Concepts are used for iterators, then many input iterators will be mistaken for forward iterators, and the dispatch will go to the wrong algorithm, causing the wrong run-time behavior. (Imagine dispatching to the forward iterator algorithm when the iterator is over an iostream.)
Despite this issue, there was strong opposition against explicit Concepts based on fears regarding their usability. It is unfortunate that this fear remained, even though there are two very useful historical precedents that point to explicit concepts being quite usable. First, the present day coding style of using iterator_traits (and other traits for other abstractions) amounts to the same amount of work by programmers to establish that a class implements a concept. Currently, the programmer has to select the appropriate iterator tag for their new iterator class, which corresponds to choosing which Concept to write a concept map for. Second, Haskell has had explicit type classes for several decades now, and I've never heard complaints from Haskell programmers that writing instance declarations is too much extra typing. Especially because instance declarations (and concept maps) can be parameterized.
Despite these historical precedences, there was a effort late in the process to somehow remove explicit concepts and make the auto concepts safer. But it was really too late for such large changes, and since agreement could not be reached, the whole proposal was pulled.
Oh well, it may be a long time before we reach consensus on the design for Concepts, perhaps we never will. But in the mean time we're going to push forward slowly with a production-quality implementation.
In this post I’ll describe the effort to bring concepts into C++0x and the reasons that effort ultimately failed.
Doug Gregor — это тот самый человек, который героически погрузился в пучины GCC, чтобы родить СonceptGCC — единственная реализация концепций на сегодняшний день.
Думаю, любой, кто видел исходники GCC, оценит безумный объем работы.
Along with an overwhelming majority of committee members, I voted to remove concepts, because I felt that removing them was our best available option both for C++0x and for concepts as a language feature.
Luck in life always exists in the form of an abstract class that cannot be instantiated directly and needs to be inherited by hard work and dedication.
