>> Не проверять в каждой фукнции правильность переданных параметров.
хотел написать:
Не нужно же проверять в каждой фукнции правильность переданных параметров.
Да, но если это не входные данные, т.е. программист не выспался и забыл отсортировать массив, мы скорее всего поймаем этот ассерт еще на стадии отладки или тестирования.
Не проверять в каждой фукнции правильность переданных параметров.
Т.е. подразумевается, что проверки на свои же ошибки писать глупо, плюс не эффективно, плюс можно погрязнуть в ифах. Но что бы улучшить себе немного жизнь — есть ассерты.
«Вы говорите об этом так, как будто это что-то плохое» (с)
Хотя если чесно, я не помню откуда я это узнал, вполне возможно, что не придумал, а подсмотрел у кого-то :)
Основная их цель проверить ошибки которые могут быть допущенны программистом.
Естественно внешние данные ассертами не стоит проверять.
Например если моя функция подразумевает (precondition), что переданный в нее вектор должен быть отсортирован, то я пишу в начале нечто вроде assert( is_sorted( v ); Это своего рода и комментарий и не замедлит работу программы в релизе.
Странно, но если код к примеру не ексцепшн сейф, тогда на использование ексцепшнов логично наложить ограничения типа: не бросать из утилит и использовать их только в полностью новых и безопасных учатках кода.
Хотя в любом случае подобные ограничения меня тоже повергают в ступор, но они, к сожалению, бывают. У нас, к примеру, главный программист, который в штатах наложил вето на использование ассертов.
Немного поправляю, для функторов компилятор создает отдельную специализацию того же std::for_each, и поэтому может встроить его тело в данную ф-цию.
В случае реализации через указатели на ф-ции, встраивание невозможно.
Конечно я не считаю время затраченное на вызов, огромным профитом, но всеже :)
Наверное я слоупук, но у меня был период развивития, когда каждый раз, когда приходилось использовать указатель на функицю я тупил/гуглил, прежде чем выходило написать правильно :)
Я впринципе согласен с вами, но ситуации бывают разными.
Некоторые апи могут требовать указатели на ф-ции, некоторым проектам лет по 10, некоторые код-конвеншны могут не одобрять использования темплейтс, и тд.
Цель заметки состояла не в том, что бы пропогандировать использование указателей на ф-ции, а в том что бы подсказать как можно сэкономить время и нервы некоторым программистам.
Всегда воспринимал эту фразу, как напуствие писать код так, что бы как можно больше ошибок проявились на стадии компиляции.
Но в данном контексте он тоже очень подходит.
ну то бросто Blue Screen, такие экраны могли возникнуть если вытягиваеш дискету во время обращения к ней, и исчезали после того как снова вставиш дискету.
настоящие BSODы были в векте NT, а потом в Win2K, XP,…
А на стену она вешается?
Просто помоему самый большой профит от подобной подставки можно извлечь, повесив ее на стену рядом с розеткой, что бы ставить телефон заряжаться, и он не мешал.
я вот думал когда-то что-то типа мд5 от
{STRONGPART}mail
{STRONGPART}corp
{STRONGPART}pc
{STRONGPART}whatever
или на крайний случай перемешивать {STRONGPART} и вторую часть.
хотел написать:
Не нужно же проверять в каждой фукнции правильность переданных параметров.
Не проверять в каждой фукнции правильность переданных параметров.
Т.е. подразумевается, что проверки на свои же ошибки писать глупо, плюс не эффективно, плюс можно погрязнуть в ифах. Но что бы улучшить себе немного жизнь — есть ассерты.
Хотя если чесно, я не помню откуда я это узнал, вполне возможно, что не придумал, а подсмотрел у кого-то :)
Основная их цель проверить ошибки которые могут быть допущенны программистом.
Естественно внешние данные ассертами не стоит проверять.
Например если моя функция подразумевает (precondition), что переданный в нее вектор должен быть отсортирован, то я пишу в начале нечто вроде assert( is_sorted( v ); Это своего рода и комментарий и не замедлит работу программы в релизе.
Хотя в любом случае подобные ограничения меня тоже повергают в ступор, но они, к сожалению, бывают. У нас, к примеру, главный программист, который в штатах наложил вето на использование ассертов.
В случае реализации через указатели на ф-ции, встраивание невозможно.
Конечно я не считаю время затраченное на вызов, огромным профитом, но всеже :)
Некоторые апи могут требовать указатели на ф-ции, некоторым проектам лет по 10, некоторые код-конвеншны могут не одобрять использования темплейтс, и тд.
Цель заметки состояла не в том, что бы пропогандировать использование указателей на ф-ции, а в том что бы подсказать как можно сэкономить время и нервы некоторым программистам.
Но в данном контексте он тоже очень подходит.
Просто в Win95 — это не были экраны «Of Death», система часто могла продолжить работать.
настоящие BSODы были в векте NT, а потом в Win2K, XP,…
Просто помоему самый большой профит от подобной подставки можно извлечь, повесив ее на стену рядом с розеткой, что бы ставить телефон заряжаться, и он не мешал.