Что толку в Ада если Ариан 5 все равно упал - Философия программирования

Здравствуйте, faulx, Вы писали:

ПК>>Ну, все-таки use cases анализировать надо... Если use case для некоторой языковой возможности не находится, то я слабо представляю, как ее можно спроектировать так, чтоб она в итоге оказалась удобной в использовании. <...>

F>Когда "use case" возникнет, может быть уже поздно. Вспоминается в связи с этим история с утилитой make. (Ссылку сейчас не найду). Автор изначальной версии make написал ее "на коленке" для друзей. Он спешил, и поэтому принял простое решение — использовать символы табуляции для обозначения начала команд (синтаксис Makefile'ов все знают и, надеюсь, понимают, о чем идет речь). Буквально через несколько дней он избавился от этого "хака" — но было уже поздно. Пользователи (их было не больше десятка) уже успели написать Makefile'ы с табуляциями и поленились переписывать их.

Это пример, как раз подтверждающий нежелательность введения возможностей "чтоб были". Когда/если появятся веские основания для введения семантики возобновления, ничто не помешает ее ввести в том виде, каком она нужна будет для поддержки как раз тех use cases. А вот если бы семантику возобновления ввели "чтоб была", то получился бы как раз случай с табуляциями: в том виде, как надо переделать нельзя, т.к. могут быть случаи использования в том виде, как уже есть.

F>Что касается конкретной темы обсуждения, то речь о той странной ситуации, когда "use cases" из какого-либо языка программирования рассматриваются как аксиомы для совсем другого языка программирования. При этом совершенно неизвестно, насколько правильны и всеобъемлющи эти "use cases".

Можно по-другому посмотреть: use cases просто не нашлись. Даже в других языках.

F>PS. А все-таки, неужели это правда, что в C++ могли быть Лисповские condition'ы?

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

Сергей Губанов wrote:

> FR> Мое мнение этот тест подстава, реально он не выполняет работу для
> которой предназначен.
> Нет-нет, как раз смысл теста drystone в проверке способности
> компилятора распутывать запутанный код.
> Попробуйте распутать код вручную, там (кажется) должен получится
> просто пустой цикл.

Я вроде бы тут приводил результаты тестов dhrystone на IntelC++ — он
вигрывал у XDS, причем значительно.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Posted via RSDN NNTP Server 1.9

Здравствуйте, eao197, Вы писали:

E>Сторонникам Lisp-а просьба не обижаться

E>Просто слишком часто в последнее время про него говорят в неизменно превосходной форме.

А никто, как я вижу, и не обижается. Ни разу не встречал священной войны "C++ vs. Lisp". Как-то они мирно уживаются.

Беда C++ в том, что на него наезжает слишком много народу, который не слишком-то умеет/хочет его применять. Странная позиция, но что поделать! Lisp же, не будучи мэйнстримовым языком, в такой переплёт не попал. Хотя, и на мой взгляд, он куда как гибче C++ во многих отношениях, и уж тем более, гибче чем Oberon/Java/.Net/прочие наследники Algol и C.

... << RSDN@Home 1.1.4 beta 3 rev. 185>>

Здравствуйте, FR, Вы писали:

VD>>Ну, почему же? В области типобезопасности действительно C#, Java, Oberon, Ada, а в области метапрограммирования ему противопоставляются R#, Java Syntactic Extender... и как раз ФЯ с мощьными препроцессорами вроде Lisp-а или Ocaml-а.

FR>Угу семеро на одного.

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

... << RSDN@Home 1.1.4 beta 3 rev. 185>>

Здравствуйте, AVC, Вы писали:

ГВ>>Это много кто говорил.

Собственно, C++ как раз этой парадигме соответствует: вместо конкретных решений даётся инструмент создания решений. Т.е., варианты применения продуманы "до" и выведена некая более или менее общая языковая основа. Что не так?

AVC>Да все не так.
AVC>Не было продумывания "до", а был язык Си, Страуструпу ничем не обязанный.
AVC>Или его он тоже продумал "до" его создания?
Тут я с VladD2 согласен — совместимость с C — это была важная вещь во время создания C++. Но он даже самим Страуструпом не позиционировался, как "расширение C", но выставляется как другой язык.

ГВ>>Да, он применим где угодно. Вопрос только в конечной цене применения.
AVC>Насчет цены. За годы с 1998 по 2002 годы число ЧП, вызванных ненадежностью ПО, выросло в 20 раз.
А насколько выросло число программистов? А в какой примерно период времени появился фразеологизм "индусский код"? Спрашивается — при чём тут C++?

AVC>>>В Обероне (и других модульных языках) единица инкапсуляции не класс, а модуль.
AVC>>>Это существенно влияет на проектные решения.
AVC>>>Множественное наследование в Обероне просто не нужно (и рассматривается как вредное).
ГВ>>ИМХО — это глобальная парадигматическая ошибка. В ДНК.
AVC>В разных местах на RSDN я говорил, что Си++программисты все объясняют двумя причинами: "кривыми ручками" и "ошибками в ДНК".
AVC>Вот очередное подтверждение.
К сожалению, почти все неадекватности ПО (читай — ошибки) объясняются двумя вещами — кривизной рук и/или мозгов. "Ошибка в ДНК" — это просто оборот такой. Устойчивый.

AVC>>>Модули позволяют естественно реализовывать целые паттерны проектирования.
AVC>>>Множественное наследование в Си++ — заплата на отсутствии нормальных модулей.
AVC>>>Вот и пишут на Си++ программы, обращаясь сразу к "человеку и пароходу". (c) Маяковский
ГВ>>Э... высокая риторика, спору нет. Слог хорош! Кратко напоминаю содержание предыдущих серий: динамическое приведение типов в Обероне эффективно работает отчасти из-за строго одиночного наследования.
AVC>А еще в Обероне есть модульность, которой нет в Си++.
AVC>И поэтому нет кентавров.
Надо смотреть конкретные примеры. "Модульность" на C++ обычно достигается не то, чтобы легко, а очень легко. Основные сложности не в отсутсвии ключевого слова module, а в сложностях, связанных с жизненными циклами, согласованием интерфейсов и т.п.

AVC>>>>>Опять-таки оптимизатор может устранить некоторые лишние проверки.
ГВ>>>>Здесь согласен. Хотя я бы не стал полагаться на оптимизатор...
AVC>>>В руководстве по компилятору XDS (в разделе об оптимизации) говорится:
AVC>>>

AVC>>>It is possible not to turn run-time checks off in the product versions of your programs,
AVC>>>because the code generator usually removes redundant checks. A typical
AVC>>>program runs only 10-15% faster with all run-time checks turned off (but the code
AVC>>>size is usually significantly smaller).

AVC>>>Здесь указана цена проверок: программа на 10-15% медленнее.
AVC>>>Разница в размере кода больше.

ГВ>>Ключевая фраза вот эта: "A typical program". Можно это загадочное определение раскрыть полнее? Почему цепляюсь — потому что уже где-то слышал про эти пресловутые 10-15%, вот и стало интересно.

AVC>Вопрос разумный.
AVC>Если Вы не доверяете данным Excelsior (XDS),
Если судить по соседней ветке с обсуждением drystone, то не доверяю.

AVC>то надо заниматься измерениями самостоятельно.
Не хочу.

AVC>Найду время — "погоняю" разные программы, откомпилированные с разными опциями.
AVC>Пока что лично у меня получалось, что при полной оптимизации XDS (90-х годов) в три раза крыл Visual C++ 6.0.
Конкретику, плз. На каких конкретно тестах?

AVC>Предположим, в "нетипичном" случае на проверки уйдет не 10-15%, а 20-30%. Это принципиально?
В некотором роде — да.

ГВ>>>>>>Средствами C++ можно обойти type safety. Разумность такого решения — отдельный вопрос. Если голова на плечах есть — всмё будет в порядке, если с этим проблема, то runtime проверками дела не поправишь. Приведённый пример с NASA свидетельствует, скорее, не о бенефитах типобезопасности, а о том, что всем в NASA было настолько страшно взять ответственность на себя, что спихнули всё на "неправильную" фичу языка. Т.е., проблема не в языке, а в головах.
AVC>>>>>Согласен, что проблема — в головах.
AVC>>>>>Потому что именно из голов она попадает в языки.

ГВ>>>>В огороде бузина, а в трюме акулы...
AVC>>>Которые съели дядьку в Киеве?

AVC>>>А что, я сказал глупость?
ГВ>>Ага.

AVC>Выбор языка — уже проектное решение.
AVC>Проектные решения, надеюсь, предполагают наличие головы?
AVC>В чем же глупость?
Как эта фраза связана связана с: "Потому что именно из голов она попадает в языки.

" ? Ладно, ладно, не буду докапываться дальше. Я и так всё понял.

AVC>>>Может, я чего не знаю, и Си++ создавался не посредством головы?

ГВ>>И ещё одну.

Потому что попытался применить "передёргивание". Вернее — приведение аргументов на основании одной только лексической аналогии (голова — голова). Забавно, спору нет, но это уже надоедает.

AVC>Ну, тогда "акулы в трюме" — неотразимый аргумент.
AVC>Поздравляю, Вас, Геннадий, с заслуженной победой.
Спасибо, только "акулы в трюме" — суть иллюстрация, приведённая для того, чтобы показать некорректность аргументации. Рад, что тебе понравилось.

AVC>>>>>Забавно читать, что "средствами C++ можно обойти type safety".

AVC>>>>>Где бы найти в Си++ эту самую type safety...
ГВ>>>>Да есть она там, что тут можно сказать...
AVC>>>Ну разве что правду — что ее там нет.
ГВ>>Хм. Всё чудесатее и чудесатее. От повторения тезиса его истинность увеличивается? Не знал.

AVC>Это Вы о своем утверждении, что в Си++ есть (а не может быть при некоторых исключительных обстоятельствах) type safety?

А по моему опыту — её нет в некоторых исключительных ситуациях. Что из этого следует?

AVC>А пока что самые разные источники твердят одно: в программах на Си++ ошибок больше, чем в программах на Си.
Да нет же. C++ вполне себе предполагает type safety, просто её обход — тривиальнейшее занятие (например — static_cast, dynamic_cast, const_cast, c-style-cast-over-void*). Отсюда и стоны о граблях и прочей белиберде. Ну и кто виноват? Кстати, разные же источники утверждают, что "дураков всегда больше". И что теперь?

Или ты предполагаешь, что "наличие type-safety" должно трактоваться как: "typesafe, только typesafe и ничего кроме typesafe"?

Я отношусь к подобным утверждениям проще — возможно или нет. Если возможно, то ответ на вопрос "есть ли X в чём-нибудь?" утвердительный. Если не возможно — то отрицательный. На C++ type-safe программы писать вполне возможно, он прямо апеллирует к такому стилю. Таким образом, в C++ type-safety есть. Её обход — целиком на совести конкретных товарисчей. И неча тут на зеркало пенять.

AVC>Уж если в Си++ есть type safety, то Си, наверное, — просто скала!
Нет, разумеется. C, например, позволяет передавать константные строки как аргумент типа char*, а не только const char*. Посмотри в файл stdio.h — это как раз файл для C. Правда, сейчас уже заголовки почти везде переделаны под C++-стиль, а лет десять назад на Watcom С++ был как раз sprintf(char *, ...);

... << RSDN@Home 1.1.4 beta 3 rev. 185>>

Здравствуйте, AVC, Вы писали:

CX>>Если для тебя так принципиально, чтобы указатель был проинициализирован нулем, обертка с нулевым оверхедом, которая просто при инициализации заносит 0 в инкапсулируемый указатель, пишется за 1 минуту и потом используется сколько угодно раз. Это, кстати, относится все к той же теме — не используй голые указатели, если только это тебе не нужно. Ты же все равно пытаешся их использовать. Вот скажи мне, какая разница для меня как программиста — использовать голый указатель или использовать объект с семантикой указателя, но обладающий дополнительными проверками/иницализацией? Почему нужно обязательно использовать именно голый указатель везде, где только вздумается? Только потому, что такая возможность есть в языке? Топором, например, можно себе ногу отрубить, но ведь нормальный человек никогда не станет этого делать. Откуда же это стремление использовать язык максимально опасным способом?
AVC>Дмитрий, помнишь, как у Чехова?
AVC>Если в первом акте на сцене висит ружье, в последнем оно выстрелит.

Алексей, если бы каждый программист был Чеховым, жизнь была бы прекрасна.

... << RSDN@Home 1.1.4 beta 3 rev. 185>>

Здравствуйте, AVC, Вы писали:

ГВ>>Ключевое слово "Маркетинг".

AVC>Ключевое слово — "вранье" (в данном случае — маркетологов и издателей).
[...]
AVC>(Прошу прощения за, может быть, излишнюю эмоциональность. Но иначе я бы врал.)
Да нет, наоброт. Спасибо за честность.

[...]
AVC>Сам не знаю, зачем я о наболевшем, очевидна ли связь? Просто вранье — везде вранье. Самые страшные беды — от вранья.
AVC>Никакой безопасности (ни ПО, ни в "большом мире") не будет, пока всякие там "маркетологи" будут врать.

У них работа такая. Вот покупаются люди на маркетинг C#, Java и т.п.! А вот C++ как-то без особого маркетинга разошёлся. Ну так, и "Где правда, брат"?

[...]
ГВ>>И когда дело доходит до "простейшего стакана" в коде, то выясняется, что представления о, например, параметре "прочность стенок" находятся у разных людей в разных, иной раз не пересекающихся областях. Всё бы ничего, об этом можно договориться. Но всё становится много хуже, когда под высказыванием "какой-нибудь стакан" подразумевается вполне конкретный набор допусков и ограничений. Ergo, их нужно уметь оговаривать, вот отсюда и "сложности". Вернее — вагоны конструкторской документации на простейшие, казалось бы, вещи.

AVC>Во многом Вы правы.
AVC>Не всегда простое "просто".
AVC>Именно к обсуждению этих вопросов и хочется, наконец, перейти.
AVC>Что мы все "ломаем копья" вокруг явных дефектов Си++?!

Копья мы ломаем вокруг формулировки "дефект" и некорректного использования логики.

AVC>Я не спорю с тем, что в Си++ много интересных идей. Но на базе совместимости с Си никогда не получится надежного языка. А тема legacy code — почти сплошное вранье. Старый код на Си и Си++ (если он действительно ценный, что редко) вполне можно использовать в DLL.

Ну и какое конструктивное обсуждение может получиться, если твой базовый тезис: "С++ — дефективный язык"?

... << RSDN@Home 1.1.4 beta 3 rev. 185>>

Здравствуйте, CrystaX, Вы писали:

CX>Здравствуйте, Gaperton, Вы писали:

G>>А что делать — приходится шапками закидвать — с Лиспом или Диланом вы почему-то тягаться отказываетесь принципиально

. И что интересно, даже про "низкую производительность" в этот раз никто не вспомнил — сразу кверху лапками.

CX>Хмм... Нежелание спорить на очевидные темы — не есть признак слабости. Как и обвинение в слабости не есть признак силы.

Респект, сильный ответ

Здравствуйте, Трурль, Вы писали:

AVC>>Если у Вас дойдут руки проверить этот пример на Вашем компьютере и на Вашем компиляторе Си++, сообщите мне о результатах, пожалуйста.
AVC>>А то они меня самого смущают (3 раза все-таки!

), но неизменно подтверждаются при запуске drystone.

Т>3 раза — это слишком

. Просто XDS слишком уж оптимизирует — выбрасывает нафиг большую часть кода. Весь смысл теста теряется.

Вот и у меня возникло такое подозрение.
Если это действительно так, то (конечно, хвала оптимизатору XDS) смысл теста действительно теряется.
К чести Excelsior, они никогда не говорили о трехкратном преимуществе.
Это я в январе взял тест, откомпилировал и, по наивности, очень удивился результату.
И, возможно, породил миф.

Здравствуйте, FR, Вы писали:

AVC>>Если у Вас дойдут руки проверить этот пример на Вашем компьютере и на Вашем компиляторе Си++, сообщите мне о результатах, пожалуйста.
AVC>>А то они меня самого смущают (3 раза все-таки!

), но неизменно подтверждаются при запуске drystone.

FR>В общем я посмотрел этот dry.c кошмар какой-то, написан на K&R си, много вещей (типа пустых циклов) которые просто выкидываются современными компиляторами в общем результаты тестирования такие:

FR>XDS:
FR>Dhrystone time for 40000000 passes = 12
FR>This machine benchmarks at 3333333 dhrystones/second

FR>vc6(cl /GX /O2 Dry_c.c):
FR>Dhrystone time for 40000000 passes = 24
FR>This machine benchmarks at 1666666 dhrystones/second

FR>vc7.1(cl /GX /O2 Dry_c.c + #pragma auto_inline(on)):
FR>Dhrystone time for 40000000 passes = 16
FR>This machine benchmarks at 2500000 dhrystones/second

FR>Два раза есть, но мне кажется тест полная подстава, меня очень смущают сообщения которые в процессе компиляции выдает XDS компилятор redundant code eliminated (к тому же внутри циклов). Мое мнение этот тест подстава, реально он не выполняет работу для которой предназначен. Вообще конечно я восхищен умением XDS выкидывать не влияющие на результат куски кода, но для реальных приложений которые все таки что-то считают это не дает преимуществ, что показывает рядом лежащий тест LINPACK на котором XDS уже немного отстает от VC.

Спасибо за то, что потратили время и постарались в этом разобраться.
У меня тоже какие-то сомнения. Может, и правда подстава?

Для LINPACK наши результаты почему-то расходятся.
Вот что получилось у меня для XDS:

LINPACK benchmark, Double precision.
Machine precision: 14 digits.
Array size 200 X 200.
Average rolled and unrolled performance:

Reps Time(s) DGEFA DGESL OVERHEAD KFLOPS
----------------------------------------------------
16 0.55 79.63% 0.00% 20.37% 50589.767
32 0.83 86.59% 7.32% 6.10% 56502.857
64 1.42 80.85% 0.00% 19.15% 76328.421
128 2.75 63.97% 8.09% 27.94% 88790.204
256 5.61 71.71% 6.49% 21.80% 80197.604
512 11.09 94.08% 1.55% 4.37% 66296.686
1024 22.29 91.39% 2.27% 6.34% 67355.123
2048 44.49 80.93% 5.31% 13.76% 73294.572

А вот что для Visual C++ 6.0 с оптимизацией (cl /GX /O2 linnew.c + #pragma_inline(on)):

LINPACK benchmark, Double precision.
Machine precision: 15 digits.
Array size 200 X 200.
Average rolled and unrolled performance:

Reps Time(s) DGEFA DGESL OVERHEAD KFLOPS
----------------------------------------------------
8 0.71 100.00% 0.00% 0.00% 15474.178
16 0.77 87.01% 6.49% 6.49% 30518.519
32 1.54 90.26% 3.25% 6.49% 30518.519
64 3.13 92.65% 1.60% 5.75% 29794.350
128 6.26 92.49% 2.56% 4.95% 29543.978
256 12.53 89.70% 3.19% 7.10% 30203.895
512 25.04 91.09% 2.96% 5.95% 29857.608
1024 49.98 90.90% 2.62% 6.48% 30087.577

Это лучший результат Visual C++, который у меня получился.
Уж не знаю почему, но XDS на моем компьютере все время кроет Visual C++ как бык овцу.

Но, пока есть сомнения, не буду на этом настаивать.
Принципиально (для меня) здесь лишь то, что код на Модуле/Обероне (у них в XDS один кодогенератор, хотя разные подсистемы управления динамической памятью) может быть эффективным. (Не зря все-таки Excelsior создал систему программирования для нашего космического ведомства. Эта система программирования и использовалась для написания ПО для "Глонасс-М" и т.д.)

Здравствуйте, AVC, Вы писали:

AVC>Спасибо за то, что потратили время и постарались в этом разобраться.
AVC>У меня тоже какие-то сомнения. Может, и правда подстава?

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

AVC>Для LINPACK наши результаты почему-то расходятся.
---------------------------
AVC>Это лучший результат Visual C++, который у меня получился.
AVC>Уж не знаю почему, но XDS на моем компьютере все время кроет Visual C++ как бык овцу.

AVC>Но, пока есть сомнения, не буду на этом настаивать.

угу с этими тестами просто беда, вот мои результаты:
XDS:

LINPACK benchmark, Double precision.
Machine precision:   14 digits.
Array size  200 X  200.
Average rolled and unrolled performance:

    Reps Time(s) DGEFA   DGESL  OVERHEAD    KFLOPS
----------------------------------------------------
      64   0.54  69.81%  16.98%  13.21% 189161.739
     128   0.98  82.47%   3.09%  14.43% 209673.253
     256   1.95  84.97%   1.55%  13.47% 208417.725
     512   3.84  78.68%   4.74%  16.58% 219594.700
    1024   7.76  78.26%   5.21%  16.54% 217196.630
    2048  16.25  83.16%   3.48%  13.36% 199746.112
    4096  35.05  80.95%   4.96%  14.09% 186813.875
    8192  65.24  82.69%   3.05%  14.26% 201116.706

vc6:

LINPACK benchmark, Double precision.
Machine precision:  15 digits.
Array size 200 X 200.
Average rolled and unrolled performance:

    Reps Time(s) DGEFA   DGESL  OVERHEAD    KFLOPS
----------------------------------------------------
     128   1.00  82.83%   3.99%  13.17%  202053.640
     256   1.99  81.94%   2.51%  15.55%  208896.811
     512   3.97  86.16%   3.77%  10.06%  196684.382
    1024   8.13  82.27%   4.55%  13.18%  199191.690
    2048  16.10  84.51%   3.99%  11.51%  197374.503
    4096  33.19  83.92%   3.43%  12.65%  194031.711
    8192  66.61  84.85%   3.37%  11.78%  191469.190

vc7.1:

LINPACK benchmark, Double precision.
Machine precision:  15 digits.
Array size 200 X 200.
Average rolled and unrolled performance:

    Reps Time(s) DGEFA   DGESL  OVERHEAD    KFLOPS
----------------------------------------------------
     128   0.89  94.39%   2.24%   3.37%  204165.699
     256   1.75  90.30%   2.28%   7.42%  216619.429
     512   3.66  81.34%   7.11%  11.55%  217490.463
    1024   7.43  84.10%   6.59%   9.30%  208679.824
    2048  14.09  85.37%   4.05%  10.59%  223238.881
    4096  28.09  85.34%   4.82%   9.84%  222110.611
    8192  60.02  86.45%   4.25%   9.30%  206674.872

В общем почти одинаковые результаты.

AVC>Принципиально (для меня) здесь лишь то, что код на Модуле/Обероне (у них в XDS один кодогенератор, хотя разные подсистемы управления динамической памятью) может быть эффективным. (Не зря все-таки Excelsior создал систему программирования для нашего космического ведомства. Эта система программирования и использовалась для написания ПО для "Глонасс-М" и т.д.)

Да хороший компилятор.
Хотя я не знаю не сажают ли производительность проверки которые как я понял есть в обероне и нет в модуле.

Здравствуйте, FR, Вы писали:

FR>В общем почти одинаковые результаты.

Мне кажется, что примерно так и должно быть. (В смысле примерного равенства результатов.)
Но что тогда с моим компом?!

AVC>>Принципиально (для меня) здесь лишь то, что код на Модуле/Обероне (у них в XDS один кодогенератор, хотя разные подсистемы управления динамической памятью) может быть эффективным. (Не зря все-таки Excelsior создал систему программирования для нашего космического ведомства. Эта система программирования и использовалась для написания ПО для "Глонасс-М" и т.д.)

FR>Да хороший компилятор.
FR>Хотя я не знаю не сажают ли производительность проверки которые как я понял есть в обероне и нет в модуле.

Действительно, в Обероне есть ряд критических проверок в run-time, связанных с безопасностью типов:
1) проверка указателей и процедурных переменных на NIL при их разыменовании;
2) проверка динамического типа при переходе к более узкому типу;
3) проверка индекса массива при получении доступа к элементу.
Все вместе они (конечно, в совокупности со статическим контролем типов) обеспечивают полную безопасность типов (type safety). Это означает, что переменную можно использовать только в соответствии с ее типом.
Конечно, возникает вопрос о стоимости проверок.
Часть излишних (redudant) проверок может быть устранена оптимизатором, который, например, у XDS довольно сильный.
После чего, по данным XDS, разница в быстродействии составляет 10-15% (по сравнению с полной оптимизацией).
Эти сведения нуждаются в проверке.
При удобном случае я это сделаю. (Собственно, проблема только в том, чтобы выбрать достаточно "репрезентативный" исходник.

)
Кроме того, есть и "бескомпромиссные" компиляторы Оберона/Компонентного Паскаля, не позволяющие отменять такие проверки. Например — BlackBox.
На дне Оберона в ЦЕРН (10 марта 2004 года, кажется здесь (pdf)) приводились данные (кажется, нашим физиком Ткачевым), что BlackBox без особой оптимизации и с проверками не уступает тому же Visual C++ с полной оптимизацией.
Глядя на то, какие результаты показывает на моем компе Visual C++ (хотя он у меня старенький, но ведь и XDS — тоже), я готов поверить и в более "сенсационные" цифры.

Для компиляторов вроде XDS есть возможность полностью отменить проверки. (Конечно, после отладки.)
Есть основания думать (хотя бы на основании результатов тестов XDS), что в таком случае эффективность оберновского кода в принципе не уступает эффективности кода на Си/Си++.
Но я предпочитаю оставлять проверки в коде (следуя "заветам" Хоара

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Это пример, как раз подтверждающий нежелательность введения возможностей "чтоб были".

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

ПК>Когда/если появятся веские основания для введения семантики возобновления, ничто не помешает ее ввести в том виде, каком она нужна будет для поддержки как раз тех use cases.

По-моему, то, что "ничто не помешает" — это иллюзия. Мешает очень многое, и чем дальше, тем больше.

ПК>А вот если бы семантику возобновления ввели "чтоб была", то получился бы как раз случай с табуляциями: в том виде, как надо переделать нельзя, т.к. могут быть случаи использования в том виде, как уже есть.

Если есть случаи использования, зачем убирать?

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

F>>Что касается конкретной темы обсуждения, то речь о той странной ситуации, когда "use cases" из какого-либо языка программирования рассматриваются как аксиомы для совсем другого языка программирования. При этом совершенно неизвестно, насколько правильны и всеобъемлющи эти "use cases".

ПК>Можно по-другому посмотреть: use cases просто не нашлись. Даже в других языках.

Может, плохо искали? И потом, в программах на Ассемблере не так-то просто найти use case, который привел бы к появлению, скажем, Koenig lookup rule в С++

F>>PS. А все-таки, неужели это правда, что в C++ могли быть Лисповские condition'ы?

ПК>Я не настолько разбираюсь в Лиспе, чтоб подтвердить или опровергнуть данную аналогию, поэтому на эту часть вопроса не отвечаю.

Жаль, это самое интересное, а все остальное — просто болтовня для развлечения. Может, ты просто расскажешь, что они хотели сделать с исключениями (что такое семантика возобновления), а те, кто разбираются в Лиспе, сравнят?

Здравствуйте, faulx, Вы писали:

ПК>>Это пример, как раз подтверждающий нежелательность введения возможностей "чтоб были".

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

Это аналогия. Некорректность ее легко увидеть, если обратить внимание на то, что в случае make-файлов изменения нельзя было сделать, т.к. существовал код пользователей, "завязанный" на использование табуляций. В случае семантики возобновления такой проблемы нет, т.к. существующий код по очевидным причинам ее использовать не может.

ПК>>Когда/если появятся веские основания для введения семантики возобновления, ничто не помешает ее ввести в том виде, каком она нужна будет для поддержки как раз тех use cases.

F>По-моему, то, что "ничто не помешает" — это иллюзия. Мешает очень многое, и чем дальше, тем больше.

Конкретно, что помешает ввести семантику возобновления, если появится такое желание?

ПК>>А вот если бы семантику возобновления ввели "чтоб была", то получился бы как раз случай с табуляциями: в том виде, как надо переделать нельзя, т.к. могут быть случаи использования в том виде, как уже есть.

F>Если есть случаи использования, зачем убирать?

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

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

Это возможность продолжить исполнение в точке, где было выброшено исключение, если в одной из вызывающих функций исключительную ситуацию "исправили". (*)

ПК>>Можно по-другому посмотреть: use cases просто не нашлись. Даже в других языках.

F>Может, плохо искали? И потом, в программах на Ассемблере не так-то просто найти use case, который привел бы к появлению, скажем, Koenig lookup rule в С++

Опять аналогии... Давай ты приведешь конкретные use cases, если о них знаешь, а?

ПК>>Я не настолько разбираюсь в Лиспе, чтоб подтвердить или опровергнуть данную аналогию, поэтому на эту часть вопроса не отвечаю.

F>Жаль, это самое интересное, а все остальное — просто болтовня для развлечения. Может, ты просто расскажешь, что они хотели сделать с исключениями (что такое семантика возобновления), а те, кто разбираются в Лиспе, сравнят?

См. выше (*). Грубо говоря, примерно так:

void copy_file( path const& source, path const& destination )
{
  if ( file_exists( destination ) )
    throw FileExistsException( destination );
  do_copy_file( source, destination );
}

void f()
{
  . . .
  try {
    copy_file( source, destination );
  }
  catch ( FileExistsException& e )
  {
    delete_file( e.path() );
    resume; // в результате этой инструкции управление вернется обратно в функцию copy_file,
            // в точку, где было выброшено исключение
  }
}

При этом можно заметить, что в коде copy_file есть существенно ненадежный момент: т.к. исполнение может возобновиться после throw, то нужно снова проверить, действительно ли исправлена исключительная ситуация:

void copy_file( path const& source, path const& destination )
{
  while ( file_exists( destination ) )
    throw FileExistsException( destination );
  do_copy_file( source, destination );
}

Однако теперь ненадежность "переехала" в другое место: если вызывающая сторона "полагает", что исключительная ситуация исправлена, а с точки зрения copy_file это не так, то мы (неявно) получим "вечный цикл".

Соответственно, вопрос: почему бы вместо этого "спагетти" не сделать происходящее более явным, передав в copy_file некоторый call-back, позволяющий более организованно обработать данную ситуацию?

Здравствуйте, Павел Кузнецов, Вы писали:

F>>По-моему, то, что "ничто не помешает" — это иллюзия. Мешает очень многое, и чем дальше, тем больше.

ПК>Конкретно, что помешает ввести семантику возобновления, если появится такое желание?

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

ПК>Случаев использования нет, т.к. семантику возобновления не вводили. Если бы ввели -- ее могли бы начать использовать в тех местах, где вполне можно без этого обойтись.

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

F>>Может, плохо искали? И потом, в программах на Ассемблере не так-то просто найти use case, который привел бы к появлению, скажем, Koenig lookup rule в С++

ПК>Опять аналогии... Давай ты приведешь конкретные use cases, если о них знаешь, а?

Чуть ниже. Пример из Practical Common Lisp, он же повторяется в Википедии.

ПК>См. выше (*). Грубо говоря, примерно так:
ПК>

ПК>void copy_file( path const& source, path const& destination )
ПК>{
ПК>  if ( file_exists( destination ) )
ПК>    throw FileExistsException( destination );
ПК>  do_copy_file( source, destination );
ПК>}

ПК>void f()
ПК>{
ПК>  . . .
ПК>  try {
ПК>    copy_file( source, destination );
ПК>  }
ПК>  catch ( FileExistsException& e )
ПК>  {
ПК>    delete_file( e.path() );
ПК>    resume; // в результате этой инструкции управление вернется обратно в функцию copy_file,
ПК>            // в точку, где было выброшено исключение
ПК>  }
ПК>}
ПК>

ПК>При этом можно заметить, что в коде copy_file есть существенно ненадежный момент: т.к. исполнение может возобновиться после throw, то нужно снова проверить, действительно ли исправлена исключительная ситуация:
ПК>

ПК>void copy_file( path const& source, path const& destination )
ПК>{
ПК>  while ( file_exists( destination ) )
ПК>    throw FileExistsException( destination );
ПК>  do_copy_file( source, destination );
ПК>}
ПК>

ПК>Однако теперь ненадежность "переехала" в другое место: если вызывающая сторона "полагает", что исключительная ситуация исправлена, а с точки зрения copy_file это не так, то мы (неявно) получим "вечный цикл".

ПК>Соответственно, вопрос: почему бы вместо этого "спагетти" не сделать происходящее более явным, передав в copy_file некоторый call-back, позволяющий более организованно обработать данную ситуацию?

Это действительно похоже на систему condition'ов и restart'ов в Лиспе, только там это, кажется, более упорядочено. Там при бросании исключения (condition'а) можно предоставить несколько способов исправления ситуации (они называются restart'ами, нечто похожее на предложенный callback, только таких сallback'ов может быть несколько, и определяет их функция нижнего уровня). Затем при возобновлении можно указать, какой именно restart выбирать.

Примеры:

1. Функция обработки записей в некотором логе. Иерархия функций следующая: функция log_analyzer получает список логов и анализирует каждый с помощью функции analyze_log. Функция analyze_log открывает файл лога, считывает оттуда записи с помощью функии parse_log_file и возвращает список этих записей, закрыв предварительно файл. Функция parse_log_file считывает строки из файла и обрабатывает каждую строку функцией parse_log_entry, которая возвращает объект, представляющий запись в логе. (Псевдо)графически это выглядит так:

log_analyzer
     |
     +---> analyze_log
               |
               +---> parse_log_file
                           |
                           +---> parse_log_entry

Что делать, если функция самого нижнего уровня, parse_log_entry, не может "распарсить" строку? Вариантов может быть несколько: остановить всю работу, пропустить строку (возможно, выдав предупреждение), вернуть NULL, вернуть специально выделенный объект, попросить пользователя исправить запись и т.д. Даже если в данном конкретном приложении можно ограничиться только одним вариантом, функцию parse_log_entry можно повторно использовать в другом контексте, где нужен другой вариант обработки (возможно, не один, в зависимости от настроек и пожеланий пользователя).

Далее, решение о выборе того или иного варианта обработки надо принимать на достаточно высоком уровне (возможно, на уровне функции log_analyzer). Но тащить на этот уровень детали реализации нижележащих функций — нарушение инкапсуляции, да и попросту некрасиво. Именно здесь-то и помогают restart'ы. Функция parse_log_entry определяет возможные виды возобновления, при возникновении ошибки бросает condition, и ждет, пока кто-нибудь вышестоящий не укажет, что ей делать дальше. Функция log_analyzer может получить список доступных restart'ов и, например, предоставить их выбор пользователю.

2. С помощью той же системы делаются предупреждения. Если по ходу работы функции надо выдать предупреждение, вместо того, чтобы самостоятельно вызывать printf, cout << или MessageBox, можно бросить предупреждение, которое поймает вышестоящая функция, которая уже знает, что делать с этими предупреждениями, а выполнение продолжится, как ни в чем не бывало.

3. Еще пример есть в другой главе, но ее я еще толком не читал и подробно объяснить подробно не смогу.

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

От:	Сергей Губанов	http://sergey-gubanov.livejournal.com/
Дата:	12.07.05 12:26
Оценка:

От:	eao197	http://eao197.blogspot.com
Дата:	12.07.05 12:26
Оценка:	+3

	От:	FR
	Дата:	12.07.05 12:35
	Оценка:

От:	CrystaX	https://crystax.me/
Дата:	12.07.05 12:54
Оценка:	+2

	От:	Трурль
	Дата:	12.07.05 12:55
	Оценка:

	От:	Павел Кузнецов
	Дата:	12.07.05 13:26
	Оценка:	+3

От:	Геннадий Васильев	http://www.livejournal.com/users/gesha_x
Дата:	12.07.05 14:31
Оценка:

От:	Gaperton	http://gaperton.livejournal.com
Дата:	12.07.05 16:17
Оценка:	+2

	От:	faulx
	Дата:	13.07.05 04:02
	Оценка:

	От:	faulx
	Дата:	14.07.05 04:20
	Оценка: