LINUX.ORG.RU

C++0x: концептов не будет

 ,


0

0

Комитет по стандартизации ISO языка программирования С++ на июльском собрании принял решение отказаться от идеи концептов в новом стандарте. Основных причины две - сомнительная польза от столь существенного нововведения и сырость текущего предложения: за шесть лет разработки авторам так и не удалось определиться с полным и однозначным описанием.

Концепты предполагали дать возможность наложения ограничений на обобщённые типы в шаблонах функций и классов; можно провести аналогию с классами типов из Haskell.

По словам Майкла Вонга, члена комитета по стандартизации C++, пересмотра данного решения стоит ожидать не ранее чем через пять лет. Стоит заметить, что ранее из проекта стандарта была выброшена идея сборщика мусора; причиной была названа излишняя сложность в реализации.

Статья Страуструпа «Simplifying the Use of Concepts»: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2906.pdf

Статья Вонга (часть 1): http://www-949.ibm.com/software/rational/cafe/blogs/cpp-standard/2009/07/20/the-view-or-trip-report-from-the-july-2009-c-standard-meeting

Статья Вонга (часть 2): http://www-949.ibm.com/software/rational/cafe/blogs/cpp-standard/2009/07/20/the-view-or-trip-report-from-the-july-2009-c-standard-meeting-part-2

>>> Подробности

★★★★★

Проверено: Shaman007 ()

> за шесть лет разработки авторам так и не удалось определиться с полным и однозначным описанием.

Что там говорил Проффессор про Страус-трупа?

Переусложненный язычок C++ привел к эпическому фейлу с проектом IBM Taligent.

После чего Apple окончательно и бесповоротно перешла на Objective C, как надмножеству 100% кавайного pure C, а прикладные программисты из Бангалора - на Java.

Bioreactor ★★★★★
()
Ответ на: комментарий от Bioreactor

>После чего Apple окончательно и бесповоротно перешла на Objective C, как надмножеству 100% кавайного pure C

Ещё раз прошу: кроме агиток, посмотри потроха программ. Внезапно ты заметишь, что в потрохах CoreAnimation присутствует C++, что исключения ObjC оборачиваются в std::exception, и многое другое.

Языки эти — для совершенно разных задач. Ты в курсе, надеюсь, что отправка сообщения на ObjC дороже вызова виртуальной функции как минимум на порядок?

Для интерфейса, и всякой коре даты ObjC — то, что доктор прописал, но что-то высокопроизводительное на нём будет писать только конченный отморозок.

adarovsky ★★★★
()
Ответ на: комментарий от fAX

вы думаете те у кого они есть будут вам, да и вообще обществу, их показывать?

acefsm
()
Ответ на: комментарий от Bioreactor

> как надмножеству 100% кавайного pure C

А pure C ни разу не кавайный. По-хорошему, его нужно закопать одновременнно с плюсами.

Manhunt ★★★★★
()
Ответ на: комментарий от adarovsky

Мы это уже обсуждали. Я даже лог приводил.

Carbon - чистый C. MacApp был написан на С++. Только это уже legacy.

Obj-C это 100% pure C. Для C++ это не так.

Никто не мешает разрабатывать критичные участки кода на pure C и оборачивать это в Obj-C.

Мой посыл был - C++ абсолютно не подходит для задач прикладного программирования. И уступает pure C для задач системного программирования.

Вопрос - где ниша С++?

Bioreactor ★★★★★
()
Ответ на: комментарий от Manhunt

На чем тогда разрабытывать ядро Linux (BSD, XNU & etc.)

На ассемблере? Проходили - был такой недоЮНИКС, назывался Coherent.

Bioreactor ★★★★★
()
Ответ на: комментарий от Bioreactor

> На чем тогда разрабытывать ядро Linux

На чем-то вроде Оберона. Чтобы исчерпывающая спецификация языка занимала 15 страниц, а не 550. Чтобы при этом семантика была очевидной и недвусмысленной. Чтобы не тащилось груды legacy дерьма из дремучих 70х.

Manhunt ★★★★★
()
Ответ на: комментарий от Manhunt

Что же тогда не пишут?

--------------------------

По поводу pure С99 + Obj-C. Связка делается очень просто.

$ cat demo.m
#import <objc/Object.h>

// extern int cadder(int);

@interface MyClass : Object
   {
      int i;
   }
   -(void) setI: (int) theI;
   -(int)  getI;
   -(void) adder;
@end

@implementation MyClass
   -(void) setI: (int) theI
   {
      i = theI;
   }
   -(int) getI
   {
     return i;
   }
   -(void) adder
   {
     i = cadder(i);
   }
@end

main()
{
   MyClass *myClass = [[MyClass alloc] init];
   [myClass setI: 42];
   [myClass adder];
   int i = [myClass getI];
   printf("%d \n", i);
}

$ cat cdemo.c
int cadder(int i)
{
    // Все сколь угодно сложное и ресурсоёмкое, для примера:
    return i + 42;
}

$ cc -lobjc -o demo demo.m cdemo.c
$ ./demo
84
$

cadder здесь для примера у меня тривиальна. Может быть что угодно с новым синтаксисом С99. Видно, что синтаксис Obj-С "чище" и понятнее, чем C++.

Bioreactor ★★★★★
()
Ответ на: комментарий от Bioreactor

> Что же тогда не пишут?

Потому, что пишут на Си и C++. Из-за обратной совместимости с имеющейся колоссальной базой кода. Из-за наличия компиляторов, достигающих высокой степени оптимизации (с Си и C++ тут может соревноваться только Фортран). В случае с С++, еще из-за zero overhead, из-за доступности обобщенного и мета- программирования.

Manhunt ★★★★★
()
Ответ на: комментарий от Bioreactor

>Вопрос - где ниша С++?

Везде, где критична скорость, но желателен ОО подход. Например, CoreAnimation. Интерфейс — на С (для совместимости), а потроха плюсовые. В макоси плюса много, просто наружу он не выставляется.

>Мой посыл был - C++ абсолютно не подходит для задач прикладного программирования

хреновый посыл, если честно. C++ не подходит для задач, где требуются динамические свойства языка. Троллям пришлось для этого делать "нашлёпки" на C++ в виде сигналов и слотов, а в Cocoa те же задачи решаются через делегаты и KVO, что гибче и удобнее.

Обработка сцен в игре, обсчёт видимости/невидимости (см. BSP и прочее) — вполне себе прикладная задача, но делать это на ObjC будет только укурок :)

adarovsky ★★★★
()

Из ямы с Сипипи торчит труп страуса, вяло зарывающем самого себя... - вот он, концепт! :)

Просто поражаюсь тупорылости этого комитета - без сборщика мусора сам язык превращается в мусор! И так этот сипипи - не самый изящный язык.

Короче, чем глубже сипипи, тем легче переходить на D. :)

matumba ★★★★★
()
Ответ на: комментарий от funky_dennis

> Первое, что нужно заставить школьников изучить, это - assembler.

:)

Старая как мир поговорка. Хуже неё только билгейтовское "640К достаточно для любых программ" :)

matumba ★★★★★
()
Ответ на: комментарий от JackyTreehorn

> Ты бредишь.

Обоснуй. С чем конкретно ты не согласен?

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

Причем тут новые компиляторы?

Manhunt ★★★★★
()
Ответ на: комментарий от Manhunt

С тем, что придется переписывать гигабайты кода. Я сам работаю с легаси-проектом, и никто там ничего переписывать не собирается ради того, чтобы переползти на более новую версию компилятора.

JackyTreehorn
()
Ответ на: комментарий от r

> В то время как народ бороздит моря дактайпинга реализуя в статических языках в виде структурных типов....

Дактайпинг -- опасная вещь, если ее очень сильно не ограничить специальным образом. Предположим, у типов Т1 и Т2 реализован bool operator<(T,T). Однако у Т1 он "обычный", а у Т2 при некоторых a,b (a<b)==false и (a>b)==false, но при этом транзитивный a>b && b>c => a>c (В качестве такого оператора м.б. например отношение включения множеств или наследования классов). Тогда у Т1 можно определить min(a,b) как a<b?a:b, а у Т2 -- нет.

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от JackyTreehorn

> для этого делать "нашлёпки" на C++ в виде сигналов и слотов, а в

чего действительно не хватает, так это Reflection/RTTI 
мы с этими мудрарями из комитета&Страустрапом это обсуждали, 
но они эту вешч задвинули на следующий этап.
Как только будет Reflection/RTTI, сигналы/слоты появяться автоматически 
в любом коде (в юности сам такое написал)

Valeriy_Onuchin ★★
()
Ответ на: комментарий от impfp

>Я про такой компилер который в себе реализует к.-л. вероятностную грамматику языка со словарями, знаниями и прочими лингвистическими плюшками...

А результат компиляции получается в зависимости от образования компилятора и понимания им написанного кода.

gena2x ★★★
()
Ответ на: комментарий от funky_dennis

struct B
{
char arr[0x80000];
int c;
};

int main()
{
B * b = NULL;
int a = b->c;//сегфолт необязателен
}

legolegs ★★★★★
()
Ответ на: комментарий от mannaz

>> разработчики Qt Software нахардкодили много random-мусора в Qt4... :)

>Фигня. Qt высок.

это вообще-то шутка была :)

только про "Qt высок" я не понял, что Вы имели в виду?

shty ★★★★★
()
Ответ на: комментарий от www_linux_org_ru

>Дактайпинг -- опасная вещь, если ее очень сильно не ограничить специальным образом.

Ага и этот ограничиель называется "статическая типизация".

r ★★★★★
()
Ответ на: комментарий от www_linux_org_ru

>Дактайпинг -- опасная вещь

переходить утром дорогу - тоже опасная вещь, однако все (многие?) делаем это каждое утро....

>[...] Тогда у Т1 можно определить min(a,b) как a<b?a:b, а у Т2 по-другому.

fixed

не вполне понял что Вы хотели своим примером сказать, что не надо безмозгло шлёпать код - так это и так понятно должно быть, не?

shty ★★★★★
()
Ответ на: комментарий от r

>> Дактайпинг -- опасная вещь, если ее очень сильно не ограничить специальным образом.

> Ага и этот ограничиель называется "статическая типизация".

Статический дактайпинг - это вывод типов // К.О.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

>Статический дактайпинг - это вывод типов

Не обязательно. Я ж показывал эквивалентные примеры на камле и скале - на камле с инференсом, на скале с минифестацией структуры. Просто тип сравнивается не на "same || subclass", а на структурное соотвтетствие.

r ★★★★★
()

Очень-очень жаль, что не будет. Без концептов писать на метопрограммировании что-то большое и сложноструктурированное очень тяжело. А практически - невозможно.

На мой взгляд метапрограммирование времени компиляции сейчас уже устарело. Инжиниринг байт-кода в той же Java справляется с этими задачами куда более эффективно. И, самое важное, в run-time. Единственный минус - не такие мощные оптимизации, как в статическом режиме.

Для меня оптимальной была бы иерархическая платформа, ядро которой составляла бы облегченная виртуальная машина типа Java (например, на основе LLVM), с развитыми средствами рефлексии и подгрузки классов (кода), только без обязательного GC и с прямым доступом к памяти как в С/С++.

И вот уже над ней реализовать семейство универсальных языков и DSL, каждый со своей моделью памяти.

Кто что думает по этому поводу?)))

aist1 ★★★
()
Ответ на: комментарий от JackyTreehorn

Мне думается, процентов 80% пишущих здесь каменты не слышали о нём. :)

eRazor ★★★
()
Ответ на: комментарий от funky_dennis

> Объясню на пальцах - сейчас можно не беспокоиться о скорости выполнения участков кода, так как компиляторы стали настолько суровы, что программисты будут скоро не нужны. Можно будет писать прямо словами на своем родном языке :) Компилятор сделает наиболее оптимальный алгоритм выполнения задачи :)

А ты думаешь, как мы на Лиспе пишем? Правда, английскими словами писать приходится, но это исключительно потому, что у меня на ноутбуке русских букав нету :(

mv ★★★★★
()
Ответ на: комментарий от aist1

> На мой взгляд метапрограммирование времени компиляции сейчас уже устарело. Инжиниринг байт-кода в той же Java справляется с этими задачами куда более эффективно. И, самое важное, в run-time. Единственный минус - не такие мощные оптимизации, как в статическом режиме.

Класслоадер -- это метапрограммирование для бедных. Где-то на ЛОРе wfrr жаловался на проблемы с реализацией синглтона из-за класслоадера.

Вообще, все что может быть вычислено во время компиляции (в т.ч. поля и методы класса) -- должно быть вычислено именно там. Или в стадии, аналогичной (динамической) линковке (llvm?).

> И, самое важное, в run-time.

Возможности в рантайм создать прокси-класс например и прочие в том же духе нужны только при прототипировании и отладке (не?).

С другой стороны, в хорошем языке должны быть возможности трактовать классы динамически, т.е. должно быть АПИ для создания классов налету типа как в яве, с целью прототипирования и отладки.

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от www_linux_org_ru

Про статику спора нет. Что может - то должно))

Метапрограммирование в рантайме - это возможность изменять структуру программы в зависимости от данных, обрабатываемых ею. Здесь рулит теория колмогоровской сложности. Жаль, что массы о ней не знают.

Из близкого к жизни - это IOC/DI/JMX для создания приложений по конфигурацииям.

Для настольных приложений, где важен быстрый старт, динамическое метапрограммирование не подходит. Но, как вариант, здесь можно использовать псевдодинамическое метапрограммирование, когда результат работы метапрограммы сохраняется для многократного использования.

aist1 ★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.