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

F>Ого ! Даже интересно как это вас заставляли писать плохо читабельный код ? Не пойму, для чего это понадобилось Это как если бы повару сказали "Приготовь обед так, чтобы посетитель получил расстройство желудка"

Бывает и не такое , а как вам требование не использовать assert или похожие макросы ?

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

F>>Ого ! Даже интересно как это вас заставляли писать плохо читабельный код ? Не пойму, для чего это понадобилось Это как если бы повару сказали "Приготовь обед так, чтобы посетитель получил расстройство желудка"
M>Бывает и не такое , а как вам требование не использовать assert или похожие макросы ?

Нормальное требование. Ассерты в сервере, например — нонсенс.

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

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

F>>>Ого ! Даже интересно как это вас заставляли писать плохо читабельный код ? Не пойму, для чего это понадобилось Это как если бы повару сказали "Приготовь обед так, чтобы посетитель получил расстройство желудка"
M>>Бывает и не такое , а как вам требование не использовать assert или похожие макросы ?

aik>Нормальное требование. Ассерты в сервере, например — нонсенс.

А чем тебе сервера-то не угодили?

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

F>>>>Ого ! Даже интересно как это вас заставляли писать плохо читабельный код ? Не пойму, для чего это понадобилось Это как если бы повару сказали "Приготовь обед так, чтобы посетитель получил расстройство желудка"
M>>>Бывает и не такое , а как вам требование не использовать assert или похожие макросы ?
aik>>Нормальное требование. Ассерты в сервере, например — нонсенс.
D>А чем тебе сервера-то не угодили?

Их не видно. А ассерт ставит колом процесс, пока ты по кнопке не жмакнешь. Там вообще правила более жесткие, чтобы лепить даже лишний вывод в лог.

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

aik>Их не видно. А ассерт ставит колом процесс, пока ты по кнопке не жмакнешь. Там вообще правила более жесткие, чтобы лепить даже лишний вывод в лог.

Лог это и есть асертородобный макрос который запрещен

А идея перенаправить асерты в лог , не пользуется популярностью ?

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

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

F>>>>>Ого ! Даже интересно как это вас заставляли писать плохо читабельный код ? Не пойму, для чего это понадобилось Это как если бы повару сказали "Приготовь обед так, чтобы посетитель получил расстройство желудка"
M>>>>Бывает и не такое , а как вам требование не использовать assert или похожие макросы ?
aik>>>Нормальное требование. Ассерты в сервере, например — нонсенс.
D>>А чем тебе сервера-то не угодили?

aik>Их не видно. А ассерт ставит колом процесс, пока ты по кнопке не жмакнешь. Там вообще правила более жесткие, чтобы лепить даже лишний вывод в лог.

Так делать их видимыми. Писать в лог, например. Если assert fail'ится, значит, что-то пошло не так. Тут уж дело не до производительности (которую логи могут, вроде бы, понизить). Это может казаться противоестественным, но fail fast подход делает программы более устойчивыми.

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

aik>>Их не видно. А ассерт ставит колом процесс, пока ты по кнопке не жмакнешь. Там вообще правила более жесткие, чтобы лепить даже лишний вывод в лог.
M>Лог это и есть асертородобный макрос который запрещен
M>А идея перенаправить асерты в лог , не пользуется популярностью ?

Это не важно. Логи растут, переполняются, забивают винт => сервер лежит.

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

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

aik>>>Их не видно. А ассерт ставит колом процесс, пока ты по кнопке не жмакнешь. Там вообще правила более жесткие, чтобы лепить даже лишний вывод в лог.
M>>Лог это и есть асертородобный макрос который запрещен
M>>А идея перенаправить асерты в лог , не пользуется популярностью ?

aik>Это не важно. Логи растут, переполняются, забивают винт => сервер лежит.

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

Здравствуйте, aik, Вы писали:
D>>А чем тебе сервера-то не угодили?

aik>Их не видно. А ассерт ставит колом процесс, пока ты по кнопке не жмакнешь. Там вообще правила более жесткие, чтобы лепить даже лишний вывод в лог.
Ты, наверное, какие-то не те ассерты встречал.
Настоящие ассерты:
а) не имеют никакой связи с кнопками. Их обычная функция — вызвать аварийную остановку, при этом гарантируя запись/выдачу соответствующей информации. Отличие от самопроизвольной остановки — именно в наличии этой дополнительной информации
б) обладают способностью автоматически исчезать из релизного кода. Потому, что ассерт — это средство отладки. Его задача не в том, чтобы помочь обработать ошибку в данном коде, а в том, чтобы найти ошибку в коде, который им пользуется.

А про какие ассерты ты говоришь?

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

aik>>>>Их не видно. А ассерт ставит колом процесс, пока ты по кнопке не жмакнешь. Там вообще правила более жесткие, чтобы лепить даже лишний вывод в лог.
M>>>Лог это и есть асертородобный макрос который запрещен
M>>>А идея перенаправить асерты в лог , не пользуется популярностью ?
aik>>Это не важно. Логи растут, переполняются, забивают винт => сервер лежит.
D>А что, логи никто не смотрит до тех пор пока они не забьют винт? Тогда, конечно, assert'ы вам ни к чему.

Да все можно. И логи смотреть/стирать можно. И ассерты лепить. А можно направить усилия на повышение надежности кода, чтобы просто не было в коде веток, куда управление не может попасть в принципе.

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

D>>>А чем тебе сервера-то не угодили?
aik>>Их не видно. А ассерт ставит колом процесс, пока ты по кнопке не жмакнешь. Там вообще правила более жесткие, чтобы лепить даже лишний вывод в лог.
S>Ты, наверное, какие-то не те ассерты встречал.
S>Настоящие ассерты:
S>а) не имеют никакой связи с кнопками. Их обычная функция — вызвать аварийную остановку, при этом гарантируя запись/выдачу соответствующей информации. Отличие от самопроизвольной остановки — именно в наличии этой дополнительной информации

Аварийная остановка — плохо. У тебя система видео-наблюдения работает или диск пишется — аварийная остановка фатальна.
Вот сейчас с фирмварью вожусь — ну куда там ассертить? Это power management controller, он повиснет — дорогой, очень дорогой телекомный ящик встанет колом и целая деревня без телефонов сидеть будет, например. Там и аварийно остановиться нельзя даже.

S>б) обладают способностью автоматически исчезать из релизного кода. Потому, что ассерт — это средство отладки. Его задача не в том, чтобы помочь обработать ошибку в данном коде, а в том, чтобы найти ошибку в коде, который им пользуется.

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

S>А про какие ассерты ты говоришь?

Да про всякие Я веду к тому, что случаи — они разные бывают, и универсальное решение только одно — "убицца аб стенку, выпеть йад, ехать в бабруйск" и все такое прочее.

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


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

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

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

aik>>>Их не видно. А ассерт ставит колом процесс, пока ты по кнопке не жмакнешь. Там вообще правила более жесткие, чтобы лепить даже лишний вывод в лог.
M>>Лог это и есть асертородобный макрос который запрещен
M>>А идея перенаправить асерты в лог , не пользуется популярностью ?

aik>Это не важно. Логи растут, переполняются, забивают винт => сервер лежит.
Пусть логирующий класс\другой класс сам чистит логи

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

aik>Аварийная остановка — плохо. У тебя система видео-наблюдения работает или диск пишется — аварийная остановка фатальна.
Гм. Ну так, друг любезный, надо ее отлаживать, значит. До того, как она в продакшн попадет. А не после того.
aik>Вот сейчас с фирмварью вожусь — ну куда там ассертить?
Туда же, надо полагать. Или ты без эмулятора работаешь?
aik>Это power management controller, он повиснет — дорогой, очень дорогой телекомный ящик встанет колом и целая деревня без телефонов сидеть будет, например. Там и аварийно остановиться нельзя даже.
Ну и я об чем? Ассерт применяется примерно так:

void SetData(MyStr* struct, Data* data)
{
  ASSERT(struct!= NULL, "ERROR: Null value passed to setData!");
    struct->Field1 = data;
}

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

int RegisterUser(char * szFirstName, char* szLastName)
{
  ASSERT(szFirstName != NULL); // внещний код обязан передать нам валидный поинтер!
  ASSERT(szLastName != NULL);
    if(strlen(szLastName) == 0) // а вот тут уже пользовательский ввод
    {
      return -1; // возвращаем код ошибки, чтобы вызывающий код мог отразить это в интерфейсе
    }
    return SaveToDb(szFirstName, szLastName);
}

int RegisterUser(char * szFirstName, char* szLastName)
{
  ASSERT(szFirstName != NULL); // внещний код обязан передать нам валидный поинтер!
  ASSERT(strlen(szLastName) != 0); // и длина должна быть ненулевой!
}

При отладке у нас очень быстро выявляются места, где мы забыли корректно обработать ошибки — ассерты выкидывают нам необходимую информацию.

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

aik>Ну да, и тогда концов не найдешь почему у клиента, например, падает. Ведь у него ж релиз, ассертов нет.
Если тебе условия позволяют развернуть обратную связь с клиентом — отдавай ему обассерченную версию. Без ассертов-то вообще ничего не получишь, разве что AV/BSOD/core dump...
S>>А про какие ассерты ты говоришь?
aik>Да про всякие
Ну например?
aik>Я веду к тому, что случаи — они разные бывают,
Бывают. Но я пока не встречал случая, в котором бы ассерты были вредны. Так что я пока не вижу оправдания запрету на их использование.

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

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

M>>>А идея перенаправить асерты в лог , не пользуется популярностью ?

aik>>Это не важно. Логи растут, переполняются, забивают винт => сервер лежит.
LM>Пусть логирующий класс\другой класс сам чистит логи

Не, не его это дело. Да и программа может работать на высоком приоритете, когда нельзя из нее запускать какие-то административные действия (типа архивирования логов), либо слишком это геморройно.

Меня тут недавно VladD2 спрашивал, что я на Ruby реального делаю Вот как раз последнее, что я делал -- это набор скриптов, которые ищут старые логи и архивируют их, а слишком старые заархивированные логи просто удаляют. Такой скрипт настраивается один раз администратором, запускается, например, через cron и все -- винты всегда остаются сухими и чистыми

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

S>В тех местах, где мы не можем гарантировать корректных параметров, вместо ассерта надо писать логику обработки. Примерно так:
S>

S>int RegisterUser(char * szFirstName, char* szLastName)
S>{
S>  ASSERT(szFirstName != NULL); // внещний код обязан передать нам валидный поинтер!
S>  ASSERT(szLastName != NULL);
S>    if(strlen(szLastName) == 0) // а вот тут уже пользовательский ввод
S>    {
S>      return -1; // возвращаем код ошибки, чтобы вызывающий код мог отразить это в интерфейсе
S>    }
S>    return SaveToDb(szFirstName, szLastName);
S>}
S>

Имхо, самая большая проблема ASSERT-ов это то, что они выбрасываются из production кода. Абыдна бывает получать в production ошибку в функции RegisterUser (или даже в дебрях SaveToDb) из-за того, что где-то выше один из szFirstName, szLastName получился нулевым. Благодоря ASSERT-ам мы теряем возможность быстро продиагностировать проблему.

А отладить все невозможно. Поэтому и в production системах баги, к сожалению, есть.

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

S>int RegisterUser(char * szFirstName, char* szLastName)
S>{
S> ASSERT(szFirstName != NULL); // внещний код обязан передать нам валидный поинтер!
S> ASSERT(szLastName != NULL);
S> if(strlen(szLastName) == 0) // а вот тут уже пользовательский ввод
S> {
S> return -1; // возвращаем код ошибки, чтобы вызывающий код мог отразить это в интерфейсе
S> }
S> return SaveToDb(szFirstName, szLastName);
S>}

Здесь ошибка. Вместо

ASSERT(szFirstName != NULL);

надо писать

ASSERT(szFirstName != NULL);
if (NULL == szFirstName)
return -1;

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

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

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

M>>>>А идея перенаправить асерты в лог , не пользуется популярностью ?

aik>>>Это не важно. Логи растут, переполняются, забивают винт => сервер лежит.
LM>>Пусть логирующий класс\другой класс сам чистит логи

E>Не, не его это дело. Да и программа может работать на высоком приоритете, когда нельзя из нее запускать какие-то административные действия (типа архивирования логов), либо слишком это геморройно.

E>Меня тут недавно VladD2 спрашивал, что я на Ruby реального делаю Вот как раз последнее, что я делал -- это набор скриптов, которые ищут старые логи и архивируют их, а слишком старые заархивированные логи просто удаляют. Такой скрипт настраивается один раз администратором, запускается, например, через cron и все -- винты всегда остаются сухими и чистыми
Или так. Разница небольшая : места нам хватит

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


aik>Здесь ошибка. Вместо

aik>ASSERT(szFirstName != NULL);

aik>надо писать

aik>ASSERT(szFirstName != NULL);
aik>if (NULL == szFirstName)
aik> return -1;

aik>Так и ассерт не нужен. Везде, всегда проверять коды возвратов. Но, в общем, я описал почему может быть запрет на ассерты, кто хотел — тот понял, кто не хочет понимать — будет упираться. Дальше тему развивать не интересно.
ТОгда уж лучше исключения. И корректно обрабатывать все такие ситуации... Времени своего не жалко?

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

E>Имхо, самая большая проблема ASSERT-ов это то, что они выбрасываются из production кода. Абыдна бывает получать в production ошибку в функции RegisterUser (или даже в дебрях SaveToDb) из-за того, что где-то выше один из szFirstName, szLastName получился нулевым.
Нет. Если там стоял ассерт, то ты получил ошибку из-за того, что test coverage был неполным. А если он был неполным, то нефиг выкидывать ассерты из продакшна.
E>Благодоря ASSERT-ам мы теряем возможность быстро продиагностировать проблему.
А что, без ассерта ты имел какую-то возможность быстро продиагностировать проблему? Расскажи мне, что это за замечательная возможность. Я тоже хочу ей пользоваться.
E>А отладить все невозможно. Поэтому и в production системах баги, к сожалению, есть.
Это, конечно, да. Но для борьбы с этим есть и другие способы.