Здравствуйте, Павел Кузнецов, Вы писали:
ПК>В этом отношении очень интересно добавление generics в C# 2.0 и Java (во втором случае, по-моему, это замерло на стадии проектирования).
Вот только там обработка дженериков ведется компилятором, хотя и лучше интегрирована в язык чем в случае С++ (сказывется меньшее количество неоднозначностей при парсинге), в следствии чего с диагностикой ошибок проблем нет. Но вот к сожалению в Яве жденерики не могут быть использованы для управления вэлью-типами и производительность сильно страдает (боксинг/анбоксинг).
ПК> Уж .Net или Java, как ни крути, от компонентного подхода просто не отделимы.
Именно. Причем применено два разных подхода. В дотнете дженерики поддерживаются рантаймом, а в яве компилятором. В обоих сулчаях никаких проблем.
ПК>Имхо, кардинальная разница с copy-and-paste в том, что в случае шаблонов мы по-прежнему способны вносить изменения в одном месте, в то время как в случае copy-and-paste изменения локализации если и поддаются, то очень слабо.
Да это как минимум намного больший объем кода. А это и лишняя работа, и лишний объем изучаемого кода.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Сложность современных средств разработки ПО
Здравствуйте, Дарней, Вы писали:
Д>Если убрать из языка циклы, то это не значит, что в программе не будет циклов. Они просто будут эмулироваться при помощи других средств. Хотя эта тема тут уже долго обсуждалась.
Ксткти, один в один с ФЯ. Там вместо циклов используется рекурсия.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Так я об этом и пишу.
Убрать из C++ ключевые слова:
- template,
- struct, (достаточно class),
- for/do, (вполне хватит while)
- switch/case/default, (достаточно if)
- break/continue, (по тем же причинам, это же замаскированные goto)
- static_cast/dynamic_cast/reinterprete_cast, (хаватит обычного приведения типов),
- RTTI вместе с typeid/typename
и конечно (под бурные овации) goto
Ну и то, что — язык станет проще — но станет ли проще на нём программировать?
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>В этом отношении очень интересно добавление generics в C# 2.0 и Java (во втором случае, по-моему, это замерло на стадии проектирования). Уж .Net или Java, как ни крути, от компонентного подхода просто не отделимы.
Это очень интересная информация (о C# 2.0), спасибо!
Надо будет посмотреть, как это там реализовано. (Ведь я защищаю Оберон с точки зрения прозрачности, простоты и надежности механизмов его реализации, особенно важных для автономных систем.)
Но, даже если Вы и правы в отношении C# 2.0, обращаю Ваше внимание, как долго шаблоны и компонентное программирование "шли друг другу навстречу". В лучшем случае они изначально были друг другу "ортогональны".
>> Что же касается варианта (2), то я не очень ясно понимаю, что же именно "такое" позволяют делать шаблоны? Автоматизировать операцию "copy-and-paste"?
ПК>Имхо, кардинальная разница с copy-and-paste в том, что в случае шаблонов мы по-прежнему способны вносить изменения в одном месте, в то время как в случае copy-and-paste изменения локализации если и поддаются, то очень слабо.
Здесь я, конечно, согласен. (Именно такую "инкапсуляцию" я и имел в виду, когда написал, что меня может "заносить". К сожалению, переформулировать "пост" поточнее вчера уже не было времени.)
>> Уверяю Вас, что 95% программистов на Си++ не понимают свой код, написанный с применением STL, и, следовательно, не могут быть за него ответственными.
ПК>Благо, мне везет работать с оставшимися 5%
Я охотно верю, что все участники форумов RSDN входят в число этих 5%.
Но по моим наблюдениям (видно я работаю среди сплошных неумех, которые при этом каким-то образом умудряются делать весьма сложные программные комплексы, не прибегая к C#) 90% программистов, пишущих на Си++, пользуются шаблонами лишь эпизодически или не пользуются вовсе. А про тех, кто пользуется, я уже писал.
Отдельная благодарность за информативность и корректность Вашего поста.
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
AVC:
> я защищаю Оберон с точки зрения прозрачности, простоты и надежности механизмов его реализации, особенно важных для автономных систем
> обращаю Ваше внимание, как долго шаблоны и компонентное программирование "шли друг другу навстречу". В лучшем случае они изначально были друг другу "ортогональны".
При этом еще интересно, что в C# (а точнее, в .Net), собственно, и не совсем шаблоны. Даже совсем не шаблоны И имя у них другое — generics.
В этом отношении согласен: если говорить буквально о шаблонах, в том виде, как они приняты в C++, то можно вполне уверенно утверждать, что практическая вероятность пересечения ими границы модуля во время исполнения, фактически, равна нулю. Если, конечно, не добавлять к программе полный компилятор C++, что вряд ли кому-нибудь реально нужно. Особенно учитывая, что область применения компонентного подхода вполне покрывается платформой .Net, которая уже обеспечивает "докомпиляцию" во время исполнения. На эту "докомпиляцию", собственно, и полагаются generics.
В общем, поэтому в C++/CLI (*) шаблоны и generics существуют параллельно — или, в зависимости от взгляда на вещи, ортогонально
(*) C++/CLI — модификация C++ для более тесной интеграции с .Net. CLI — название .Net в терминологии организации ECMA, занимающейся стандартизацией этой платформы.
Posted via RSDN NNTP Server 1.9 gamma
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
VladD2:
> ПК> В этом отношении очень интересно добавление generics в C# 2.0 и Java (во втором случае, по-моему, это замерло на стадии проектирования).
> Во втором случае (Явы) уже вышел релиз. Вэлкам: http://java.sun.com/j2se/1.5.0/download.jsp.
Спасибо, с удовольствием гляну, что у них получилось в результате.
Posted via RSDN NNTP Server 1.9 gamma
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
P.S. Оставил цитату, и не заметил, что ответ не дописал.
> AVC:
>> я защищаю Оберон с точки зрения прозрачности, простоты и надежности механизмов его реализации, особенно важных для автономных систем
Я очень симпатизирую подходу Вирта в отношении проектирования языков (за исключением деталей типа принятого синтаксиса, что здесь совершенно не важно), но, к сожалению, имхо, далеко не (с)только дизайн языка определяет его реальные перспективы. И почему-то я мало верю в оптимизм Вирта в отношении того, что что-то заметно изменится, если сменить язык, на основе которого ведется преподавание в вузах.
Тот же C++, при всех объективных недостатках, обусловленных совместимостью с C, является столь популярным не потому, что его начали преподавать в вузах, а благодаря все той же совместимости с C. А сейчас ситуация такова, что если за новым языком не будет стоять гигант индустрии типа Microsoft или Sun, и, тем более, если язык не будет давать принципиально новых возможностей (к каковым его простоту и даже большую безопасность я относить не склонен), то вряд ли он станет, действительно, популярным.
Posted via RSDN NNTP Server 1.9 gamma
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Чтобы случайно не ввести никого в заблуждение, стоит уточнить, что дженерикам с шаблонами принципиально отличаются в отношении возможностей. Это можно считать их положительной или отрицательной чертой — зависит от точки зрения, — но аналогия далеко не буквальная.
Posted via RSDN NNTP Server 1.9 gamma
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Сергей Губанов, Вы писали: СГ>Теперь, что, собственно, Вирт предлагает. А предлагает он свои обероны.
Ну и что. Оберон — реинкарнация Паскаля. Сделав то же предложение, Вирт получит тот же результат.
И действительно, язык не есть средство разработки (http://www.rsdn.ru/Forum/Message.aspx?mid=883537&only=1
). Если вы согласны, следует сдвинуть фокус внимания именно в сторону системы разработки. Она как, встроена в ОС? Можно там набрать выражение языка и в соседнем окошке получить результат? Компиляция там явно вызывается или этот процесс, как и промежуточные файлы, спрятан?
Я думаю, по сравнению с богатством ЯП, в области IDE есть застой. Для программиста была бы удобной её более тесная интеграция с ОС, так, чтобы функции были first-class citizens в файловой системе, чтобы написанными функциями можно было бы сразу начинать полноценно пользоваться, а не заворачивая их перед этим в графический интерфейс. Средств разработки много, и они для самых разных задач: от конкатенации файлов с помощью copy (это тоже программирование) через БД и SQL к численным методам и графическим интерфейсам. Они как-то поразительно разобщены. Например, как в MS SQL Server загрузить файл в ячейку таблицы стандартными средствами SQL? Или выполнить на записи некоторые вычисления, которые можно задать только в другом ЯП, не проходя через геморрой с компиляцией DLL и под постоянным страхом, что она порушит работающий сервер? Я не знаю. (Я привожу просто пример, ибо у Microsoft больше всех шансов сделать среду более удобной, раз он владеет и ОС, и ЯП.) А например, найти в таблице функцию, применить её к файлу, и результат скормить другой программе, так, чтобы, когда исходный файл меняется, программа получала уведомление? Думаю, на интеграцию всех этих компонентов будет затрачено больше времени, чем собственно на программирование. А ведь это рядовая автоматизация повседневной работы, каких много. Может быть, ОС должна создавать для пользователя более декларативное (в смысле парадигмы программирования) окружение.
Это IMHO более существенный вопрос, чем пережевывание резины с хорошими и плохими ЯП. Тема поднята верная, только ставить на первый план ЯП не совсем верно.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, AVC, Вы писали:
AVC>>Как мне кажется, в других языках дело обстоит также.
VD>Кристись. К примеру, C# 2.0 поддерживает дженерики которые полностью комилируются в промежуточный код (в точности как в Обероне) и могут размещаться в отдельных бинарных модулях. При этом его можно использовать из других модулей. Т.е. на лицо полное непротиворечие идеи модульного и обобщенного программирования.
Кажется, Павел Кузнецов писал, что дженерики и шаблоны все-таки не совсем одно и то же?
Кроме того, что Вы имеете в виду под промежуточным кодом "в точности как в Обероне"? Насколько я понимаю, Оберон-система состоит из модулей (а не stand-alone программ), и каждый модуль представлен объектным, а не промежуточным кодом.
AVC>>Что же касается варианта (2), то я не очень ясно понимаю, что же именно "такое" позволяют делать шаблоны?
VD>Создавать обобщенный код. Другими словами поднимать уровень абстракции, уменьшать объем кода, создавать безопасный (проверяемый во времы компиляции) полиморфный код.
В целом согласен, но почему-то сомневаюсь насчет "уменьшать объем кода".
AVC>>его эффективность — гораздо ниже кода, написанного самим.
VD>Гы. Щаз тебя порвут. VD>По своему опыту скажу, что скорость шаблонного кода не отличается от рукопашного.
Ну, что же, в таком случае предлагаю "порвать" заодно и Кернигана вместе с Пайком. Эти злобные критики Си++ пишут в третьей главе своей книги "Практика программирования":
"Менее понятно, однако, как оценит ослабление контроля над программой и понимания происходящего со стороны программиста, когда размер заимствованного кода становится настолько большим, что отследить все нюансы становится невозможно. STL-версия — это как раз тот самый случай: ее производительность непредсказуема, и нет простых способов с этим разобраться."
Хочу также обратить Ваше драгоценное внимание на время исполнения на 400 MHz Pentium II(c) программ с одинаковым алгоритмом:
на Си — 0.3 сек
на AWK — 2.1 сек
на Java — 9.2 сек
на Си++/STL/deque — 11.2 сек
Конечно, этот случай — из ряда вон, но как же нужно писать "рукопашный" код, что бы он не отличался по эффективности от этого кода STL?
Ведь нарочно не напишешь!
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Чтобы случайно не ввести никого в заблуждение, стоит уточнить, что дженерикам с шаблонами принципиально отличаются в отношении возможностей. Это можно считать их положительной или отрицательной чертой — зависит от точки зрения, — но аналогия далеко не буквальная.
Они аналогичны в том смысле, что исходно предназначены для решения одной и той же проблемы — отсуствия среств обобщенного программирования. В данном случае разница между неми не принципильна. Тем более, что в основном разница состоит в побочных эффектах которые действительно можно трактовать по разному.
Несомненное приемущество у денириков только одно. Они намного проще в использовании.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>В этом отношении согласен: если говорить буквально о шаблонах, в том виде, как они приняты в C++, то можно вполне уверенно утверждать, что практическая вероятность пересечения ими границы модуля во время исполнения, фактически, равна нулю. Если, конечно, не добавлять к программе полный компилятор C++, что вряд ли кому-нибудь реально нужно. Особенно учитывая, что область применения компонентного подхода вполне покрывается платформой .Net, которая уже обеспечивает "докомпиляцию" во время исполнения. На эту "докомпиляцию", собственно, и полагаются generics.
Как всегда, спасибо за интересную информацию.
Я и правда поотстал тут, занимаясь в последнее время исключительно автономными системами.
Причем те системы программирования, которые для них приходится делать, они же и выполняют функции операционной системы. Отчасти поэтому меня и интересует Оберон, ведь он для таких случаев и создавался.
Но пока что пишу Си-компиляторы, ассемблеры и отладчики, и страдаю угрызениями совести, глядя как ребята мучаются с отладкой "прикладного" кода на "железе" и FPGA.
Предполагаю, что "докомпиляция" есть "компиляция на лету" или JIT?
Это очень интересная идея (кажется тема диссертации одного виртовского аспиранта?), но, увы, неприменимая для автономных систем, которыми я занимаюсь, обязанных работать в real-time. (Правда, может быть, я опять тороплюсь с выводами?)
В целом же мне кажется, что большого противоречия между нашими высказываниями нет, если опустить некоторые мои неосторожные формулировки.
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Тот же C++, при всех объективных недостатках, обусловленных совместимостью с C, является столь популярным не потому, что его начали преподавать в вузах, а благодаря все той же совместимости с C. А сейчас ситуация такова, что если за новым языком не будет стоять гигант индустрии типа Microsoft или Sun, и, тем более, если язык не будет давать принципиально новых возможностей (к каковым его простоту и даже большую безопасность я относить не склонен), то вряд ли он станет, действительно, популярным.
Насколько я помню пару интервью, взятых у Вирта, его видение ситуации практически совпадает с Вашим, и на оптимиста он что-то не похож. (Скорее похож на стоика. )
Но простоту и безопасность он, похоже, готов защищать до конца (в чем с ним всегда были согласны все "отцы" структурного программирования: Дейкстра, Хоар и т.д., просто Вирт остался "последним из могикан"), что не так уж удивительно, если вспомнить, что Оберон используется в ряде систем, критических с точки зрения безопасности.
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
AVC>Кроме того, что Вы имеете в виду под промежуточным кодом "в точности как в Обероне"? Насколько я понимаю, Оберон-система состоит из модулей (а не stand-alone программ), и каждый модуль представлен объектным, а не промежуточным кодом.
Промежуточный код — это то что находится в нутри модулей оберона (и дотнета). Разница дотнета и оберона только в том, что модули дотнета не обязаны соотвесвовать каким-то структурным еденицам программы и содержиут полное описание всех типов (мета-информацию).
Компонентность обязательно подразумевает использование независимых физических едениц.
AVC>В целом согласен, но почему-то сомневаюсь насчет "уменьшать объем кода".
Зря сомневаешся. Объем кода уменьшается в любом смысле. В обычном смысле (объем исходного кода) уменьшается потому, что исключается дублирование кода. Так в проектах на дотнете 1.1 я обязан реализовать по отдельной копии класса для каждой типизированной колеекции и создать по отдельной реализации метода для каждого типа аргументов. А с дженериками мне достаточно написать одину реализацию.
С точки зрения объема исполняемого (машинного) кода, то он тоже уменьшается, так как для ссылочных типов код дженерик-типов испльзуется повторно.
Так же уменьшается и объем промежуточного кода (кода из которного и состоят распростроняемые модули (сборки)). Это происходит потому, что даже для вэлью-типов промежуточный код один. Это сокращает объем сборок, т.е. уменьшает размер дистрибутивов.
AVC>Ну, что же, в таком случае предлагаю "порвать" заодно и Кернигана...
Им давно пора не пенсию. Меня вообще сегда удручало защита устаревших технологий.
Обращение же в таких вопросах к "классикам" совершенно не корректно. Мнение даже самых умных людей в этом мире — всего лишь частное мнение отдельных личностей. С истиной оно ничего общего не имеет. Доказательством могут быть только непредвзятые исследования. О непредвзятости же критиков говорить не приходится.
AVC>Хочу также обратить Ваше драгоценное внимание на время исполнения на 400 MHz Pentium II(c) программ с одинаковым алгоритмом:
AVC>
AVC>AVC>на Си — 0.3 сек AVC>на AWK — 2.1 сек AVC>на Java — 9.2 сек AVC>на Си++/STL/deque — 11.2 сек
AVC>Конечно, этот случай — из ряда вон, но как же нужно писать "рукопашный" код, что бы он не отличался по эффективности от этого кода STL? AVC>Ведь нарочно не напишешь!
Мне кажется, что это намеренное введение в заблуждение. Я просто уверен, что алгоритмы не идентичны. В качестве опровержения этогой инсинуации могу привести результаты собственных эксперементов: http://gzip.rsdn.ru/article/devtools/perftest.xml
В частности, советую обратить внимание на результаты теста "Quick Sort (быстрая сортировка)". Там как раз в С++ применялась шаблонная функция.
Что же касается конкретно СТЛ. СТЛ — это всего лишь интерфейс. Он не может быт ни медленным, ни быстрым. Скорость работы СТЛ-кода зависит исключительно от двух факторов:
1. Качество реализации библиотеки.
2. Качество оптимизации компилятора.
Уверяю, вас что на свете имеются довольно качесвенные реализации STL (например StlPort) которые обеспечивают неплохую производительность.
Более того осмелюсь утверждать, что во многих случаях аналогичный код на С будет значительно медленее С++-кода. Например, применение универсльной фукнции сортировки (qsort) значительно проиграет шаблонной реализации из того же StlPort. И произойдет это не по каким-то там шаманским соображениям, а потому что шаблонная реализация будет использоват статический полиморфизм и соптимизирвется намного лучше, чем qsort который вынужден передавать указатель на процедуру сравнения элементов, заниматься приведением типов и т.п.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AVC, Вы писали:
AVC>Предполагаю, что "докомпиляция" есть "компиляция на лету" или JIT?
"Де" — означает обратный. Докомпиляция — означает востановление исходников по бинарным форматам вроде модулей оберона, сборок дотнета или исполняемым файлам Виндовс.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
AVC:
> Я и правда поотстал тут, занимаясь в последнее время исключительно автономными системами. Причем те системы программирования, которые для них приходится делать, они же и выполняют функции операционной системы. Отчасти поэтому меня и интересует Оберон, ведь он для таких случаев и создавался.
Согласен. Когда началось обсуждение Оберона и аналогичных языков, меня очень удивил переход на обсуждение его применения для создания "настольных" систем, GUI и т.п., т.к., имхо, там практически более важно наличие возможности использовать большое количество имеющихся наработок, плюс развитые средства разработки и т.п.
Однако в плане программирования встроенных систем на Обероне мне интересен другой вопрос: насколько я понимаю, такие системы должны тесно взаимодействовать с "железом". А насколько это просто организовать, учитывая, что адресной арифметики и многих других "низкоуровневых" возможностей в Обероне и аналогах нет?
Впрочем, наверное, можно/нужно разделять части на "прикладные" и "системные", с изоляцией работы с железом в последней. Но, снова-таки, я пока не очень понял, как предполагается это реализовывать, если считается, что система будет моноязычной...
> Но пока что пишу Си-компиляторы, ассемблеры и отладчики, и страдаю угрызениями совести, глядя как ребята мучаются с отладкой "прикладного" кода на "железе" и FPGA.
Интересно, что для C вполне возможна организация всевозможных проверок времени исполнения для контроля выхода за границы массивов и т.п. Более того, существовало несколько компиляторов, которые это делали. Идея там достаточно простая: т.к. на самом деле сам язык не требует, чтобы указатели были просто адресами, вполне можно хранить в них информацию о параметрах блока памяти, ассоциированного с каждым указателем.
Фактически, это означает, что указатель будет состоять из трех частей: 1) собственно, адрес; 2) адрес/смещение начала блока; 3) размер блока или адрес/смещение его конца. В "настольных" системах это используется редко (фактически, почти не используется) из-за проблем бинарной совместимости с существующим кодом.
Непосредственно на "железе" это, наверное, тоже использовать будет нельзя, но на эмуляторах, на которых, насколько я это себе представляю, обычно и "обкатываются" встроенные системы, имхо, это вполне возможно.
Плюс, если нужны проверки времени компиляции, то, имхо, вполне адекватным вариантом могло бы быть использование C++, если работать с массивами и т.п. через всевозможные "переходники". Заранее согласен с любыми возражениями относительно того, что это может оказаться сложнее или менее надежно, чем использование "готового" языка типа Ады, Оберона или еще чего-нибудь, предоставляющего эти возможности изначально.
> Предполагаю, что "докомпиляция" есть "компиляция на лету" или JIT?
Ага. Просто не хотелось использовать очередной buzzword, коих последнее время наплодили в особом избытке, каждый раз объявляя очередную революцию
> Это очень интересная идея (кажется тема диссертации одного виртовского аспиранта?), но, увы, неприменимая для автономных систем, которыми я занимаюсь, обязанных работать в real-time. (Правда, может быть, я опять тороплюсь с выводами?)
Я тоже склонен полагать, что встроенным системам JIT и аналоги вряд ли нужны. Более того, у меня есть стойкое ощущение, что и компонентность в трактовке Java/.Net им тоже не слишком нужна. Впрочем, здесь у меня практического опыта нет, только академический интерес.
> В целом же мне кажется, что большого противоречия между нашими высказываниями нет <...>
И вновь мне ничего не остается, кроме как согласиться Да, собственно, вроде, мы и не спорим
Posted via RSDN NNTP Server 1.9 gamma
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, AVC, Вы писали:
AVC>Ну, что же, в таком случае предлагаю "порвать" заодно и Кернигана вместе с Пайком. Эти злобные критики Си++ пишут в третьей главе своей книги "Практика программирования":
Канэчно порвем. Код в студию!
... << RSDN@Home 1.1.4 rev. 185 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, AVC, Вы писали:
AVC>на Си — 0.3 сек AVC>на AWK — 2.1 сек AVC>на Java — 9.2 сек AVC>на Си++/STL/deque — 11.2 сек
AVC>Конечно, этот случай — из ряда вон, но как же нужно писать "рукопашный" код, что бы он не отличался по эффективности от этого кода STL? AVC>Ведь нарочно не напишешь!
Если не ошибаюсь, то там речь шла о построении словаря или о чём-то подобном. Здесь прикол в том, что они использовали довольно медлительную версию STL и, кстати, сами чуть ниже об этом упомянули.
... << RSDN@Home 1.1.3 stable >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Здравствуйте, AVC, Вы писали:
AVC>>на Си — 0.3 сек AVC>>на AWK — 2.1 сек AVC>>на Java — 9.2 сек AVC>>на Си++/STL/deque — 11.2 сек
AVC>>Конечно, этот случай — из ряда вон, но как же нужно писать "рукопашный" код, что бы он не отличался по эффективности от этого кода STL? AVC>>Ведь нарочно не напишешь!
ГВ>Если не ошибаюсь, то там речь шла о построении словаря или о чём-то подобном. Здесь прикол в том, что они использовали довольно медлительную версию STL и, кстати, сами чуть ниже об этом упомянули.
я помню этот тест, там была еще куча приколов.
они юзали std::string, хотя он и нафиг не сдался, если не предполагается активно изменять содержимое строк,
там было много new и delete и в тесте не использовались никакие аллокаторы, понятно, что даже Java будет быстрее.
У многих С++ — программистов получается писать код на С++ не уступающий С. Тут не в языках дело, а в людях. На С тоже немало тормознутых и неоптимальных программ.
(Именно такую "инкапсуляцию" я и имел в виду, когда написал, что меня может "заносить". К сожалению, переформулировать "пост" поточнее вчера уже не было времени.)
В данном случае AVC совершенно прав: я имел в виду именно JIT и аналогичные решения.
