> Там раздел Background безапелляционно описывает недостатки языка C++, вот бы любителям C++ почитать

Нашел там только один недостаток: C++ feature bloat. С этим они борются, запрещая кое-какие фичи, но это должно делаться директивами компилятору (типа как в Аде).

Кстати callack-и и передача указателя на них активно используются в gtk, так как он именно на чистом с написан.

>>Но в первоначальном посте речь шла о том, что кроме жабы в 90-х ничего, чтоб и ООП, и Гуи, и бесплатно не было.

>Оригинальный AWT честно говоря ужасен.

Были ещё библиотеки:
Borland TurboVision (аналог Ncurses) для DOS;
Borland Java Beans Component Library (JBCL, более функциональная чем AWT);
Андерс Хайлсберг после ухода из Borland в Microsoft изобрёл Windows Foundation Classes (WFC, Java-обёртка для Windows-виджетов). В принципе, их можно было использовать бесплатно, но осторожно. Ж)

Re^4: Страуструп о будущем семантических средств разработки с комментариями

>>И давно там можно делать множественное наследование классов, наследованных от QObject? В 4.1 точно нельзя было.

> Это уже следующий вопрос? Или ты думаешь, что твой вопрос совпадает с тем, который задал Absurd?

Ну я так полагаю, что говоря "в qt" подразумевается "со всеми классами, как чисто c++-ными, так и с qobject-ными расширениями"

Re^2: Страуструп о будущем семантических средств разработки с комментариями

> Если Вы располагаете тестами о реальном значительном превосходстве в скорости компиляции Делфи програм перед их Цшнами аналогами будет очень интересно глянуть.

Какими на..й тестами? Просто тупо запускаешь компиляцию и получаешь бинарь за время, различающееся раз в 30. У паскаля необычайно быстрые компиляторы.

Re^2: Страуструп о будущем семантических средств разработки с комментариями

> Даже на мобильниках со 100 кб памяти используется джава с ооп. Говорит о том что Вы: 1 не понимаете ооп, его назначение, 2 не знаете с++, его отичие от с, 3 не понимаете принцип работы компилятора и линкера.

Джабка там используется исключительно потому что более ни на чём писать не позволяется производителями телефонов. Промах.

>>На C++ я бы либо передал указатель на функцию,

>Обнослять прогресс-бар будет метод класса-окна содежащего прогресс-бар. В контексте свободной функции нету нужной ссылки.

Я бы *в своем языке на основе С* все это ООП делал в виде обычных функций (а не так, как в плюсах). Это еще имело бы такие преимущества, как некостыльная реализация множественной диспетчеризации.

>Возьмем более популярную задачу - пользовательский интерфейс. Задача великолепно решается специализированными средствами, например, тиклем или XML. Или SQL. Каким боком тут можно использовать С++ в качестве языка предметной области?

А ребята из Trolltech и не знают...

>>Плюсовое ООП для гуйков подходит слабо - виртуальными функциями C++ для создания хандлеров типа onPaint или onMouseMove не пользуется никто.

>http://doc.trolltech.com/4.2/qwidget.html , перейди в раздел "Protected functions" и узри

А может без сигналов/слотов и moc Qt напишем?

Пример: Eclipse и OpenOfice.

Сборка Eclipse из исходников (eclipse-sourceBuild-srcIncluded-3.3.2.zip, 89.8МБ) занимает где-то 15...20 минут.

Сборка OpenOffice из исходников (OOo_OOH680_m17_source.tar.bz2, 273.2МБ) занимает в среднем 5 часов.

Разница в объёме исходников в три раза, а разница времени на сборку — 15 раз.

Ещё: Sun JDK 1.5 из исходников собирался за полтора часа чистого времени. Более новый Sun JDK 1.6 собирается гораздо быстрее — 30...40 минут. Видимо, появились оптимизации в схеме сборки и опциях компиляции.

> В кресты изначально заложены трейдофы в расчете на производительность, который с современным уровнем развития техники являются абсолютно излишними.

Список или ссылку в студию (тема интересная).

>В C++ это не так, в зависимости от контекста семантика у одной конструкции может быть разной.

А еще в Си можно придумать такие макросы, дальнейший онанизм с которыми ни к чему, кроме туннельного эффекта не приведет (на примере gtk3)

>У Зуева, комментарии которого мы здесь типа обсуждаем, есть отличная статья "Редкая профессия", где эти тонкости описаны.

С твоими идейными вдохновителями я не знаком

>Да нет, никакого смысла не имеет шаблоны использовать, можно точно так же как и в чистом с передать указатель void (*)(void* handback, int percentDone),

Самые простая и надежная вещь в С++ - это Си подмножество. Я знал.

>можно ссылку на функцию: void (&)(void* handback, int percentDone)

А это что за хрень? Чем оно отличается от просто указателя?

>Только с++ объектно-ориентированный язык, соответственно и ситуаций с необходимостью передавать callback'и для перерисовки чего-либо должно быть меньше.

Да, давай писать по классу на каждый калбэк.

>Ну я так полагаю, что говоря "в qt" подразумевается "со всеми классами, как чисто c++-ными, так и с qobject-ными расширениями"

Вопрос был "используется ли в Qt множественное наследование". Ответ --- да.

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

Сделали они виртуальное наследование или нет --- хз, не проверял, ибо как-то не нужно было. Обойти необходимость наслодования от двух потомков QObject --- как два пальца об асфальт, даже напрягаться не потребуется. Более того: само наличие такой необходимости как бы намекает на ошибку в проектировании. Имхо.

> Вот ты мне скажи: ты не устал так лажаться? Или проводишь исследование на тему "сколько раз нужно лажануться, чтобы тебе перестали отвечать всерьёз"?

Абсурд часто лажается, но иногда говорит интересные вещи. Если бы он, перед тем как сказать, проверял свои идеи в своем блоге, было бы гораздо лучше.

>Так я вроде не абстрактным эмбедом в вакууме занимаюсь. Вижу кто чем занят у меня на работе и слышу от людей чем занимаются в "конкурирующих фирмах". Да и бывал на собеседованиях, где речь шла о работниках, которые будут писать софт под девайсы где вообще ОС нету Угадай с 3х раз какой язык там предполагалось использовать и куда бы там тебе предложили засунуть кресты?

Sidrian (*) (10.09.2008 17:33:10)

Ну вот сталкивался с программированием под мобильные устройства. В качестве языка применялся чистый с, но при этом в заголовочных файлах был код типа #ifdef cplusplus, то есть там предполагалась совместимость с плюсами и те, кто разрабатывал, не отрицали возможность его применения.

>А может без сигналов/слотов и moc Qt напишем?

А может без макросов Gtk напишем?

Тебя куда-то в сторону ведёт. Не уходи, мне всё ещё весело.

При чём тут "сигналы/слоты и moc", когда там в чистом виде использование тех самых виртуальных методов? Переопределяешь в своём потомке QWidget виртуальный метод paintEvent и поехал рисовать что тебе надо. Класс даже не будет обрабатываться moc-ом (пока сам не добавишь в него сигналы или слоты и не объявишь Q_OBJECT). А перерисовка, мышиные эвенты и всё прочее будет работать.

Ой?

>>Только с++ объектно-ориентированный язык, соответственно и ситуаций с необходимостью передавать callback'и для перерисовки чего-либо должно быть меньше.

> Да, давай писать по классу на каждый калбэк.

Absurd * (*) (10.09.2008 22:05:17)

Зачем же? В нормальных объектно-ориентированных языках(типа Java) для этого применяется наследование и механизм виртуальных функций. Наследуешь свой класс от базового и делаешь свою реализацию виртуального метода, callback не надо передавать.

> Кстати вируальная машина в Java непонятно с какого перепугу взялась, я считаю это чистым маркетингом. Если бы Java не имел этого тяжелого камня на шее, мне кажется он значительно сильнее потеснил бы C++.

Во-первых, Java была запущена, когда JIT существовал только в теории. Во-вторых, не забываем, что изначально Java во многом позиционировалась, как язык апплетов, расширяющих известные браузеры, а для них расширение с помощью виртуальной машины сделать проще. И в-третьих, как следствие во-вторых, так проще обеспечить безопасность приложения -- за счет изоляции его от остальной системы. Это только у MS с его ActiveX виртуальная машина якобы не нужна.

>Неплохо бы еще покурить С++ Coding Conventions для C++ в гугле для общего развития. К примеру они не используют С++ исключения (http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#Exceptions), что подозрительно, т.к STL по моей памяти исключения кидает в некоторых местах. Т.е они не используют STL или бодяжат с ключиками?

Проведу ликбез: текущая реализация исключений в GCC такая говеная по сравнению с борландовской SEH, что отказ многих от исключений в GCC - действие вполне ожидаемое. Вообщем, учи матчасть.

> Использовался в основном Паскаль. На мой взгляд он очень удобен для обучения

Можно спросить, у вас большой опыт преподавания и в каком вузе? Судя по моим наблюдениям, паскаль (в виде дельфи 10-летней давности) в ВУЗе подходит скорее для обучения не-программистов азам алгоримитризации наиболее дубовым способом.

> Реализацию исключений на С в студию!

http://www.di.unipi.it/~nids/docs/longjump_try_trow_catch.shtml

Ы?

>А это что за хрень? Чем оно отличается от просто указателя?

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

> void(U::*)() и void(V::*)() это неприводимые друг к другу типы даже если V унаследован от U.

Че-то не понял. У меня компилится:

class U { public: void f() {} };
class V: public U {};

typedef void (U::*UF)();
typedef void (V::*VF)();

int main(int argc, char** argv) {
UF uf ;
VF vf = uf;
return 0;
}

anonymous (*) (10.09.2008 22:16:29)

И смысла даже с точки зрения производительности и объема занимаемой памяти использовать callback вместо виртуального метода нет- если даже создать класс с виртуальным методом только для того чтобы передать адрес- он будет занимать память для хранения одного адреса-элемент таблицы виртуальных функций, допустим 4 байта, заполняется при вызове конструктора, при передаче коллбека тратится столько же памяти для передачи указателя(те же 4б), значение копируется при вызове функции с колбеком. Тем более если эта функция вызывается в цикле, значение будет копироваться несколько раз, что еще хуже:)

>некостыльная реализация множественной диспетчеризации.

интересное сравнение http://www.smalltalk.ru/articles/cpp-is-faster.html

Колбек применялся для таких целей в чистом си только по той причине что там ооп нету.

>> В кресты изначально заложены трейдофы в расчете на производительность, который с современным уровнем развития техники являются абсолютно излишними.

>Список или ссылку в студию (тема интересная).

например, http://www.smalltalk.ru/articles/cpp-is-faster.html

>>А это что за хрень? Чем оно отличается от просто указателя?

>Ты не понимаешь, чем ссылка отличается от указателя?

Ссылка - это кастрированный указатель, так как нельзя поменять сущность на которую она указывает, сделать null или применить адресную арифметику. В остальном - ничем.

>Тогда скажи, до какой страницы и какую книжку ты прочитал, чтобы в будущем говорить только о том, что ты понимаешь.

Начинаются обвинения в ниасиливании - слив засчитан.

> Написать мутный код можно везде, но на ассемблере каждая конкретная конструкция имеет кристально чистую семантику, почти ни в одной инструкции нет дополнительного контекста, который бы повлиял на семантику. В C++ это не так, в зависимости от контекста семантика у одной конструкции может быть разной. У Зуева, комментарии которого мы здесь типа обсуждаем, есть отличная статья "Редкая профессия", где эти тонкости описаны.

да и Волтер Брайт, который вроде умеет писать компиляторы С++ (тот же Zortech) пришел к тому же выводу, что С++ неудобен и придумал D.

Это ж VC6, эталон С++ с его легендарным ключиком /vmg! А почему не VC5, или BorlandC++?

>> void(U::*)() и void(V::*)() это неприводимые друг к другу типы даже если V унаследован от U.

>Че-то не понял. У меня компилится:

В одном из предыдущих плюсосрачей я написал шаблон для автогенерации каллбэков который обходит косяки С++ указателей на метод, любитель плюсов пообещал упростить предлагаемый шаблон но не смог, tailgunner слинял. Влом копаться на ночь глядя.

boost::function работает AFAIK так: operator() -> virtual call в объект-переходник тип которого сгенерен шаблоном -> вызов через C++ указатель на метод.

Иначе делегат с семантикой значений не пользуясь расширениями С++ не определить 2 my mind.

> Во-первых, Java была запущена, когда JIT существовал только в теории.

извините, не соглашусь. JIT в Java -- это HotSpot VM? А HotSpot VM корнями из Смоллтока и его диалекта Strongtalk http://astares.blogspot.com/2008/09/google-chrome-javascript-and-smalltalk.html

>>можно ссылку на функцию: void (&)(void* handback, int percentDone)

>А это что за хрень? Чем оно отличается от просто указателя?

указатели указывают на объекты в куче, ссылки -- в стеке.

>указатели указывают на объекты в куче, ссылки -- в стеке.

ха

думаешь, картинка в целом с другим компилятором существенно изменится? Я так не думаю. Для всех С++-подобных языков C++/Java/C# были получены примерно похожие результаты.

да можно взять какой-нибудь St/X http://www.smalltalk.ru/2008/07/stx-smalltalkx-541.html , написать под него тесты и проверить. St/X встраиваемый в C, так что поэкспериментировать с вызовами можно довольно широко.

>указатели указывают на объекты в куче, ссылки -- в стеке.

вообще-то это один из возможных случаев

>>>можно ссылку на функцию: void (&)(void* handback, int percentDone)

>>А это что за хрень? Чем оно отличается от просто указателя?

>указатели указывают на объекты в куче, ссылки -- в стеке.

Что мешает объект в куче передать по ссылке если не надо передавать владение или объект в стеке - по указателю если клиент кода не будет удалять это указатель/пользоваться им когда объект выйдет из скопа?

> В одном из предыдущих плюсосрачей я написал шаблон для автогенерации каллбэков который обходит косяки С++ указателей на метод, любитель плюсов пообещал упростить предлагаемый шаблон но не смог, tailgunner слинял. Влом копаться на ночь глядя.

Давай завтра с утра расскажи про косяки. (Кто любитель плюсов - я не знаю, но был случай, твой шаблон я действительно не смог упростить)

Меня именно косяки интересуют.

>Меня именно косяки интересуют.

Такая схема и есть косяк:

operator() -> virtual call в объект-переходник тип которого сгенерен шаблоном -> вызов через C++ указатель на метод.

На codeproject.com местный спорт есть - написать делегат который бы разворачивался в простой __thiscall, не использовал кучу, и был бы стандартен и портируем.

> или объект в стеке - по указателю если клиент кода не будет удалять это указатель/пользоваться им когда объект выйдет из скопа?

ага, куча если и оговорок. Если передавать указатели, то они могут быть откуда угодно, невалидный указатель на объект в стеке. Если передавать ссылки на объекты в стеке, они будут валидными всегда. В итоге не нужны объекты в куче, хватит локальных в стеке (там, где alloca выделяет).

> void(U::*)() и void(V::*)() это неприводимые друг к другу типы даже если V унаследован от U.

Они неприводимые, если V унаследован от U приватно! (не забыл ли ты отнаследовать его публично?)

Таки жду про косяки.

> На codeproject.com местный спорт есть - написать делегат который бы разворачивался в простой __thiscall, не использовал кучу, и был бы стандартен и портируем.

Ссылкой поделись плиз.

>Ссылка - это кастрированный указатель, так как нельзя поменять сущность на которую она указывает, сделать null или применить адресную арифметику. В остальном - ничем.

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

>Если передавать ссылки на объекты в стеке, они будут валидными всегда.

Не будут. Ссылка может быть полем класса, если ее инициализировать в конструкторе. А если инстанс класса к примеру создан в куче, то ссылка легко переживет тот объект на который она указывала при конструировании.

>думаешь, картинка в целом с другим компилятором существенно изменится? Я так не думаю. Для всех С++-подобных языков C++/Java/C# были получены примерно похожие результаты.

написал я когда-то простенький RLE-кодер, так вот: бинарник от VC7 работал в 2.5(!) раза быстрее, чем бинарник от VC6. Посмотрев asm-листинг все прояснилось: VC7 в некоторых местах просто выкинул прологи/эпилоги функций и сделал fastcall/inline, хотя VC6 даже принудительно этого не хотел делать. В тесткейсе плюсов и смолтолка ясно видно, что VC6 затыкается именно на вызовах функций - это очевидно, т.к. явно используется cdecl вместо fastcall, и любой замечающий подобные тонкости человек скажет вам, что очень много вещей зависит от реализации, а не самого языка

>Что мешает объект в куче передать по ссылке

ничто не мешает, просто стек быстрее

>> На codeproject.com местный спорт есть - написать делегат который бы разворачивался в простой __thiscall, не использовал кучу, и был бы стандартен и портируем.

>Ссылкой поделись плиз.

http://www.codeproject.com/KB/cpp/CppDelegateImplementation.aspx http://www.codeproject.com/KB/cpp/FastDelegate.aspx http://www.codeproject.com/KB/cpp/fd.aspx http://www.codeproject.com/KB/cpp/fastdelegate2.aspx http://www.codeproject.com/KB/cpp/ImpossiblyFastCppDelegate.aspx

Ну и тд.

> Ты бы бложек хотя бы с краткими примерами и ссылочками завел что-ли по поводу недостатков плюсов... а я бы читал :-)

http://yosefk.com/c++fqa/defective.html

Пойдет? Вот, кстати, от признанных апологетов:

http://eao197.narod.ru/better_language/1_whats_wrong_with_cpp.html

:-)