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

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

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

Это намного ольше чем можешь предложить ты. Да и другие варианты тоже решаемы. Я все же не предлагаю использовать именно R# для этого случая. Я говорю, о возможности.

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

Объеденять значения? Да вообще-то можно. А типы просто не нужно.

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

ПК>Да, об этом тоже думали. Объем работы очень большой получается.

Что же там большого?

В отличии от твоего "решения" "Стратегия" действительно решает проблему. Что-то мне кажется, что у тебя получился хороший пример того как не нужно проектировать.

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

... << RSDN@Home 1.1.4 beta 7 rev. 466>>

Просьба, уменьшить объем цитирования.

... << RSDN@Home 1.1.4 beta 7 rev. 466>>

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

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

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

AVC>Ясно.
AVC>Хотя по некоторым заявлениям сторонников Си++ у меня сложилось впечатление, что они все проблемы рещают в compile-time.

AVC>Но вот что характерно — в Обероне такой потенциальной ошибки нет.

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

... << RSDN@Home 1.1.4 stable rev. 510>>

Просьба, уменьшить объем цитирования.

... << RSDN@Home 1.1.4 beta 7 rev. 466>>

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

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

Производительность в этом деле стоит на одном из последних мест. Я даже хотел выбросить предложение с упоминанием производительности, чтоб не уводить дискуссию в сторону. Собственно, вся остальная глава об этом молчит. Упор на удобство использования и т.п. Производительность -- только бонус. А обработка исключительных ситуаций обычно все-таки приводит к замедлению, но, в "zero-overhead" реализациях, не в случае, когда исключение не возникает, а в случае, когда оно таки возникает. В случае, описанном в цитате, исключения, насколько я понимаю, использовались для управления логикой программы. Т.е. когда не было контекста, возникало исключение, в обработке которого контекст инициализировался и выполнение возобновлялось. Т.е. исключение возникало в "нормальной" ситуации.

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

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

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

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

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

AVC>Ясно.
AVC>Хотя по некоторым заявлениям сторонников Си++ у меня сложилось впечатление, что они все проблемы рещают в compile-time.

AVC>Но вот что характерно — в Обероне такой потенциальной ошибки нет.

А как там с контролем нулевых ссылок справляются?

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

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

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

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

Разрешите полюбопытствовать, "возобновление исполнения после исключения" — это как-то связано с Лисповской системой condition'ов и restart'ов? Если да, то любопытно было бы послушать возражения против этой системы. Сам я ее не использовал, но приведенные по ссылке примеры весьма впечатляют.

ПК>

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

Безотносительно к тому, о чем идет речь, и оправдано ли было такое решение, хочу сказать, что такие примеры меня всегда умиляют. Решения о включении того или иного свойства в язык принимают на основе того, что кто-то когда-то где-то смотрел на какие-то проекты "из полмиллиона строк" (присутствующие могут оценить представительность статистики) и пришел к тому или иному выводу, который отныне будет почитаться за аксиому. Такое впечатление, что старые проекты (существовавшие до создания языка) — это некое "священное писание", и там все безгрешно. Попробуй сейчас кто-нибудь сказать: а вот мы в нашем проекте из 100 млн. строк ни разу не использовали свойство X какого-либо языка программирования, давайте исключим это свойство. Сразу поднимется шум и возникнет куча людей, которые жить не могут без свойства X. А священные старые проекты, определившие дизайн языка, под сомнение ставить нельзя — ересь.

Извините, наболело.

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

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

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

Не, это совершенно лишее.

Ничего интересного в ветке не сказано, и отвечаю я не на всю ветку, а на одну вполне конкретную вашу фразу. Вот она, ключевое выделено:

отказавшись от C++, я потеряю мощнейшую вещь, которой нет пока ни в одном другом языке — шаблонное метапрограммирование

Я возражаю по поводу выделения.

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

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

G>Не, это совершенно лишее.

Ничего интересного в ветке не сказано, и отвечаю я не на всю ветку, а на одну вполне конкретную вашу фразу. Вот она, ключевое выделено:

G>

G>отказавшись от C++, я потеряю мощнейшую вещь, которой нет пока ни в одном другом языке — шаблонное метапрограммирование

G>Я возражаю по поводу выделения.

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

... << RSDN@Home 1.1.4 stable rev. 510>>

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

CX>Если бы прочитал немного больше, понял бы, что возражаешь в пустоту. Этот вопрос уже был рассмотрен и я уже пояснял здесь и здесь, что имелось в виду. Так что все-таки читать ветку нелишне.

Хе-хе

. Хорошо, ты прав

. Но все-таки

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

Ну, чтоль-же хорошо показать не смогу, а вот лучше — это запросто. То есть, я вычеркну из своего списка лишнее

Dylan. Lisp.

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

G>

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

G>Ну, чтоль-же хорошо показать не смогу, а вот лучше — это запросто. То есть, я вычеркну из своего списка лишнее

Dylan. Lisp.

Видимо, ты все-таки невнимательно прочитал. C++ противопоставлялся в этой ветке языкам C#, Java, Oberon, Ada. Не лиспу! Вот еще один линк. На этом тему считаю закрытой.

... << RSDN@Home 1.1.4 stable rev. 510>>

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

F> Безотносительно к тому, о чем идет речь, и оправдано ли было такое решение, хочу сказать, что такие примеры меня всегда умиляют. Решения о включении того или иного свойства в язык принимают на основе того, что кто-то когда-то где-то смотрел на какие-то проекты "из полмиллиона строк" <...>

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

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

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

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

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

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

Для отлова подобных вещей (на как только можно более ранней стадии) повсеместно используется ASSERT

PROCEDURE f(a: MyPtr);
BEGIN
  ASSERT(a # NIL, 20);  
  ...
END f;

Здравствуйте, Сергей Губанов, Вы писали:

ПК>>

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

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

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

Так в том-то и фокус, что если у нас есть:

T * get_some_object();

То компилятор нам не даст записать:

f( get_some_object() );

поскольку T* не подходит в качестве ptr<T,!0>. В то же время, если у нас есть:

ptr< T, !0 > create_some_object();

То мы вполне можем записать:

f( create_some_object() );
// И даже, если захотеть и поколдовать над ptr<>:
g( create_some_object() );

И, что самое замечательное, проверкой всего этого дела занимается компилятор.

СГ>Для отлова подобных вещей (на как только можно более ранней стадии) повсеместно используется ASSERT
СГ>

СГ>PROCEDURE f(a: MyPtr);
СГ>BEGIN
СГ>  ASSERT(a # NIL, 20);  
СГ>  ...
СГ>END f;
СГ>

Проблема в ASSERT-ах в том, что их видит автор f. Но не пользователь f! А предложенный Пашей подход как раз позволяет показать клиенту, что такой ASSERT внутри f присутствует.

... << RSDN@Home 1.1.4 stable rev. 510>>

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

ПК>Сергей Губанов,

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

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

Это было понятно с самого начала — в момент ее написания. Таким образом повторная ревизия уже не нужна. Всё что нужно было написать уже было написано.

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

На реплики по отдельности отвечать не буду, отвечаю в общем.

Главный вопрос — сколько методов и интерфейсов.

Сейчас не буду вдаваться глубоко в анализ, но тем не менее, ответ примерно такой:

Группируем методы по их семанитике. Например: группа управления граничными размерами окна, группа управления размерами, группа управления Z-порядком. Соответственно, предполагая, что API поддерживает свободную функцию ::RegisterPolicyUser(void*, int):

template<typename T>
struct PolicyTrait
{
  // enum PolicyTrait
};

#define PT(itf, code) template<> struct PolicyTrait<class itf> { enum pc {policy_code = code}; };

template<typename T>
class PolicyRegistrar {
        HANDLE handle_;
  public:
      inline PolicyRegistrar(T *user) { handle_ = ::RegisterPolicyUser(this, (int)PolicyTrait<T>::policy_code) }
        inline ~PolicyRegistrar() { ::CloseHandle(handle_); }
};

PT(BoundarySizes, 11)

class BoundarySizes : private PolicyRegistrar<BoundarySizes> {
  public:
        BoundarySizes() : PolicyRegistrar(this){}
      virtual void minimize() = 0;
        virtual void maximize() = 0;
};

PT(FloatingSizes, 12)

class FloatingSizes : private PolicyRegistrar<FloatingSizes> {
  public:
        FloatingSizes() : PolicyRegistrar(this){}
      virtual void change_width(int delta) = 0;
        virtual void change_hegth(int delta) = 0;
        virtual void move(int dx, int dy) = 0;
};

PT(ZOrderMgmt, 13)

class ZOrderMgmt : private PolicyRegistrar<ZOrderMgmt> {
  public:
        ZOrderMgmt() : PolicyRegistrar(this){}
      virtual void move_top() = 0;
        virtual void move_bottom() = 0;
        virtual void move_relative(int steps) = 0;
};

Суть, думаю, понятна. Естественно, что интерфейсы, ожидаемые системой не должны меняться часто — должны вводиться новые, типа FloatingSizesAdvanced и т.п. Сколько конкретно их будет? Ну, не знаю, прямо скажем, здесь нужно много посчитать. Но даже если окажется больше сотни-двух, особой проблемы я здесь не вижу.