Здравствуйте, Sni4ok, Вы писали:
ТКС>>По-хорошему надо бы просто завести по буферу на поток, чтобы не терять много на синхронизации, из которых потом (когда наберется цельная запись лога) асинхронно (overlapped I/O) сбрасывать все в один файл.
S>всё равно эту запись(хоть и асинхронную) вам придётся синхронизировать,
Нифига, эта забота операционки. Да и вообще, подобную операцию можно выполнять достаточно эффективно, даже если ОС не умеет асинхронную запись, коллизии на синхронизации в реальной программе будут очень редкими.
S>да и ждать- пока наберётся нужное количество информации, чтобы записать- утопично, поскольку где гарантия что, программа не рухнет прямо через мгновение, а вы потеряете ту информацию ради которой и велось логирование?
Конец строки (вернее, разрушение анонимного объекта типа MyLog) — сброс буфера. Потерять половину подобного буфера считаю вполне приемлемым. Если и это не устраивает, целесообразнее будет завести отдельный сервис логгирования, а не мучатся с отдельным файлом для каждой нитки.
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re[12]: Насколько "вредно" использование singleton?
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, enji, Вы писали:
I>>>Проблема в том, что класс получается зависимым от системы логирования.
E>>А как иначе? Код, который что-то логирует, безусловно зависит от системы логиривания. Класс, который сохраняет сообщения лога куда-либо, так же зависит от системы логирования.
I>Иначе — зависимость только от интерфейса для логирования а не всей системы или синглтона какого.
Ну дык я об этом и говорю... Подразумевается, что система логирования имеет два "интерфейса" — один для регистрации обработчиков, второй — для логирования.
первый — это класс LogStream, второй — интерфейс обработчика, класс LogMessage и функция registerProcessor()
Но внутри то сидят общие данные, к которым полезут как LogStream, так и registerProcessor. Наружу они не видны, клиенты от них не зависят. Дальше есть два варианта — или эти данные глобальны, или LogStream и registerProcessor дополнительно получают некую ссылку. Возможно это наиболее универсальный способ, но тогда надо что бы тот, кто хочет что-нить логировать, имел эту ссылку. ИМХО, таскать во многих объектах такую ссылку нифига не удобно.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
Re[13]: Насколько "вредно" использование singleton?
Здравствуйте, blackhearted, Вы писали:
I>>А как можно сделать "создаёт нужную категогрию логирования " без зависимости от системы логирования ?
B>вызывая B>
B>logSingleton.createCategory("someString");
B>
B>C таким подходом вообще всё логирование — это зависимость от системы логирования.
В данном случае ты проблему зависимости решил с помощью синглтона.
Это именно тот случай, где синглтон не стоит применять.
Re[10]: Насколько "вредно" использование singleton?
Здравствуйте, Тот кто сидит в пруду, Вы писали:
ТКС>Если и это не устраивает, целесообразнее будет завести отдельный сервис логгирования, а не мучатся с отдельным файлом для каждой нитки.
а вы ещё и отдельный файл для каждой нити делаете? а что вы делаете, когда этих нитей >100 но каждая из них какюу-нибудь фигню для плюёт в лог?
и какже вы потом их мержите, или поведение одной нитки у вас никогда не зависит от поведения(а значит и описания их работы в логе) от других?
Re[14]: Насколько "вредно" использование singleton?
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, enji, Вы писали:
E>>первый — это класс LogStream, второй — интерфейс обработчика, класс LogMessage и функция registerProcessor()
I>Это уже слишком много
Ну тогда готов выслушать ваши предложения по поводу системы логирования
E>>ИМХО, таскать во многих объектах такую ссылку нифига не удобно.
I>Конечно неудобно, но это не значит, что для решения этой проблемы нужно создавать синглтон.
А что нужно создавать? Неужели вы реально хотите таскать ссылку на систему логирования через всю программу?
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
Re[14]: Насколько "вредно" использование singleton?
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, blackhearted, Вы писали:
I>>>А как можно сделать "создаёт нужную категогрию логирования " без зависимости от системы логирования ?
B>>вызывая B>>
B>>logSingleton.createCategory("someString");
B>>
B>>C таким подходом вообще всё логирование — это зависимость от системы логирования.
I>В данном случае ты проблему зависимости решил с помощью синглтона.
I>Это именно тот случай, где синглтон не стоит применять.
Ваш рецепт логирования на плюсах?
Re[15]: Насколько "вредно" использование singleton?
Здравствуйте, blackhearted, Вы писали:
I>>В данном случае ты проблему зависимости решил с помощью синглтона.
I>>Это именно тот случай, где синглтон не стоит применять.
B>Ваш рецепт логирования на плюсах?
Как минимум service locator
Re[15]: Насколько "вредно" использование singleton?
Здравствуйте, enji, Вы писали:
I>>Конечно неудобно, но это не значит, что для решения этой проблемы нужно создавать синглтон.
E>А что нужно создавать? Неужели вы реально хотите таскать ссылку на систему логирования через всю программу?
Не конечно. И синглтон тоже не нужен
Re[16]: Насколько "вредно" использование singleton?
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, blackhearted, Вы писали:
I>>>В данном случае ты проблему зависимости решил с помощью синглтона.
I>>>Это именно тот случай, где синглтон не стоит применять.
B>>Ваш рецепт логирования на плюсах?
I>Как минимум service locator
Не тяжеловато-ли будет в нагруженном сервере его использовать для логирования?
Re[17]: Насколько "вредно" использование singleton?
Здравствуйте, blackhearted, Вы писали:
B>>>Ваш рецепт логирования на плюсах?
I>>Как минимум service locator
B>Не тяжеловато-ли будет в нагруженном сервере его использовать для логирования?
Что ты понимаешь под словами "service locator" ?
Нужно один раз на объект получить ссылку на логгер. Если это можт повалить нагруженый сервер, то сдаётся проблема где то в другом месте.
Re[18]: Насколько "вредно" использование singleton?
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, blackhearted, Вы писали:
B>>>>Ваш рецепт логирования на плюсах?
I>>>Как минимум service locator
B>>Не тяжеловато-ли будет в нагруженном сервере его использовать для логирования?
I>Что ты понимаешь под словами "service locator" ?
I>Нужно один раз на объект получить ссылку на логгер. Если это можт повалить нагруженый сервер, то сдаётся проблема где то в другом месте.
Я понимаю это так же как и википедия
The service locator pattern is a design pattern used in software development to encapsulate the processes involved in obtaining a service with a strong abstraction layer. This pattern uses a central registry known as the "service locator" which on request returns the information necessary to perform a certain task.
Не вижу преимущества central registry перед singleton.
Re[19]: Насколько "вредно" использование singleton?
I>>Нужно один раз на объект получить ссылку на логгер. Если это можт повалить нагруженый сервер, то сдаётся проблема где то в другом месте.
B>Я понимаю это так же как и википедия
B>
B>The service locator pattern is a design pattern used in software development to encapsulate the processes involved in obtaining a service with a strong abstraction layer. This pattern uses a central registry known as the "service locator" which on request returns the information necessary to perform a certain task.
B>Не вижу преимущества central registry перед singleton.
Здравствуйте, Sni4ok, Вы писали:
ТКС>>Если и это не устраивает, целесообразнее будет завести отдельный сервис логгирования, а не мучатся с отдельным файлом для каждой нитки.
S>а вы ещё и отдельный файл для каждой нити делаете?
Нет конечно. Но тут кто-то предлагал.
S> а что вы делаете, когда этих нитей >100 но каждая из них какюу-нибудь фигню для плюёт в лог? S>и какже вы потом их мержите, или поведение одной нитки у вас никогда не зависит от поведения(а значит и описания их работы в логе) от других?
Не ко мне вопрос.
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re[19]: Насколько "вредно" использование singleton?
B>The service locator pattern is a design pattern used in software development to encapsulate the processes involved in obtaining a service with a strong abstraction layer. This pattern uses a central registry known as the "service locator" which on request returns the information necessary to perform a certain task.
B>Не вижу преимущества central registry перед singleton.
ну так service locator не сводится к central registry.
Преимущетсво локатора оного в слабой связности, тестируемости, прозрачности, реюзабельности кода. заплатить за это нужно зависимостью от одного конкретного интерфейса и интерфейсом самого локатора.
В случае с синглтоном всё это отсутствует.
сам central registry и будет синглтоном, но кроме него не будет никаких других синглтонов, ни для лога, ни для чего еще.
Не зря в букварях по паттернам сообщается что использовать синглтон для управления зависимостями крайне некузяво
Есть еще более сильная вещь, dependency injection, но на с++ я видел такое только для COM-объектов.
Re[20]: Насколько "вредно" использование singleton?
Здравствуйте, Ikemefula, Вы писали:
I>Локатор дает доступ к самым различным сервисам, а не только к логгеру.
I>Логгер — это т.н. сквозной функционал, ты что, будешь для каждого такого сервиса синглтон городить ?
I>Используя dependency injection у тебя получится примерно так
I>
Здравствуйте, Ikemefula, Вы писали:
B>>Не вижу преимущества central registry перед singleton.
I>ну так service locator не сводится к central registry.
I>Преимущетсво локатора оного в слабой связности, тестируемости, прозрачности, реюзабельности кода. заплатить за это нужно зависимостью от одного конкретного интерфейса и интерфейсом самого локатора.
I>В случае с синглтоном всё это отсутствует.
I>сам central registry и будет синглтоном, но кроме него не будет никаких других синглтонов, ни для лога, ни для чего еще.
Ну т.е. вместо 20 несвязанных друг с другом синглтонов, каждый из которых ничего не знает о других, будет 1 мегасинглтон, который знает и о системе логирования и о загрузке данных через интернет (где-то выше мелькал пример) и о драйверах оборудования, ... Получается этот мегасинглтон заточен под конкретный проект, перетащить его в другой проект в принципе невозможно.
Или же этот реестр будет хранить что-то вроде void*, а затем будет иметься кошмарный интерфейс вида reestr::get<LogSystem>()->log("bla bla")
И чем такой подход лучше?
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
Re[6]: Насколько "вредно" использование singleton?
Здравствуйте, szag, Вы писали:
S>Здравствуйте, sidorov18, Вы писали:
S>>У меня, например, синглтоном класс лог. S>>А еще есть класс-синглтон, который контент из нета качает и парсит в свои структуры.
S>всегда может понадобится второй лог и работа через несколько соединений. Чисто моё имхо, в идеальной программе сингелтонов быть не должно. Практически всегда может потребоваться вторая копия объекта и исправить это будет не так просто, как изначально отказаться от использования синглтонов.
Это зависит от того, как сделан синглтон, насколько его "синглтоновость" вшита в класс. И может решатся комментированием одной строчки или даже его можно сделать многофункциональым.
например:
template<typename T>
T& get_instance_singletone()
{
static T t;//работу в многопоточной среде убираем для наглядности.return t;
}
или это уже не синглтон?
второй экземпляр может понадобится, а может и не понадобится.
Например есть COM класс, который должен быть синглтоном. и за последние пол года это не изменилось пока)
Синглтоном его делает своя фабрика. Как в этом случае избавится от синглтона? COM сервер — внепроцессный.
А чтобы его переделать в обычный класс, нужно закомментить одну строчку — DECLARE_CLASSFACTORY_EX(...) или добавить еще один класс, который будет от него наследоватся — если нужно 2 класса.
Re[21]: Насколько "вредно" использование singleton?
Здравствуйте, enji, Вы писали:
E>Ну т.е. вместо 20 несвязанных друг с другом синглтонов, каждый из которых ничего не знает о других, будет 1 мегасинглтон, который знает и о системе логирования и о загрузке данных через интернет (где-то выше мелькал пример) и о драйверах оборудования, ... Получается этот мегасинглтон заточен под конкретный проект, перетащить его в другой проект в принципе невозможно.
Код конфгурации знает про всё в системе. Сам regisry вообще ни про что не знает.
этот мегасингтон перетаскивается на раз в другой проект.
E>Или же этот реестр будет хранить что-то вроде void*, а затем будет иметься кошмарный интерфейс вида reestr::get<LogSystem>()->log("bla bla")
Реестр будет хранить то, что в него напихал конфигуратор.
E>И чем такой подход лучше?