Re[17]: Sqrt - хороший пример компонента обороняющегося от о - Философия программирования

Почему нельзя отключать ASSERT-ы в релизе

В модульных (компонентных) расширяемых системах отключать ASSERT-ы в «релизе» нельзя. Это связано с тем, что для Вас-то, быть может эта система «релизная», а вот для клиента, который пишет для неё (и отлаживает) свои компоненты, она никакая не «релизная».

Фрагмент из хелпа к BlackBox:

Хорошо известно, что определение ошибки тем более затруднено и дороже обходится, чем позже она обнаруживается, т.е. чем дальше разнесены источник и его эффекты. Это позволяет сформулировать правило:

Позволяйте ошибкам заявлять о себе как можно раньше.

В компонентно-ориентированных системах дефекты всегда должны содержаться в их компонентах
и не распространяться на другие компоненты. Другие компоненты даже могут быть черными ящиками и не иметь исходных текстов, что делает отладку на уровне исходных текстов невозможной. Более того, поток передачи управления в больших объектно-ориентированных программных системах настолько запутанный, что нереально, и это пустая трата времени, проследить его за пределами границ компонентов для целей отладки.
Единственный жизнеспособный отладочный подход есть проектирование всего, от языка программирования до библиотек, до компонентов и приложений, используя оборонительный стиль программирования. В частности, входные точки в компоненты (вызовы процедур/методов) должны останавливать исполнение, если их предусловия не обеспечены:

Никогда не позволяйте ошибкам проникать сквозь границы компонентов.

К счастью, большинство проверок предусловий недорого и поэтому их отключение при исполнении не имеет смысла. Это важно, поскольку в компонентно-ориентированной системе проверки периода исполнения не могут быть выключены в конечной (готовой) системе, поэтому разрабатываемая и готовая системы не различаются. На практике большинство компонентов уже отлажено в режиме черного ящика ("продукция"), а другие отлаживаются в режиме белого ящика. Готовые компоненты должны взаимодействовать, чтобы доказать приверженность сформулированному выше правилу, которое означает «никогда не отключать проверки периода исполнения».

Перевод на русский язык выполнен здесь.

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

СГ>Почему нельзя отключать ASSERT-ы в релизе

СГ>В модульных (компонентных) расширяемых системах отключать ASSERT-ы в «релизе» нельзя. Это связано с тем, что для Вас-то, быть может эта система «релизная», а вот для клиента, который пишет для неё (и отлаживает) свои компоненты, она никакая не «релизная».

Я склонен думать, что здесь присутствует терминологическая путаница. ASSERT по определению должен быть отключен в релизе. Иначе он такровым не является — так уж исторически сложилось и менять этот распорядок нехорошо. Если нечто, подобное ассерту должно присутствовать в релизе, то и называться это должно по-другому. Например, VERIFY. И это будет являться штатным механизмом сообщения об ошибках. Весь смысл и заключается в том, что это уже другой механизм, отличный от ASSERT. Тем не менее, встречаются люди, которые даже не могут себе представить, что на свете существуют задачи, в которых наличие ASSERT в релизе категорически недопустмо.

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

Честно говоря, релизный код не должен содержать ошибок.

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

С уважением, Gleb.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

СГ>Почему нельзя отключать ASSERT-ы в релизе
Догма сомнительная, один термин "компонента" о чем говорит .

Как пример , использую я гдето двусвязанный список объектов ( интрузивный ), и при разработке использую такую функцию как ValidateList, ValidateObject и т.д. которые проверяют список на инварианты.

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

И что , мне эти asserts оставлять в релизе ?

McSeem2 wrote:
>
> Я склонен думать, что здесь присутствует терминологическая путаница.
> ASSERT по определению должен быть отключен в релизе. Иначе он такровым
> не является — так уж исторически сложилось и менять этот распорядок
> нехорошо. Если нечто, подобное ассерту должно присутствовать в релизе,
> то и называться это должно по-другому. Например, VERIFY. И это будет
> являться штатным механизмом сообщения об ошибках. Весь смысл и

А чем этот VERIFY отличается от ASSERT'а, кроме названия?

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

И что это за задачи такие?

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

Posted via RSDN NNTP Server 2.0

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

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

СГ>>Почему нельзя отключать ASSERT-ы в релизе

СГ>>В модульных (компонентных) расширяемых системах отключать ASSERT-ы в «релизе» нельзя. Это связано с тем, что для Вас-то, быть может эта система «релизная», а вот для клиента, который пишет для неё (и отлаживает) свои компоненты, она никакая не «релизная».

MS>Я склонен думать, что здесь присутствует терминологическая путаница. ASSERT по определению должен быть отключен в релизе. Иначе он такровым не является — так уж исторически сложилось и менять этот распорядок нехорошо. Если нечто, подобное ассерту должно присутствовать в релизе, то и называться это должно по-другому. Например, VERIFY. И это будет являться штатным механизмом сообщения об ошибках. Весь смысл и заключается в том, что это уже другой механизм, отличный от ASSERT. Тем не менее, встречаются люди, которые даже не могут себе представить, что на свете существуют задачи, в которых наличие ASSERT в релизе категорически недопустмо.

Сергей говорит о расширяемых (extensible) системах и о применении в них принципа контрактного программирования (Мейер).
В таких системах заранее неизвестно, кто и как будет вызывать наш код. Поэтому отключать проверку предусловий и правда не следует.
Тот ASSERT, о котором говорит Сергей, не приводит к завершению работу программной системы, а только прерывает выполнение текущей команды. Т.е. это разновидность исключения, обрабатываемая системой, "ловушка" (trap).
Вы же говорите, как мне кажется, о другом типе систем.
Поэтому, скорее всего, противоречия нет.
Но у меня возник вопрос: а почему "наличие ASSERT категорически недопустимо"?
Если все предусловия верны, то ASSERT никак себя не проявит. А если где-то предусловие не выполняется, то, не исключено, что генерация исключения — меньшее из зол. (Я не утверждаю, что всегда.)

AVC,

> Но у меня возник вопрос: а почему "наличие ASSERT категорически недопустимо"?

При достаточно глубоких проверках, ASSERT's могут быть очень дороги. Например, это так в отладочной версии STLport, проверяющей валидность и принадлежность итераторов одному контейнеру и т.п.

Posted via RSDN NNTP Server 2.0

    internal void Fill(TDataSet dataSet) {
      // Объявлена как internal, то есть я могу и должен проконтролировать все вызовы
      // Во время отладки не "замылится", заявит о себе так, что внимания не обратить невозможно…
      Debug.Assert(dataSet != null, "dataSet != null"); 

      // Но если не проконтролировал - чтож, и такое случается  :shuffle: 
      // … а в релизе сообщит об ошибке и программа продолжит работать.
      if(dataSet == null) {
        throw new ArgumentNullException("dataSet"); // Если недосмотрел, то вместо NullReferenceException получу нечно более осмысленное.
      }//if

      // …
    }

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

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

СГ>… для клиента, который пишет для неё (и отлаживает) свои компоненты, она никакая не «релизная».

Для таких целей можно у разработчиков используемой библиотеки попросить Debug-версии с символами. Майкрософт предоставляет.

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

>> Но у меня возник вопрос: а почему "наличие ASSERT категорически недопустимо"?

ПК>При достаточно глубоких проверках, ASSERT's могут быть очень дороги. Например, это так в отладочной версии STLport, проверяющей валидность и принадлежность итераторов одному контейнеру и т.п.

Т.е. первый (и самый очевидный) ответ — по причине больших накладных расходов.
Понятно, что в релизной версии предпочитают не сипользовать отладочную версию STLport.
Но, ИМХО, это не означает категорической недопустимости ASSERT в релизе, а является некоторым (разумным) компромиссом между надежностью и эффективностью.
(Предложение реализовать итераторы (STL) таким образом, чтобы необходимые проверки осуществлялись эффективно, я опускаю. Наверное, это выше человеческих сил.

)
Но отдельное (stand-alone) приложение с использованием STL мы можем "вылизать", выловив (почти) все ошибки.
А что делать с программным компонентом, который будет использоваться неизвестно кем и неизвестно как?
Например, зловредными индусами, которыми нас тут недавно стращали.

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

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

про это еще Страуструп говорил
примененять защитные проверки в debug конфигурации и отключать их в release — это всё равно что плавать на корабле с полным набором спасательных кругов и шлюпок возле берега, и сгружать их на берег перех выходом в открытое море.

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

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

Pzz>А чем этот VERIFY отличается от ASSERT'а, кроме названия?

#ifdef _DEBUG
#definr VERIFY(f) ASSERT(f)
#else
#define ASSERT(f) ((void)0)
#define VERIFY(f) ((void)f)
#endif

Это вырезка из AFX.H

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

AVC>Например, зловредными индусами, которыми нас тут недавно стращали.

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

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

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

С другой стороны, если я в release версии своего компонента оставлю все ASSERTs, и в один прекрасный момент вы обнаружите, что срабатывает ASSERT где-то на двенадцатом уровне вызовов, чем вам это поможет?

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

СГ>Почему нельзя отключать ASSERT-ы в релизе

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

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

Д>про это еще Страуструп говорил
Д>примененять защитные проверки в debug конфигурации и отключать их в release — это всё равно что плавать на корабле с полным набором спасательных кругов и шлюпок возле берега, и сгружать их на берег перех выходом в открытое море.

Да-да, еще Страуструп.
А до Страуструпа — еще Хоар.

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

AVC>>Например, зловредными индусами, которыми нас тут недавно стращали.

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

AF>Почему-то постоянно кто-то пытается использовать ASSERTs для того, для чего они не предназначены.

Покажите мне этих негодяев, я им задам!

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

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

AF>С другой стороны, если я в release версии своего компонента оставлю все ASSERTs, и в один прекрасный момент вы обнаружите, что срабатывает ASSERT где-то на двенадцатом уровне вызовов, чем вам это поможет?

В BlackBox (как и в большинстве Оберон-систем) практически нет разницы между release и debug.
Отладочная информация не включается в код, а в случае срабатывания "ловушки" восстанавливается RTS.
Недавно подобный факт открыл для себя VladD2, правда, теоретически — при чтении статьи об одном из способов обработки исключений в Обероне. (Кажется, он думал, что Сергей об этом не знал.

)
на Ваш вопрос отвечаем: в результате срабатывания ASSERT на двенадцатом уровне вызовов мы можем восстановить полную информацию о всех 12 подпрограммах, и даже больше. По крайней мере, в BlackBox.

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

GZ>Честно говоря, релизный код не должен содержать ошибок.

Естественно, но дело не в ошибках внутри Вашего модуля (а я говорю именно о модулях — бинарниках). Ошибок внутри релизного модуля быть, конечно, не должно, но и ASSERT-ы в нём не должны быть отключены.

Причина запрета отключения ассертов в модуле находится не внутри модуля, а вне его.

Другой разработчик, разрабатывая свои модули взаимодействующие с Вашим (безошибочным) модулем, сам может ошибаться. Так вот, чтобы ошибка из его модуля не пролезла внутрь Вашего — Ваш модуль должен тщательно "обороняться". Оставленные ассерты — это "оборона" Вашего (безошибочного) модуля от ошибок других программистов в других модулях (чтоб ошибки не проникали из одного модуля внутрь другого).

Pavel Dvorkin wrote:
>
> Pzz>А чем этот VERIFY отличается от ASSERT'а, кроме названия?
>
> #ifdef _DEBUG
> #definr VERIFY(f) ASSERT(f)
> #else
> #define ASSERT(f) ((void)0)
> #define VERIFY(f) ((void)f)
> #endif

Т.е., VERIFY, это ASSERT для идиотов, допускает без последствий проверки
с побочными эффектами?

Posted via RSDN NNTP Server 2.0

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

AVC>А до Страуструпа — еще Хоар.

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

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

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

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

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

С уважением, Gleb.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

>> #define VERIFY(f) ((void)f)

Pzz>Т.е., VERIFY, это ASSERT для идиотов, допускает без последствий проверки
Pzz>с побочными эффектами?

Идиоты как раз те, кто пишет

some_debug_assert(stream != NULL && ptr != NULL);
if (!stream || !ptr)
{
  ...
  return E_INVALIDARG;
}

или

{
  BOOL bRv = CloseHandle(...);
  ASSERT(bRv);
}

вместо

if (!some_verify(stream != NULL && ptr != NULL))
{
  ...
  return E_INVALIDARG;
}

или

VERIFY(CloseHandle(...));

if (handle == INVALID_VALUE)
{
  // throw "grenade";
  return ERROR_INVALID_ARGUMENT;
}

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

Будет ли каждой такой проверке сопутствовать дебажный ASSERT(), дело программиста.

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

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

СГ>>Почему нельзя отключать ASSERT-ы в релизе

SK>Лучше использовать настраиваемые логи, тогда вопрос о том, что отключать в релизе, а что нет, просто не будет существовать, т.к. это можно будет сделать в любой момент.
Логи не спасают. В них смотрят только тогда, когда наблюдаемое поведение системы не соответствует ожиданиям. Более того, в них смотрят только тогда, когда наблюдаемое поведение системы включает вывод транспаранта "А-А-А-А! Случилась страшная фигня! Ничего не заработает, пока ты не посмотришь в логи!"
Логи по хорошему нужны для того, чтобы когда пользователь видит фразу "Невозможно выполнить операцию. Обратитесь к администратору", администратору было куда посмотреть для обнаружения дополнительной информации вроде "Попытка обратиться к ресурсу за пределами домена, отклонена в соответствии с установленной политикой безопасности". Потому, что администратор знает, что такое домен, ресурс, и политика безопасности. (А пользователь, естественно, не знает). Также логи полезны для того, чтобы когда администратор пишет в суппорт письмо о том, что "internal error 5412", ему было что приложить к этому письму, облегчая саппорту гадание на кофейной гуще. Потому, что саппорт знает, что такое "ResourceAcquisitionException at ...Utils.ResourceHelper.Copy(IResourceItem source, IResourceItem target, ResourceCopyFlags options)". (А админ, естественно, не знает).

1.1.4 stable rev. 510

Здравствуйте, GlebZ,

Всё наоборот.

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

GZ>1. Роль — программист который делает модуль. Для него ассерт как таковой информативен, поскольку несет в себе информацию о месте возникновения ошибки. Имея место, существует надежда что он может локализовать ошибку.

У него ассерты не срабатывают никогда, так как его модуль не содержит ошибок.

GZ>2. Роль — программист-клиент модуля. Для него ассерт по боку. Если он получит ассерт, то единственное что он поймет что где-то что-то у нас порой. Для него нужна более информативная ошибка о неверных параметрах, и каким образом он дошел до такой жизни.

Наоборот.
Для программиста второго модуля эти ассерты очень даже информативны, так как показывают, что он использовал первый модуль не так как положено. Он смотрит на полученное сообщение об ошибке (весь стек вызова со всеми полями объектов):

понимает, что это он — дурак и исправляет ошибку в своём модуле.

GZ>3. Роль — клиент.

А клиент, тут вообще не причем. Ему поставляется система без ошибок.

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

СГ>>>Почему нельзя отключать ASSERT-ы в релизе
SK>>Лучше использовать настраиваемые логи, тогда вопрос о том, что отключать в релизе, а что нет, просто не будет существовать, т.к. это можно будет сделать в любой момент.
S>Логи не спасают. В них смотрят только тогда, когда наблюдаемое поведение системы не соответствует ожиданиям. Более того, в них смотрят только тогда, когда наблюдаемое поведение системы включает вывод транспаранта "А-А-А-А! Случилась страшная фигня! Ничего не заработает, пока ты не посмотришь в логи!"
S>Логи по хорошему нужны для того, чтобы когда пользователь видит фразу "Невозможно выполнить операцию. Обратитесь к администратору", администратору было куда посмотреть для обнаружения дополнительной информации вроде "Попытка обратиться к ресурсу за пределами домена, отклонена в соответствии с установленной политикой безопасности". Потому, что администратор знает, что такое домен, ресурс, и политика безопасности. (А пользователь, естественно, не знает). Также логи полезны для того, чтобы когда администратор пишет в суппорт письмо о том, что "internal error 5412", ему было что приложить к этому письму, облегчая саппорту гадание на кофейной гуще. Потому, что саппорт знает, что такое "ResourceAcquisitionException at ...Utils.ResourceHelper.Copy(IResourceItem source, IResourceItem target, ResourceCopyFlags options)". (А админ, естественно, не знает).

Ты о чем пишешь? О том, что плохо в логах и или о том, что иногда надо использовать вместо них ассерты?
Что касается ассертов, то ASSERT пользователю полездного скажет еще меньше, чем логи. Реальзация ассертов в большинстве случаев сильно страдает из-за своей неуниверсальности. Что ты будешь делать с с ассертами на сервере или в сервисе? В большистве случаев придется их выкинуть в релизной версии. Зачем они тогда вообще нужны? Самые сложные ошибки как раз в релизах. Надо забыть про ASSERTы и писать логи.

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

Pzz>Т.е., VERIFY, это ASSERT для идиотов, допускает без последствий проверки
Pzz>с побочными эффектами?

Я така дкмаю, что идиоты могут использовать и то и другое там, где не надо, но зачем нам думать об идиотах ?

Ассерт — это не обязательно вывод дебильного окошка с тремя вариантами. MSVC позволяет кастомизировать поведение ассертов (см. _CrtSetReportHook) — для сервера меня вполне устроит "int 3" вместо окошка или хотя бы запись в лог. Для более других компиляторов никто не запрещает перекрыть #define assert и делать в нём то что считаешь нужным. Я лично могу себе представить только одну ситуацию когда assert становится вредным — в случае написания какого-нибудь супертребовательного к реалтайму софта, где лишняя проверка не позволит влезть в требования по производительности. Но и в таком софте, подозреваю, мест где asssert поставить нет возможности вряд ли будет много.

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

СГ>Почему нельзя отключать ASSERT-ы в релизе

Все это напомнило мне давний фидошный флейм о том, нужна ли проверка на NULL в Сишной функции strlen. Я считаю, что данная конкретная проверка (на NULL в strlen) однозначно классифицируется как паранойя. .

McSeem2 wrote:
>
> СГ>*Почему нельзя отключать ASSERT-ы в релизе*
>
> Все это напомнило мне давний фидошный флейм о том, нужна ли проверка на
> NULL в Сишной функции strlen. Я считаю, что данная конкретная проверка
> (на NULL в strlen) однозначно классифицируется как паранойя. .

Мне приходилось иметь дело с компилятором, в рантайме которого вызов
функции memchr( s, c, 0 ) возвращал s + 1 (а не NULL) для любых значений
s и c.

Posted via RSDN NNTP Server 2.0

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

AVC>В BlackBox, хелп к которому цитировал Губанов, ASSERT именно этим и занимается.
AVC>И как Вы правильно сказали, определенные требования к аргументам являются частью интерфейса компонента.
AVC> Поэтому отключать ASSERT в таких условиях нельзя. О чем опять же правильно написано в этом хелпе.

А что произойдет если компоненту передать неправильные аргументы?
Идеальный (с моей точки зрения) компонент вернет с помощью того или иного механизма ошибку, а клиент компонента вправе сам решать что ему делать в этом случае — падать или продолжать работать.
Оставляя ASSERT в компоненте программа аварийно завершится по инициативе компонента.
Вы считаете это правильным?

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

SK>Ты о чем пишешь? О том, что плохо в логах и или о том, что иногда надо использовать вместо них ассерты?
Я пишу о том, что не надо сводить задачу обеспечения устойчивости к записи "если чо" в лог. Система должна обеспечить изменение наблюдаемого поведения в случае обнаружения внутренних сбоев. Достигается ли это ассертами или верифаями — неважно.
SK>Что касается ассертов, то ASSERT пользователю полездного скажет еще меньше, чем логи. Реальзация ассертов в большинстве случаев сильно страдает из-за своей неуниверсальности.
Я не вижу в ассертах никакой неуниверсальности.
SK> Что ты будешь делать с с ассертами на сервере или в сервисе? В большистве случаев придется их выкинуть в релизной версии.
Например, перезапущу сервис. Выкину исключение пользователю. Да мало ли что можно сделать, кроме как выкинуть в релизной версии?

1.1.4 stable rev. 510

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

MS>А что произойдет если компоненту передать неправильные аргументы?
MS>Идеальный (с моей точки зрения) компонент вернет с помощью того или иного механизма ошибку, а клиент компонента вправе сам решать что ему делать в этом случае — падать или продолжать работать.
MS>Оставляя ASSERT в компоненте программа аварийно завершится по инициативе компонента.
MS>Вы считаете это правильным?

Так ведь об этом-то и речь! Против неправильных данных передаваемых внутрь компонента стоит именно ASSERT. Это потому, что в интерфейсе к компоненту чётко прописано какие данные в него передавать можно. В функцию Sqrt можно передавать только неотрицательные числа. В качестве индекса массива можно использовать только число из соответствующего диапазона. Делить на ноль нельзя и т.д. Если программа всё-таки позволяет себе передавать отрицательное число в Sqrt, неправильный индекс массива, собирается разделить на ноль и т.д., то значит программа — ошибочна — получи ассертом по башке и иди ищи ошибку.

MS>Оставляя ASSERT в компоненте программа аварийно завершится по инициативе компонента.

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

ASSERT — оборона одного компонента от других: тот кто собирается не правильно использовать этот компонент — жестоко поплатится за это.

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

Все мои дальнейшие рассуждения пойдут применительно C/C++ и похожих языках.

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

СГ>Здравствуйте, MShura, Вы писали:

MS>>А что произойдет если компоненту передать неправильные аргументы?
MS>>Идеальный (с моей точки зрения) компонент вернет с помощью того или иного механизма ошибку, а клиент компонента вправе сам решать что ему делать в этом случае — падать или продолжать работать.
MS>>Оставляя ASSERT в компоненте программа аварийно завершится по инициативе компонента.
MS>>Вы считаете это правильным?

СГ>Так ведь об этом-то и речь! Против неправильных данных передаваемых внутрь компонента стоит именно ASSERT. Это потому, что в интерфейсе к компоненту чётко прописано какие данные в него передавать можно. В функцию Sqrt можно передавать только неотрицательные числа. В качестве индекса массива можно использовать только число из соответствующего диапазона. Делить на ноль нельзя и т.д. Если программа всё-таки позволяет себе передавать отрицательное число в Sqrt, неправильный индекс массива, собирается разделить на ноль и т.д., то значит программа — ошибочна — получи ассертом по башке и иди ищи ошибку.

Ну вот мы и добрались до сути.
"Против неправильных данных передаваемых внутрь компонента стоит именно ASSERT" — это идеологически неверно. Если ASSERT испульзуется не по назначению (как в этом случае) тогда конечно его нельзя из релиза убирать.
Проверку неправильных данных обязана быть отработанна штатными средствами , и даже больше при тестировании "компонент" надо заваливать некоректными данными и убедиться , что он возвращает вменяемые ошибки.

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

Собственно Sqrt ведет себя вменяемо , на неправильные данные он реагирует исключением (или NAN), и уже дело программиста поставить ASSERT() на проверку аргумента перед отсылкой в Sqrt.

MS>>Оставляя ASSERT в компоненте программа аварийно завершится по инициативе компонента.

СГ>По инициативе-то оно по инициативе (первого) компонента, но по причине того, что другой (второй) компонент собирался неправильно использовать первый компонент. За это он (второй) получил по башке (от первого).

Это возможная ситуация при ОТЛАДКЕ приложения с использованием дебаговых библиотек.

СГ>ASSERT — оборона одного компонента от других: тот кто собирается не правильно использовать этот компонент — жестоко поплатится за это.

Это совершенно неправильное идеологически использование ASSERT, этим должны заниматься штатные средства обработки входных параметров (исключения, коды ошибок).

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

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

M>Проверку неправильных данных обязана быть отработанна штатными средствами , и даже больше при тестировании "компонент" надо заваливать некоректными данными и убедиться , что он возвращает вменяемые ошибки.

Штатность зависит от языка и системы. Например, в языке Component Pascal — ASSERT — это самое что ни на есть штатное средство, часть языка, а не внешняя библиотека.

M>А асерты в данном случае должен свавить пользователь компонента, перед тем как подавать данные на компонент, и на возвращаемый результат.

На те данные которые он впихивает в компонент? Зачем? Если он попытается впихнуть в компонент неправильные данные, то компонент сам ругнётся — чего это мол вы тут в меня впихиваете отрицательные числа, когда в интерфейсе ко мне явно прописано, что я принимаю только неортицательные! Он просто должен впихивать в компонент правильные данные или не впихивать их вовсе.

M>Собственно Sqrt ведет себя вменяемо , на неправильные данные он реагирует исключением (или NAN), и уже дело программиста поставить ASSERT() на проверку аргумента перед отсылкой в Sqrt.
...
M>Это совершенно неправильное идеологически использование ASSERT, этим должны заниматься штатные средства обработки входных параметров (исключения, коды ошибок).

Дык ASSERT — это (на машинном уровне) и есть исключение и внутри Sqrt он уже поставлен за нас.

Так что Sqrt — хороший пример компонента обороняющегося от ошибок внешних компонентов с помощью ASSERT(x >= 0) на входные данные.

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

Если менять названия, тогда уж лучше на такие: ASSERT.PRECONDITION(), ASSERT.INVARIANT(), ASSERT.POSTCONDITION().

Обратите внимание на разницу между двумя типами ситуаций:
1) Данные впихиваются в компонент другим компонентом.
2) Компонент самостоятельно пытается откуда-то взять данные.

В первом случае компонент над которым производят действие имеет право жестоко обороняться (с помощью ассертов/исключений).
Во втором случае компоненту оборонятся не от кого, т.е. ассерты/исключения и т.п. тут не при чём.

СГ>Так что Sqrt — хороший пример компонента обороняющегося от ошибок внешних компонентов с помощью ASSERT(x >= 0) на входные данные.

Сомневаюсь, что ASSERT в Sqrt нужен.
Sqrt просто может вернуть NaN и пусть клиент сам решает, что делать — падать или продолжать работать.
ASSERT просто обрушит программу не позволяя сохранить данные.

Я специально подчеркнул что , все мною излагаемое касалось C/C++.

Только позвольте поинтересоваться КАК в языке в котором ASSERT является штатным средством обработки неправильных данных , ASSERT вообще может убираться в релизе ?

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

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

GZ>>1. Роль — программист который делает модуль. Для него ассерт как таковой информативен, поскольку несет в себе информацию о месте возникновения ошибки. Имея место, существует надежда что он может локализовать ошибку.
СГ>У него ассерты не срабатывают никогда, так как его модуль не содержит ошибок.
Нет. Как раз у него и срабатывают assert на этапе разработки. Собственно он и есть пользователь assert. В дальнейшем они не нужны.

GZ>>2. Роль — программист-клиент модуля. Для него ассерт по боку. Если он получит ассерт, то единственное что он поймет что где-то что-то у нас порой. Для него нужна более информативная ошибка о неверных параметрах, и каким образом он дошел до такой жизни.
СГ>Наоборот.
СГ>Для программиста второго модуля эти ассерты очень даже информативны, так как показывают, что он использовал первый модуль не так как положено. Он смотрит на полученное сообщение об ошибке (весь стек вызова со всеми полями объектов):
СГ>понимает, что это он — дурак и исправляет ошибку в своём модуле.
Какая разница в основных языках у assert и exception. Разница маленькая, exception посылает текст ошибки, и assert кроме того что содержит место в исходниках где проверялось условие, предоставляет возможность загрузить отладчик. В случае релиза — первое нужно, а вот отладчик — совсем не нужен.

GZ>>3. Роль — клиент.
СГ>А клиент, тут вообще не причем. Ему поставляется система без ошибок.
Ну вообще-то нет. Клиент есть машина по генерации непредвиденных ситуаций. Ну а на непредвиденные ситуации также нужно обрабатывать и отвечать вразумительными ответами.

С уважением, Gleb.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

M>Я специально подчеркнул что , все мною излагаемое касалось C/C++.

Ну вот и хорошо.
А эту ветку форума я затеял как обсуждение фрагмента из хелпа к Блэкбоксу, т.е. для языка Component Pascal.

M>Только позвольте поинтересоваться КАК в языке в котором ASSERT является штатным средством обработки неправильных данных , ASSERT вообще может убираться в релизе ?

Дык он и не убирается. В этом весь смысл. Система Блэкбокс — расширяемая. Ни когда нельзя сказать, что вот теперь она окончательно готова и далее расширять ее запрещено.

M>тот ASSERT про кторый я говорю , не нужен в релизе , поскольку он полезен только разработчику модуля.

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

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

СГ>>Так что Sqrt — хороший пример компонента обороняющегося от ошибок внешних компонентов с помощью ASSERT(x >= 0) на входные данные.

MS>Сомневаюсь, что ASSERT в Sqrt нужен.
MS>Sqrt просто может вернуть NaN и пусть клиент сам решает, что делать — падать или продолжать работать.

Ну, тоже вариант. Если в интерфейсе Sqrt прописать, что она может возвращать NaN, то пусть возвращает...

MS>ASSERT просто обрушит программу не позволяя сохранить данные.

Это смотря какую программу. На Си/С++ — легко. В Блэкбоксе на Component Pascal — ничего подобного, там просто снимется выполнение этой ошибочной команды. Данные никуда пропадать от этого не обязаны — смотря как напишешь. Но не зависимо от этого, в любом случае — сработавший ассерт — это ошибка в программе и её надо переписывать.

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

M>>Только позвольте поинтересоваться КАК в языке в котором ASSERT является штатным средством обработки неправильных данных , ASSERT вообще может убираться в релизе ?
СГ>Дык он и не убирается. В этом весь смысл.

Тогда о чём статья вообще? Убедить разработчиков BlackBox, что и не надо такую возможность добавлять? А они читают этот форум?

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

GZ>Нет. Как раз у него и срабатывают assert на этапе разработки. Собственно он и есть пользователь assert. В дальнейшем они не нужны.

Наоборот. Посмотрите на эту ситуацию "наизнанку"

То что ассерт размещен в его коде — не означает что в его срабатывании виноват он. Ошибка снаружи.

Пример.
Я разработал компонент, который предназначен для вычисления квадратного корня из числа:

DEFINITION MySuperCalculator;
  
  PROCEDURE Sqrt (x: REAL): REAL; (* precondition x >= 0, 20 *)

END MySuperCalculator.

Я ЗАПРЕТИЛ впихивать внутрь моего компонента отрицательные числа. Для того чтобы мой запрет не был очередным "последним китайским предупреждением", я сказал, что тот кто попытается впихнуть в мой компонент отрицательное число, тот пожалеет об этом — здорово получит по мозгам, так как MySuperCalculator.Sqrt(x), я "заминировал ассертом" на проверку предусловия ASSERT(x >= 0)
Вот исходный код моего модуля:

MODULE MySuperCalculator;

  IMPORT Math;

  PROCEDURE Sqrt* (x: REAL): REAL;
  BEGIN
    ASSERT(x >= 0, 20); (* <-- это оборона от внешних по отношению к моему компоненту ошибок *)
    RETURN Math.Sqrt(x)
  END Sqrt;

END MySuperCalculator.

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

Тогда подрезюмирую.

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

2. НИКАКИЕ выводы сделанные о использовании ASSERT в BlackBox нельзя перносить на другие языки/платформы.

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

MS>>ASSERT просто обрушит программу не позволяя сохранить данные.

СГ>Это смотря какую программу. На Си/С++ — легко. В Блэкбоксе на Component Pascal — ничего подобного, там просто снимется выполнение этой ошибочной команды. Данные никуда пропадать от этого не обязаны — смотря как напишешь. Но не зависимо от этого, в любом случае — сработавший ассерт — это ошибка в программе и её надо переписывать.

Ладно я понимаю, как можно "снять выполнение ошибочной комманды" если значение Sqrt() нигде не сохраняется.
А если Sqrt() используется в выражении, то как можно "снять выполнение ошибочной комманды"?

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

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

double MySqrt(double x)
{
  ASSERT(x>0);//это внутренняя ошибка программиста пишущего модуль.
                            //при ее срабатывании поднимается отладчик, и этот программист
                            //может посмотреть что случилось
    if (x>0)
    throw new MyException("вы кормите MySqrt отрицательными значениями");//а вот это
                            //сообщение для некорректного программиста модуля
                            //ему будет вполне понятно что случилось
    return Math.Sqrl(x);
}

А теперь представь себе что это рассчет матриц в полумегабайтном коде и ошибка произошла на 10 уровне вложенности.

void CountMatrix()
{
  try
    {
    }
    catch(MyException e)
    {
      Logger.Write(e);
      throw new MyException("Произошла внутренняя ошибка. Бери трубку и звони производителям", e);
    }
}

Теперь понятна разница между ASSERT и EXCEPTION? Исключение мы можем представить пользователю в понятном виде, ассерт — никогда.

С уважением, Gleb.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

MS>Ладно я понимаю, как можно "снять выполнение ошибочной комманды" если значение Sqrt() нигде не сохраняется.
MS>А если Sqrt() используется в выражении, то как можно "снять выполнение ошибочной комманды"?

Как снять выполнение команды не потеряв при этом данные?

Интерфейс модуля:

DEFINITION MyModule;

 PROCEDURE Command1;
 PROCEDURE Command2

END MyModule.

Исходный текст модуля:

MODULE MyModule;

  IMPORT 
    ...

  TYPE
    MyData = ...

  VAR
    data: MyData;

 PROCEDURE Init;
 BEGIN (* инициализация данных *)
 END Init;

 PROCEDURE Command1*;
 BEGIN (* код команды 1, выполняющей операцию с данными data *)
 END Command1;

 PROCEDURE Command2*;
 BEGIN (* код команды 2, выполняющей операцию с данными data *)
 END Command2;

 PROCEDURE Close;
 BEGIN (* закрытие данных *)
 END Close;

BEGIN
  Init
CLOSE
  Close  
END MyModule.

Выполняя процедуры: MyModule.Command1, MyModule.Command2 как команды, мы не потеряем данные data даже если выполнение этих команд будет аварийно завершено.

Команда — это средство предоставляемое системой. Фактически это есть запуск процедуры по её (текстовому) имени "MyModule.MyCommand" (допустимые типы аргументов процедуры предопределены системой, в частности — любую процедуру без параметров можно выполнять как команду). Запуск команды делается системой внутри системной ловушки, так что если внутри процедуры происходит "авария", то "исключение" ловится системной ловушкой. Это всё равно что в Windows/Linux в командной строке набрать имя программы и нажать Enter — программа будет запущена по имени, а в оберон-системах, в любом текстовом документе пишете имя процедуры: MyModule.MyCommand, выделяете мышью и нажав на соответсвующий пункт меню запускаете эту процедуру на выполнение как команду (разумеется есть масса других способов инициировать выполнение команды, в том числе и в "фоновом" режиме — не одной же коммандной строкой ограничиваться). Если модуль MyModule не был загружен в память, то он автоматически загружается. Выгрузить его можно потом выполнив другую специальную системную команду. Команда в оберон-системе в этом смысле похожа на программу в Windows/Linux. Снять выполнение текущей команды (если она что-то долго выполняется и быть может зависла) можно нажав на клавиатуре кнопку Break (аналог Ctrl+Alt+Del в Windows).

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

GZ>Теперь понятна разница между ASSERT и EXCEPTION? Исключение мы можем представить пользователю в понятном виде, ассерт — никогда.

Это у Вас в С++ так, а у нас в Component Pascal подругому — exteption нету, а вместо них есть ASSERT

Ну, а что касается пользователя, то единственный понятный вид сообщения об ошибке для него таков:

"В программе обнаружена ошибка, поэтому использование программы далее — бессмысленно. Обратитесь к разработчику."

всё остальное ему до лампочки...

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

MS>>Ладно я понимаю, как можно "снять выполнение ошибочной комманды" если значение Sqrt() нигде не сохраняется.
MS>>А если Sqrt() используется в выражении, то как можно "снять выполнение ошибочной комманды"?

СГ>Как снять выполнение команды не потеряв при этом данные?

СГ>Команда в оберон-системе в этом смысле похожа на программу в Windows/Linux. Снять выполнение текущей команды (если она что-то долго выполняется и быть может зависла) можно нажав на клавиатуре кнопку Break (аналог Ctrl+Alt+Del в Windows).

Интересно.

А если эта команда вызывает 10 других команд, или рекурсивно саму себя, что именно будет прервано? Как поведут себя внешние по отношению к этой команды?

Что будет, если вызывающий ожидает от команды возвращаемого значения (через var-параметр или результат функции), как ему продолжить выполнение, если результата он не получил? Как он узнает, что было прерывание и результат не получен?

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

СГ>Это у Вас в С++ так, а у нас в Component Pascal подругому — exteption нету, а вместо них есть ASSERT

Тогда тему нужно было обзывать "Почему нельзя отключать ASSERT-ы Component Pascal в релизе"

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

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

Pzz>И что это за задачи такие?

Первое, что пришло в голову, например марсоход NASA

... << RSDN@Home 1.2.0 alpha rev. 619>>

0rc wrote:
>
> Pzz>И что это за задачи такие?
>
> Первое, что пришло в голову, например марсоход NASA

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

Что должна делать программа марсохода при обнаружении _внутренней
ошибки_ на Марсе, когда ASSERT отключен (а ошибка не отключена)?

Posted via RSDN NNTP Server 2.0

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

Pzz>Что должна делать программа марсохода при обнаружении _внутренней
Pzz>ошибки_ на Марсе, когда ASSERT отключен (а ошибка не отключена)?

А если ASSERT включен на Марсе, что тогда, легче будет?
Я бы не применял в таких программах вообще ASSERT и проектировал бы с таким важным условием.

Pzz wrote:

> Что должна делать программа марсохода при обнаружении _внутренней
> ошибки_ на Марсе, когда ASSERT отключен (а ошибка не отключена)?

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

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

Posted via RSDN NNTP Server 2.0

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

>> Что должна делать программа марсохода при обнаружении _внутренней
>> ошибки_ на Марсе, когда ASSERT отключен (а ошибка не отключена)?

C>Перезагружать систему, после N перезагрузок входить в безопасный режим.

...командировать специалиста...

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

Кё>Интересно.

Кё>А если эта команда вызывает 10 других команд, или рекурсивно саму себя, что именно будет прервано? Как поведут себя внешние по отношению к этой команды?

Кё>Что будет, если вызывающий ожидает от команды возвращаемого значения (через var-параметр или результат функции), как ему продолжить выполнение, если результата он не получил? Как он узнает, что было прерывание и результат не получен?

1) Это процедура может вызвать саму себя, но это будут вызовы в контексте одной и той же команды.
2) Никакого возвращаемого значения у команды нет.

В Обероне задачи бывают двух типов: интерактивные и фоновые. Команда — это интерактивная задача, её исполнение инициирует непосредственно пользователь (отдаёт команду — отсюда и название). Фонововые задачи запускает (ставит в очередь исполнения) либо сам пользователь, либо другие задачи (команды), в том числе и фоновые. Ситуация описанная Вами, по всей видимости, решается через фоновые задачи. Например так: одна задача ставит в очередь задач другую и засыпает, потом просыпается и смотрит что произошло. В Блэкбоксе фоновые задачи представлены расширениями типа Services.Action

DEFINITION Services;

  CONST
    immediately = -1;
    now = 0;

    resolution = 1000;

  TYPE
    Action = POINTER TO ABSTRACT RECORD 
      (a: Action) Do-, NEW, ABSTRACT
    END;

  ...

  PROCEDURE DoLater (a: Action; notBefore: LONGINT);
  PROCEDURE RemoveAction (a: Action);

  ...

  PROCEDURE Ticks (): LONGINT;

  ...

END Services.

Метод Action.Do — это квант работы задачи (многозадачность в Блэкбоксе кооперативная), он выполняется в окружении системной ловушки и если в нём произойдёт авария, то эта задача будет снята. Задача должна каждый раз себя устанавливать заново после каждого "такта" своей работы: Services.DoLater(task, Services.Ticks() + milliseconds);

СГ>Задача должна каждый раз себя устанавливать заново после каждого "такта" своей работы: Services.DoLater(task, Services.Ticks() + milliseconds);

Естественно, только если ей это нужно...

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

M>Тогда подрезюмирую.

M>1. Разработчики внесли ASSERT в свои библиотеки подразумевающий другую идеологию использования, чем это общепринято испторически.

M>2. НИКАКИЕ выводы сделанные о использовании ASSERT в BlackBox нельзя перносить на другие языки/платформы.

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

Стыд и позор также Стиву Макконелу за такие вот мысли:

По мере возможности делайте интерфейсы программными, а не семан-
тическими Каждый интерфейс состоит из программной и семантической
частей. Первая включает типы данных и другие атрибуты интерфейса, которые могут
быть проверены компилятором. Вторая складывается из предположений об ис-
пользовании интерфейса, которые компилятор проверить не может. Семантический
интерфейс может включать такие соображения, как «Метод А должен быть выз-
ван перед Методом B» или «Метод А вызовет ошибку, если переданный в него Эле-
мент Данных 1 не будет перед этим инициализирован». Семантический интерфейс
следует документировать в комментариях, но вообще интерфейсы должны как
можно меньше зависеть от документации. Любой аспект интерфейса, который не
может быть проверен компилятором, является потенциальным источником оши-
бок. Старайтесь преобразовывать семантические элементы интерфейса в програм-
мные, используя утверждения (assertions) или иными способами.

А вот такой фрагмент тебя не заставляет задуматься:

Любой аспект интерфейса, который не
может быть проверен компилятором, является потенциальным источником ошибок.

?

assert в рантайме не есть проверка компилятором, тебе так не кажется?
Имхо Стиву как раз ни разу не стыд и не позор.

AVC>Стыд и позор также Стиву Макконелу за такие вот мысли:
AVC>

AVC>... Старайтесь преобразовывать семантические элементы интерфейса в програм-
AVC>мные, используя утверждения (assertions) или иными способами.

Есть практические рекомендации, как этого достигать? С примерами?

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

К>А вот такой фрагмент тебя не заставляет задуматься:
К>

К>Любой аспект интерфейса, который не
К>может быть проверен компилятором, является потенциальным источником ошибок.

К>?

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

Я что-то переврал?
В приведенной цитате Макконнелла не содержалось совета использовать утверждения?
Или я отрицал важность статического контроля типов?
В чем претензия?

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

AVC>>Стыд и позор также Стиву Макконелу за такие вот мысли:
AVC>>

AVC>>... Старайтесь преобразовывать семантические элементы интерфейса в програм-
AVC>>мные, используя утверждения (assertions) или иными способами.

MP>Есть практические рекомендации, как этого достигать? С примерами?

Да, есть.
См. главы 11 и 12 книги Мейера "Объектно-ориентированное конструирование программных систем".
Там вводится понятие Design By Contract (проектирование по контракту).
А одним из примеров в 12-й главе является как раз функция вычисления квадратного корня sqrt(x).

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

AVC>Я что-то переврал?
AVC>В приведенной цитате Макконнелла не содержалось совета использовать утверждения?

AVC>Или я отрицал важность статического контроля типов?
Речь у Сергея о динамических проверках, minorlogic же говорил, что они по смыслу не совпадают с нормальными статическими assert'ами, принятыми в других языках (насколько я это понял).
Ты же привёл как раз цитату о статических проверках, противопоставляя утверждению о них же по сути.
AVC>В чем претензия?
Претензия к неправомерности твоей претензии.

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

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

AVC>>>Стыд и позор также Стиву Макконелу за такие вот мысли:
AVC>>>

AVC>>>... Старайтесь преобразовывать семантические элементы интерфейса в програм-
AVC>>>мные, используя утверждения (assertions) или иными способами.

MP>>Есть практические рекомендации, как этого достигать? С примерами?

AVC>Да, есть.
AVC>См. главы 11 и 12 книги Мейера "Объектно-ориентированное конструирование программных систем".
AVC>Там вводится понятие Design By Contract (проектирование по контракту).
AVC>А одним из примеров в 12-й главе является как раз функция вычисления квадратного корня sqrt(x).

Статью про контрактное программирование читал. Еще что-нибудь интересное есть? Можете ссылку дать?

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

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

AVC>>Я что-то переврал?
AVC>>В приведенной цитате Макконнелла не содержалось совета использовать утверждения?

AVC>>Или я отрицал важность статического контроля типов?
К>Речь у Сергея о динамических проверках, minorlogic же говорил, что они по смыслу не совпадают с нормальными статическими assert'ами, принятыми в других языках (насколько я это понял).
К>Ты же привёл как раз цитату о статических проверках, противопоставляя утверждению о них же по сути.
AVC>>В чем претензия?
К>Претензия к неправомерности твоей претензии.

Вообще-то говоря, assert (=утверждать) — по определению связан именно с рантаймом.
Утверждение привязано к определенной точке выполнения программы.
Интересно, в каком же это языке иначе сделано?

Во всяком случае — не в Си/Си++.
Другое дело, что иногда компилятор может вычислить значение утверждения (оно константно).
Например, BlackBox отказывается компилировать следующий ASSERT:

  ASSERT(SIZE(INTEGER) # 4, 20);

и пишет: ASSERT fault.
Макконнелл же, ИМХО, призывает не оставлять интерфейсные семантические требования только в качестве благих пожеланий в документации, а вводить соответствующие им программные конструкции, например — ASSERT.

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

MP>Статью про контрактное программирование читал. Еще что-нибудь интересное есть? Можете ссылку дать?

Первое, что приходит в голову — упомянутый Сергеем Губановым BlackBox.
Там принцип программирования по контракту применяется "всерьез".
Вот пример из модуля Math:

    PROCEDURE ArcTan2* (y, x: REAL): REAL;
    BEGIN
        ASSERT((y # 0)  OR (x # 0), 20);
        ASSERT((ABS(y) # INF)  OR  (ABS(x)  # INF), 21);
        FLD(y); FLD(x); FATAN; WAIT; RETURN TOP()
    END ArcTan2;

Здесь где-то высказывалась мысль, что математические функции могли бы просто вернуть NaN. Дескать, ничего страшного.
Я с этой мыслью не согласен. (Хотя NaN и лучше, чем ошибочное значение, притворяющееся числом.)
AFAIK, на BlackBox написаны программы, производящие очень сложные и длительные вычисления. Некоторые из этих программ могут требовать нескольких месяцев вычислений. А теперь представьте себе, что Вы дождались и наконец получили долгожданный результат. И читаете: NaN.
Что Вы после этого скажете о программистах, не следующих принципу контрактного программирования?
Конечно, принцип программирования по контракту применяется не только в вычислительных задачах.
Вот другой простой пример: проход по списку. У Вас есть две функции: First и Next.
Предусловием цепочки вызовов Next является предварительный вызов First, инициализирующий итератор и присваивающий ему значение первого элемента в списке или NIL, если список пуст.
И т.д. и т.п.
Если Вас заинтресуют исходные тексты BlackBox (на предмет использования в них design-by-contract), то вот сайт Oberon Microsystems Inc.:
http://www.oberon.ch

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

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

MS>>А что произойдет если компоненту передать неправильные аргументы?
MS>>Идеальный (с моей точки зрения) компонент вернет с помощью того или иного механизма ошибку, а клиент компонента вправе сам решать что ему делать в этом случае — падать или продолжать работать.

Поддерживаю

MS>>Оставляя ASSERT в компоненте программа аварийно завершится по инициативе компонента.
MS>>Вы считаете это правильным?

Только если вы автор и клиента и компоненты. Хотя это все равно неправильно.

СГ>Так ведь об этом-то и речь! Против неправильных данных передаваемых внутрь компонента стоит именно ASSERT. Это потому, что в интерфейсе к компоненту чётко прописано какие данные в него передавать можно. В функцию Sqrt можно передавать только неотрицательные числа. В качестве индекса массива можно использовать только число из соответствующего диапазона. Делить на ноль нельзя и т.д. Если программа всё-таки позволяет себе передавать отрицательное число в Sqrt, неправильный индекс массива, собирается разделить на ноль и т.д., то значит программа — ошибочна — получи ассертом по башке и иди ищи ошибку.

Мощно, однако. Особенно, когда речь идет про невизуальные компоненты, работающие в невизуальном клиенте. Типа OLEDB провайдера в MSSQL сервере, обслуживающем промышленную базу данных. Тебе потом за этот assert клиенты такой ... вломят — "мама не горюй"

СГ>ASSERT — оборона одного компонента от других: тот кто собирается не правильно использовать этот компонент — жестоко поплатится за это.

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

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

>>> Что должна делать программа марсохода при обнаружении _внутренней
>>> ошибки_ на Марсе, когда ASSERT отключен (а ошибка не отключена)?

C>>Перезагружать систему, после N перезагрузок входить в безопасный режим.

Кё>...командировать специалиста...

Шутки — шутками, а один из "ненаших" сторонников Лиспа, насколько я помню, где-то писал про "незабываемые впечатления от использования REPL, работающего где-то там на расстоянии N километров". REPL использовался для отладки/исправления ошибок, естественно.

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

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

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

AVC>Стыд и позор также Стиву Макконелу за такие вот мысли:

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

Дык надо различать понятие внешних и внутренних интерфейсов.

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

А вот параметры внешних интерфейсов, извольте проверять без вот этих крайностей. Поскольку трубу могут не услышать. А за терминирование могут сразу дать по башке. Правильно, не правильно — это потом разбираться будут.

Более того, кто писал компоненты для DCOM, тот обычно прорюхивает еще одно правило внешних интерфейсов — сначало проинициализируй OUT-параметры, а уж потом проверяй IN-параметры и возвращай всякие там коды ошибок.

Кстати еще один замечательный пример — компонент может использоваться в дизайнере. И что — если юзер (ну программер, то есть), указал в инспекторе не то значение — нам всю студию закрывать что ли? Типа "ах ты, негодяй такой, а еще программировать лезешь!"

Здравствуйте, Коваленко Дмитрий, Вы писали:

КД>Дык надо различать понятие внешних и внутренних интерфейсов.

Если можно, уточните, что Вы понимаете под внутренними и внешними интерфейсами.
На всякий случай скажу, что принцип проектирования по контракту не применяется к операциям ввода/вывода.

КД>Кстати еще один замечательный пример — компонент может использоваться в дизайнере. И что — если юзер (ну программер, то есть), указал в инспекторе не то значение — нам всю студию закрывать что ли? Типа "ах ты, негодяй такой, а еще программировать лезешь!"

ASSERT не ведет к "терминированию" BlackBox.
Думаю, что и для других программ "терминирование" необязательно.

ИМХО, Сергей Губанов затронул очень серьезную тему: что делать, если обеспечить корректную работу компонента в сложившихся обстоятельствах невозможно.
(Единственное критическое замечание, которое я могу сделать: ИМХО, он слишком много раз употребил выражение "дать по башке". Создается впечатление, что ПО — это война всех против всех, а компонент компоненту — волк.

)
Кроме прочих причин невозможности обеспечить корректную работу компонента, назову две.
1) Ограничения реализации. Вам надо получить сумму X и Y, а у Вас случилось переполнение. Такая жалость!

2) Частичные функции. Функция применима не ко всем сочетаниям элементов входных множеств.
Простые примеры:
— sqrt(x) неприменима к случаю x < 0:
— inv(x) = 1/x неприменима к случаю x = 0.
В основном, тема, затронутая Сергеем, относится ко второму случаю.
Подчеркну, что (ИМХО) причина этой ситуации не может быть устранена полностью, т.к. здесь мы упираемся в математический факт. А именно — существование частичных функций.
Думаю, что существует не единственный способ бороться с этой бедой.

Например, на здешних форумах сторонники Си++ не раз приводили примеры классов, гарантирующих некоторые свойства своих объектов. Например, класс реализует указатель и гарантирует, что он — ненулевой.
Я с интересом читаю подобные посты, но мне кажется, что подобный "укрепленный" код не слишком читабелен. (Здесь — жирное ИМХО, конечно.)
На мой взгляд, ASSERT (или другое синтаксическое средство проверки утверждений), проверяющие предусловия подпрограммы (метода) — проще. И потому предпочтительнее в использовании.

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

КД>>Дык надо различать понятие внешних и внутренних интерфейсов.

AVC>Если можно, уточните, что Вы понимаете под внутренними и внешними интерфейсами.

Если уточнять на конкретном примере, то COM-интерфейсы — относятся к категории внешних. А интерфейс, например, std::vector — к категории внутренних. По крайней мере — в моей голове именно такое представление об устройстве мира.

AVC>ИМХО, Сергей Губанов затронул очень серьезную тему: что делать, если обеспечить корректную работу компонента в сложившихся обстоятельствах невозможно.

Компонентная технология сама по себе тема серьезная. И компромиссы с реальной практикой здесь играют не последнюю роль.

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

AVC>Стыд и позор также Стиву Макконелу за такие вот мысли:

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

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

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

К>>Претензия к неправомерности твоей претензии.

AVC>Вообще-то говоря, assert (=утверждать) — по определению связан именно с рантаймом.
На основаниии чего ты такое утверждаешь?
Чем утверждение времени компиляции не утверждение?
Прочитай ещё раз приведённую тобой цитату и покажи — где там рантайм есть? (про компилятор я тебе уже показывал)

Кратко о C/C++:
Assert — с которым я знаком это элемент контроля ошибок ПРОГРАММИСТА а не программы.
У программы есть свои методы контроля, исключения к примеру, коды ошибок.

И большая неразбериха возникнет если путать инструменты и использовать их не по назначению.

Здравствуйте, Коваленко Дмитрий, Вы писали:

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

Ваша мысль в той или иной форме здесь уже многократно высказывалась. И я на неё уже отвечал (в той или иной форме). Потрудитесь сначала прочитывать все сообщения...

AVC>Здесь где-то высказывалась мысль, что математические функции могли бы просто вернуть NaN. Дескать, ничего страшного.
AVC>Я с этой мыслью не согласен. (Хотя NaN и лучше, чем ошибочное значение, притворяющееся числом.)
AVC>AFAIK, на BlackBox написаны программы, производящие очень сложные и длительные вычисления. Некоторые из этих программ могут требовать нескольких месяцев вычислений. А теперь представьте себе, что Вы дождались и наконец получили долгожданный результат. И читаете: NaN.
Если в документации к Sqrt написано, что в случае ошибки она вертает NaN, а вы никогда результат не проверяете, то виноваты будете именно вы.

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

AVC>>Здесь где-то высказывалась мысль, что математические функции могли бы просто вернуть NaN. Дескать, ничего страшного.
AVC>>Я с этой мыслью не согласен. (Хотя NaN и лучше, чем ошибочное значение, притворяющееся числом.)
AVC>>AFAIK, на BlackBox написаны программы, производящие очень сложные и длительные вычисления. Некоторые из этих программ могут требовать нескольких месяцев вычислений. А теперь представьте себе, что Вы дождались и наконец получили долгожданный результат. И читаете: NaN.
MS>Если в документации к Sqrt написано, что в случае ошибки она вертает NaN, а вы никогда результат не проверяете, то виноваты будете именно вы.

Совершенно согласен.
Допустим, я всегда проверяю значение, возвращаемое функцией sqrt, на предмет, является ли оно числом.
Значит ли это, что теперь я могу спокойно "подсовывать" этой функции отрицательный аргумент, не утруждая себя проверкой его на неотрицательность?
И разве следующий код

    y = sqrt(x);
    if (IsNaN(y)) { ... }

лучше, чем

    if (x >= 0.0)
        у = sqrt(x);
    else { ... }

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

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

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

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

К>>>Претензия к неправомерности твоей претензии.

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

На основании того, что есть такое понятие — мониторинг утверждений.
И того, что assert() в Си/Си++ в случае невыполнения утверждения вызывает abort().
Вызывать abort() необязательно (это крайность), но согласись, что вызов abort() имеет смысл только для рантайма.
Не компилятор же будет терминироваться.

К>Чем утверждение времени компиляции не утверждение?

Частный (вырожденный) случай утверждения.

К>Прочитай ещё раз приведённую тобой цитату и покажи — где там рантайм есть? (про компилятор я тебе уже показывал)

Покажи, где его там нет.

Приведи пример осмысленного использования assertion в твоем понимании.
Вот Сергей Губанов привел такой пример:

PROCEDURE Sqrt(x: REAL): REAL;
BEGIN
  ASSERT(x >= 0.0, 20);

Хороший это пример или плохой, наверное, можно спорить.
Но он осмысленный.
А вот вы на пару с minorlogic пока кроме особо изысканного

assert(sizeof(int) == 32); /* почему именно 32, я не понял */

ничего путного пока не предложили (имхо, конечно

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

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

if (!CloseHandle(...))
    throw InvalidHandleException("Все козлы! Жизнь не удалась с самого утра :(!");

Ну, нормальные пацаны ваще вот так лабают:

string[] lines = File.ReadAllLines();

... << RSDN@Home 1.2.0 alpha rev. 620>>

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

0rc>А если ASSERT включен на Марсе, что тогда, легче будет?

Ещё бы! Сейчас не те времена! Залезаем на марсоход через терминалку и жмем "Ignore". А если писать код на интерпретаторе или на языке поддерживющем модификаци кода без перекомпиляции, то ваще жмем "Retry" и правим код!

... << RSDN@Home 1.2.0 alpha rev. 620>>

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

Какие люди в Голиваде?

... << RSDN@Home 1.2.0 alpha rev. 620>>

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

Д>>про это еще Страуструп говорил
Д>>примененять защитные проверки в debug конфигурации и отключать их в release — это всё равно что плавать на корабле с полным набором спасательных кругов и шлюпок возле берега, и сгружать их на берег перех выходом в открытое море.

AVC>Да-да, еще Страуструп.
AVC>А до Страуструпа — еще Хоар.

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

... << RSDN@Home 1.2.0 alpha rev. 620>>

На здоровье :

return_code func( handle h)
{
if( h == 0 )
{
assert(0 && "invalid handle passed in function func");
return INVALID_HANDLE_RESULT_CODE;
}
.....
}

С Sqrt вааще все просто :

double Sqrt( double v)
{
assert( (v >= 0) && "passed negative value into sqrt func" );
if( v < 0 )
return NAN;
return sqrt(v);
}

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

Как вы относитесь к утвержению, что правильная программа, которая работает месяцами, должна проверять результаты перед каждой операцией. Даже перед обычными арифметическими операциями.
Т.е. процессор предоставляет вам, например, операцию сложения с её ограничениями, если вы вызываете эту операцию, то вы должны проверить аргументы и результат, либо только аргументы, если уверены, что при правильных аргументах будет правильный результат. Очевидно, что процессор не вызывает никаких ASSERT, а только взводит флаги в случае ошибки. Учитывать или не учитывать ошибку это дело клиента, а не самого процессора.

0rc>>А если ASSERT включен на Марсе, что тогда, легче будет?

VD>Ещё бы! Сейчас не те времена! Залезаем на марсоход через терминалку и жмем "Ignore". А если писать код на интерпретаторе или на языке поддерживющем модификаци кода без перекомпиляции, то ваще жмем "Retry" и правим код!

А вот зря смеетесь

Lisp на Марсе (еще есть история у Franz):

The Remote Agent software, running on a custom port of Harlequin Common Lisp, flew aboard Deep Space 1 (DS1), the first mission of NASA's New Millennium program. Remote Agent controlled DS1 for two days in May of 1999. During that time we were able to debug and fix a race condition that had not shown up during ground testing. (Debugging a program running on a $100M piece of hardware that is 100 million miles away is an interesting experience. Having a read-eval-print loop running on the spacecraft proved invaluable in finding and fixing the problem.

... << RSDN@Home 1.2.0 alpha rev. 619>>

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

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

MS>Как вы относитесь к утвержению, что правильная программа, которая работает месяцами, должна проверять результаты перед каждой операцией. Даже перед обычными арифметическими операциями.
MS>Т.е. процессор предоставляет вам, например, операцию сложения с её ограничениями, если вы вызываете эту операцию, то вы должны проверить аргументы и результат, либо только аргументы, если уверены, что при правильных аргументах будет правильный результат. Очевидно, что процессор не вызывает никаких ASSERT, а только взводит флаги в случае ошибки. Учитывать или не учитывать ошибку это дело клиента, а не самого процессора.

Почему "даже перед обычными арифметическими операциями"? Чем арифметические операции хуже других?

Далеко не всегда процессор ограничивается выставлением флагов. Самый простой пример: инструкции DIV и IDIV вызывают прерывание при попытке деления на ноль. Чем не аналог ASSERT?

Рассмотрим ситуацию, когда при выполнении арифметической операции прерывание не вызывается.
Как правило, при сложении или вычитании переполнение не ведет к прерыванию.
Возможны две ситуации.
(1) Взводится флаг переполнения (если таковой имеется).
В зависимости от заданных опций, компилятор может вставить проверку флага и сгененрировать соответствующее исключение. Какие опции выберет программист — зависит от его потребностей. Иногда арифметика по модулю 2 в степени n — то, что нужно. А иногда — нет.
(2) Процессор простой, даже флага переполнения нет.
В таком случае компилятор может сам сгенерировать проверку переполнения (опять же зависит от опций).
Делается это примерно так (отрывок из виртовского "Compiler construction")

Whenever arithmetic expressions are evaluated, the inherent danger of overflow exists. The evaluating
statements should therefore be suitably guarded. In the case of addition guards can be formulated as
follows:
IF x.a >= 0 THEN
  IF y.a <= MAX(INTEGER) - x.a THEN x.a := x.a + y.a ELSE Mark("overflow") END
ELSE
  IF y.a >= MIN(INTEGER) - x.a THEN x.a := x.a + y.a ELSE Mark("underflow") END
END
The essence of delayed code generation is that code is not emitted before it is clear that no better solution
exists. For example, an operand is not loaded into a register before this is known to be unavoidable.

Как видите, это полный аналог ASSERT, создаваемый самим компилятором.
Но что это мы все об арифметике, да об арифметике?

Рассмотрим операции связанные с доступом к памяти:
— разыменование указателя;
— взятие элемента массива по индексу.
Надеюсь, здесь у Вас не будет возражений, что разыменование "невалидного" указателя и выход индекса за границы массива — недопустимые операции? (Хотя у некоторых Си-программистов даже это может вызвать возражения...

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

It is absurd to make elaborate security checks on debugging runs, when no trust
is put in the results, and then remove them in production runs, when an erroneous
result could be expensive or disastrous. What would we think of a sailing
enthusiast who wears his life-jacket when training on dry land but takes it off as
soon as he goes to sea?

In our Algol compiler every occurrence of every subscript of every array element
was on every occasion checked at run time against the declared bounds. Many
years later we asked our customers whether they wished us to provide an option
to switch off these checks in the interest of efficiency in production runs.
Unanimously they urged us not to — they already knew how frequently index
errors occur on production runs where failure could be disastrous. I note with
fear and horror that even today, language designers and users have not learned
this lesson. In any respectable branch of engineering, failure to observe such
elementary precautions would have long been against the law.

Последнее предложение выделил для внушительности.

AVC>Почему "даже перед обычными арифметическими операциями"? Чем арифметические операции хуже других?

AVC>Далеко не всегда процессор ограничивается выставлением флагов. Самый простой пример: инструкции DIV и IDIV вызывают прерывание при попытке деления на ноль. Чем не аналог ASSERT?

Неужели вы не видете (?), что кидание исключения при неправильных аргументах это совершенно не эквивалентно ASSERT!
ASSERT остановит программу, а исключение даст шанс клиенту исправиться.

Если вы помните начало ветки про Sqrt, то противниками ASSERT как раз предлагалось два варианта
— Кинуть исключение
— Вернуть NaN

В случае с операцией целочисленного деления архитекторы Intel выбрали путь "кинуть исключение", а не остановить программу с помощью ASSERT.

AVC>Рассмотрим ситуацию, когда при выполнении арифметической операции прерывание не вызывается.
AVC>Как правило, при сложении или вычитании переполнение не ведет к прерыванию.
AVC>Возможны две ситуации.
AVC>(1) Взводится флаг переполнения (если таковой имеется).
AVC>В зависимости от заданных опций, компилятор может вставить проверку флага и сгененрировать соответствующее исключение. Какие опции выберет программист — зависит от его потребностей. Иногда арифметика по модулю 2 в степени n — то, что нужно. А иногда — нет.
Чаще всего программисту нужны оба варианта.

AVC>(2) Процессор простой, даже флага переполнения нет.
AVC>В таком случае компилятор может сам сгенерировать проверку переполнения (опять же зависит от опций).
AVC>Делается это примерно так (отрывок из виртовского "Compiler construction")
AVC>

AVC>Whenever arithmetic expressions are evaluated, the inherent danger of overflow exists. The evaluating
AVC>statements should therefore be suitably guarded. In the case of addition guards can be formulated as
AVC>follows:
AVC>
AVC>IF x.a >= 0 THEN
AVC>  IF y.a <= MAX(INTEGER) - x.a THEN x.a := x.a + y.a ELSE Mark("overflow") END
AVC>ELSE
AVC>  IF y.a >= MIN(INTEGER) - x.a THEN x.a := x.a + y.a ELSE Mark("underflow") END
AVC>END
AVC>
AVC>The essence of delayed code generation is that code is not emitted before it is clear that no better solution
AVC>exists. For example, an operand is not loaded into a register before this is known to be unavoidable.

AVC>Как видите, это полный аналог ASSERT, создаваемый самим компилятором.

— Во первых ничего подобного я не вижу. Быть может Mark("overflow") на этих процессорах будет означать взвести не флаг Overflow, а другой флаг?
— Во вторых если Mark — это кидание исключения, то это опять же не эквивалентно ASSERT, поскольку ASSERT останавливает программу.
— Аналогом ASSERT оно может служить если останавливает программу с сообщением "overflow"

AVC>Но что это мы все об арифметике, да об арифметике?

AVC>Рассмотрим операции связанные с доступом к памяти:
AVC>- разыменование указателя;
AVC>- взятие элемента массива по индексу.
AVC>Надеюсь, здесь у Вас не будет возражений, что разыменование "невалидного" указателя и выход индекса за границы массива — недопустимые операции? (Хотя у некоторых Си-программистов даже это может вызвать возражения...

)
AVC>Значит, требуется предварительная проверка указателя и индекса на корректность. И то, и другое, к примеру, в Обероне требуют всего одной операции сравнения.
AVC>Опять же — предварительная проверка и исключение (ловушка) в случае невыполнения требований. Полный аналог ASSERT.

Кинуть исключение лучше, что собственно разные OS и делают по разному, но с одинаковым эффектом.
Проверка индексов массива в случае когда они ВСЕГДА верны не имеет смысла.
Точно также как и проверка указателя после операции new, которая в случае нехватки памяти кидает исключение.
Если в этих случаях нет возможности исключить эти проверки, то грош цена таким компиляторам.

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

_FR>Я, например, не линюсь писать как-то так:

Это слово произошло от Linux?

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

MS>Неужели вы не видете (?), что кидание исключения при неправильных аргументах это совершенно не эквивалентно ASSERT!
MS>ASSERT остановит программу, а исключение даст шанс клиенту исправиться.

Вы другие сообщения из этой ветки читать когда-нибудь будете? Сто раз тут уже было сказано! Но всё-равно обязательно найдётся ещё один, не успевший это прочитать!

Повторяю в сто первый раз:
1) ЭКВИВАЛЕНТНО!
2) НЕ ОСТАНОВИТ!

В Блэкбоксе ASSERT — это и есть кидание исключения, которое будет поймано в системной ловушке (system-trap).
Не программа будет остановлена, а будет остановлена команда в которой произошла авария.
Сам Блэкбокс будет работать дальше как ни в чём не бывало.

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

> В Блэкбоксе ASSERT — это и есть кидание исключения, которое будет
> поймано в системной ловушке (system-trap).
> Не программа будет остановлена, а будет остановлена команда в которой
> произошла авария.

Ну да. После чего умрет весь поток (пардон, "активный объект").

> Сам Блэкбокс будет работать дальше как ни в чём не бывало.

Угу. "Улыбнется и пойдет дальше", как в анекдоте.

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

Posted via RSDN NNTP Server 2.0

СГ>Вы другие сообщения из этой ветки читать когда-нибудь будете? Сто раз тут уже было сказано! Но всё-равно обязательно найдётся ещё один, не успевший это прочитать!

Читать ветки Вашего авторства не хватит никакого времени.
Наверное программирование на Oberon освобождает очень много времени?
Я к сожалению пользуюсь более трудоемкими инструментами и времени у меня немного.

СГ>В Блэкбоксе ASSERT — это и есть кидание исключения, которое будет поймано в системной ловушке (system-trap).
Объясните зачем тогда нужен ASSERT, если есть механизм исключений?

СГ>Не программа будет остановлена, а будет остановлена команда в которой произошла авария.
А что будет дальше? Программа будет ждать нажатия клавиши (кстати хорошее решение для серверов!) ?
В какое место будет передано управление после нажатия клавиши?
А если клиент предусмотрел обработку исключений при вызове этой функции, то system-trap все равно сработает?

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

VD>>Ещё бы! Сейчас не те времена! Залезаем на марсоход через терминалку и жмем "Ignore". А если писать код на интерпретаторе или на языке поддерживющем модификаци кода без перекомпиляции, то ваще жмем "Retry" и правим код!

M>А вот зря смеетесь

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

... << RSDN@Home 1.2.0 alpha rev. 620>>

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

AVC>>Почему "даже перед обычными арифметическими операциями"? Чем арифметические операции хуже других?

AVC>>Далеко не всегда процессор ограничивается выставлением флагов. Самый простой пример: инструкции DIV и IDIV вызывают прерывание при попытке деления на ноль. Чем не аналог ASSERT?

MS>Неужели вы не видете (?), что кидание исключения при неправильных аргументах это совершенно не эквивалентно ASSERT!
MS>ASSERT остановит программу, а исключение даст шанс клиенту исправиться.

Насколько я понимаю, это и есть Ваше настоящее возражение против ASSERT.
(В отличие от, ИМХО, "местечковой"

ссылки на то, что кто-то и где-то использует ASSERT по-другому.)
Попытаемся разобраться вместе. Допускаю, что моя точка зрения может быть спорной и даже неверной..
Я же не вижу, как именно здесь клиент мог бы "исправиться".
(Я не стану еще раз повторять, что программа — BlackBox — не "упадет".
Ясно, что Вы под программой понимаете данный поток, в котором произошла ошибка.)
Посудите сами. Функция Sqrt имеет предусловие (x >= 0.0). Оно указано в документации к модулю Math.
Несмотря на это, программист не проверил значение x перед вызовом Sqrt, что гарантировало ему корректное вычисление квадратного корня.
Кроме того, он, похоже, не тестировал свою программу. (Иначе он с большой вероятностью столкнулся бы с данной ошибкой и все-таки вставил бы необходимую проверку.)
И как, по Вашему, он мог бы теперь "исправиться"?

Мне кажется, что здесь мы вышли за пределы обсуждения использования ASSERT в BlackBox.
Вопрос, скорее, о разумном использовании исключений вообще.
Интересно, была ли уже на RSDN такая ветка, не привязанная к специфике конкретного языка программирования или конкретной системы программирования?

MS>Если вы помните начало ветки про Sqrt, то противниками ASSERT как раз предлагалось два варианта
MS>- Кинуть исключение
MS>- Вернуть NaN

В принципе, и тот, и другой вариант заслуживает внимания.
В данном случае (Sqrt) я предпочитаю первый.
В рамках BlackBox ASSERT есть разновидность исключения.

Мне жаль, что за разногласиями по поводу правомерности использования ASSERT потерялась главная, ИМХО, деталь в утверждении Сергея Губанова. А именно — речь шла о расширяемых (extensible) системах.

AVC>>Рассмотрим ситуацию, когда при выполнении арифметической операции прерывание не вызывается.
AVC>>Как правило, при сложении или вычитании переполнение не ведет к прерыванию.
AVC>>Возможны две ситуации.
AVC>>(1) Взводится флаг переполнения (если таковой имеется).
AVC>>В зависимости от заданных опций, компилятор может вставить проверку флага и сгененрировать соответствующее исключение. Какие опции выберет программист — зависит от его потребностей. Иногда арифметика по модулю 2 в степени n — то, что нужно. А иногда — нет.
MS>Чаще всего программисту нужны оба варианта.

Т.е. нужна и знаковая, и беззнаковая арифметика.
Не уверен, что они равноценны. Знаковая, ИМХО, "важнее".

MS>Проверка индексов массива в случае когда они ВСЕГДА верны не имеет смысла.

Мысль понятна. Например, в следующем цикле

FOR i := 0 TO LEN(a)-1 DO a[i] := 0 END; (* LEN(a) в Обероне = длина массива a *)

проверки излишни, и с Вами можно согласиться.
В таком случае проверку вставлять не нужно.
А в менее очевидном случае?

MS>Точно также как и проверка указателя после операции new, которая в случае нехватки памяти кидает исключение.

Тоже верно.
Но представьте следующую ситуацию:

p->foo();

если мы не уверены, был ли вообще инициализирован указатель p.

MS>Если в этих случаях нет возможности исключить эти проверки, то грош цена таким компиляторам.

Это крайнее суждение. (На всякий случай успокою Вас — возможность отключить проверки есть. Хотя я не уверен, что это правильно для операций с памятью в случае когда компилятор (не программист!) не может гарантироовать корректность индекса.)
У меня обратное (и тоже крайнее

) суждение: грош цена таким компиляторам, которые не могут вставить такие проверки в код (как минимум — для отладки).

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

AVC>>>В зависимости от заданных опций, компилятор может вставить проверку флага и сгененрировать соответствующее исключение. Какие опции выберет программист — зависит от его потребностей. Иногда арифметика по модулю 2 в степени n — то, что нужно. А иногда — нет.
MS>>Чаще всего программисту нужны оба варианта.

AVC>Т.е. нужна и знаковая, и беззнаковая арифметика.

Здесь меня, конечно, "переклинило".

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

M>>А вот зря смеетесь

VD>Дык, и в этой шутке есть доля шутки. Ты прикинь каким самообладанием нужно обладать, чтобы наботать по терминалке с компьютером находящемся на растоянии 8 световых минут.

Так мало, что 8 световых минут, так еще и на оборудовании стоимостью в н мегабаксов

... << RSDN@Home 1.2.0 alpha rev. 619>>

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

СГ>Здравствуйте, MShura, Вы писали:

MS>>Неужели вы не видете (?), что кидание исключения при неправильных аргументах это совершенно не эквивалентно ASSERT!
MS>>ASSERT остановит программу, а исключение даст шанс клиенту исправиться.

СГ>Вы другие сообщения из этой ветки читать когда-нибудь будете? Сто раз тут уже было сказано! Но всё-равно обязательно найдётся ещё один, не успевший это прочитать!

Вы же не отвечаете на другие посты , вот и приходиться повторять.

СГ>Повторяю в сто первый раз:
СГ>1) ЭКВИВАЛЕНТНО!
Если эквивалентно то ПОЧЕМУ кому либо в голову может прити в этой системе BlackBox отключать ASSERT в релизе ? Ну объясните , ну почему кому то не придет в голову в релизе отключить исключения ? или отулючить обработку ошибок как таковую в релизе ?

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

C>Ну да. После чего умрет весь поток (пардон, "активный объект").

В Блэкбоксе нет потоков и активных объектов.

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

СГ>>В Блэкбоксе ASSERT — это и есть кидание исключения, которое будет поймано в системной ловушке (system-trap).
MS>Объясните зачем тогда нужен ASSERT, если есть механизм исключений?

Механизма исключений в самом языке Component Pascal нет.

СГ>>Не программа будет остановлена, а будет остановлена команда в которой произошла авария.
MS>А что будет дальше? Программа будет ждать нажатия клавиши (кстати хорошее решение для серверов!) ?
MS>В какое место будет передано управление после нажатия клавиши?

Есть главный цикл, в котором крутится сам Блэкбокс. В него и вернётся.

MS>А если клиент предусмотрел обработку исключений при вызове этой функции, то system-trap все равно сработает?

Механизма исключений в самом языке Component Pascal нет, но в принципе, можно сделать так, что сработавший system-trap вызовет обработчик предусмотренный пользователем.

Сергей Губанов wrote:
> C>Ну да. После чего умрет весь поток (пардон, "активный объект").
> В Блэкбоксе нет потоков и активных объектов.
Ээээ? А что там есть?

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

Posted via RSDN NNTP Server 2.0

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

C>Сергей Губанов wrote:
>> C>Ну да. После чего умрет весь поток (пардон, "активный объект").
>> В Блэкбоксе нет потоков и активных объектов.
C>Ээээ? А что там есть?

Чёрный ящик же — исследователь ничего о содержимом не знает

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

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

C>>Сергей Губанов wrote:
>>> C>Ну да. После чего умрет весь поток (пардон, "активный объект").
>>> В Блэкбоксе нет потоков и активных объектов.
C>>Ээээ? А что там есть?

К>Чёрный ящик же — исследователь ничего о содержимом не знает

Думаю, там нет ничего — чистый вакуум. Потому что сферические кони в другой среде не живут

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

>> В Блэкбоксе нет потоков и активных объектов.
C>Ээээ? А что там есть?

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

А вообще, есть свободный доступ к WinAPI, но это уже из разряда: "Сделай сам!". Сами делаете свои потоки, сами в них и исключения ловите с помощью соответствующих WinAPI-шных функций.

Сейчас Oberon Microsystems делает следующую версию BlackBox. Когда выйдет, посмотрим что они там наворотили. Может и потоки прикрутят.

Сергей Губанов wrote:
> В самом Блэкбоксе, как я уже тут писал, многозадачность кооперативная.
> Делаете свою службу, регистрируете её в Блэкбоксе и он её периодически
> дёргает из своего главного цикла в окружении системной ловушки.
Уууууу...... Это "ОС нового поколения"????

> А вообще, есть свободный доступ к WinAPI, но это уже из разряда: "Сделай
> сам!". Сами делаете свои потоки, сами в них и исключения ловите с
> помощью соответствующих WinAPI-шных функций.
Ага, еще надо самому написать компилятор и спаять компьютер.

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

Posted via RSDN NNTP Server 2.0

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

C>Уууууу...... Это "ОС нового поколения"????

BlackBox — это не ОС. ОС нового поколения — это BlueBottle. Кстати, на счет Блюботлины — ходят слухи, что скоро выйдет новая Рождественская версия (как в прошлом году).

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

M>Так мало, что 8 световых минут, так еще и на оборудовании стоимостью в н мегабаксов

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

... << RSDN@Home 1.2.0 alpha rev. 620>>

СГ>Хорошо известно, что определение ошибки тем более затруднено и дороже обходится, чем позже она обнаруживается, т.е. чем дальше разнесены источник и его эффекты. Это позволяет сформулировать правило:

СГ>Позволяйте ошибкам заявлять о себе как можно раньше.
Совершенно согласен.

СГ>В компонентно-ориентированных системах дефекты всегда должны содержаться в их компонентах
СГ>и не распространяться на другие компоненты. Другие компоненты даже могут быть черными ящиками и не иметь исходных текстов, что делает отладку на уровне исходных текстов невозможной. Более того, поток передачи управления в больших объектно-ориентированных программных системах настолько запутанный, что нереально, и это пустая трата времени, проследить его за пределами границ компонентов для целей отладки.
СГ>Единственный жизнеспособный отладочный подход есть проектирование всего, от языка программирования до библиотек, до компонентов и приложений, используя оборонительный стиль программирования. В частности, входные точки в компоненты (вызовы процедур/методов) должны останавливать исполнение, если их предусловия не обеспечены:

СГ>Никогда не позволяйте ошибкам проникать сквозь границы компонентов.
Совершенно верно, оборонительный стиль , это предполагать что на вход могут дать ЛЮБЫЕ данные и мы обязанны их обработать и немедленно сообщить если данные были некоректны (ексепшеном или кодом возврата в релизе и дополнительно асертом в дебаге).

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

Совершенно верно.

СГ>Перевод на русский язык выполнен здесь.

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

Тут высказывалась мысль что асерты это ШТАТНОЕ средство обработки ошибок в рантайме в блак боксе , по косвеннм признакам я начинаю в этом сомневаться ....

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

M>Ок, решил перечитать исходный текст, потому что возникла мысль. Если авторы блакбокса не рекомендуют отключать асерты в релизе , почему вообще они предусмотрели такое отключение?

Дык, они и не предусмотрели возможность его отключения. Отключать нельзя, а раз нельзя, то и возможности отключить — нету.

M>А теперь позвольте спросить , где тут сказанно что проверки во время выполнения рекомендованно осуществлять асертами ? Может документация неправильно понята ? Можно кусок текста из которого видно что речь идет об асертах ?

Э-э-э, это моя вина. Я здесь разместил только фрагмент текста хелпа.

M>Тут высказывалась мысль что асерты это ШТАТНОЕ средство обработки ошибок в рантайме в блак боксе , по косвеннм признакам я начинаю в этом сомневаться ....

Не обработки ошибок, а сообщения о них. Обрабатывать ошибки будет потом программист.

От:	Сергей Губанов	http://sergey-gubanov.livejournal.com/
Дата:	05.12.05 16:01
Оценка:	13 (2) +1

От:	McSeem2	http://www.antigrain.com
Дата:	05.12.05 16:56
Оценка:	21 (4) +11

	От:	GlebZ
	Дата:	05.12.05 17:19
	Оценка:

	От:	minorlogic
	Дата:	05.12.05 17:27
	Оценка:

От:	Pzz	https://github.com/alexpevzner
Дата:	05.12.05 18:43
Оценка:	1 (1)

	От:	Павел Кузнецов
	Дата:	06.12.05 00:00
	Оценка:	+3

От:	_FRED_	@ViIvanov
Дата:	06.12.05 00:27
Оценка:	1 (1) +1

	От:	Alex Fedotov
	Дата:	06.12.05 03:38
	Оценка:	15 (3) +14 -2

	От:	Кодёнок
	Дата:	06.12.05 11:24
	Оценка:	+1 -1

От:	Sinclair	https://github.com/evilguest/
Дата:	06.12.05 11:50
Оценка:

От:	eao197	http://eao197.blogspot.com
Дата:	08.12.05 08:58
Оценка:	+5

От:	Курилка	http://kirya.narod.ru/
Дата:	10.12.05 10:33
Оценка:

От:	Mikhail Polykovsky	http://glader.ru
Дата:	10.12.05 12:26
Оценка:

От:	Коваленко Дмитрий	http://www.ibprovider.com
Дата:	11.12.05 11:24
Оценка:

От:	VladD2	www.nemerle.org
Дата:	13.12.05 01:52
Оценка:

От:	Mamut	http://dmitriid.com
Дата:	13.12.05 13:14
Оценка:	6 (1)