Бібліотека журналу для (с ++) ігор [закрито]

Я знаю багато бібліотек журналів, але я їх не перевіряв. (GoogleLog, Pantheios, прискорене збільшення :: бібліотека журналів ...)

В іграх, особливо у віддалених багатокористувацьких та багатопотокових іграх, ведення журналу є життєво важливим для налагодження, навіть якщо ви видалите всі журнали врешті-решт.

Скажімо, я роблю гру на ПК (не консольну), яка потребує журналів (багатокористувацькі та багатопотокові та / або багатопроцесорні), і у мене є вагомі причини шукати бібліотеку для ведення журналів (наприклад, у мене немає часу або я не впевнений у своїй здатності написати правильно для мого випадку).

Припускаючи, що мені потрібно:

1. виконання
2. простота використання (дозволити потокове чи форматування чи щось подібне)
3. надійний (не протікайте і не вибивайте!)
4. кросплатформна (принаймні Windows, MacOSX, Linux / Ubuntu)

Яку бібліотеку реєстрації ви б не рекомендували?

В даний час я вважаю, що boost :: log є найбільш гнучким (можна навіть увійти дистанційно!), Але не мають хорошого оновлення продуктивності : є для високої продуктивності, але поки не випускається. Пантеос часто цитується, але я не маю порівняльних балів щодо продуктивності та використання. Я давно використовую власну ліб, але я знаю, що вона не керує багатопотоковою передачею, тому це велика проблема, навіть якщо вона досить швидка. Google Log здається цікавим. Мені просто потрібно перевірити його, але якщо ви вже порівняли ці вкладки та інше, ваші поради можуть бути корисними.

Ігри часто вимагають високої продуктивності, в той час як складні для налагодження, тому було б добре знати бібліотеки журналів, які в нашому конкретному випадку мають явні переваги.

журнал за допомогою socket (достатньо будь-якого пакета розетки) + веб-браузер websocket => найбільш універсальний, ненав'язливий інструмент ведення журналу, отримає години налагодження та уникне болі в очах.

• асинхронний (швидкість, оскільки вона відкладає всю роботу в браузері)
• відформатований (колір, розмір тощо)
• надійний (розетки ...)
• крос-платформа (браузер)

Тепер, бонус:

• динамічна фільтрація виконується дуже просто (за потреби використовуючи jage regex)
• з історією журналу, пам'яттю та порівнянням (специфікація HTML5 у базі даних "в браузері")
• Легкий спосіб зробити деякий графік яких - небудь даних ( з використанням SVG, або полотно або що - небудь) , як пам'ять , фрагментація пам'яті , і т.д. ...
• простий спосіб зробити якийсь 2D графік будь-яких даних ( підрозділ kd-дерева ? потенційне поле? або навіть просто змінне значення змінної? тощо)
• дозволяє віддалений журнал (за допомогою браузера іншого комп’ютера)
• використовуючи html5 у сховищі браузера, ви можете зберігати параметри сеансів журналу (поточні фільтри журналу тощо) та навіть примітки до кожного)
• дуже просто створити звіт про помилку або зв’язати квитки на проїзд лише одним клацанням
• можливість легко перемотати журнал, за допомогою графічного інтерфейсу

та багато інших завдань поза журналом:

• дозволяє отримати інформацію про профілі (графіки ...)
• може навіть слугувати консоллю (відправити команду з браузера) або навіть із швидким графічним інтерфейсом, використовуючи якийсь HTML або навіть флеш-інтерфейс
• зображення відрізняється у веб-переглядачі (надсилайте зображення за допомогою сокета та порівнюйте у веб-переглядачі, використовуючи можливості піксельного зображення на полотні)
• тощо ...

(майже все вищезазначене можна зробити за допомогою флеш-розеток, зберегти можливості бази даних)

Тепер я знаю, що здається, що ця річ трохи довга. Але це дійсно виграш часу на тривалий проект, із важкою ситуацією налагодження (наприклад, в іграх). Це найпотужніше, що я використовував з налагоджувачів ...

Примітка 1: єдиний мінус => подвійна перевірка побічного ефекту при налагодженні коду ігрової мережі (вплив на розмір буфера сокета, затримку, пропускну здатність тощо)

Примітка 2: деякий браузер деактивований веб-розеткою за замовчуванням з причини безпеки, перевірте: конфігуруйте речі, щоб переконатися, що він увімкнено.

Що стосується продуктивності, я вважаю, що темплог майже непереможений. Він використовує шаблони виразів, щоб відкласти оцінку операторів журналу, поки не буде встановлено, що інформація взагалі буде реєструватися. Оскільки ви також можете частково вимкнути ведення журналу (залежно від серйозності, походження та цільової аудиторії повідомлення журналу), деякі з цих записів реєстрації можуть бути усунені нульовим кодом компілятором для складання релізів. (Я насправді бачив, як це відбувається з VC.)

Нещодавно в бібліотеці мало що було зроблено, і інші на ЗО виявили, що багажник дещо не вистачає, але в компанії, в якій я працював, ми знайшли хлопця досить чуйним, а один із моїх тодішніх корівників навіть отримали доступ до комісії та додали до неї якийсь код, тож ви можете вважати, що це варто зробити.

Для перерахування ваших вимог:

виконання

Найкраще, що я знайшов. Особливо його здатність виключати повідомлення журналу під час компіляції та змушувати компілятор повністю їх усунути, була дуже привабливою.

простота використання (дозволити потокове чи форматування чи щось подібне)

Є класичні жахливі повідомлення про помилки компілятора шаблонів-мета-речей, коли ви робите щось не так, але коли справа стосується простоти використання, це

TEMPLOG_LOG(my_logger,sev_error,aud_support) << "logged in as " << user_name;

важко перемогти.
Однак, можливо, вам доведеться створити власні раковини журналу (саме туди йдуть повідомлення журналу), оскільки декілька попередньо упакованих (stderr, файл, журнал Windows тощо) не все так складно. Через те, що продуктивність є основною метою, суть справи є дещо складною (наприклад, формати форматів повідомлень журналу досить заплутані з протоколами журналу), але ми все-таки це освоїли (я пам'ятаю, перебираючи його в налагоджувачі, допомагаючи з цим) і один раз розумів, що не все так складно написати власні формати повідомлень або помилки журналів.

надійний (не протікайте і не вибивайте!)

Ми використовували його, не знаходячи жодних таких серйозних проблем. Динамічного розподілу пам’яті практично немає, тому важко навіть уявити, що вона робить щось не так. Звичайно, ми лише коли-небудь ставимо це на реальні тести в одному продукті.

кросплатформна (принаймні Windows, MacOSX, Linux / Ubuntu)

Коли ми використовували його, ми використовували його на Win32, OSX та декількох різних дистрибутивах Linux, серед них Ubuntu.

Що стосується багатопотокової передачі: ми цього не використовували, але з того, що я пам’ятаю про архітектуру lib, здається, вам потрібно було б обробити це лише в протоколах журналів. ICBWT.

Ви можете розглянути бібліотеку логотипів за адресою http://www.logog.org , яка, на мою думку, може відповідати вашим вимогам. Caveat: Я написав це.

Дивіться також відповіді інших людей на /programming/696321/best-logging-framework-for-native-c .

Можливо, вас зацікавить набір інструментів Baical :

• Бібліотека з відкритим кодом та крос-платформи (Win, Linux, x86 / x64) для журналів, слідів та телеметрії - P7
• Неймовірно швидкий (призначений для вбудованих пристроїв) - 3 мільйони журналів за секунду в мережу, 5 мільйонів для подачі на сучасний процесор. Я не знаю жодної іншої бібліотеки для ведення журналів, яка б забезпечила таку швидкість і настільки детальну інформацію для кожного повідомлення журналу.
• Нитка безпечна
• Кожне повідомлення про сліди містить:
  • текстове повідомлення
  • рівень
  • точний час (100ns)
  • вихідний файл, назва функції та рядок
  • ідентифікатор модуля та назва модуля
  • ідентифікатор потоку та ім’я потоку
  • індекс ядра процесора
• Серверна програма для отримання та перегляду журналів і телеметрії
• Ви можете збирати, аналізувати, шукати, фільтрувати журнали з різних джерел у режимі реального часу