Войти
ФлеймФорумПрограммирование

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

Страницы: 1 2 3 4 5 Следующая »
#30
14:46, 13 фев. 2019

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


#31
14:58, 13 фев. 2019

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

#32
15:06, 13 фев. 2019

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

Stronger guarantees are sometimes provided—for example, the standard iostream objects, as described below, and types specifically intended for multithreading, like those in <atomic>

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

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

#33
15:14, 13 фев. 2019

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

#34
(Правка: 15:32) 15:22, 13 фев. 2019

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

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

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

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

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

#35
(Правка: 15:32) 15:26, 13 фев. 2019

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

#36
16:30, 13 фев. 2019

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

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

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

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

#37
17:42, 13 фев. 2019

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

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

#38
17:54, 13 фев. 2019

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

#39
18:00, 13 фев. 2019

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

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

#40
(Правка: 18:12) 18:10, 13 фев. 2019

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

#41
18:26, 13 фев. 2019

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

30.2.3  Thread safety[iostreams.threadsafety]
1Concurrent access to a stream object (30.8, 30.9), stream buffer object (30.6), or C Library stream (30.12) bymultiple threads may result in a data race (6.8.2) unless otherwise specified (30.4). [Note:Data races resultin undefined behavior (6.8.2).— end note]

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

#42
18:39, 13 фев. 2019

Вот по винде:

If an object is being written to by one thread, then all reads and writes to that object on the same or other threads must be protected. For example, given an object A, if thread 1 is writing to A, then thread 2 must be prevented from reading from or writing to A.

#43
18:41, 13 фев. 2019

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

#44
19:01, 13 фев. 2019

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

Concurrent access to a synchronized ([ios.members.static]) standard iostream object's formatted and unformatted input and output functions or a standard C stream by multiple threads shall not result in a data race.
[ Note: Users must still synchronize concurrent use of these objects and streams by multiple threads if they wish to avoid interleaved characters.
— end note
 ]
See also: ISO C 7.21.2
Страницы: 1 2 3 4 5 Следующая »
ФлеймФорумПрограммирование