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

EP>>более того — для формально верифицированного кода они не нужны.
·>Для формально верифицированного их разве кто-то пишет?

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

EP>>·>Если медленно — это уже проблема алгоритма.
EP>>Это ещё почему?
·>Точнее не так. Если медленно, то можно перенести ассерт в юнит-тест.

Sinix выше правильно заметил — assert'ы отрабатывают во время всех тестов, как юнит, так и интеграционных, и поэтому есть приличный шанс того что они поймают баг пропущенный непосредственно юнит-тестированием.

Более того, юнит-тест конкретного компонента может успешно пройти при наличии бага, или например двойного бага — то есть false positive. При этом внутренний assert мог поймать эти баги на этом же прогоне. То есть assert'ы это отличное дополнение unit-тестов.

EP>>·>При хорошем покрытии тестами ценность ассертов падает до нуля.
EP>>Точно также как и ценность других defensive примочек, а-ля bounds checking
·>Не точно также же. В проде bounds checking валит исключения

Да какая разница если у тебя в оттестированном и корректном коде не будет этих исключений?
То есть ты определись — либо у тебя код оттестирован и defensive programming не нужен, либо не оттестирован и ты тестируешь его на своих пользователях

EP>>>>С другой стороны, выключение части из проверок в runtime'е, ровно как и отсутствии часть проверок вообще — не делает программу некорректной.
EP>>·>Но только если ассерты расставлены корректно.
EP>>Что ты имеешь в виду? То что проверка внутри assert'а может иметь side-effect?
·>Да, и такое бывает, к сожалению.

Я уже сказал что это ловится тестированием и debug и release версий. Но встречается крайне редко — я видел подобное только когда человек не знал что такое assert.

EP>>·>Я что-то не понял что это. Судя по if (!condition)throw это не ассерты в понимании С++.
EP>>Там некоторые из них опциональные, и не попадают в Release.
·>Ух ты. Это как устроено? Что-то не могу разобраться...

Conditional

Conditional methods allow developers to create methods whose calls can be placed in the code and then either included or omitted during compilation based on a preprocessing symbol.

EP>>·>В unmanaged наоборот: когда может — работает правильно, и всегда быстро.
EP>>Не всегда быстро, только когда assert'ы отключены.
·>При релизном использовании отключены.

Совсем необязательно — я их видел в коммерческом продукте имеющим сотни миллионов установок

·>>>Есть конечно. Я говорю о корректности самого кода, а не логических ошибок в алгоритме.
EP>>В чём ты видишь отличие? Выход за пределы bounds это есть логическая ошибка, которой в корректном коде нет
·>Эта ошибка явно прописана в спеке языка

Да какая разница — это и есть логическая ошибка в твоём алгоритме.

EP>>>>P.S. Ничто не мешает оставить часть assert'ов включенных в Release. Для этого их обычно разбивают на классы "быстрые", "медленные", "очень медленные" — и уже пользователь библиотеки решает что попадёт в Release.
EP>>·>По-моему излишнее усложнение. Собственно на основании чего пользователь будет принимать решение?
EP>>1. На основании того какое быстродействие его устраивает
·>Чем быстрее, тем лучше, очевидно.

Совсем не очевидно, ибо это не единственный критерий.

EP>>2. На основании того насколько корректен его код (здесь речь идёт про библиотеку и пользовательский код, ассерты внутри библиотеки могут ловить ошибки в пользовательском коде).
·>Конечно, корректен, я что ламер некорректный код писать?

Тогда тебе и не нужен никакой defensive programming

·>А ты как корректность своего кода оцениваешь?

Зависит от конкретного случая — различные комбинации unit/integration тестов, разбиение на классы эквивалентности, поиск изоморфизмов, assert'ы на пред/пост-условия и ванрианты/инварианты, доказательства. Вот до чего пока не доходил, так это до выражения доказательств на формальных языках и их дальнейшей автоматизированной проверки.

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

А причём тут логи? Если у тебя условие assert'а сфейлилось — то дальше всё может полететь в тартарары, и лучше всего пристрелить такую программу.

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

EP>>более того — для формально верифицированного кода они не нужны.
·>Для формально верифицированного их разве кто-то пишет?

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

EP>>·>Если медленно — это уже проблема алгоритма.
EP>>Это ещё почему?
·>Точнее не так. Если медленно, то можно перенести ассерт в юнит-тест.

Sinix выше правильно заметил — assert'ы отрабатывают во время всех тестов, как юнит, так и интеграционных, и поэтому есть приличный шанс того что они поймают баг пропущенный непосредственно юнит-тестированием.

Более того, юнит-тест конкретного компонента может успешно пройти при наличии бага, или например двойного бага — то есть false positive. При этом внутренний assert мог поймать эти баги на этом же прогоне. То есть assert'ы это отличное дополнение unit-тестов.

EP>>·>При хорошем покрытии тестами ценность ассертов падает до нуля.
EP>>Точно также как и ценность других defensive примочек, а-ля bounds checking
·>Не точно также же. В проде bounds checking валит исключения

Да какая разница если у тебя в оттестированном и корректном коде не будет этих исключений?
То есть ты определись — либо у тебя код оттестирован и defensive programming не нужен, либо не оттестирован и ты тестируешь его на своих пользователях

EP>>>>С другой стороны, выключение части из проверок в runtime'е, ровно как и отсутствии часть проверок вообще — не делает программу некорректной.
EP>>·>Но только если ассерты расставлены корректно.
EP>>Что ты имеешь в виду? То что проверка внутри assert'а может иметь side-effect?
·>Да, и такое бывает, к сожалению.

Я уже сказал что это ловится тестированием и debug и release версий. Но встречается крайне редко — я видел подобное только когда человек не знал что такое assert.

EP>>·>Я что-то не понял что это. Судя по if (!condition)throw это не ассерты в понимании С++.
EP>>Там некоторые из них опциональные, и не попадают в Release.
·>Ух ты. Это как устроено? Что-то не могу разобраться...

Conditional

Conditional methods allow developers to create methods whose calls can be placed in the code and then either included or omitted during compilation based on a preprocessing symbol.

EP>>·>В unmanaged наоборот: когда может — работает правильно, и всегда быстро.
EP>>Не всегда быстро, только когда assert'ы отключены.
·>При релизном использовании отключены.

Совсем необязательно — я их видел в коммерческом продукте имеющем сотни миллионов установок

·>>>Есть конечно. Я говорю о корректности самого кода, а не логических ошибок в алгоритме.
EP>>В чём ты видишь отличие? Выход за пределы bounds это есть логическая ошибка, которой в корректном коде нет
·>Эта ошибка явно прописана в спеке языка

Да какая разница — это и есть логическая ошибка в твоём алгоритме.

EP>>>>P.S. Ничто не мешает оставить часть assert'ов включенных в Release. Для этого их обычно разбивают на классы "быстрые", "медленные", "очень медленные" — и уже пользователь библиотеки решает что попадёт в Release.
EP>>·>По-моему излишнее усложнение. Собственно на основании чего пользователь будет принимать решение?
EP>>1. На основании того какое быстродействие его устраивает
·>Чем быстрее, тем лучше, очевидно.

Совсем не очевидно, ибо это не единственный критерий.

EP>>2. На основании того насколько корректен его код (здесь речь идёт про библиотеку и пользовательский код, ассерты внутри библиотеки могут ловить ошибки в пользовательском коде).
·>Конечно, корректен, я что ламер некорректный код писать?

Тогда тебе и не нужен никакой defensive programming

·>А ты как корректность своего кода оцениваешь?

Зависит от конкретного случая — различные комбинации unit/integration тестов, разбиение на классы эквивалентности, поиск изоморфизмов, assert'ы на пред/пост-условия и ванрианты/инварианты, доказательства. Вот до чего пока не доходил, так это до выражения доказательств на формальных языках и их дальнейшей автоматизированной проверки.

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

А причём тут логи? Если у тебя условие assert'а сфейлилось — то дальше всё может полететь в тартарары, и лучше всего пристрелить такую программу.