Re[23]: Что толку в Ада если Ариан 5 все равно упал
От: CrystaX Россия https://crystax.me/
Дата: 08.07.05 20:45
Оценка: +1
Здравствуйте, AVC, Вы писали:

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

AVC>Хочу предупредить. Оберон может не произвести впечатления на первый взгляд.

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

AVC>По этому поводу я не поленился перепечатать свою любимую китайскую притчу.

[skipped]

Притча красивая.

AVC>Отбирает зерно, отметая мякину — точная характеристика Вирта.

AVC>Большинство же современных "гуру программирования" — всего лишь циркачи, способные разве что удивить парой трюков.
AVC>Но трюки на самом деле не повышают качества программ, а только отвлекают внимание от действительно важных вещей.

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

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


CX>>Да, вот это хотелось бы обсудить.


AVC>Надеюсь, в ближайшее время нам это удастся.
... << RSDN@Home 1.1.4 stable rev. 510>>
Re[16]: Что толку в Ада если Ариан 5 все равно упал
От: VladD2 Российская Империя www.nemerle.org
Дата: 08.07.05 20:48
Оценка: -3
Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Это повседневная реальность:...до языков, которые чаще всего противопоставляются в данном форуме C++ (C#, Java, Оберон, Ада, Delphi).


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

>> Чтобы поймать такую ошибку достаточно написать запрос на R#-е.


ПК>R# здесь отдыхает:


Отдыхают плюсы. Причем чем дальше тем больше. И сознание у людей меняется. Тут вот между делом у нас случился забавный факт. Количество голосов за дотнет превысило количество голосов за С++ http://rsdn.ru/poll/1181.aspx
Автор: csharper
Дата: 20.06.05
Вопрос: Допустим, Вы одинаково хорошо (или одинаково плохо :) ) знаете .NET/C# и C++(с сопутвующим). Вам предлагают работу в обеих направлениях, с одинаковой зарплатой и условиями. Что Вы выберете?
. Раньше такое и представить себе было сложно. И то ли еще будет.

ПК> 1) тянуть только из-за этого его никто в проект не будет;


Ненадо обощать себя со всеми.

ПК> 2) запросы, как я понимаю, писать нелегко,


Ну, ты всегда все понимашь так как нужно чтобы обосновать свое мнение. Запрос пишется довольно просто. Достаточно изучить XPath запустить CodeAnalizer. Потом такой запрос можно вставить в юнит-етст.

ПК> так что для каждой функции их просто-напросто никто писать не будет,


Запрос типовой. Меняй имя типа и радуйся.

>> А можно вообще превратить подобную фигню в диекларативную с ватоматической проверкой при инициализации.


ПК>Вот там как раз и есть "декларативная с автоматической проверкой при инициализации".


Вот "там" как раз есть ужасный копипыст.

>> Ну, и что самое главное в твоем случае я вообще не заметил никакого контроля. Или рассчитывается, что кто-то особо зоркий будет сидеть и сравнивать if-ы с объявлениями переменных?


ПК>Контроль происходит в момент, когда возникла ошибка компиляции по поводу недостающего значения. Этого (для наших целей) достаточно; главное не пропустить само место, где не ожидают нового возвращаемого значения.


Может быть я что-то не понял, но в твоем примере был банальный if. И никакие шаблоны не заставят компилятор проверить, что у этого if-а нужное количество else if-ов содержащее нужные проверки.

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


Пластинка больно заезженная. Это самовнушение уже даже не смешит.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: LSP, ДК, Вирт - поехали...
От: Павел Кузнецов  
Дата: 08.07.05 20:50
Оценка: +1
Сергей Губанов,

> ГВ> Не согласен. В данном случае при проектировании функции диспетчеризации мы используем знание о наборе поступающих сообщений. Если источник сообщений добавит ещё одно-два, то придётся модифицировать клиентский код, который придётся разыскивать через search и т.п.

>
> Нет не придется модифицировать. Все новые сообщения будут просто проигнорированы.

В таком случае нужно проанализировать функцию диспетчеризации, чтобы убедиться, что данный вид новых сообщений можно безопасно игнорировать.
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Re[24]: Что толку в Ада если Ариан 5 все равно упал
От: AVC Россия  
Дата: 08.07.05 21:35
Оценка: 23 (3) :)
Здравствуйте, CrystaX, Вы писали:

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

AVC>>Хочу предупредить. Оберон может не произвести впечатления на первый взгляд.

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


AVC>>По этому поводу я не поленился перепечатать свою любимую китайскую притчу.

CX>[skipped]

CX>Притча красивая.


AVC>>Отбирает зерно, отметая мякину — точная характеристика Вирта.

AVC>>Большинство же современных "гуру программирования" — всего лишь циркачи, способные разве что удивить парой трюков.
AVC>>Но трюки на самом деле не повышают качества программ, а только отвлекают внимание от действительно важных вещей.

CX>Утверждение на грани фола. Вот так и хочется опять вскочить и ринуться в драку. Осталось только уточнить, кто эти самые гуру и какие это трюки, а затем флейм может начаться сначала. Поэтому я тебя очень прошу — не называй имен и не приводи примеры трюков! Драться-то не хочется.


Драться и правда не хочется. Мы и не будем.
Имен называть также не стану.
Хотя мне трудно молча снести заявления о каких-то там потенциальных возможностях Си++ в отношении контроля типов, тогда как каждый из нас знает, что в 99,9% случаев Си++ используется совсем иначе.
Тезис о "возможностях" языка в отношении type safety не выдерживает критики.
Язык должен гарантировать столько type safety, сколько он может, а не заманивать какими-то "возможностями".
Но я вот сижу и молчу.

Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

Хоар
Re[25]: Что толку в Ада если Ариан 5 все равно упал
От: CrystaX Россия https://crystax.me/
Дата: 08.07.05 21:58
Оценка: 1 (1)
Здравствуйте, AVC, Вы писали:

AVC>Драться и правда не хочется. Мы и не будем.

AVC>Имен называть также не стану.
AVC>Хотя мне трудно молча снести заявления о каких-то там потенциальных возможностях Си++ в отношении контроля типов, тогда как каждый из нас знает, что в 99,9% случаев Си++ используется совсем иначе.

Но откуда же это знание взялось-то о 99%? Веришь, я как раз эти возможности C++ и использую (контроль типов). В моем нынешнем проекте эта его возможность используется на полную катушку — семантические проблемы превращаются в синтаксические и поэтому компилятор их не пропускает. Вот ты компиляторы разрабатываешь, а у меня как раз парсер в проекте используется. Сделан на основе template-ов с возможностью отлавливать все несогласованные изменения в грамматике как несоответствия типов. Если хочешь, могу показать, но это уже не в public форум.

AVC>Тезис о "возможностях" языка в отношении type safety не выдерживает критики.

AVC>Язык должен гарантировать столько type safety, сколько он может, а не заманивать какими-то "возможностями".
AVC>Но я вот сижу и молчу.

Да-да, я заметил.
... << RSDN@Home 1.1.4 stable rev. 510>>
Re[17]: Что толку в Ада если Ариан 5 все равно упал
От: Павел Кузнецов  
Дата: 08.07.05 21:58
Оценка:
VladD2,

> ПК>Это повседневная реальность:...до языков, которые чаще всего противопоставляются в данном форуме C++ (C#, Java, Оберон, Ада, Delphi).

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

Тише-тише... Мы ж конкретный пример обсуждаем. Если ты хочешь показать, что проблема решена неудачно, достаточно продемонстрировать, насколько лихо это можно было сделать по-другому. Если хочешь порекламировать C#/R#, давай, сейчас хорошая возможность: я весь — внимание Скажем, пример на OCaml, приведенный Трурль, для меня оказался достаточным, чтобы существенно изменить свое отношение к данному языку.

> ПК> 2) запросы, как я понимаю, писать нелегко,

>
> Ну, ты всегда все понимашь так как нужно чтобы обосновать свое мнение. Запрос пишется довольно просто. Достаточно изучить XPath запустить CodeAnalizer. Потом такой запрос можно вставить в юнит-етст.

Так все-таки, примерчик можно? А то я пока не вполне понимаю, о чем речь идет: мне мерещатся всякие ужасы с достаточно серьезным анализом AST и т.п...

>>> А можно вообще превратить подобную фигню в диекларативную с ватоматической проверкой при инициализации.

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

Гм... По-моему, достаточно близко к минимуму (который мы имели удовольствие наблюдать на примере OCaml). Всего один лишний раз повторяется имя константы, обозначающей выбранный вариант.

> ПК> Контроль происходит в момент, когда возникла ошибка компиляции по поводу недостающего значения. Этого (для наших целей) достаточно; главное не пропустить само место, где не ожидают нового возвращаемого значения.

>
> Может быть я что-то не понял, но в твоем примере был банальный if.

Точно. А перед ним явное указание списка ожидаемых значений, совмещенное с вызовом функции. Вот там-то и зарыта потенциальная ошибка: набор ожидаемых значений не соответствуют реально возвращаемым. Все, что после — ее следствия. Нарушено предусловие последующего блока кода (значение принадлежит определенному набору); когда нарушается предусловие, рассуждать о правильности кода смысла не имеет. В случае приведенного примера соблюдение данного предусловия контролируется компилятором. Определять предусловия своего кода — ответственность программиста.

> И никакие шаблоны не заставят компилятор проверить, что у этого if-а нужное количество else if-ов содержащее нужные проверки.


Это уже несущественно: наличие всех веток тоже не гарантирует правильности обработки. Для меня достаточно того, что ни один вызов функции-члена communicator не может быть случайно сделан так, что будет получено неожиданное значение.
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Re[26]: Что толку в Ада если Ариан 5 все равно упал
От: AVC Россия  
Дата: 08.07.05 22:34
Оценка: 1 (1) +1
Здравствуйте, CrystaX, Вы писали:

AVC>>Драться и правда не хочется. Мы и не будем.

AVC>>Имен называть также не стану.
AVC>>Хотя мне трудно молча снести заявления о каких-то там потенциальных возможностях Си++ в отношении контроля типов, тогда как каждый из нас знает, что в 99,9% случаев Си++ используется совсем иначе.

CX>Но откуда же это знание взялось-то о 99%? Веришь, я как раз эти возможности C++ и использую (контроль типов). В моем нынешнем проекте эта его возможность используется на полную катушку — семантические проблемы превращаются в синтаксические и поэтому компилятор их не пропускает. Вот ты компиляторы разрабатываешь, а у меня как раз парсер в проекте используется. Сделан на основе template-ов с возможностью отлавливать все несогласованные изменения в грамматике как несоответствия типов. Если хочешь, могу показать, но это уже не в public форум.


Мне действительно интересно будет посмотреть.
Конечно я частенько спорю с тобой, но и учусь тоже.
В "новом" Си++ мне следует освоить прежде всего приемы работы с шаблонами.
А насчет 99%... Вряд ли это большое преувеличение. Возможно, этот процент будет понемногу меняться в сторону более осторожного и грамотного использования языка.

AVC>>Тезис о "возможностях" языка в отношении type safety не выдерживает критики.

AVC>>Язык должен гарантировать столько type safety, сколько он может, а не заманивать какими-то "возможностями".
AVC>>Но я вот сижу и молчу.

CX>Да-да, я заметил.


Да это я так... шепотом.
Но заметь, я не говорил, что в Си++ нет таких возможностей, а говорил только о типовом применении Си++.

Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

Хоар
Re[27]: Что толку в Ада если Ариан 5 все равно упал
От: CrystaX Россия https://crystax.me/
Дата: 08.07.05 23:14
Оценка: +2
Здравствуйте, AVC, Вы писали:

AVC>Мне действительно интересно будет посмотреть.


Ок, может тогда пообщаемся в аське? Вышли на e-mail в профиле свой ICQ# или я свой могу выслать.

AVC>Конечно я частенько спорю с тобой, но и учусь тоже.


Я тоже.

AVC>В "новом" Си++ мне следует освоить прежде всего приемы работы с шаблонами.

AVC>А насчет 99%... Вряд ли это большое преувеличение. Возможно, этот процент будет понемногу меняться в сторону более осторожного и грамотного использования языка.

Не буду спорить — большинство C++ программистов использует его очень небезопасным способом, но тут уж ничего не поделаешь. Очень уж C++ сложен. Усилий на его изучение приходится приложить значительно больше, чем на изучение других языков (специально для любителей придраться к формулировке: "других языков" следует читать как "языков, противопоставляемых C++ в этой ветке, а именно C#, Java, Oberon, Ada"). Но зато если уж использовать его самые сильные стороны, все недостатки с лихвой окупаются (это мое частное мнение и я никому его не навязываю).

AVC>>>Но я вот сижу и молчу.


CX>>Да-да, я заметил.


AVC>Да это я так... шепотом.

AVC>Но заметь, я не говорил, что в Си++ нет таких возможностей, а говорил только о типовом применении Си++.

... << RSDN@Home 1.1.4 stable rev. 510>>
Re[28]: Что толку в Ада если Ариан 5 все равно упал
От: VladD2 Российская Империя www.nemerle.org
Дата: 09.07.05 00:58
Оценка: +1 :)
Здравствуйте, CrystaX, Вы писали:

CX>Не буду спорить — большинство C++ программистов использует его очень небезопасным способом, но тут уж ничего не поделаешь.


Вот хоть раз с таким пообщаться. А то как не глянь на форум, так на нем таких нет. А как залезь в код, так там... мам дорогая...
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[27]: Что толку в Ада если Ариан 5 все равно упал
От: Павел Кузнецов  
Дата: 09.07.05 00:59
Оценка: 3 (3) +2
AVC,

> AVC>> Тезис о "возможностях" языка в отношении type safety не выдерживает критики. Язык должен гарантировать столько type safety, сколько он может, а не заманивать какими-то "возможностями".


Это очень верно. К сожалению, при выборе из обсуждаемых языков приходится выбирать между гарантированной type safety и отсутствием "возможностей" и негарантированной type safety и наличием "возможностей". Если бы в каком-либо из обсуждаемых языков было бы и то, и другое в большей мере, чем у альтернативных вариантов, то и обсуждать бы было нечего. Наверное

> Но заметь, я не говорил, что в Си++ нет таких возможностей, а говорил только о типовом применении Си++.


И в таком случае спорить, имхо, бессмысленно. С другой стороны, кому из присутствующих интересно типовое применение, если есть возможность применения более привлекательного, пусть и не совсем типового?
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Re[28]: Что толку в Ада если Ариан 5 все равно упал
От: AVC Россия  
Дата: 09.07.05 07:48
Оценка: :))
Здравствуйте, CrystaX, Вы писали:

AVC>>Мне действительно интересно будет посмотреть.


CX>Ок, может тогда пообщаемся в аське? Вышли на e-mail в профиле свой ICQ# или я свой могу выслать.


OK. В понедельник "реанимирую" аську на работе (заодно и номер вспомню).
А то я совсем ее, бедную, забросил после переустановки системы.
Потому что все сводилось к полуденной переписке коллег, вроде:

Че, ты уже на работе? В такую рань?
А я вот все думаю — может еще поспать?
Ну лады, шеф будет меня спрашивать — скажи, мол, только что был здесь.


AVC>>Конечно я частенько спорю с тобой, но и учусь тоже.


CX>Я тоже.


Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

Хоар
Re[28]: Что толку в Ада если Ариан 5 все равно упал
От: AVC Россия  
Дата: 09.07.05 16:27
Оценка: 7 (2)
Здравствуйте, Павел Кузнецов, Вы писали:

>> Но заметь, я не говорил, что в Си++ нет таких возможностей, а говорил только о типовом применении Си++.


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


Павел, я знаю, что Вы знаток Си++, но совсем не фанатик.
Но все же Вы — идеалист.
Неужели Вы не видите того препятствия, которое находится на пути грамотного программирования на Си++?
Это препятствие — сложность.

Посмотрите на что стали похожи современные программы на Си++. Их ведь практически нельзя читать!
Недавно Cyberax родил смешную фразу о "марсианском синтаксисе" Оберона.
Я и правда долго смеялся.

Поясню примером.
Обычно я говорю, что моим первым языком был Си. (Я не беру в расчет языки, на которых я выполнял студенческие работы — Фортран, PL/1, автокод БЭСМ-6. )
Так оно и было. На моей самой первой работе я писал на Си. (Это был сначала Microsoft C 5.0, затем 5.1.)
Но как я осваивал Си? Я брал какую-нибудь программу из книги Вирта "Алгоритмы + структуры данных = программы", желательно с достаточно детальным алгоритмом, выжидал, пока алгоритм немного подзабудется, а затем писал его на Си, опираясь уже только на общую идею алгоритма. (Подобный метод, оказывается, использовал Франклин, когда вырабатывал у себя литературный стиль. )
И вот только недавно до меня дошло — а ведь Паскаль-то я вообще не изучал!
Просто брал книгу Вирта и читал с листа без проблем.
Это я к тому, какой именно синтаксис здесь "марсианский".
Но от чтения современного исходного кода на Си++ просто становится физически плохо (без шуток).
Если код нечитабелен, то его никакие возможности по выработке рукодельной type safety не спасут: его не возможно будет сопровождать.

Поэтому я не верю ((c) Станиславский), что "программистские массы" когда-либо будут писать на Си++ грамотно.

Что же касается того, что Оберон — "небезопасен в отношении типов", так за все время дискуссии нашли только один пункт, к которому можно "прицепиться" — гетерогенность коллекций из-за отсутствия темплитов.
По тем или иным причинам обероновское сообщество не стало вводить параметрический полиморфизм (хотя простое решение было предложено еще в 1990-х годах Роу и Шиперски).
Может быть, и правильно? Где-то в соседней ветке обсуждается статья Generics considered harmful.
Но эту проблему не сравнить с проблемами достижения безопасности на Си++!
Даже если решать эту проблему вручную (надстроив вспомогательный интерфейс), то это гораздо проще, чем городить кучу классов на Си++ для решения простейших задач.
Можно использовать малюсенькую программку, которая автоматически сделает "обертку" для коллекции.
Можно явно добавить в коллекцию отладочную функцию проверки типа.
А можно сделать это неявно, использовав метапрограммирование.
Ведь в Оберон-системе информация о типах доступна в рантайме.
Например, в BlackBox (в модуле Kernel) есть тип Type и процедура-функция TypeOf:
    PROCEDURE TypeOf* (IN rec: ANYREC): Type;
    BEGIN
        RETURN S.VAL(Type, S.TYP(rec))
    END TypeOf;

А в модуле Services куча вспомогательных процедур, помогающих этим пользоваться.
Так что, можно "научить" спискм, деревья и проч. контролировать тип записей и указателей.
А после этого, написал что-нибудь вроде
  VAR r: MyRec;
    list: Lists.List;
BEGIN
  ...
  Lists.NewList(list, r);

сидишь и радуешься — неправильная переменная в список не пролезет.
Вообще, с помощью метапрограммирования в Обероне можно решать разные задачи.
Например, с помощью метапрограммирования легко реализуется обработка исключений, не требующая никаких дополнительных расходов в рантайме (ни одной дополнительной инструкции!), если исключение не случилось
(здесь).
Библиотечная процедура Exceptions.Raise сама найдет обработчик требуемого типа, но этот поиск производится только в случае вызова Raise. Никакого расширения языка не требуется. (Так сделано в ETH Oberon. Кстати такое решение применимо и к Java, и к C#.) А вот программа на Си++ заметно "тяжелеет" при использовании try и catch, даже если исключение не было выброшено. Кроме того, семантика обработки исключений в Обероне богаче.

А к чему еще в Обероне можно придраться с точки зрения контроля типов?

Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

Хоар
Re[29]: Что толку в Ада если Ариан 5 все равно упал
От: Павел Кузнецов  
Дата: 09.07.05 21:23
Оценка: 39 (3) +2
Здравствуйте, AVC, Вы писали:

AVC>Поэтому я не верю ((c) Станиславский), что "программистские массы" когда-либо будут писать на Си++ грамотно.


Мне "массы" интересны исчезающе мало. Мне интересен язык, позволяющий относительно небольшой команде квалифицированных программистов работать, эффективно помогая друг другу. По моим впечатлениям при определенном подходе C++ становится очень эффективным инструментом, подходящим как раз для таких целей. Имхо, главным аспектом C++ в этом отношении является достаточно широкий диапазон средств, доступных автору класса или функции, для того, чтобы влиять на их использование. Т.е. автор компонента может относительно много сделать для того, чтобы облегчить, а иногда и частично автоматизировать использование его класса или функции, равно как и использовать возможности компилятора для диагностики неправильных их использований. Но т.к. само по себе так не происходит, то в случае использования в проекте "масс", C++ подходит, действительно, значительно хуже, чем Java, C#, Ada, Oberon и т.п., т.к. при беззаботном подходе к программированию C++ позволяет наломать очень много дров, и, равно как позволяет авторам компонентов облегчать жизнь своим пользователям, также легко позволяет и обратное.

AVC>По тем или иным причинам обероновское сообщество не стало вводить параметрический полиморфизм (хотя простое решение было предложено еще в 1990-х годах Роу и Шиперски).

AVC>Может быть, и правильно? Где-то в соседней ветке обсуждается статья Generics considered harmful.
AVC>Но эту проблему не сравнить с проблемами достижения безопасности на Си++!
AVC>Даже если решать эту проблему вручную (надстроив вспомогательный интерфейс), то это гораздо проще, чем городить кучу классов на Си++ для решения простейших задач.
AVC>Можно использовать малюсенькую программку, которая автоматически сделает "обертку" для коллекции.
AVC>Можно явно добавить в коллекцию отладочную функцию проверки типа.
AVC>А можно сделать это неявно, использовав метапрограммирование.
AVC>Ведь в Оберон-системе информация о типах доступна в рантайме.

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

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


То же самое можно сделать и для исключений C++. Technical Report on C++ Performance: 5.4.1.2 The "Table" Approach (стр. 36 и далее):

The primary advantage of this method is that no stack or run-time costs are associated with managing the try/catch or object bookkeeping. Unless an exception is thrown, no run-time overhead is incurred.

Там же описаны и недостатки такого подхода.

AVC> А вот программа на Си++ заметно "тяжелеет" при использовании try и catch, даже если исключение не было выброшено.


Это особенности конкретных реализаций.

AVC> Кроме того, семантика обработки исключений в Обероне богаче.


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

AVC>А к чему еще в Обероне можно придраться с точки зрения контроля типов?


Речь идет не о недостаточной строгости Оберона в отношении контроля типов, которые он позволяет описать, а о том, что если бы он позволял описать больший диапазон свойств типов, то его с большей эффективностью можно было бы использовать для делегирования компилятору диагностики некоторых нарушений логики программы: const-correctness, использование generic programming и compile-time meta-programming для контроля правильности программы, использование четких правил времени жизни и детерминированного разрушения для организации транзакций на уровне языка и т.п.

Один из примеров с перечислениями уже приводился
Автор: Павел Кузнецов
Дата: 07.07.05
, приведу другой. Хотя я далеко не всегда согласен с таким решением, на мой взгляд, оно является хорошим примером использования возможностей C++ для документации в коде и контроля некоторых контрактов во время компиляции.

Во всех обсуждаемых языках, вне зависимости от "силы типизации", есть одна и та же проблема передачи нулевых ссылки/указателя в функцию, к этому не готовую. При этом подчас "отловить" место, где формируется нулевой указатель или ссылка нелегко, т.к. это может происходить далеко от места попытки использования. Решение может быть простым: создать шаблон указателя, явно указывающий одним из своих аргументов на то, принимает функция нулевые указатели или нет:
void f( ptr<T, !0> p ); // сюда можно передавать только ненулевые указатели
void g( ptr<T, 0> p );  // а сюда подойдут и нулевые

при этом контроль передачи потенциально нулевого указателя в функцию, требующую ненулевого, будет происходить во время компиляции, обращая внимание программиста на потенциальное нарушение контракта.
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Re[30]: Что толку в Ада если Ариан 5 все равно упал
От: AVC Россия  
Дата: 10.07.05 00:34
Оценка: 44 (1) :)
Здравствуйте, Павел Кузнецов, Вы писали:

AVC>>Поэтому я не верю ((c) Станиславский), что "программистские массы" когда-либо будут писать на Си++ грамотно.


ПК>Мне "массы" интересны исчезающе мало. Мне интересен язык, позволяющий относительно небольшой команде квалифицированных программистов работать, эффективно помогая друг другу. По моим впечатлениям при определенном подходе C++ становится очень эффективным инструментом, подходящим как раз для таких целей. Имхо, главным аспектом C++ в этом отношении является достаточно широкий диапазон средств, доступных автору класса или функции, для того, чтобы влиять на их использование. Т.е. автор компонента может относительно много сделать для того, чтобы облегчить, а иногда и частично автоматизировать использование его класса или функции, равно как и использовать возможности компилятора для диагностики неправильных их использований. Но т.к. само по себе так не происходит, то в случае использования в проекте "масс", C++ подходит, действительно, значительно хуже, чем Java, C#, Ada, Oberon и т.п., т.к. при беззаботном подходе к программированию C++ позволяет наломать очень много дров, и, равно как позволяет авторам компонентов облегчать жизнь своим пользователям, также легко позволяет и обратное.


В отношении непригодности языка для "масс" (или "масс" для языка?) мы, кажется, пришли к "консенсусу".
А ведь, между тем, что-то я не видел на книжках по Си++ надписей вроде: "Минздрав предупреждает".
Напротив: от "Освой Си++ за 21 день" до "Си++ для чайников".

AVC>>Ведь в Оберон-системе информация о типах доступна в рантайме.


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


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

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


ПК>То же самое можно сделать и для исключений C++. Technical Report on C++ Performance: 5.4.1.2 The "Table" Approach (стр. 36 и далее):

ПК>

ПК>The primary advantage of this method is that no stack or run-time costs are associated with managing the try/catch or object bookkeeping. Unless an exception is thrown, no run-time overhead is incurred.

ПК>Там же описаны и недостатки такого подхода.

AVC>> А вот программа на Си++ заметно "тяжелеет" при использовании try и catch, даже если исключение не было выброшено.


ПК>Это особенности конкретных реализаций.


AVC>> Кроме того, семантика обработки исключений в Обероне богаче.


ПК>Там можно возобновлять исполнение после исключения или еще что-то? Если первое, то я так и не видел примеров, где бы это было полезно.


Да, там можно возобновлять исполнение после исключения, если удалось исправить ситуацию, приведшую к исключению.

AVC>>А к чему еще в Обероне можно придраться с точки зрения контроля типов?


ПК>Речь идет не о недостаточной строгости Оберона в отношении контроля типов, которые он позволяет описать, а о том, что если бы он позволял описать больший диапазон свойств типов, то его с большей эффективностью можно было бы использовать для делегирования компилятору диагностики некоторых нарушений логики программы: const-correctness, использование generic programming и compile-time meta-programming для контроля правильности программы, использование четких правил времени жизни и детерминированного разрушения для организации транзакций на уровне языка и т.п.


Не совсем понятно, какие проблемы с const-correctness, например, в Компонентном Паскале?
Экспорт переменных только для чтения, передача параметров по значению или по ссылке только для чтения (IN).
Например, компилятор не позволит изменить значение строки в следующем примере:
    PROCEDURE Get(OUT a: ARRAY OF CHAR);
    BEGIN
        a := "QWERTY";
    END Get;

    PROCEDURE Set(IN a: ARRAY OF CHAR);
    BEGIN
        a := "QWERTY"; (* здесь компилятор скажет, что параметр read-only *)
        Get(a);        (* здесь тоже *)
    END Set;



ПК>Один из примеров с перечислениями уже приводился
Автор: Павел Кузнецов
Дата: 07.07.05
, приведу другой. Хотя я далеко не всегда согласен с таким решением, на мой взгляд, оно является хорошим примером использования возможностей C++ для документации в коде и контроля некоторых контрактов во время компиляции.


ПК>Во всех обсуждаемых языках, вне зависимости от "силы типизации", есть одна и та же проблема передачи нулевых ссылки/указателя в функцию, к этому не готовую. При этом подчас "отловить" место, где формируется нулевой указатель или ссылка нелегко, т.к. это может происходить далеко от места попытки использования. Решение может быть простым: создать шаблон указателя, явно указывающий одним из своих аргументов на то, принимает функция нулевые указатели или нет:

ПК>
ПК>void f( ptr<T, !0> p ); // сюда можно передавать только ненулевые указатели
ПК>void g( ptr<T, 0> p );  // а сюда подойдут и нулевые
ПК>

ПК>при этом контроль передачи потенциально нулевого указателя в функцию, требующую ненулевого, будет происходить во время компиляции, обращая внимание программиста на потенциальное нарушение контракта.

Что, кажется, не избавляет от ошибки (исключения) в рантайме на этапе создания такого ненулевого указателя (при вызове конструктора).
Справиться со всеми потенциальными исключениями все равно не удастся.
Грамотное использование ASSERT в данном случае не менее эффективно позволяет выявлять и предупреждать ошибки.
А вот использовать ASSERT гораздо проще, а значит — применять его будут чаще и охотнее.
Кроме того, разве в Си++ достаточно проконтролировать указатель на 0? Ведь в Си++ он может быть просто "мусором".
Например:
int *p; // здесь мусор: забыли инициализировать или обнулить после delete
...
ptr<int, !0> *p_not_zero = p; // да, здесь не 0. Ну и что?

Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

Хоар
Re[23]: Что толку в Ада если Ариан 5 все равно упал
От: AVC Россия  
Дата: 10.07.05 16:54
Оценка:
Здравствуйте, Сергей Губанов, Вы писали:

СГ>Не сочтите за коммерческую рекламу, но в июльском номере журнала "Мир ПК" на компакт диске в разделе "Студия программирования" обещают поместить соответсвующие материалы (BlackBox). Это я на тот случай сообщаю, если Вы вдруг по модему чего из интернета скачивать надумаете, так лучше сначала там посмотреть.


Сергей, спасибо за информацию (и "рекламу" )!
Увидел новый "Мир ПК" в киоске и купил.
И теперь страшно доволен, т.к. кроме и без того любимого Оберона там куча интересных материалов, и особенно — головоломки (в том числе замечательные книги Смаллиана) и сборники шахматных задач. Ловлю кайф!

Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

Хоар
Re[9]: Что толку в Ада если Ариан 5 все равно упал
От: Шахтер Интернет  
Дата: 10.07.05 17:15
Оценка: +2
Здравствуйте, AVC, Вы писали:

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


AVC>>>Что это — хак, кряк? Или хрюк? Применительно к Страуструпу — скорее последнее.

AVC>>>(Ничего не могу с собой поделать. Я его очень не люблю. Я вообще не люблю жуликов.

E>>Ребята, давайте Страуструпа оставим в покое. Он сделал то, что сделал. А мы можем либо пользоваться результатами его труда, либо нет. Но я уверен, что разработок масштаба достижений Страуструпа (язык программирования которым пользуются уже 20 лет и пару книг-бестселлеров) никто на данном форуме не достиг и, имхо, далеко не всем суждено достигнуть. Так что "Don't shot pianist...".


AVC>Евгений, мне жаль, что я огорчил тебя.

AVC>Но ведь у каждого своя точка зрения.
AVC>Достижения бывают разными. Мне кажется, если у человека нет достижений вроде тех, которыми отличились Герострат или Гитлер, то это хорошо.
AVC>Поэтому аргумент о достижениях вообще не убеждает.
AVC>Для меня не является аргументом, что кто-то написал бестселлер. Это чисто коммерческий аргумент, применимый не всегда и не во всех обстоятельствах.
AVC>Поэтому аргумент о бестселлерах не принимается, по крайней мере — в абстрактном виде.
AVC>Я бы принял его во внимание, если бы был книготорговцем.
AVC>По поводу самих книг я хочу сказать, что они написаны действительно хорошо, и они гораздо лучше языка, которому они посвящены. Я и не думал отрицать наличие у Страуструпа таланта.
AVC>Гораздо хуже обстоит с языком, которым "пользуются уже 20 лет".
AVC>Наш мир вообще очень опасен и нестабилен.
AVC>Но некоторые люди делают его еще опаснее.
AVC>Ты говоришь, что надо оставить в покое Страуструпа. А он оставит меня в покое?
AVC>Все в мире взаимосвязано.
AVC>Во-первых, неправда, что у нас есть свобода "не пользоваться результатами его труда".
AVC>Если ты обыкновенный программист, тебе, вероятно, придется иногда писать на Си++. В случае твоего гордого отказа другой программист "воспользуется результатами его труда", а тебе будет нечем кормить семью.
AVC>Разумеется, в тех случаях, когда у меня есть выбор, я не стану пользоваться Си++. (Я так и делаю, и ни разу не ощутил, что мне не хватает каких-либо "фич" Си++. Поэтому я полагаю, что Си++ — сильно раздутый миф. Конечно, я стараюсь внимательно слушать оппонентов, опасаясь собственных заблуждений. При такой собственной пристрастности мне очень важно иметь возможность услышать и другую точку зрения.)
AVC>Во-вторых, я никак не могу понять аргументов, что чрезмерно сложный и раздутый язык, не позволяющий даже в отладочном режиме обеспечить контроль типов, является вершиной человеческой мысли и результатом непосильного труда.
AVC>Скорее, я склонен видеть в нем результат халтурной работы.

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

Что до сложности -- а мне он кажется недостаточно сложным. Я бы оценил ряд добавлений в язык.

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

AVC>Говорят, что тому, кто любит кобасу, не надо знать, как она делается.
AVC>Моя проблема в том, что я "люблю колбасу", но "знаю, как она делается".
AVC>На душе у меня действительно неспокойно. Конечно, не только из-за Страуструпа. Но ведь и из-за него тоже.
AVC>Поэтому я не люблю Страуструпа и считаю, что имею право высказывать это вслух, а не шептать ночью в подушку.
AVC>Мне жаль, что иногда по несдержанности я делаю это в грубой форме. (Все-таки темперамент у меня, увы, бурный. )
AVC>Вместе с тем, мне приятно общаться с интересными мне людьми, даже если им Страуструп нравится.
AVC>По возможности, я сдерживаюсь и не слишком выпячиваю свое отношение к автору Си++, а больше сосредотачиваюсь на самом языке.
AVC>Но иногда меня все-таки "прорывает". Прости дурака.

Нет, не прощу. Дураков не прощаю. Будь умным, тогда можешь расчитывать на прощение.



:
В XXI век с CCore.
Копай Нео, копай -- летать научишься. © Matrix. Парадоксы
Re[31]: Что толку в Ада если Ариан 5 все равно упал
От: Павел Кузнецов  
Дата: 10.07.05 17:49
Оценка: 1 (1)
Здравствуйте, AVC, Вы писали:

ПК>>Там можно возобновлять исполнение после исключения или еще что-то? Если первое, то я так и не видел примеров, где бы это было полезно.


AVC>Да, там можно возобновлять исполнение после исключения, если удалось исправить ситуацию, приведшую к исключению.


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

Последний довод был подкреплен еще и теоретическим рассуждением Флавия Кристиана (Flaviu Cristian), который доказал, что при наличии завершениия семантика возобновления не нужна [Cristian, 1998].

Потратив два года на споры, я вынес впечатление, что можно привести убедительные логические доводы в пользу любой точки зрения. Они имелись даже в специальной работе [Goodenough, 1975] по обработке исключений. Мы оказались в положении все тех же античных философов, которые так яростно и умно спорили о природе Вселенной, что как-то забыли о ее изучении. Поэтому я просил любого, кто имел реальный опыт работы с большими системами, представить конкретные факты.


Свое утверждение Митчелл подкрепил рассказом о работе над несколькими операционными системами. Самым главным был пример системы Cedar/Mesa, которую написали программисты, любившие и умевшие пользоваться семантикой возобновления. Однако через десять лет в системе из полумиллиона строк остался лишь один случай использования возобновления — в запросе контекста. Поскольку и в данной ситуации оно фактически было не нужно, механизм возобновления исключили полностью, после чего скорость работы этой части системы значительно возросла. Во всех тех случаях, когда применялась операция возобновления (а это более десяти лет эксплуатации), появлялись определенные проблемы и приходилось искать более подходящий механизм. По сути дела, все применения возобновления были связаны с неумением отделить друг от друга различные уровни абстракции.


AVC>Не совсем понятно, какие проблемы с const-correctness, например, в Компонентном Паскале?

AVC>Экспорт переменных только для чтения, передача параметров по значению или по ссылке только для чтения (IN).

А как это взаимодействует с типами, определенными пользователем? Можно ли разделить методы класса на те, которые изменяют состояиние его объектов, и на те, которые состояине объектов не изменяют?

AVC>Что, кажется, не избавляет от ошибки (исключения) в рантайме на этапе создания такого ненулевого указателя (при вызове конструктора).


Это делает создание объекта ptr<T,!0> явным, обращая внимание программиста на потенциальную проблему в момент инициализации этого объекта.

AVC>Кроме того, разве в Си++ достаточно проконтролировать указатель на 0? Ведь в Си++ он может быть просто "мусором".


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

AVC>
AVC>ptr<int, !0> *p_not_zero = p; // да, здесь не 0. Ну и что?
AVC>


Так этот указатель проинициализировать нельзя. Можно так:
ptr<int,!0> p_not_zero = ptr_cast<int,!0>( p );

делая невозможным неосознанное создание объекта ptr<int,!0> из потенциально нулевого указателя.
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Re[18]: Что толку в Ада если Ариан 5 все равно упал
От: VladD2 Российская Империя www.nemerle.org
Дата: 10.07.05 18:01
Оценка:
Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Тише-тише... Мы ж конкретный пример обсуждаем. Если ты хочешь показать, что проблема решена неудачно, достаточно продемонстрировать, насколько лихо это можно было сделать по-другому. Если хочешь порекламировать C#/R#, давай, сейчас хорошая возможность: я весь — внимание Скажем, пример на OCaml, приведенный Трурль, для меня оказался достаточным, чтобы существенно изменить свое отношение к данному языку.


Я вообще не свитаю твое решение решением. Проблему он не решает. Он создает новую проблему — необходимость бегать по году и менять имя типа. С тем же успехом я мог бы просто предложить менять имя перечисления при добавлении в него новых значений. Можно даже почти так же как ты, т.е. закладывая в имя перечисления (или в пространство имен, чтбы было удобнее) все его члены.

ПК>Так все-таки, примерчик можно? А то я пока не вполне понимаю, о чем речь идет: мне мерещатся всякие ужасы с достаточно серьезным анализом AST и т.п...


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

В общем, в этот раз считай, что ты взял меня "на слабо". Но в будущем не обессуть... Вот подобный запрос:
//RSwitchStatement[Sections/RSwitchSection/Labels/RMemberReferenceExpression[
    TargetObject[@VariableName='A'] ] 
    and not 
    (
        Sections/RSwitchSection/Labels/RMemberReferenceExpression[TargetObject[@VariableName='A'] and MemberName[@VariableName='A'] ] 
        and Sections/RSwitchSection/Labels/RMemberReferenceExpression[TargetObject[@VariableName='A'] and MemberName[@VariableName='B'] ] 
        and Sections/RSwitchSection/Labels/RMemberReferenceExpression[TargetObject[@VariableName='A'] and MemberName[@VariableName='C'] ]
    )
]


Этот запрос отлавливает все switch-и в одном из case-ов которых встречается ссылка на 'A' и при условии что switch не содержит case-ы для элементов A, B и C. Я к сожалению не силен в XPath. Наверно можно как-то написать этот запрос более универсально. Но даже с этим можно написать небольшой скриптик автоматизирующий создание этого запроса. Далее останется включить этот скрипт в список тестов и будет тебе контроль.

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

ПК>Гм... По-моему, достаточно близко к минимуму (который мы имели удовольствие наблюдать на примере OCaml).


А по моему копипжст есть, а толку нет.

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


Не один, а столько раз сколько встречается тип. Чем это будет отличаться от например вот такого решения:
namespace FileExists.Cancel.Overwrite.Skip
{
    enum Answer
    {
            Cancel,
            Overwrite,
            Skip,
    }
}

interface ICommunicator
{
  FileExists.Cancel.Overwrite.Skip FileExists(Path path);
  . . .
};

?

В общем, это не решение. Это понты.

>> Может быть я что-то не понял, но в твоем примере был банальный if.


ПК>Точно. А перед ним явное указание списка ожидаемых значений, совмещенное с вызовом функции.


Вот выше я тебе привел подобное "решение".

ПК> Вот там-то и зарыта потенциальная ошибка: набор ожидаемых значений не соответствуют реально возвращаемым. Все, что после — ее следствия. Нарушено предусловие последующего блока кода (значение принадлежит определенному набору); когда нарушается предусловие,


Ты перевернул все вверх ногами. У тебя не предусловие не выполняется, а код в switch-е не отвечает требованиям прикладной логики.

ПК>рассуждать о правильности кода смысла не имеет. В случае приведенного примера соблюдение данного предусловия контролируется компилятором. Определять предусловия своего кода — ответственность программиста.


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

>> И никакие шаблоны не заставят компилятор проверить, что у этого if-а нужное количество else if-ов содержащее нужные проверки.


ПК>Это уже несущественно: наличие всех веток тоже не гарантирует правильности обработки. Для меня достаточно того, что ни один вызов функции-члена communicator не может быть случайно сделан так, что будет получено неожиданное значение.


Гы. Не существнно? Да только это и стоит контролировать. И то если это действительно критичный код. А так ничего страшного нет в том, чтобы подождать исключения на дефолте.

ЗЫ

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

В данном случае я бы вместо изращений с перечислениями и темболее символами просто создал бы интерфейс или абстрактный класс и заставли бы клиентов создать его реализацию. Вот тут уж действительно наличие обработчика было бы гарантированно компилятором:
interface IFileExistsAnswer
{
    void OnCancel();
    void OnOverwrite();
    void OnSkip();
}

interface IFolderDoesNotExistsAnswer
{
    void OnCancel();
    void OnContinue();
}

class Communicator
{
    bool FileExists(string path, IFileExistsAnswer answer)
    {
        ...
        communicator.FileExists(path, answer);
        ...
    }
        
    bool FolderExists(string path, IFolderDoesNotExistsAnswer answer) { ... }
}


Попробуй теперь не реализовать рекцию на один из элементов.
Решение, кстати, из разряда "для первокласников", так как это всего лишь использование паттерна стратегия, так и напрашивающегося в данном случае.

Кстати, характерно, что ты вместо того чтобы применить этот тривиальный паттерн занялся написанием "крутого кода который нельзя повторить на Шарпе". Это что назывется и есть "пусть С++".
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[19]: Что толку в Ада если Ариан 5 все равно упал
От: Павел Кузнецов  
Дата: 10.07.05 18:21
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Этот запрос отлавливает все switch-и в одном из case-ов которых встречается ссылка на 'A' и при условии что switch не содержит case-ы для элементов A, B и C.


Этого недостаточно. Еще нужно отлавливать все if, равно как и переходить по вызовам внутрь функций, т.к. обработка может быть разбита на две функции. Полагаю, если подумать, найдутся и другие случаи, где этой проверки будет недостаточно. Навскидку: обработка ветвления через массив указателей на функции/делегатов/объектов-обработчиков.

VD>Не один, а столько раз сколько встречается тип. Чем это будет отличаться от например вот такого решения:

VD>
VD>namespace FileExists.Cancel.Overwrite.Skip
VD>{
VD>    enum Answer
VD>    {
VD>            Cancel,
VD>            Overwrite,
VD>            Skip,
VD>    }
VD>}

VD>interface ICommunicator
VD>{
VD>  FileExists.Cancel.Overwrite.Skip FileExists(Path path);
VD>  . . .
VD>};
VD>

VD>?

Я уже писал: такие типы нельзя объединять и передавать в третью функцию для совместной обработки разных исключительных ситуаций.

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


Да, об этом тоже думали. Объем работы очень большой получается.
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Re[32]: Что толку в Ада если Ариан 5 все равно упал
От: AVC Россия  
Дата: 10.07.05 19:58
Оценка:
Здравствуйте, Павел Кузнецов, Вы писали:

ПК>>>Там можно возобновлять исполнение после исключения или еще что-то? Если первое, то я так и не видел примеров, где бы это было полезно.


AVC>>Да, там можно возобновлять исполнение после исключения, если удалось исправить ситуацию, приведшую к исключению.


ПК>В "Дизайне и эволюции Си++" есть описание длительных споров в комитете как раз на эту тему, и приведены убедительные (для меня) обоснования, почему именно для исключений была выбрана семантика завершения. Всю главу мне перепечатывать лень, напечатаю лишь два небольших фрагмента.


ПК>

ПК>Последний довод был подкреплен еще и теоретическим рассуждением Флавия Кристиана (Flaviu Cristian), который доказал, что при наличии завершениия семантика возобновления не нужна [Cristian, 1998].

ПК>Потратив два года на споры, я вынес впечатление, что можно привести убедительные логические доводы в пользу любой точки зрения. Они имелись даже в специальной работе [Goodenough, 1975] по обработке исключений. Мы оказались в положении все тех же античных философов, которые так яростно и умно спорили о природе Вселенной, что как-то забыли о ее изучении. Поэтому я просил любого, кто имел реальный опыт работы с большими системами, представить конкретные факты.


ПК>

ПК>Свое утверждение Митчелл подкрепил рассказом о работе над несколькими операционными системами. Самым главным был пример системы Cedar/Mesa, которую написали программисты, любившие и умевшие пользоваться семантикой возобновления. Однако через десять лет в системе из полумиллиона строк остался лишь один случай использования возобновления — в запросе контекста. Поскольку и в данной ситуации оно фактически было не нужно, механизм возобновления исключили полностью, после чего скорость работы этой части системы значительно возросла.


Хочу напомнить, что обероновское решение с помощью метапрограммирования не приводит к оверхеду.
Статья так и называлась: Zero-overhead exception handling.

ПК>

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


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

AVC>>Не совсем понятно, какие проблемы с const-correctness, например, в Компонентном Паскале?

AVC>>Экспорт переменных только для чтения, передача параметров по значению или по ссылке только для чтения (IN).

ПК>А как это взаимодействует с типами, определенными пользователем? Можно ли разделить методы класса на те, которые изменяют состояиние его объектов, и на те, которые состояине объектов не изменяют?


Да, конечно.
Ведь в присоединенных процедурах Компонентного Паскаля объект указывается явно.
Следовательно его можно снабдить соотвествующим квалификатором, как и любой другой параметр.
    PROCEDURE (IN self: ObjectDesc) SetName* (name: ARRAY OF CHAR), NEW;
    BEGIN
        self.name := name$; (* компилятор опять ругается :) *)
    END Do;


AVC>>Кроме того, разве в Си++ достаточно проконтролировать указатель на 0? Ведь в Си++ он может быть просто "мусором".


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


Ясно.
Хотя по некоторым заявлениям сторонников Си++ у меня сложилось впечатление, что они все проблемы рещают в compile-time.
Но вот что характерно — в Обероне такой потенциальной ошибки нет.

AVC>>
AVC>>ptr<int, !0> *p_not_zero = p; // да, здесь не 0. Ну и что?
AVC>>


ПК>Так этот указатель проинициализировать нельзя. Можно так:

ПК>
ПК>ptr<int,!0> p_not_zero = ptr_cast<int,!0>( p );
ПК>

ПК>делая невозможным неосознанное создание объекта ptr<int,!0> из потенциально нулевого указателя.

Конечно, это имеет значение.

Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

Хоар
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.