December 2008 - Boost - lists.boost.org

[logging] Interest check on logging library.
by Jason Wagner 27 Dec '08

27 Dec '08

Hello all, I know there are two proposed logging libraries out there for Boost, already, but I had a different itch to scratch on a project. I think I saw that Andrey Semashev was going to submit his far more mature version soon, but I thought I'd throw my technique out there for an interest check and hopefully commentary. This is very much a prototype-- there's a lot of work yet to be done but the basic outline and functionality is implemented. Getting the code ---------------- http://www.nialscorva.net/boost_logging-0_1.tar.bz2 File is also attached, since it's small. Just unzip, put on path, and include. It's header only for now. Tested against 1.36 and 1.37 on gcc 4+ and msvc 8+. Elevator Conversation Rundown ----------------------------- My logging library involves no macros, it relies on using template metaprogramming and the compiler optimizer to mostly eliminate logging statements that cannot be logged. It also supports conditional output within the context of a single statement, complex filter evaluation and chaining, lazy function evaluation, and support for standard ostream operators. All features are easily extensible without macros or hidden code. Requirements ------------ I had several wants/needs that weren't elegantly handled by existing log libraries. - Tagging mentality for enabling logs with in-line conditions. I'm writing a client/server program. I want to be able to write: logger << severity::error() << "An error has occurred!" << severity::debug() << " packet= " << hex_dump(packet); When debug is disabled, the packet contents are not logged. Tags should be easy to add and define. There is common code between the client and server and I want slightly different output on each: // action, ip, and context are local vars that are defined for operator<<(ostream&,T&) logger << "Action failed to occur: " << action << target::server() << " from ip address " << ip << " with context= " << context; When the code is compiled for the server, the ip and context are logged. When compiled on the client, it is removed from completely. The code is compiled every time, so there's no risk of stale code hidden by macros. The optimizer removes the strings and dead code later. - Sink selection based upon filter evaluation. For example, sending severity::warning and above to a console and everything to a file: filter_split_action f(severity() >= severity::warning()); f.on_success(my_console_log); f.always(my_log_file); logger.set_action(f); - Chaining filter evaluation. The client sends certain log events back to the server, but also to local sources: filter_split_action f(severity() >= severity::warning()); f.on_success(my_console_log); f.always(my_log_file); logger.set_action(f); // build the server reporter filter_split_action to_server(target() == target::client() && send_to_server() == send_to_server::yes()); to_server.on_success(my_server_sink); // chain the server reporter off of the original filter f.always(to_server); Chaining to on_success and on_failure works as well. - Lazy evaluation of expensive functions. Only invoke them if they are going to be logged. The library accepts any boost::function that returns an ostream compatible type and takes no arguments. The "lazy()" convenience functions create a boost::bind wrapped in a boost::function for this purpose. int nth_digit_of_pi(int place); logger << lazy(nth_digit_of_pi,500000); - Reconfigurable on the fly (excluding compile-time conditions). Not yet implemented but the groundwork is laid and will be implemented in the core via facades that act as handles. - Hierarchical variable sets. When looking up a variable for filtering or for formatting, climb a chain of parents from record->logger->channel->thread->global. Example ------- namespace bl=boost::logging; // defined in logger.hpp typedef boost::mpl::vector< bl::condition::greater_equal<bl::severity::warning>, bl::condition::in<bl::build_type::release> > optimized_conditions; typedef boost::mpl::vector<bl::build_type::release,bl::severity::info> optimized_tags; // end defined in logger.hpp bl::logger<optimized_conditions, optimized_tags> log(sink); log << "severity::info-- not printed\n" << bl::severity::debug() << "debug is not printed\n" << bl::severity::warning() << "warning is printed\n" << bl::severity::error() << "and so is error\n" << bl::build_type::debug() << "but build_type::debug fails the condition\n" << bl::end_record(); Other samples can be found in lib/logging/examples. Other ----- There are still a lot of things in the TODO list. The best look at usage is found in the lib/logging/examples directory. I've been using speed.cpp to take simple timing information to watch performance. Mostly they are one-off snippets I've been using while prototyping this. There's an excel spreadsheet with numbers in it, but generally it takes 3+-0.5 times as long to write to a logger as to cout, depending upon sinks, conditions, etc. A lot of this time is spent in variable_set, which is an easy target for optimization. Whole messages rejected by filters take about 1/2 as long as writing to cout, while rejection at compile time take 1% to 2% of the time to write to cout. Currently, there is no multithreading support. The places that need guarding are localized and will be implemented as facades on variable_set, filter_action, and sink. Core will be a registry and factory for populating variable_set parents and filter_actions on loggers, as well as properly putting multithreading and reconfiguration facades on things that need them. I'm not planning on implementing i19n, scoped variables, functor variables, or some of the other requirements in the boost logging list unless there's interest. There's more, I'm sure, but I can't write the whole project's documentation in an introduction email. -- Jason Wagner jason(a)nialscorva.net

2 1

which implementation for move semantics?
by k-oli＠gmx.de 27 Dec '08

27 Dec '08

Hello, I saw that some boost libraries (for instance boost::thread) implement their own move semantics. I'd like to know which would be the prefered implementation I should choose.

1 0

[Test] reopened trac issues floating comaparison
by Juergen Hunold 26 Dec '08

26 Dec '08

Hi Gennadyi ! Nice to see you back ! Could you please take a look at issue #2390 again ? https://svn.boost.org/trac/boost/ticket/2390 There are currently two patches missing: - attached patch to make operator() of check_is_small and check_is_close "const". This is needed because Boost.Test now stores "const&" due those two objects due to the previous applied ODR-patch. - gcc-4.3 warnings "../boost/test/floating_point_comparison.hpp:88: warning: suggest parentheses around && within ||" which are rather annyoing. Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister Straße 15 * juergen.hunold(a)ivembh.de ! www.ivembh.de * * Geschäftsführer: ! Sitz des Unternehmens: Hannover * Prof. Dr.-Ing. Thomas Siefer ! Amtsgericht Hannover, HRB 56965 * PD Dr.-Ing. Alfons Radtke !

3 6

[test] Runtime parameter handling subsystem updated
by Gennadiy Rozental 26 Dec '08

26 Dec '08

Hi, I've checked in an update to the runtime parameters handling subsystem. It's not completely up to my liking yet, but should fare better than old one. From usage prospective you will see major differences in features supported by command line argument parser (don't worry - everything is backward compatible). New command line arguments parser allows: a) double identification for parameters (is not used for all parameters, but most). For example: "--log_level=<value>" and "-l <value>" for log level b) name guessing for long names. For example "--log_l=<value>" and "--log_le=<value>" will work fine Note though that --log_=<value> will produce an error message complaining about ambiguity, since there are two parameters - --log_level and --log_format that may fit. c) boolean parameters does not require the value. For example "--catch_system_errors" will work fine Parameter --random can be used without any value as well. d) New parameter --help,-? is supported that produces help message with usage information. Note that usage information is being printed also in case there was error parsing command line. Any comments and suggestions appreciated, Gennadiy

2 2

[python] bogus backward-compatibility code
by Ulrich Eckhardt 26 Dec '08

26 Dec '08

Hi! I'm looking at versions up to at least 1.37, and in python/detail/config.hpp, I find found some code that is currently in my way, because I'm not sure what it should do. I'm talking about the following few lines: // backwards compatibility: #ifdef BOOST_PYTHON_STATIC_LIB # define BOOST_PYTHON_STATIC_LINK # elif !defined(BOOST_PYTHON_DYNAMIC_LIB) # define BOOST_PYTHON_DYNAMIC_LIB #endif Notes here: 1. The first macro, BOOST_PYTHON_STATIC_LIB, is undocumented and probably (I'm guessing) an old spelling of BOOST_PYTHON_STATIC_LINK. It is used in some Jamfile.v2s, probably to link with or build a static library. On first view, it's odd that the build system depends on backward code. 2. On second look, you see that BOOST_PYTHON_STATIC_LINK is completely unused and similarly undocumented, in any case defining it is not necessary for Boost itself. 3. The macro BOOST_PYTHON_DYNAMIC_LIB is also of questionable use. It is used in that file to setup auto linking and symbol visibility for a dynamic library, but otherwise it is unused. Actually, compare that to config/user.hpp, which says that you should use either of BOOST_{PYTHON,ALL}_DYN_LINK to get dynamic linking. 4. Speaking about config/user.hpp, there is no documented way to specify static linking. I think some libraries use e.g. the _DLL macro on MS' compiler to default to dynamic linking and otherwise assume static linking. Boost.Python instead assumes dynamic linking when nothing is specified and the only way to get static linking is by defining an otherwise undocumented macro. Suggested resolution: 1. Remove above quoted lines. They have been there since 2002 (SVN revisions 12083, 12146, 13462), and any code relying on undocumented backward compat code for such a long time is broken anyway (yes, sadly, that includes Boost itself sadly). 2. Replace checks for BOOST_PYTHON_DYNAMIC_LIB with checks for the macros documented in config/user.hpp. 3. Document BOOST_{ALL,foo}_STATIC_LINK as guaranteed way to get statically linked libraries in config/user.hpp. 4. Maybe introduce a header config/guess_linkage.hpp which will define BOOST_ALL_STATIC_LINK or BOOST_ALL_DYNAMIC_LINK based on heuristics like e.g. _DLL under win32, unless either of these two is already defined. I think that such heuristics already are in place in some libraries, but they should actually be central. I'd start off with 1-3 and then see what breaks. Step 4 will require that checks are changed so that they look like this: if (ALL_DYN_LINK|FOO_DYN_LINK) && !FOO_STATIC_LINK // use dynamic linking else // use static linking endif instead of just like this: if (ALL_DYN_LINK|FOO_DYN_LINK) // use dynamic linking else // use static linking endif so that the detected default does not override an explicitly set linkage. Comments anyone? Uli

1 0

Re: [boost] [Boost-users] [review][constrained_value] Review of Constrained Value Library begins today
by Mika Heiskanen 25 Dec '08

25 Dec '08

Mathias Gaunard wrote: > Mika Heiskanen wrote: > >> If the value must be checked beforehand, why bother using a constrained >> type at all? > > Because it performs checking in debug mode to make sure the invariant is > indeed true. I do not believe boost should accept a library which would only work in debug mode. I believe boost is mostly about runtime libraries, not about debugging aids. --> Mika Heiskanen

7 27

[shared_ptr] A smarter smart pointer proposal for dynamic libraries
by J.D. Herron 25 Dec '08

25 Dec '08

I have a suggestion for the shared pointer implementation to overcome a severe limitation it has currently regarding dynamically unloaded libraries. I posted a little while back regarding this problem which is illustrated with the following example from a Microsoft Windows environment. I have a simple factory interface like so: class Factory { public: virtual shared_ptr<int> GetIntSharedPtr() = 0; virtual int * GetIntRawPtr() = 0; }; I implement a factory DLL to provide one of these factories that has an exported function GetFactory() like so: /// implementation of the Factory interface class TestFactory : public Factory { public: virtual shared_ptr<int> GetIntSharedPtr() { return shared_ptr<int>( new int(5) ); } virtual int * GetIntRawPtr() { return new int(0); } }; /// Library instance of the factory implementation TestFactory g_Factory; /// Exported function to return the factory for this library _declspec(dllexport) extern "C" Factory & GetFactory() { return g_Factory; } This is compiled into a library named "TestFactory.dll". Now I create a simple command line application that does the following: /// Typedefinition for for the GetFactory exported function typedef Factory & (_cdecl * GetFactory)(); int main() { // dynamically load the TestFactory library HMODULE hFactoryDll = ::LoadLibrary( "TestFactory.dll" ); // get the GetFactory() interface from the loaded library GetFactory pfnGetFactory = ::GetProcAddress( hFactoryDll, "GetFactory" ); // Acquire the factory object Factory & factory = pfnGetFactory(); // Call the factory interfaces to get dynamically allocated integers int * pRawInt = factory.GetIntRawPtr(); shared_ptr<int> spInt = factory.GetIntSharedPtr(); // everything is fine so far, now unload the factory library ::FreeLibrary( hFactoryDll ); // deallocating the raw pointer recieved from the factory works just fine delete pRawInt; // THIS WORKS! // However due to the reasons outlined below, releasing the shared_ptr causes // an access violation spInt.reset() // THIS CRASHES! } The basic problem is that the shared_ptr implementation uses virtual functions in the sp_counted_base class that gets generated in the factory dll since it is a template instantiation and once that factory dll is unloaded the virtual function tables for all shared_ptrs it generated are now garbage. In my opinion the virtual function implementation in the template is an unnecessary design flaw that creates this limitation. I also think the reference counter just simply does too much. I would propose an alternative design that eliminated the use of virtual functions in template generated base classes and let the outer smart pointer class handle the deallocation chores and make the reference counter just a simple reference counter. This could eliminate the limitation illustrated in this simple and very common use case. Ignoring a bunch of stuff right now like custom deallocators, weak references, some basic members like assignment, etc., here is a simple reference counted smart pointer that is able to handle this library unloading example without a problem just as you could do with a raw pointer: /// reference counter THAT ONLY REFERENCE COUNTS AND HAS NO VTABLE class SimpleRefCounter { public: /// Constructor initializes reference count to 0 SimpleRefCounter( long count = 0 ) : m_Count(count) {} /// Increments the reference count and returns it long Increment() { return ::InterlockedIncrement( &m_Count ); } /// Decrements the reference count and returns it long Decrement() { return ::InterlockedDecrement( &m_Count ); } /// Returns the current reference count long Count() const { return m_Count; } private: long m_Count; }; /// Simple smart pointer template that handles the deallocation chores and therefor /// can be used safely across dynamic dll boundaries template < typename _type > class SmarterPtr { public: /// Default constructor creates a null pointer SmarterPtr() : m_pValue( NULL ), m_pRefCounter( NULL ) {} /// Constructor taking an allocated value to manage SmarterPtr( _type * p_pValue ) : m_pValue( p_pValue ) { m_pRefCounter = new SimpleRefCounter( 1 ); } /// Copy constructor SmarterPtr( const SmarterPtr & p_Original ) : m_pValue( p_Original.m_pValue ), m_pRefCounter( p_Original.m_pRefCounter ) { m_pRefCounter->Increment(); } /// Destructor releases ~SmarterPtr() { reset(); } /// Resets the managed pointer to the passed in one releasing the /// currently managed pointer and deallocating if necessary void reset( _type * pNewValue = NULL ) { if ( pNewValue != m_pValue ) { if ( m_pValue && 0 == m_pRefCounter->Decrement() ) { // need to deallocate current value delete m_pValue; delete m_pRefCounter; // ignore weak ref for now m_pValue = NULL; m_pRefCounter = NULL; } if ( pNewValue ) { m_pRefCounter = new SimpleRefCounter( 1 ); m_pValue = pNewValue; } } } private: _type * m_pValue; SimpleRefCounter * m_pRefCounter; }; Again the key is no VTABLE and deallocation handled by the exposed templates. Why shouldn't shared_ptr move to an equivalent model so it can be used across dynamic dll boundaries safely? J.D.

5 8

Is program_options unmaintained?
by Peter Simons 24 Dec '08

24 Dec '08

Hi, a couple of weeks ago, I reported a bug in the program_options library to the author, Vladimir Prus, but received no response. Then I tried reporting the problem on the boost-users mailing list, but didn't receive a response either. Since then, I've seen at least one other poster on the boost-users list wondering about this library, but did not receive a no response either. Does anyone still maintain the program_options library? More generally speaking, what is the procedure if it turns out that a Boost library *is* unmaintained? Take care, Peter

2 4

[test] Floating point comparison update
by Gennadiy Rozental 24 Dec '08

24 Dec '08

Hi, I've checked in 2 changes to the floating point comparison tools. 1. BOOST_CHECK_CLOSE now can compare values of different types: BOOST_CHECK_CLOSE( 2, 2.1, 6 ); // compare and and double BOOST_CHECK_CLOSE( 2.1, 2, 6 ); // compare double and int BOOST_CHECK_CLOSE( 2.1, 2.f, 6 ); // compare double and float 2. Floating point comparison tools now report difference if any: BOOST_CHECK_CLOSE( 2, 2.1, 3 ) will lead to: difference{4.7619%} between 2{2} and 2.1{2.1} exceeds 3% BOOST_CHECK_CLOSE_FRACTION( 2, 2.1, 0.04 ) will lead to: difference{0.047619} between 2{2} and 2.1{2.1} exceeds 0.04 Any comments appreciated, Gennadiy

3 2

Re: [boost] [uuid] Interface
by Vladimir Batov 24 Dec '08

24 Dec '08

It seems I did it again. :--( Just noticed that I misread the following excerpt of Scott's email. Apologies and corrections further below. >> Take, for example, a map<string, uuid>. No default constructor means >> that you can't use operator[], First, my preference is to *have* the default constructor -- we disagree on its behavior as I'd like the default constructor to *be part* of the constructors family (constructing a valid object) and you insist on the default constructor being an exception. The latter is not how the language interprets the default constructor. Therefore, me not happy. IMHO that deviation of the meaning from the letter of the language is unacceptible. Second, even if I cannot use operator[], so what? std::fstream has no default constructor. std::list has no operator[], std::vector has no push_front(). That did not stop anyone from using those classes. What the lack of those "features" achieved instead is that it most likely saved a few people from shooting themselves in a foot. Best, V.

3 4