[FYI] The Removal of Concepts From C++0x
От: remark Россия http://www.1024cores.net/
Дата: 20.07.09 11:24
Оценка: 64 (9)

The Removal of Concepts From C++0x

Last updated Jul 17, 2009.

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?


http://www.informit.com/guides/content.aspx?g=cplusplus&seqNum=441


Зато вот недавно видел такую штуку: User-friendly compile errors for templates in C++0x
http://blog.think-async.com/2009/07/user-friendly-compile-errors-for.html
Фактически до некоторой степени замена концептам... Может это и к лучшему...



1024cores — all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[2]: [FYI] The Removal of Concepts From C++0x
От: byleas  
Дата: 21.07.09 18:04
Оценка: :))) :))) :)
Здравствуйте, astral_marine, Вы писали:

_>А мозги у программистов то не резиновые.

Бросьте, в С++ вы не платите за то, что не используете.
Re: [FYI] The Removal of Concepts From C++0x
От: astral_marine  
Дата: 20.07.09 23:03
Оценка: :)

R>The Removal of Concepts From C++0x


Супер! А то уже в C# и Java столько говна подобавляли. Выкинуть теперь не могут. А мозги у программистов то не резиновые.

Вообще уже давно есть реализация концептов: http://www.boost.org/doc/libs/1_39_0/libs/concept_check/concept_check.htm В GCC есть форк с концептами. Но что то не видно желающих их использовать.

Какой смысл добавлять в язык, а не в билиотеку STL, редко используемую возможность, которая нужна только для отладки. Здесь просто нужен нормальный компилятор. А эти костыли — к черту!
Re: [FYI] The Removal of Concepts From C++0x
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 20.07.09 14:15
Оценка:
Здравствуйте, remark, Вы писали:

R>http://www.informit.com/guides/content.aspx?g=cplusplus&seqNum=441


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++.
Re[2]: [FYI] The Removal of Concepts From C++0x
От: jazzer Россия Skype: enerjazzer
Дата: 21.07.09 00:19
Оценка:
Здравствуйте, astral_marine, Вы писали:

_>Вообще уже давно есть реализация концептов: http://www.boost.org/doc/libs/1_39_0/libs/concept_check/concept_check.htm В GCC есть форк с концептами. Но что то не видно желающих их использовать.


Ну так как раз создатели Boost.ConceptCheck и пытались внести концепции как в стандарт, так и в GCC.
И поимели много проблем (что неудивительно, если заглянуть в исходники GCC).
А пытались внести в язык по той простой причине, что пользоваться, как и буст.лямбдой, не особо удобно (страшные макросы) и, как и раньше, не спасает от километровых сообщений об ошибках.

_>Какой смысл добавлять в язык, а не в билиотеку STL, редко используемую возможность, которая нужна только для отладки. Здесь просто нужен нормальный компилятор. А эти костыли — к черту!

Ну, очевидно, потому что оно, как и лямбда, не реализуется по-нормальному на уровне библиотеки.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re: Мнение бустовода
От: jazzer Россия Skype: enerjazzer
Дата: 21.07.09 01:00
Оценка:
Beman Dawes:

http://thread.gmane.org/gmane.comp.lib.boost.devel/191822

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.

jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re: [FYI] The Removal of Concepts From C++0x
От: FR  
Дата: 21.07.09 04:46
Оценка:
Здравствуйте, remark, Вы писали:


R>Зато вот недавно видел такую штуку: User-friendly compile errors for templates in C++0x

R>http://blog.think-async.com/2009/07/user-friendly-compile-errors-for.html
R>Фактически до некоторой степени замена концептам... Может это и к лучшему...

Лучше бы вместо концептов сделали аналог D'шных Template Constraints http://www.digitalmars.com/d/2.0/template.html#Constraint
Штука гораздо более простая и вполне достаточная для решения тех же проблем что решают концепты.
Re[2]: [FYI] The Removal of Concepts From C++0x
От: jazzer Россия Skype: enerjazzer
Дата: 21.07.09 05:28
Оценка:
Здравствуйте, 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.

http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D.announce&amp;article_id=16583

Как раз то, за что борются создатели систем программирования с зависимыми типами — чтоб код, не удовлетворяющий ограничениям на тип, не компилировался.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[3]: [FYI] The Removal of Concepts From C++0x
От: FR  
Дата: 21.07.09 05:45
Оценка:
Здравствуйте, jazzer, Вы писали:


J>Сам Уолтер Брайт признает, что они не вполне эквивалентны:


Так я и не говорю что эквивалентны, но для большинства задач достаточны, и не так сложны.

J>Как раз то, за что борются создатели систем программирования с зависимыми типами — чтоб код, не удовлетворяющий ограничениям на тип, не компилировался.


Это да, концепты шаг туда, но мне кажется что язык для полноценной подержки зависимых типов надо переписывать с нуля.
Re: Статья Бьярне
От: jazzer Россия Skype: enerjazzer
Дата: 22.07.09 23:43
Оценка:
The C++0x "Remove Concepts" Decision
http://www.ddj.com/architect/218600111

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

jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Bjarne Stroustrup DDJ
Re: комментарий Jeremy Siek
От: jazzer Россия Skype: enerjazzer
Дата: 27.07.09 14:37
Оценка:
Здравствуйте, remark, Вы писали:

R>The Removal of Concepts From C++0x


Комментарий одного из авторов концепций, Jeremy Siek:
http://lambda-the-ultimate.org/node/3518#comment-50071

Sad day

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.

jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re: Doug Gregor - What Happened in Frankfurt?
От: jazzer Россия Skype: enerjazzer
Дата: 12.08.09 11:17
Оценка:
Doug Gregor — What Happened in Frankfurt?
http://cpp-next.com/archive/2009/08/what-happened-in-frankfurt/

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.

jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re: [FYI] The Removal of Concepts From C++0x
От: yuriylsh  
Дата: 12.08.09 20:13
Оценка:
Здравствуйте, remark, Вы писали:

Интервью с Bjarne Stroustrup на эту (и не только) тему: http://www.devx.com/cplus/Article/42448/1954?pf=true
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.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.