Re[5]: Почему редко используются assert'ы? - C/C++

double SomeClass::get_prop1() const
{
    assert(prop1_ > 0);
    return prop1_;
}

double SomeClass::get_ptop2() const
{
    assert(prop2_ >= 0); 
    return prop2_;
}

И везде по ходу определения методов SomeClass вместо непосредственно prop2_ использую вызов get_ptop2(), тем самым гарантирую, что я нигде не налажал и значение prop2_ инициализировано верно.

Здравствуйте, <Аноним>, Вы писали:

А>Почему в большинстве библиотек которые я видел очень редко используются assert'ы?
А>Типа "настоящие" программисты ошибок не совершают...

"Настоящие" (попрошу заметить кавычки

) предпочитают как можно большее число проверок вынести в compile-time (см. Александреску, Compile-Time Assertions):

template<bool> struct CompileTimeChecker
{
   CompileTimeChecker(...);
};
template<> struct CompileTimeChecker<false> { };
#define STATIC_CHECK(expr, msg) \
   {\
       class ERROR_##msg {}; \
       (void)sizeof(CompileTimeChecker<(expr) != 0>((ERROR_##msg())));\
   }

Использование:

template <class To, class From>
To safe_reinterpret_cast(From from)
{
   {
      class ERROR_Destination_Type_Too_Narrow {};
      (void)sizeof(
         CompileTimeChecker<(sizeof(From) <= sizeof(To))>(
            ERROR_Destination_Type_Too_Narrow()));
   }
   return reinterpret_cast<To>(from);
}

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

Здравствуйте, Нахлобуч, Вы писали:

Н>Здравствуйте, <Аноним>, Вы писали:

А>>Почему в большинстве библиотек которые я видел очень редко используются assert'ы?
А>>Типа "настоящие" программисты ошибок не совершают...

Н>"Настоящие" (попрошу заметить кавычки

) предпочитают как можно большее число проверок вынести в compile-time (см. Александреску, Compile-Time Assertions):

Н>

Н>template<bool> struct CompileTimeChecker
Н>{
Н>   CompileTimeChecker(...);
Н>};
Н>template<> struct CompileTimeChecker<false> { };
Н>#define STATIC_CHECK(expr, msg) \
Н>   {\
Н>       class ERROR_##msg {}; \
Н>       (void)sizeof(CompileTimeChecker<(expr) != 0>((ERROR_##msg())));\
Н>   }
Н>

Н>Использование:

Н>

Н>template <class To, class From>
Н>To safe_reinterpret_cast(From from)
Н>{
Н>   {
Н>      class ERROR_Destination_Type_Too_Narrow {};
Н>      (void)sizeof(
Н>         CompileTimeChecker<(sizeof(From) <= sizeof(To))>(
Н>            ERROR_Destination_Type_Too_Narrow()));
Н>   }
Н>   return reinterpret_cast<To>(from);
Н>}
Н>

Такой подход я видел еще реже, пожалуй только boost на ум приходит.
Поиск выдал 112 файлов использующих BOOST_STATIC_ASSERT, это из 2940 файлов версии 1.32

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

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

А>>Почему в большинстве библиотек которые я видел очень редко используются assert'ы?
А>>Типа "настоящие" программисты ошибок не совершают...

А>Я например часто использую:
А>

А>double SomeClass::get_prop1() const
А>{
А>    assert(prop1_ > 0);
А>    return prop1_;
А>}

А>double SomeClass::get_ptop2() const
А>{
А>    assert(prop2_ >= 0); 
А>    return prop2_;
А>}
А>

А>И везде по ходу определения методов SomeClass вместо непосредственно prop2_ использую вызов get_ptop2(), тем самым гарантирую, что я нигде не налажал и значение prop2_ инициализировано верно.

Может кто-то считает более грамотным, проверять все входные величины сразу прямо в конструкторе, а не в момент их первого использования? Будет очень интересно послушать мнения на этот счет.

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

брр. Сколько разных анонимов!

А>>>Почему в большинстве библиотек которые я видел очень редко используются assert'ы?

да потому, что библиотеки отличаются от проектов. Грубо говоря, библиотеки должны иметь специфицированное поведение.
а кому нравится писать, вот при включеном макросе будет выдаваться assert при неправильных параметрах.
библиотека должна что-то делать и при вкл assert и при выклЮ и лучше одно и тоже.

А>>>Типа "настоящие" программисты ошибок не совершают...

кавычки лишние

А>>Я например часто использую:
А>>

А>>double SomeClass::get_prop1() const
А>>{
А>>    assert(prop1_ > 0);
А>>    return prop1_;
А>>}

А>>double SomeClass::get_ptop2() const
А>>{
А>>    assert(prop2_ >= 0); 
А>>    return prop2_;
А>>}
А>>

а это вообюще странно, а проверяется результат ф-ии. я бы проверял при записи неврного значения.

А>>И везде по ходу определения методов SomeClass вместо непосредственно prop2_ использую вызов get_ptop2(), тем самым гарантирую, что я нигде не налажал и значение prop2_ инициализировано верно.

тогда это должны быть
А>Может кто-то считает более грамотным, проверять все входные величины сразу прямо в конструкторе, а не в момент их первого использования? Будет очень интересно послушать мнения на этот счет.

по мне, так проверять надо там, где они могут быть ошибочными, при этом
1. коструктор это или нет не волнует
2. но если const, то в конструкторе проверка, естествено эффективней
3. надо различать проверку значений, которые вводит пользователь, и это должно входит в алгоритм обработки входных данных, а не в assert, и перестраховку программисткую.

Здравствуйте, Нахлобуч, Вы писали:

Н>Здравствуйте, <Аноним>, Вы писали:

Н>"Настоящие" (попрошу заметить кавычки

) предпочитают как можно большее число проверок вынести в compile-time (см. Александреску, Compile-Time Assertions):

Почему в кавычках?

Н>Использование:

В смыслле использования я предпочитаю

//ASSERT времени компиляции. Может быть помещён почти в любом месте программы.
#define TASSERT(COND1T1ON) typedef int TASSERT_fict1ve_namE[(COND1T1ON)?1:-1];

И не вижу преимуществ у Александреску.

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

А>В смыслле использования я предпочитаю

А>

А>//ASSERT времени компиляции. Может быть помещён почти в любом месте программы.
А>#define TASSERT(COND1T1ON) typedef int TASSERT_fict1ve_namE[(COND1T1ON)?1:-1];
А>

А>И не вижу преимуществ у Александреску.

Более информативные сообщения об ошибках. Даже если добавить возможность задания имени массива, компилятор не обязан сообщить его в тексте еррора. А имя кривого шаблона — должен. Если верить Александреску

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

HSH>Здравствуйте, Аноним, Вы писали:

HSH> Более информативные сообщения об ошибках. Даже если добавить возможность задания имени массива, компилятор не обязан сообщить его в тексте еррора. А имя кривого шаблона — должен. Если верить Александреску

Ничего компилятор не обязан. Он просто обязан сообщить, что код ill-formed.

Неа. Вот например gcc не сообщает. А про имя массива сообщает. В MSVC ровно наоборот.
И вообще, лишний код просто ради формирования сообщения об ошибке, что не работает на разных компиляторах — нафиг это надо? Чем проще, тем лучше.
Надежней написать рядом комментарий. И он может быть более удобочитаемым — можно даже http://ссылку туда всунуть.

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

HSH> Более информативные сообщения об ошибках. Даже если добавить возможность задания имени массива, компилятор не обязан сообщить его в тексте еррора. А имя кривого шаблона — должен. Если верить Александреску

Мне вполне хватает комментария у assert-а. Не вижу причин усложнять конструкцию ради текста в листинге. Всё равно придётся лазить по исходникам для исправления. Кроме того не в любом месте такой ассерт применим.

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

А>Почему в большинстве библиотек которые я видел очень редко используются assert'ы?
А>Типа "настоящие" программисты ошибок не совершают...

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

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

ME>Здравствуйте, Аноним, Вы писали:

А>>Почему в большинстве библиотек которые я видел очень редко используются assert'ы?
А>>Типа "настоящие" программисты ошибок не совершают...

ME>Чтобы ассерты имели хоть какой-то смысл необходим полный code coverage при тестировании со всеми возможными входными данными, т.е. чтобы при тестировании отработали все ветки кода на реальных данных. Часто это обеспечить очень сложно, поэтому может легко случиться так, что реальные входные данные вызвали последовательность действий, которые бы были вызвали ассерт, но это уже релизная версия и ассерта там, естественно, нет. Поэтому гораздо безопаснее не полагаться целиком на тестирование и ассерты, а всегда проверять условия в критичных местах.

ASSERT — это фича только для разработчиков кода, а не для юзера. Ассертами я проверяю самого себя во время работы над проектом, а юзера я проверяю непосредственно при вводе им значений, например если в edit'е введено неверное значение, всплывает диалог, типа "Попробуйте еще раз...".

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

Может я путано объяснил... но, если кратко, ассерты — это инструмент для разработчика. Для данных поступающих в программу от пользователя используются другие методы проверки: обычные условия, с выводом сообщения при отрицательном результате или выбросом исключения или еще что-то

Здравствуйте, <Аноним>, Вы писали:

А>Почему в большинстве библиотек которые я видел очень редко используются assert'ы?
А>Типа "настоящие" программисты ошибок не совершают...

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

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

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

А>ASSERT — это фича только для разработчиков кода, а не для юзера. Ассертами я проверяю самого себя во время работы над проектом, а юзера я проверяю непосредственно при вводе им значений, например если в edit'е введено неверное значение, всплывает диалог, типа "Попробуйте еще раз...".

А>Все реальные входные данные, естественно проверяются и в debug, и в release, потому что это данные поступающие от пользователя, т.к. входные.

А>Может я путано объяснил... но, если кратко, ассерты — это инструмент для разработчика. Для данных поступающих в программу от пользователя используются другие методы проверки: обычные условия, с выводом сообщения при отрицательном результате или выбросом исключения или еще что-то

Помимо всего прочего, assert — это еще и средство документирования кода, так как показывает инварианты в алгоритме.

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

M>Здравствуйте, <Аноним>, Вы писали:

А>>Почему в большинстве библиотек которые я видел очень редко используются assert'ы?
А>>Типа "настоящие" программисты ошибок не совершают...

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

Что за бред удалять асерты??? Они же в релизе и так не срабатывают.
Ну, и про инварианты тут выше поветке правильно сказали.

minorlogic wrote:

> А>Почему в большинстве библиотек которые я видел очень редко
> используются assert'ы?
> А>Типа "настоящие" программисты ошибок не совершают...
> Да нет , асерты используются на полную при разработке и отладке , а
> уже из отлаженных кусков кода обычно удалаяютяс.

Ассерты никогда, я повторяю НИКОГДА, не надо удалять из кода. Можно
отключать макросами (типа MYMODULE_NOASSERT) и, естественно, их надо
выключать в релизе. Но они всегда должны оставаться в коде.

Кстати, у ассертов под MSVC есть еще одно интересное применение:

#ifndef DEBUG
    #undef assert
    #define assert(e) (__assume(e))
#endif

То есть assert'ы не просто удаляются из кода, а превращаются в хинты
компилятору.

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

Posted via RSDN NNTP Server 1.9

Здравствуйте, Cyberax, Вы писали:
C>Кстати, у ассертов под MSVC есть еще одно интересное применение:
C>

C>#ifndef DEBUG
C>    #undef assert
C>    #define assert(e) (__assume(e))
C>#endif
C>

C>То есть assert'ы не просто удаляются из кода, а превращаются в хинты
C>компилятору.

А можно про это поподробнее, почему это лучше чем ((void)0) в релизе вместо ассерта?

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

А>Здравствуйте, Cyberax, Вы писали:
C>>Кстати, у ассертов под MSVC есть еще одно интересное применение:
C>>

C>>#ifndef DEBUG
C>>    #undef assert
C>>    #define assert(e) (__assume(e))
C>>#endif
C>>

C>>То есть assert'ы не просто удаляются из кода, а превращаются в хинты
C>>компилятору.

А>А можно про это поподробнее, почему это лучше чем ((void)0) в релизе вместо ассерта?

http://msdn.microsoft.com/library/en-us/vccelng/htm/msmod_36.asp:

The __assume keyword passes a hint to the optimizer. The optimizer assumes that the condition represented by expression is true at the point where the keyword appears and remains true until expression is altered (for example, by assignment to a variable). Selective use of hints passed to the optimizer by __assume can improve optimization.

Здравствуйте, <Аноним>, Вы писали:

А>Что за бред удалять асерты??? Они же в релизе и так не срабатывают.
А>Ну, и про инварианты тут выше поветке правильно сказали.

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

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

C>Кстати, у ассертов под MSVC есть еще одно интересное применение:
C>

C>#ifndef DEBUG
C>    #undef assert
C>    #define assert(e) (__assume(e))
C>#endif
C>

C>То есть assert'ы не просто удаляются из кода, а превращаются в хинты
C>компилятору.

Вообще-то поведение CRT макроса assert определяется макросом NDEBUG.
Макросом DEBUG определяется поведение _ASSERT и _ASSERTE.

	От:	Аноним
	Дата:	07.10.05 18:38
	Оценка:	+1

	От:	Аноним
	Дата:	07.10.05 18:46
	Оценка:

От:	Нахлобуч	https://hglabhq.com
Дата:	07.10.05 19:18
Оценка:

	От:	Аноним
	Дата:	07.10.05 19:27
	Оценка:

	От:	Аноним
	Дата:	07.10.05 19:32
	Оценка:

	От:	Сергей Мухин
	Дата:	07.10.05 22:33
	Оценка:

От:	HiSH	http://m0riarty.ya.ru
Дата:	08.10.05 09:31
Оценка:

От:	_Winnie	C++.freerun
Дата:	08.10.05 09:37
Оценка:

	От:	Alex Fedotov
	Дата:	08.10.05 21:11
	Оценка:	1 (1) +1

	От:	MShura
	Дата:	09.10.05 05:32
	Оценка: