Ага, тоже регулярно смотрю на кое-какие свои отладочные сообщения и думаю о том, что надо бы убрать все trailing \n. У меня всё ещё усугубляется тем, что дело происходит на маке, где NSLog(format_string, ...) не требует \n - т.е. мой отладочный вывод отличается от стандартного.
Тут тонкость "а что если writeLogInSomeThreadSafeWayWithAutoEndlineBecausePonies бросит исключение". В каких-то проектах она важна, в каких-то нет, в общем случае лучше не заниматься сложной химией в деструкторах.
В достаточно навороченных проектах логирование не бывает низкоурвневым, там обязательно ищется какой-нибудь текущий логгер, читаются его настройки из файла или делается запрос по IPC. Так что варианты - или вообще изгонять исключения из проекта, или лепить "catch (...)", что ещё хуже чем исключение в логгере. Закрыться от двойного исключения и пускай летит.
Макросы зло (действительно ли проще всегда писать этот MY_LOG с извратным синтаксисом?). Для логов вполне сойдёт вариант с деструктором (чтобы не было двойного исключения, поставить ту функцию из std:..., не помню имени), и это уже есть, например, в QDebug и google test.
Comments 19
У меня всё ещё усугубляется тем, что дело происходит на маке, где NSLog(format_string, ...) не требует \n - т.е. мой отладочный вывод отличается от стандартного.
Reply
(The comment has been removed)
Reply
(The comment has been removed)
Reply
Reply
if (дебажная трассировка) { только в дебаге вычислять аргументы для лога }.
В формате
MY_LOG("info at index " << i << " is: " << GenerateDebugString(i) );
можно спрятать такой if тривиальным образом.
Чтобы в "обычном" режиме не вычислять то, что не печатается, и чтобы не думать про эффективную генерацию дебажного вывода.
Reply
Reply
Reply
Reply
(The comment has been removed)
Reply
Leave a comment