Пытаюсь написать класс лога, данные должны выводятся в объект поддерживающий operator <<
т.е. во время работы можно менять(добавлять) объект вывода.
как должен выглядеть прототип функции принимающей в качестве параметра указатель на объект поддерживающий << (например ostream, ofstream или что-то свое), без надобности все объекты наследовать от какого-то базового класса?


или все же придется шаблон писать?

Это сообщение отредактировал(а) asmdzen - 18.7.2011, 11:23

asmdzen, или шаблон, или наследование.
На твоем бы месте я воспользовался std::ostream и передавал бы ему только разные объекты наследников streambuf. В итоге, уже имеется поддержка всех стандартных типов, а писать нужно минимум кода, необходимый для поддержки именно твоего устройства вывода лога.

идея отличная, только жадность душит, я передаю конечному объекту только string'и созданные boost::format'ом (на форуме нашел)(просто постоянные log() << "n =" << n << ";" задолбали, форматированная строка по мне лучше). думаю может лучше все таки держать только указатели на функции принимающие в качестве параметра string? но как тогда быть с методами классов?

где держать ?

mem_fun
?

Добавлено @ 17:47

  

Это сообщение отредактировал(а) borisbn - 18.7.2011, 17:48

Во-первых, я предложил бы использовать общепринятый порядок аргументов для функций, реализующих действие оператора <<. То есть на первое место я поставил бы объект, в который записываются данные, а на второе место что записывается в данные. 
Во-вторых, вместо указателя на объект также по аналогии с объявлением функций, реализующих оператор <<, я бы передавал ссылку на объект и ее же возвращал из функции, чтобы можно было организовывать цепочку вызовов функции, например, в виде

Str2Ob( Str2Ob( ptr, str1 ),  str2 ):

А еще лучше эту функцию оформить в виде оператора-=функции <<.

Шаблон, но реализации такого класса лога это не поможет (IMHO). Все равно что то общее должно быть (или у логеров, или у источников логов). В вашей оригинальной постановке задачи сделать такой логер невозможно (опять же IMHO)

в объекте лога, т.е. держать специально для этого контейнер. за mem_fun спасибо.
Сыроежка, спасибо, буду иметь ввиду.

в общем получается не очень красиво, вызов функции log с форматирующей строкой возвращает ссылку на временный объект построенный на основе boost::format, в котором operator % заменил на operator <<,
при уничтожении этого объекта, его содержимое пишется в лог (передается как параметр всем функциям из контейнера по очереди). Не нравится то что постоянно создаются временные объекты.

применяю так:


если у кого завалялся класс лога буду предельно признателен если поделитесь, исключительно в целях ознакомления. (pantheios и ему подобные просьба не предлагать, хочу понять как именно это следует писать)

Это сообщение отредактировал(а) asmdzen - 18.7.2011, 21:22

IMHO вполне даже красиво... Не безопасно, но читабельно.

borisbn, не очень красиво в смысле 

Ну и что ? У тебя в конструкторе открытие БД или коннект с сервером ??? Если же открытие файла лога для дозаписи - так это правильно, надёжно. Потому, что если создать файл в начале, а закрыть в конце, то этого конца может и не быть, если программа рухнет.

такое я себе позволить не могу )
создаются временные объекты для сборки строки, при их удалении строка передается классу лога который и пишет это в файл.
программа критичная к ресурсам, если бы файл постоянно открывался/закрывался - это бы сильно все усложнило.

Что ж это за лог, который в случае падения программы может не записать данные ? Как ты потом разберёшься из-за чего прога упала-то ?

Ну, смотри сам... Тебе виднее. Я б поискал потерю производительности в других местах, а лог бы сделал надёжным.

Это какой-то перерасход ресурсов. Проще воспользоваться: std::clog << std::flush;

я что-то не понимаю, что с того что программа рухнет? зачем мне закрывать файл вообще, разве это так важно, я просто записываю данные в файл, если прога рухнет - система сама закроет файл, перед этим делая flush, разве не так?

не совсем так. есть разный уровень буферизации. При крахе программы система сохраняет только то, что было в ее буферах. А то что стандартная библиотека С или С++ использует свои, система не в курсе. Поэтому, после каждого полностью завершенного сообщения отправленного в файл нужно делать flush для него.