- Aroch
- Постоялец
запись в файл хороша если не нужно следить за состоянием лога в определенный момент пока программа еще работает. То есть такой лог будет полезен для получения фидбека от пользователей. Для себя же во время разработки будет гораздо удобнее вариант с отдельной программой. То есть все наши сообщения отправляем по сети и в реальном времени мы можем их в удобном виде просмотреть, также добавить фильтрацию, поиск, теги. Плюс принимать сообщения можно сразу от нескольких программ которые используют данный логер.
Иона
Не, ну без экспорта в латекс и пдф это неполноценный логер.
nerengd
> А не многовато ли кода?
Нет. Я бы сказал, наоборот, маловато.
> Для примера мой лог:
файловые потоки в крестах thread-safe на запись?
Алсо, Иона - это мужское имя.
beejah
> файловые потоки в крестах thread-safe на запись?
должны быть.
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2760.htm
Логер говно. Писать из логера сразу в файл в том же потоке - это дикость. Это не настраиваемо и не конфигурируемо
Рекомендую почитать как сделано в том же log4j2 например, хотя бы общее введение чтобы понимать архитектуру.
Есть логеры - это классы куда мы пишем сообщения, где идет проверка имени логера, проверка вербосити и т.д - как в ТС, затем сообщения кладутся в кольцевой буфер и читаются т.н. аппендерами - это как раз классы, отвечающие за форматирование сообщения, запись на диск/сеть/зип-файл/дебаг-окно и т.д.
Все это настраиваться должно файлами конфигурации, чтобы не требовалось перехерачивать весь код программы, когда решишь вместо (или вместе) файла на диске отсылать пакеты на syslog.
В т.ч. и асинхронная батчевая запись на диск, которая опять таки настраивается только конфигурацией.
Aroch
> Для себя же во время разработки будет гораздо удобнее вариант с отдельной
> программой.
Если делать по уму, на код программы это никак не влияет, только на файл конфигурации логгера.
кстати, даже специально для шарперов портировали
https://logging.apache.org/log4net/
И даже для вечно сосущих крестовиков что-то там наваяли
https://logging.apache.org/log4cxx/latest_stable/
9К720
> Все это настраиваться должно файлами конфигурации
Ну да, один хмл файл конфигурации логгера для 2д платформера это как-то убого, нужна пара десятков чтоб нормальную гибкость обеспечить.
9К720
> Писать из логера сразу в файл в том же потоке - это дикость.
> асинхронная батчевая запись на диск
Не знаю как в этих ваших модных яп, но в С++ все это есть в стд и пока явно не вызовешь fflush данные будут накапливаться в памяти и записываться на диск по своей внутренней логике. Но для логера очень желательно явно вызывать запись на диск, чтоб ничего не потерялось при крэше.
kipar
> нужна пара десятков чтоб нормальную гибкость обеспечить.
Где я такое говорил? Суть в том, что логеры и апендеры должны быть разьединены.
kipar
> для 2д платформера
Для 2д платформера можно вообще нихера не делать логирование, и писать весь код в одном файле, как это делает местный создатель рогаликов. В данном треде оценивается логгер, а не платформер. Так вот, логеры итт - говно.
/A\
> Но для логера очень желательно явно вызывать запись на диск, чтоб ничего не
> потерялось при крэше.
Да, асинхронная запись в лог имеет такой недостаток. На этапе отладки решается настройкой синхронного аппендера. Либо критичные вещи пишутся синхронно, а отладочная инфа - асинхронно, в другой файл.
Но флаш вызывается не в логгере, а в аппендере. Потому что флаш - это особенность именно дискового хранения данных. Да, возможно - в том же потоке. Но это должны быть разные вещи.
exchg
> должны быть.
Concurrent access to a stream object [string.streams, file.streams], stream buffer object [stream.buffers], or C Library stream [c.files] by multiple threads may result in a data race [intro.multithread] unless otherwise specified [iostream.objects]. [Note: Data races result in undefined behavior [intro.multithread]. --end note]
Что-то я чего-то не понял тогда.
9К720
> Где я такое говорил?
Я процитировал
9К720
> В данном треде оценивается логгер, а не платформер. Так вот, логеры итт -
> говно.
Говно (в контексте логгера для 2д игр) - логгер из десятков файлов который надо конфигурировать с помощью хмл (прочитав сначала многостраничный мануал) и который небось ещё пачку зависимостей и марсианскую систему сборки за собой тянет.
kipar
> который надо конфигурировать с помощью хмл (прочитав сначала многостраничный
> мануал) и который небось ещё пачку зависимостей и марсианскую систему сборки за
> собой тянет.
Ты бы глянул по ссылкам, прежде чем ахинею то нести.
Конечно, вместо того чтобы час потратить на изучение прикручивания либы, лучше несколько дней писать свой кривой и глючный велосипед.
Впрочем, в геймдеве никогда нормальной инженерной культуры разработки не было, откуда ей взяться.
Я писал для себя по фану сириоз логгер со всеми этими логгерами, хэндлерами, пуллом сообщений (log4cxx категорически не приемлю, да и код вроде на Ц был).
Потом тупо выкинул, хотя он норм работал и расширялся, потому что для себя по фану обычного stderr - за глаза. Даже на саппорте.
Овчинка выделки не стоит, тупо некому ковыряться с этими логами. Что у меня, двадцать серверов на саппорте и бригада Искандеров, шталь.
beejah
> Что-то я чего-то не понял тогда.
Это предложение для стандарта 10 летней давности. Насколько оно прошло и т.д. я не знаю, мелкие пишут в своих сдк что это все оптокобезопасно -
iostream
The standard iostream objects cin, cout, cerr, clog, wcin, wcout, wcerr, and wclog follow the same rules as the other classes, with this exception: it is safe to write to an object from multiple threads. For example, thread 1 can write to cout at the same time as thread 2. However, this can cause the output from the two threads to be intermixed.
https://docs.microsoft.com/en-us/cpp/standard-library/thread-safe… ?view=vs-2017
Посикс (т.е. 'FILE*' для Си) также говорит, что работа с файлами должна быть атомарна и потокобезовпасна.
На практике, я думаю, нужно перепроверять для используемой реализации/целевой платформы.
Тема в архиве.