- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
void Logger::LogString( std::string &s )
{
if (s.size() > 4096) {
// предотвращаем слишком длиные строки в логе.
s.resize( 4096 );
}
m_LogStream << LogMessagePrefix() << s << std::endl;
}
Кресты / Говнокод #4579
0
народ пару дней понадобилось найти почему XML сообщения, размером слегка больше обычного, Xerces не принимает. идеи иссякли - пока в лог не посмотрели и не нашли вот по такому (проиллюстрированому выше) чудо принципу работающий логгер.
Запостил: 
Dummy00001,
(Updated )
любимая фишка оригинального кода: к переменной iostream (которую я выше обозначил m_LogStream) обращатся через три-четыре вложеных глобальных макроса, которые уровень логгера проверяют и нужный стрим подсовывают. я это порывался раньше сюда запостить, но там такая туева хуча кода, что не даже смешно. а говно как раз что три уровня логгера через четыре уровня вложенности макросов (переливающие из пустого в порожнее) генерируется код который ожидает что в контексте есть переменная m_Log указывающая на объект логгера (у объекта логгера она тоже есть и поставлена в this) и у этой переменной есть несколько предопределенных полей, включая уровень лога и стримы. мне сложно представить что происходило в голове у человека/людей кто этот код писал (код есть часть продукта купленого у французской фирмы).
Нет. Изначально это была популярная идея и были ее реализации в нескольких нишевых STLах.
Но эти все оптимизации относительно быстро умерли, даже не достигнув большинства разработчиков, благодаря популяризации много-поточности.
Как и та же оптимизация где `substr() const` возвращает только ссылку на подстроку не создавая новой строки (оригинал строки то не обязан быть const и другим потоком может уже начать меняться). Реализация оказалась сложнее чем предполагалось, и потеря производительности на всех остальных операциях была слишком большая. Проще и эффективней оказалось сделать более быстрый аллокатор памяти - без чего STL в целом тормозило бы до бесполезности.