> m_xOfstream << m_xParameters.m_pObfuscater(xFinalString) << std::endl;
так, что данные не буферизуются. А что за буферизация ОС? И даже если таковая будет иметь место, то на диск все равно будет сброшено, т.к буферизация ОС не может зависеть от приложения…
>Если приложение что-нибудь запишет в лог перед тем как упасть, в логе вы ничего не увидите, какой >тогда в нем смысл?
Как минимум будет видна точка падения, а на основании этого уже можно производить дальнейшие исследования.
>К тому-же, в лог не выводятся идентификатор процесса — потока, именованный мьютекс в коде говорит >о том, что могут быть запущены несколько экземпляров одной программы, пишущих в один файл(что >плохо), следовательно, нужно либо разделять вывод в разные файлы, либо указывать ид-р процесса
Про ID процесса это спорный вопрос, я считаю, что если будет необходимость в ID процесса то это должно быть частью message которое поступает в ф-ию записи извне. Разные файлы так же должны настраиваться при запуске приложения, почему это должно быть частью логики самого класса логирования?
>Ну и напоследок: лучше, что-бы логгер не бросал исключения, так-как он часто используется при >обработке критических ситуаций, а шанс, что что нибудь пойдет не так в этой ситуации выше
Если назначена процедура обработки ошибки, тогда будет выполнена она, что сделать в ней это уже дело пользователя. Можно просто проглатить ошибку, реализация класса это позволяет.
Меня терзают смутные сомнения, по поводу существования таких фильтров в России, да и в любой другой стране. Нужна слишком большая вычислительная мощь. Причем, такое мощное оборудование должно стоять на каждом крупном узле провайдера. Даже пассивный съем сбоит при больших нагрузках, а при фильтрации пассивного съема мало. Нужно поймать, проанализировать и запретить\разрешить, это очень затратные операции и нужна слишком большая вычислительная мощь, чтобы это организовать…
Как по мне, так если важна кроссплатформенность, то это должна быть система которая может работаь на условно-любой ОС. Не вижу смысла в программе которая работает и в десктопной версии и в веб версии, все таки это разные идиологии. Если программа предназначается для десктопа, то она должна быть на десктопе, то же справедливо и для веба.
Потомучто для правильного(сиречь документированного) использования необходимо использование direct3d paint engine. Это работает сейчас, в большинстве случаев, и надеюсь будет работать всюду в ближайшем будущем. Workaround приведен в качестве костыля, который стоит использовать, если надо поставить продукт в массы. Основной целью статьи было именно правильное использование direct3d.
А вот второго предложения я не понял, зачем использовать event log?
так, что данные не буферизуются. А что за буферизация ОС? И даже если таковая будет иметь место, то на диск все равно будет сброшено, т.к буферизация ОС не может зависеть от приложения…
Как минимум будет видна точка падения, а на основании этого уже можно производить дальнейшие исследования.
>К тому-же, в лог не выводятся идентификатор процесса — потока, именованный мьютекс в коде говорит >о том, что могут быть запущены несколько экземпляров одной программы, пишущих в один файл(что >плохо), следовательно, нужно либо разделять вывод в разные файлы, либо указывать ид-р процесса
Про ID процесса это спорный вопрос, я считаю, что если будет необходимость в ID процесса то это должно быть частью message которое поступает в ф-ию записи извне. Разные файлы так же должны настраиваться при запуске приложения, почему это должно быть частью логики самого класса логирования?
>Ну и напоследок: лучше, что-бы логгер не бросал исключения, так-как он часто используется при >обработке критических ситуаций, а шанс, что что нибудь пойдет не так в этой ситуации выше
Если назначена процедура обработки ошибки, тогда будет выполнена она, что сделать в ней это уже дело пользователя. Можно просто проглатить ошибку, реализация класса это позволяет.