Hello Tommy and all! Thank you for your feedback.
> Tommi Mäkitalo <[email protected]> hat am 23. August 2013 um 21:48 geschrieben: [...] > I don't agree at all. What do you expect people to think about tntnet if > you say: hey, we have a logging library but if you do something good, > don't use it. First, the user doesn't knows, what option they have and what the advantages and disadvantages of the option is. The idea of best practice is, to give him an over view. It is not a "must" it is a "can". > Cxxtools logging follows a philosophy. Logging must be lightweight and > quick and easy to use. The bundle with logging and serialization is - in my opinion - to hard. This makes the work complicate, not easy and not quick. To use cxxtools logging you must learn more than with POCO or boost. You must learn using loggin class, serialization and a markup language. You can't use logging class alone. > I looked at the slides of poco logging. One of the most important > features in cxxtools logging is easy formatting of messages using > std::ostream. Poco offers a solution but it is ugly. Look at that: > > Poco::Logger& logger = Logger::get("TestLogger"); > Poco::LogStream lstr(logger); > lstr << "The value of a is " << a << std::endl; > > Compared to cxxtools: > > log_debug("The value of a is " << a); > > At the top of the file you will find: > > log_define("TestLogger") > > There are several problems with the poco solution. The first thing is, > that you need 3 lines of code just to log something. I don't like it. But I like it. I think, it is very clear what he does: Poco::AutoPtr<Poco::ConsoleChannel> pCons(new Poco::ConsoleChannel); Poco::Logger::root().setChannel(pCons); Poco::Logger& logger = Poco::Logger::get("TestLogger"); logger.setLevel(Poco::Message::PRIO_ERROR); logger.information("This is an informational message"); logger.warning("This is a warning message"); logger.error( "...Oh, shit happens!"); And I can put it in a function like this: Poco::Logger& logger getMyConsoleLogger( const std::string componentName ) { Poco::AutoPtr<Poco::ConsoleChannel> pCons(new Poco::ConsoleChannel); Poco::Logger::root().setChannel(pCons); Poco::Logger& logger = Poco::Logger::get("TestLogger"); logger.setLevel( progArg.getLevel() ); return logger; } So it looks like this: Poco::Logger& logger = getMyConsoleLogger( "ExampleComponent" ); logger.information("This is an informational message too"); That are also two lines. > But what is worse is, that the formatting takes place always. If the > logging for "TestLogger" is disabled, the operator<< will format the > value of "a" into the stream and throw the result away. Formatting of > log messages takes time. And this is absolutely unacceptable to take the > time just to throw the message away. > > In cxxtools log_debug is a macro, which first checks, if logging is > enabled. If not, the message is not formatted. It is far faster. Your are sure? The documentation says (http://www.appinf.com/docs/poco/Poco.Logger.html): There are also convenience macros available that wrap the actual logging statement into a check whether the Logger's log level is sufficient to actually log the message. This allows to increase the application performance if many complex log statements are used. The macros also add the source file path and line number into the log message so that it is available to formatters. Variants of these macros that allow message formatting with Poco::format() are also available. Up to four arguments are supported. > Another point is, that cxxtools logging is used by tntnet, tntdb and of > course cxxtools itself already. If you for example encounter problems > accessing the database, enable logging for the category "tntdb" and you > get plenty of information what is going wrong here. Yes, that is a painful gap. > Configuring cxxtools logging may be improved. We already added the > possibility to use the serialization framework to do it, so that you can > configure logging using xml, properties or json. That is really great, > that we can integrate the configuration into our main configuration file > of our application. > > Runtime configuration is not really supported. I have never needed it, > since I enable logging only when I have some problems with the > application. Then it is really no problem to restart the application. > > You mentioned, that you want to have a command line argument -v to > enable logging. But a logging library has not only "yes" or "no" but you > can configure log levels per category. And this is a great feature, we > use every day in our projects. Just enabling is not really good enough. No. Not really. For example the ssh man page: -v Verbose mode. Causes ssh to print debugging messages about its progress. This is helpful in debugging connection, authentication, and configuration problems. Multiple -v options increase the verbosity. The maximum is 3. So it is conceivable and possible to do it like this: myProg -vvv=tntdb,componentA,componentB It means, full debug info from component A, B und tntndb. Best regards, Olaf ------------------------------------------------------------------------------ Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk _______________________________________________ Tntnet-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tntnet-general
