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

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

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

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

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

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

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

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

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

Спасибо. Я заблуждался.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

По поводу 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++.

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

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

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

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

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

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

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

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

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

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

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

:)

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

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

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

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

Он никогда не слышал о принципе 80/20 ;)

Они себя сами трогают по причине отсутствия женсчин :-D

> Ты бредишь.

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

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

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

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

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

Дактайпинг -- опасная вещь, если ее очень сильно не ограничить специальным образом. Предположим, у типов Т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 -- нет.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

fixed

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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