Иона учиться программировать... логгер [C#] (3 стр)

стримы-то конечно потокобезопасны сами по себе, только вот каждый << превращается в отдельный вызов, с ожидаемым результатом.

exchg
> Это предложение для стандарта 10 летней давности.
Я вот думаю, в крестовселенной миграция кодобазы размером в 15 (пятнадцать) (в 1994 вполне себе на крестах шпилили, там, правда, еще олдскульные прото-СТЛ потоки были, если вообще уже были, но не в конкретике суть) хронологических лет, вызванная необходимостью интеграции логгера с заднечисловым хвостом прицепленных комитетом ограничений - в принципе считается нормой?

exchg
> The standard iostream objects cin, cout, cerr, clog, wcin, wcout, wcerr, and
> wclog
Ну, тут нету "every file stream".
Вот вижу.

Вижу там ниже про thread-safety объектов, которые читаются/пишутся из/в потоков/потоки.
Про thread-safety потоков - не вижу.

> На практике, я думаю, нужно перепроверять для используемой реализации/целевой
> платформы.
Надо объяснять, почему так делать ни в коем случае нельзя?

exchg
> Посикс (т.е. 'FILE*' для Си) также говорит, что работа с файлами должна быть
> атомарна и потокобезовпасна.
Посикс - это не "т.е 'FILE*' для Си". "т.е 'FILE*' для Си" - это ISO/ANSI C.
Впрочем, практически не принципиально, т.е гарантии в том или ином виде есть.

beejah
> вызванная необходимостью интеграции логгера с заднечисловым хвостом
С чем? "заднечисловым хвостом" - не совсем понял.

> в принципе считается нормой?
Понятия не имею. Я последние 10 лет на плюсах активно не пишу.

> Ну, тут нету "every file stream".
Думаю это должно гарантироваться поддержкой посиксом. Т.к. плюсовые стримы прикручены к файлстримам сишки.

> Про thread-safety потоков - не вижу.
Я запутался. Что есть - thread-safety потоков ?

> Надо объяснять, почему так делать ни в коем случае нельзя?
Если намек на использование не-портабельных решений в принципе, то я имел в виду, что по сторонам нужно смотреть, даже если ты переходишь дорогу на зеленый свет.

beejah
> осикс - это не "т.е 'FILE*' для Си". "т.е 'FILE*' для Си" - это ISO/ANSI C.
в данном примере я говорил о работе с файлами в общем. Ну т.е. на уровне ОС или на уровне оберток должно быть потокобезопасно. Следовательно остается выяснить реализацию в текущей библиотеке.

exchg
> С чем? "заднечисловым хвостом" - не совсем понял.
С введеным требованием безопасности потоков. До 2011 (или какого там) года, если я правильно понял, потоки не были тред-безопасными, т.е такого требования быть не могло.

> Думаю это должно гарантироваться поддержкой посиксом. Т.к. плюсовые стримы
> прикручены к файлстримам сишки.
Там до хрена чего может быть между. Ну, теоретически. И есть наверняка.

> Я запутался. Что есть - thread-safety потоков ?
Возможность писать "одновременно" из двух разных задач в один поток.
А не читать/писать один объект из двух разных потоков, каждый в своей задаче.

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

beejah
> С введеным требованием безопасности потоков. До 2011 (или какого там) года,
> если я правильно понял, потоки не были тред-безопасными, т.е такого требования
> быть не могло.
А ну да, (только в 2008). Ну решили их обезопасить, теперь можно не делать свои обертки, а использовать из коробки. При желании можно мигрировать, при отсутствии можно нет. )) Наверно это нормально в плюсовой вселенной.

> Нет, речь о том, что текущая реализация - сама по себе не гарантия. Она может
> поменяться, и если гарантии не предоставляются - поменяется обязвтельно.
Ага, но яб добавил, что она может поменяться даже несмотря на гарантии. )  Завтра просто скажут мы вот тут пересмотрели наши подходы.

exchg
> Ага, но яб добавил, что она может поменяться даже несмотря на гарантии.
Согласен, я чушь спорол.

beejah
> файловые потоки в крестах thread-safe на запись?
  Да, вполне

beejah
> Нет. Я бы сказал, наоборот, маловато.
  А для чего нужен такой сложный лог?

nerengd
> А для чего нужен такой сложный лог?
Сложный? Да там нет ничего еще. Нужен для фильтрации информации, ее источников и приемников по тем или иным критериям.

exchg
nerengd
> Да, вполне
драфт конца ноября 2017

otherwise specified - это стандартные потоки.
Ребята, где я что-то неправильно понимаю? Откуда ваши "вполне" и "десять лет как" вылезли?
Мы про какие-то разные языки говорим?

Вот по винде:

9К720
> Ты бы глянул по ссылкам, прежде чем ахинею то нести.
ну вот я глянул.
> кстати, даже специально для шарперов портировали
> https://logging.apache.org/log4net/
два мегабайта исходников не считая доков. Секция "конфигурирование" в мануале которую устанешь скроллить мышкой. Для сборки предлагаются солюшены для студий десятилетней давности и марсианский NAnt.
Ну да, конечно это то что надо для платформера, не писать же свой велосипед из двухсот строк. Это сэкономит кучу времени, ведь теперь чтобы поменять подробность лога не надо будет менять константу в исходнике, можно будет поменять константу в хмл-файле. А если потребуется писать в лог андроида, то вместо того чтобы исправить десять строк в своем файле логгера можно будет почитать мануал и исправить пять строк в файле конфигурации. Хотя нет, что-то я среди аппендеров не вижу работающего с андроид апи, так что те же десять строк, только сначала еще научиться писать аппендеры.

beejah
> Ребята, где я что-то неправильно понимаю?
не факт.
Про эти потоки речь?