Wdrażam no-op std :: ostream

Question

Czekam na tworzenie klasy rejestrowania, która ma członków, takich jak informacje, błąd itp., Które można konfigurowalne wyjście do konsoli, pliku lub donikąd.

Dla zwiększenia efektywności chciałbym uniknąć narzutów związanych z formatowaniem wiadomości, które będą wyrzucane (tj. Wiadomości informacyjnych, gdy nie są uruchomione w trybie szczegółowym). Jeśli zaimplementuję niestandardowy std :: streambuf, który wyprowadza donikąd, wyobrażam sobie, że warstwa std :: ostream nadal będzie formatować. Czy ktoś może zaproponować sposób na naprawdę "zerowy" std :: ostream, który unika wykonywania jakiejkolwiek pracy na parametrach przekazywanych do niego z <<?

Dzięki.

Answer 1

Aby zapobiec wykonywaniu formatowania przez wywołania operator<<(), powinieneś znać typ strumienia podczas kompilacji. Można to zrobić za pomocą makr lub szablonów.

Mój roztwór szablonowy następuje.

class NullStream { 
public: 
    void setFile() { /* no-op */ } 
    template<typename TPrintable> 
    NullStream& operator<<(TPrintable const&) 
    { /* no-op */ } 
} 

template<class TErrorStream> // add TInfoStream etc 
class Logger { 
public: 
    TErrorStream& errorStream() { 
     return m_errorStream; 
    } 

private: 
    TErrorStream m_errorStream; 
}; 

//usage 
int main() { 
    Logger<std::ofstream> normal_logger; // does real output 
    normal_logger.errorStream().open("out.txt"); 
    normal_logger.errorStream() << "My age is " << 19; 

    Logger<NullStream> null_logger; // does zero output with zero overhead 
    null_logger.errorStream().open("out.txt"); // no-op 
    null_logger.errorStream() << "My age is " << 19; // no-op 
} 

Ponieważ musisz to zrobić podczas kompilacji, jest to oczywiście mało elastyczne.

Na przykład nie można wybrać poziomu rejestrowania w środowisku wykonawczym z pliku konfiguracyjnego.

Answer 2

Prawdopodobnie potrzebujesz czegoś więcej niż tylko formatowanie tekstu i filtrowanie wiadomości. A co z wielowątkowością?

Zaimplementowałem synchronizację filtrowania i wielowątkowość jako odpowiedzialność oddzielnej klasy.

Jednak rejestrowanie to nie jest taki prosty problem, a zamiast tworzyć nowe, starałbym się korzystać z istniejących rozwiązań rejestrowania.

Answer 3

Błyskawiczny google wymyślił ten przykład, który może być przydatny. Nie oferuję żadnych gwarancji, poza tym, że kompiluje się i uruchamia :-)

Answer 4

Dlaczego nie skorzystać z istniejących rozwiązań logowania używanych przez miliony użytkowników? log4j, log4net, log4cxx .., aby wymienić tylko kilka ..

Answer 5

wszystkim, dzięki za udostępnienie kodu, po prostu zrobić test, a następnie metoda Neila będzie jeszcze zrobić formatowania łańcucha znaków, na przykład:

#include <streambuf> 
#include <ostream> 
#include <iostream> 
using namespace std; 


template <class cT, class traits = std::char_traits<cT> > 
class basic_nullbuf: public std::basic_streambuf<cT, traits> { 
    typename traits::int_type overflow(typename traits::int_type c) 
    { 
     return traits::not_eof(c); // indicate success 
    } 
}; 

template <class cT, class traits = std::char_traits<cT> > 
class basic_onullstream: public std::basic_ostream<cT, traits> { 
    public: 
     basic_onullstream(): 
     std::basic_ios<cT, traits>(&m_sbuf), 
     std::basic_ostream<cT, traits>(&m_sbuf) 
     { 
      init(&m_sbuf); 
     } 

    private: 
     basic_nullbuf<cT, traits> m_sbuf; 
}; 

typedef basic_onullstream<char> onullstream; 
typedef basic_onullstream<wchar_t> wonullstream; 

class MyClass 
{ 
    int a; 
    friend ostream& operator<< (ostream&, MyClass const&); 
}; 

ostream& operator<<(ostream& out,MyClass const& b) 
{ 
    std::cout<<"call format function!!"; 
    out << b.a; 
    return out; 
} 

int main() { 
    onullstream os; 
    MyClass obj; 
    os<<obj; 
} 

Uruchomienie tego programu, można zauważyć, że "ostream & operator < < (ostream & się, MyClass const & b)" zostanie wywołana. Zatem formatowanie na obiekcie będzie nadal wywoływane. Wciąż nie możemy uniknąć nadmiarowego formatowania wiadomości.