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

> У паскаля необычайно быстрые компиляторы.

За счет синтаксиса, в основном. Кстати, Turbo Pascal в свое время был признан абсолютным чемпионом по скорости -- 150000 строк в минуту.

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

> http://www.smalltalk.ru/articles/cpp-is-faster.html

Делать выводы о языках на основе 2-х реализаций этих языков - это сильный ход %)

Ну и вот этот перл: "Объясняется это тем, что в C++ виртуальные вызовы происходят косвенным образом через таблицу диспетчеризации виртуальных методов. А, как известно, косвенный вызов является очень дорогостоящим на нынешнем поколении процессоров" - ну просто песТня %) Каким образом делается вызов - не объясняется, и делается ли вызов вообще - неясно. Вполне возможно, что VisualWorks просто заинлайнил методы, поскольку знал классы ообъектов. Этот инлайнинг - отнюдь не бесплатная операция, кстати. Может, поэтому пришлось повторять цикл 10млн раз, а при меньшем числе повторений "быстрый Смолток" сливал за счет оверхэда динамической компиляции (или что там у VWS внутри) %)

>А вот и не факт. При увеличении мощности вычисительной техники растет и объем вычислений.

Тоесть меня глючит и Банши, написаный на Моно, на самом деле у меня не работает. Ведь очевидно, что сложность запуска мп3шек из плейлиста постоянно увеличивается!

>> У паскаля необычайно быстрые компиляторы.

> За счет синтаксиса, в основном

Как мерял? %)

> Кстати, Turbo Pascal в свое время был признан абсолютным чемпионом по скорости

ИМХО, синтаксис - дело десятое, разумная модель раздельной компиляции в BP - вот главное (TurboC приходится парсить кучу заголовочных файлов).

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

Ужос!

int main(int argc, char argv[][]) {
  int i;
  scanf("%d\n", &i);
}

Вопрос на засыпку: куда указывает указатель в этом примере?

>Это только от того что Вы элементарных вещей не понимаете, считаете, что c++ использоваться не может и от непонимания тех кто проводит собеседование.

либастрал тебя подвел

>1 не понимаете ооп, его назначение

фейл

>2 не знаете с++, его отичие от с

фейл

>3 не понимаете принцип работы компилятора и линкера

эпик фейл

садись, тебе незачет

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

>> http://www.smalltalk.ru/articles/cpp-is-faster.html

>Ну и вот этот перл: "Объясняется это тем, что в C++ виртуальные вызовы происходят косвенным образом через таблицу диспетчеризации виртуальных методов. А, как известно, косвенный вызов является очень дорогостоящим на нынешнем поколении процессоров" - ну просто песТня %)

На самом деле неважно какая скорость Smalltalk-овского virtual call'а - даже если он в два раза медленнее. Главное то что в Smalltalk и Objective C виртуальные функции реализованы нормально - т.е это не примитивные массивы укзазателей на функции. ООП предназначено для описания сложной логики, а не для текстурирования полигонов с помощью виртуальных функций.

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

А ты у них поинтересуйся, что они подразумевают под С++. Я тоже был таким пионером, и делел круглые глазки наслушавшимся в нете про невье*бенную рулезность крестов, когда мне говорили, что цпп может и можно будет применить, но только если я очень четко обосную зачем он мне там нужен и не буду применять ексепшены, темплейты, СТЛ(ну и буст ясное дело). Тоесть это такой себе С с классами середины 80тых... Естественно месная пионерия, знакомая с эмбеддом по расказам за пивом от "старших товарищей" или считающая оным программирование какого нибудь банкомата или информационного терминала, который внутри обычно являются простыми лоу-энд компами с вендой этого не понимает...

> Как мерял? %)

Были исследования в середине 90-х. Оказывается, даже не Turbo Pascal, а вообще, Delphi 1.0. Сейчас нашел только следы -- ссылка на то, что Delphi 2.0 давала 120000 строк в минуту. Уже без подтверждений, увы :-(.

> ИМХО, синтаксис - дело десятое, разумная модель раздельной компиляции в BP - вот главное

Дыкть, в Аде, небось, не хуже была.

> TurboC приходится парсить кучу заголовочных файлов

А pch для кого придумали, а?

Речь именно о выигрыше по скорости при прочих равных.

>Вопрос на засыпку: куда указывает указатель в этом примере?

на стек функции main

Там еще ссылка на то, какой язык хочется: http://eao197.narod.ru/better_language/3_bye_cpp.html

Я от себя добавлю еще 2 пункта: совместимый с С и имеющий режим совместимости с С++.

>> У паскаля необычайно быстрые компиляторы. >За счет синтаксиса, в основном. Кстати, Turbo Pascal в свое время был признан абсолютным чемпионом по скорости -- 150000 строк в минуту.

>eugine_kosenko ** (*) (10.09.2008 23:21:31)

На самом деле у паскаля и с классически почему-то разные методы компиляции используются- паскаль транслируется быстро нисходящим методом, сам писал компилер, знаю;) А си-подобные языки восходящим с построением дерева в динамической памяти, в несколько проходов, что само по себе меденнее

ну тот же fpc уже со 2-й версии - двухплоходный, т.к. все движется в сторону оптимизации генерируемого кода, время компиляции уже вторично, хотя все еще важно

>ну тот же fpc уже со 2-й версии - двухплоходный, т.к. все движется в сторону оптимизации генерируемого кода, время компиляции уже вторично, хотя все еще важно

anonymous (*) (10.09.2008 23:57:17)

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

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

anonymous (*) (10.09.2008 22:53:01)

Дезинформация o_0

> Каким образом делается вызов - не объясняется, и делается ли вызов вообще - неясно. Вполне возможно, что

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

Я один заметил, что Sidrian таскает посты из былинного треда на sql.ru с участием Луговского о lisp,embedded,c++?

> На самом деле у паскаля и с классически почему-то разные методы компиляции используются- паскаль транслируется быстро нисходящим методом, сам писал компилер, знаю;) А си-подобные языки восходящим с построением дерева в динамической памяти, в несколько проходов, что само по себе меденнее

На самом деле, все дело в #include.

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

Я Вам сам расскажу:

1) Угребищная система стандартных типов. Зачем в языке 6(или 9 - смотря как считать) целочисленых типа и 2 с плавающей точкой? Нельзя было сделать по одному? Почему их размеры хотя-бы жестко не ограничены, как в точкаНЕТе(вообще удивительно, что .НЕТ и Жава переняли этот брейн демедж с их количеством)? И почему одни типы "равнее" других в вроде как ООП языке(по крайнем мере это одна из заявленых парадигм). Почему я должен подключать какие то левые заголовки с шаблонами что-бы банально проверить, представляет ли переменая НаН, денормализированое значение или бесконечность, вместо вызова num.isNaN()? Потому, что стандартные типы не являются классами. Про абсолютно "магические" имплисит приведения типов из одного в другой я вообще молчу.

2) Говоря о стандартных типах следует конечно же упомянуть о горяче всеми любимом char*, который с какого-то перепугу оказался стандартным типом строковых литералов. Они взаимодействуют с стд::стринг просто феерично. Пример:

string a = "str1"; string b = a + "str2" + "str3"; //работает

string a = "str1"; string b = "str2" + "str3" + a; //не работает

3) Отсутствие рефлексии. Причем ее даже не собираются добавлять и я смотрел видео где Страус лично говорил, что это как раз для экономии памяти.

4) Отсутствие замыканий. Что бы не говорили местные быдлокодеры замыкания частенько нужны. Ну ок, замыкания жрут хип, но почему нельзя было сделать ананимные функции(с запретом на их возврат)? Ну или хотя бы вложеное объявление именованых функция как в Паскале. Тогда бы народ наконец начал юзать стандартные алгоритмы, место ужастиков-фор с итераторами.

Это Вам для разминки списочек...

>На самом деле, все дело в #include. sv75 ** (*) (11.09.2008 0:25:30)

А разве #include не препроцессором обрабатывается? По-моему вообще отдельно Под проходом понимается сколько сам компилятор читает

> В C++ у вас есть выбор. Что в этом плохого?

В том что для большиства здешнего народа это слишком сложно.

>Потому, что стандартные типы не являются классами1) Угребищная система стандартных типов. Зачем в языке 6(или 9 - смотря как считать) целочисленых типа и 2 с плавающей точкой? Нельзя было сделать по одному? Почему их размеры хотя-бы жестко не ограничены, как в точкаНЕТе(вообще удивительно, что .НЕТ и Жава переняли этот брейн демедж с их количеством)? И почему одни типы "равнее" других в вроде как ООП языке(по крайнем мере это одна из заявленых парадигм). Почему я должен подключать какие то левые заголовки с шаблонами что-бы банально проверить, представляет ли переменая НаН, денормализированое значение или бесконечность, вместо вызова num.isNaN()? Потому, что стандартные типы не являются классами. Про абсолютно "магические" имплисит приведения типов из одного в другой я вообще молчу.

Никто не мешает сделать cвои аналоги в виде классов:)

> string a = "str1"; string b = a + "str2" + "str3"; //работает string a = "str1"; string b = "str2" + a + "str2"; //не работает Это Вам для разминки списочек... Sidrian (*) (11.09.2008 0:35:28) <

"str2" это строковая константа- соответственно и "str2"+a не работает, так как не подобрать подходящий метод для операции "+" - "str2" это не объект, а в первом случае он вызывает метод для выражения a + "str2", автоматически преобразуя "str2" в объект с помощью конструктора

Здесь просто нужно понимать

>> В C++ у вас есть выбор. Что в этом плохого?

>В том что для большиства здешнего народа это слишком сложно.

Оба-на! Элита пришлаъ !

>Про абсолютно "магические" имплисит приведения типов из одного в другой я вообще молчу

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

>Никто не мешает сделать cвои аналоги в виде классов:)

Ну хорошо ты хоть смайлик в конце поставил...

>"str2" это строковая константа- соответственно и "str2"+a не работает, так как не подобрать подходящий метод для операции "+" - "str2" это не объект, а в первом случае он вызывает метод для выражения a + "str2", автоматически преобразуя "str2" в объект с помощью конструктора

Спасибо, капитан.

>Здесь просто нужно понимать

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

>Оба-на! Элита пришлаъ !

Оба-на! Быдло заговорило!

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

Совместимость с Ц имела смысл 20 лет назад с маркетинговой точки зрения. Зачем ее оставили в 98 и хотят снова это сделать в 09?

Ах да, правила существуют. Ну давай, асиливай.

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

А что ты за свою никчемную жизнь успел написать?

>Оба-на! Элита пришлаъ !

Хосспидя.... ну уж ты-то не кривлялся бы.... =\

>"str2" это строковая константа- соответственно и "str2"+a не работает, так как не подобрать подходящий метод для операции "+" - "str2" это не объект, а в первом случае он вызывает метод для выражения a + "str2", автоматически преобразуя "str2" в объект с помощью конструктора

>здесь просто нужно понимать

Я не понимаю почему тип строкового литерала отличен от std::string. Этому не может быть никаких объяснений кроме как ФГМ у Страуструпа.

любимое слово быдла - "Быдло". однако.

>ФГМ у Страуструпа

с претензиями такого масштаба ФГМ скорее у вас, тетенька

однако, ты употребил его дважды )

> Часть твоей ругани обусловлена обычным незнанием плюсов (если хочешь -- могу дать ссылку).

О это идея. Предлагаю покидать сюда ссылок на хорошие книжки по плюсам. С кратким комметарием.

Брюс Эккель. Философия C++. Введение в стандартный C++. Второе издание. и продолжение

Брюс Эккель. Философия C++. Том второй: Практическое программирование.

Отзыв об этой книге был примено такой: "после ее прочтения я полюбил C++".

Стивен Дьюхерст. C++ священные знания.

Клево описаны тонкости C++.

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

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

Еще я где-то слышал, что есть процессоры без Memory management Unit, т.е. там нет защиты памяти и выход за границы массива может убить память другого процесса. Может потому и такие требования, чтобы сам интерпретатор защищал от ошибок.

Просто предположение.

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

> А ребята из Trolltech и не знают... > frame (*) (10.09.2008 21:55:34)

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

Вместо SQL, видимо что-то типа циклов, перебирающих строки таблицы написать.

До замены, bash, например, каким-нибудь интерактивным C++ интрепретатором пока не додумались.

Пацаны, SQL не надо заменять плюсами. этого никто не предлагал. C++ лучший язык для широкого круга задач, но без фанатизма. Он только перегружен чуток, т.к. не специализируется на узкой области, потому немного сложнее

>Еще я где-то слышал, что есть процессоры без Memory management Unit, т.е. там нет защиты памяти и выход за границы массива может убить память другого процесса. Может потому и такие требования, чтобы сам интерпретатор защищал от ошибок. Просто предположение. anonymous (*) (11.09.2008 1:37:01)

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

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

А может ты из своего любимого языка программирования выкинешь все арифметические операции и будешь так программировать?

>SQL не надо заменять плюсами

SQL и не возможно заменить по идее, это не язык программирования, а язык манипулирования данными, его можно реализовать на с++ или на чем-то другом

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

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

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

>Не ты чуток не догнал, я тоже тока раза с третьего понял

Теперь понял, спасибо за пояснения! :)

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

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

Да можно, но в C++ средств для этого больше.

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

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

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

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

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

Кроме того, если фронт-энд компилятор генерирует промежуточный код, почему бы не сделать много бэк-эндов, каждый из которых генерирует исполняемый код для определённой платформы. Тут и место для компилятора в код Java-машины нашлось бы. Был бы язык реальной заменой C++, а не монстром, тянущим за собой не везде уместную виртуальную машину.

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

Да, это правда. Только Java в виде апплетов для браузера не получила широкого распространения, а вот флэш - да.

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

Просто неудачный пример с прогресс-баром выбрали. Там проще было бы обойтись не callback-функцией, а передачей адреса static-переменной, содержащей необходимые цифири.

Заменить возможно, см. что-нибудь вроде LINQ

> Просто неудачный пример с прогресс-баром выбрали. Там проще было бы обойтись не callback-функцией, а передачей адреса static-переменной, содержащей необходимые цифири.

И что с этой переменной делать? Смысл задачи в отлавливании момента изменения значения.

>> Просто неудачный пример с прогресс-баром выбрали. Там проще было бы обойтись не callback-функцией, а передачей адреса static-переменной, содержащей необходимые цифири.

>И что с этой переменной делать? Смысл задачи в отлавливании момента изменения значения.

Не понял в чём проблема? callback функция передаётся туда, где рисуют прогрессбар. Так? При перерисовке прогрессбара, он будет вызывать callback и перерисовывать себя, в соответствии с теми данными, которые он получил из callback-функции. Прогрессбар может не вызывать функцию, которая вернёт значение, а самим заглянуть в переменную и увидеть актуальную информацию.

Если смысл именно в отлавливании момента, тогда прогрессбар сам передаёт callback на функцию собственной перерисовки той функции, которая обновляет значение переменной. В таком случае после обновления переменной функция вызовет callback, который перерисует прогрессбар.

Если бы эта переменная была бы настоящим объектом, тогда смысл в передачи callback'ов объекту переменной есть. Но опять таки, а если есть несколько подписчиков, желающих знать об изменении переменной, они все смогут отслеживать изменение переменной? В C++ с объектами простая переменная разрастётся до космических масштабов. В этом и вся соль C++, почему он не всегда пригоден.

Элегантного решением мог бы быть язык, в котором всё является объектом и на событие обновления любого объекта мог бы подписаться любой другой объект.

Но если посмотреть реальности в глаза - делать всё проще так: обновлять прогрессбар через регулярные промежутки времени. Или информировать все объекты об изменениях при каждом обновлении переменной вручную - что обычно и делается в C.

В таком простом примере видна искусственность (костыльность реализации) объектов в C++ и нецелостность языка, т.к. не любая информация является объектом.

>Брюс Эккель. Философия C++. Введение в стандартный C++. Второе издание. и продолжение

>Брюс Эккель. Философия C++. Том второй: Практическое программирование.

Можешь погуглить на тему что господин Эккель сейчас думает про плюсы :)

линк ткни, интересно однака