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

aik>>>>ASSERT(szFirstName != NULL);
aik>>>>if (NULL == szFirstName)
aik>>>> return -1;
S>>>Не надо так писать. Если у тебя есть нормальный способ обработать ошибку — обрабатывай ошибку. Ассерт здесь не нужен. Ассерт нужен для проверки выполнения договоренностей.
aik>>Все не отловишь, значит, все равно надо все проверять, значит, ассерты не так полезны.
OE>ok, еще один рывок, еще одна попытка Срабатывание assert-а означает безусловную необходимость изменения кода (текста программы), вызвавшего его срабатывание. Дружественым if (NULL == szFirstName) return -1; ты ни себя, ни кого другого на изменение кода не нагнешь.

Частое нагибание весьма часто приведет к замене ASSERT(szFirstName != NULL) на if (NULL == szFirstName) return -1

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

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

aik>>>Но вообще понятно, кто не писал систем 24*7, не поймут как жить без ассертов
G>>Я последние 6 лет пишу "24*7". Могу отвественно заявить, что без ассертов в случае сложной системы ты повесишься. Особенно для достаточно сложной асинхронной системы. Синклер тебе написал все правильно. Рекомендую перечитать и подумать.

aik>Перечитал, и утверждаю что — не повесился.
Что же — подождем!

25 октября 2007 года.

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

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

Милиция считает, что самоубийство произошло из-за пагубного пристрастия погибшего к форумам RSDN...

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

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

aik>>Но вообще понятно, кто не писал систем 24*7, не поймут как жить без ассертов

G>Я последние 6 лет пишу "24*7". Могу отвественно заявить, что без ассертов в случае сложной системы ты повесишься. Особенно для достаточно сложной асинхронной системы. Синклер тебе написал все правильно. Рекомендую перечитать и подумать.

Рекомендую посмотреть на язык программирования Eiffel, специально разработанный для поддержки КОНТРАКТНОГО программирования в ООП.

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

aik>Частое нагибание весьма часто приведет к замене ASSERT(szFirstName != NULL) на if (NULL == szFirstName) return -1
aik>)

И кто дает гарантию, что эта -1 будет корректно обработана вызвавшим кодом, если такая ситуауция никогда не тестировалась? ASSERT, как здесь уже неоднократно говорилось, прежде всего — средство отладки и документирования кода. Приментельно к данному коду это означает, что szFirstName не может быть NULL (по определению — по задумке автора) и если это не так, то вызывающий код имеет ошибку. "return -1" — может означать что угодно, читая этот код не видно, что szFirstName == NULL — это нештатная ситуация и что такая ситуация может некорректно обрабатываться вызывающим кодом.

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

ZEN>Рекомендую посмотреть на язык программирования Eiffel, специально разработанный для поддержки КОНТРАКТНОГО программирования в ООП.

Даже в Обероне ASSERT есть А ведь Вирт вырезал из этого языка "ненужные" конструкции просто нещадно

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

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

iZEN>>Рекомендую посмотреть на язык программирования Eiffel, специально разработанный для поддержки КОНТРАКТНОГО программирования в ООП.

В>Даже в Обероне ASSERT есть А ведь Вирт вырезал из этого языка "ненужные" конструкции просто нещадно
А может ему просто не хватило смелости полностью скопировать Eiffel?
Разработчикам Java, например, не хватило...а жаль.

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

iZEN>>>Рекомендую посмотреть на язык программирования Eiffel, специально разработанный для поддержки КОНТРАКТНОГО программирования в ООП.

В>>Даже в Обероне ASSERT есть А ведь Вирт вырезал из этого языка "ненужные" конструкции просто нещадно
ZEN>А может ему просто не хватило смелости полностью скопировать Eiffel?
ZEN>Разработчикам Java, например, не хватило...а жаль.

Может немного не в тему, но есть люди, пошедшие дальше Java, например Nice.
Компилится в байт-код, понимаемый JVM.
Там поддержка контрактного программирования пошла дальше assert, сделаны пре- и постусловия, например:

interface IStack<T>{
  int size() ensures result >= 0 : "size can not be less than one";
    
  void push(T t) ensures size(this) > 0 : "pushing an item should increase the size";    
    
  boolean isEmpty() ensures result == (size(this) == 0) : "if size is zero, result should be false";    

  T pop() requires !isEmpty(this) : "Can not pop an empty stack";

  T peek() requires !isEmpty(this) : "Can not pop an empty stack";
}

Здесь requires — предусловия, ensure — постусловия

Господа , у кого под рукой стандарт , посмотрите пожалуйста что там про асерты пишут ?

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

DD>Может немного не в тему, но есть люди, пошедшие дальше Java, например Nice.

В D (http://www.digitalmars.com/d) тоже такое есть такое:

    long square_root(long x)
        in
        {
        assert(x >= 0);
        }
        out (result)
        {
        assert((result * result) == x);
        }
        body
        {
        return math.sqrt(x);
        }

assert, не сишный он бросает исключение которое можно перехватить

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

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

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

aik>>>Но вообще понятно, кто не писал систем 24*7, не поймут как жить без ассертов

G>>Я последние 6 лет пишу "24*7". Могу отвественно заявить, что без ассертов в случае сложной системы ты повесишься. Особенно для достаточно сложной асинхронной системы. Синклер тебе написал все правильно. Рекомендую перечитать и подумать.

ZEN>Рекомендую посмотреть на язык программирования Eiffel, специально разработанный для поддержки КОНТРАКТНОГО программирования в ООП.

Это что — "замер"? Ну тогда — спасибо, я в курсе существования этого языка. А вам рекомендую посмотреть на язык программирования CLU, задолго до появления ОО баззвордов разработанный г-жой Лисков и компанией для поддержки метода АБСТРАКЦИЙ И СПЕЦИФИКАЦИЙ, из идей которого, в последствии, получился Eiffel и несколько других языков. Что характерно, со времен Лисков ничего радикально нового в этой области не придумано.

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

M>Супер , примерно так мне и пытались объяснить почему нельзя их использовать ..

M>Асерты — это механизм ОТЛАДКИ ,

Т. е. тебе нельзя отлаживать свой код?

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

G>>2) При фатальной ошибке прога все равно упадет, но в другом месте, и с такими дикими симптомами, что причину ошибки ты вообще не найдешь. Я говорю, разумеется, о достаточно сложных системах, от полмиллиона строк и выше. А не о микроконтроллерах.

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

если произошло что-то фатальное, лучше проге больше ничего не доверять. Самый красноречивый пример большой системы и подобной стратегии обработки фатальной ошибки — BSOD у Win

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

M>>Асерты — это механизм ОТЛАДКИ ,
M>Т. е. тебе нельзя отлаживать свой код?

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