- Boost - lists.boost.org

[New Feature Suggestion] Dynamic exception handlers registration
by Alex Tkachenko 17 May '09

17 May '09

Hello there. A while back I wrote usefull tool for organizing exception handling. The general idea is borrowed from boost::execution_monitor (http://www.boost.org/doc/libs/1_38_0/libs/test/doc/html/execution-monitor.h…) . Similarly, I call this unit "Exception Monitor". It allows to dynamically register exception converters and convert exception objects from any source types to arbitrary target type. For instance, if you write some integration code which uses several external modules, and each of these modules could generate their own tree of exceptions, you would face serious issue trying to implement error diagnostic. One approach is to handle only base exception for each module and to catch them in function main(). Let's assume that all exceptions are inherited from std::exception, so we need to catch single base (std::exception). This approach is convenient but not precise. Even if we want just to output error message using std::exception::what() we have only some general low level error description, moreover this description could be completely wrong. It doesn't reflect actual cause of the error because at the place where the exception is originally generated it couldn't know about context of execution. On the contrary, we can catch low-level exceptions in the place where execution context is more obvious and convert it to some "application" exception which contains more information about current situation. This is the solution for detailed error diagnostic, but it is too tedious. Also such code is unscalable, error prone and hard to support. Look at the following example: /////////////////////////////////////////////////////////// /////////////////////////////////////////////////////////// class app_error: public virtual std::exception { ... }; void foo() { try { ...local state... unit1::foo(...); unit2::foo(...); } catch(const unit1::exception1& ex) { //...convert caught exception to app_error using local state throw app_error(...); } catch(const unit1::exception2& ex) { //...convert caught exception to app_error using local state throw app_error(...); } catch(const unit2::exception& ex) { //...convert caught exception to app_error using local state throw app_error(...); } } int main() { try { foo(); } catch(const app_error& ex) { cout << "Error: " << ex.what() << endl; } catch(const std::exception& ex) { cout << "Unknown error: " << ex.what() << endl; } catch(...) { cout << "Unknown error" << endl; } } The main drawback of this source code is that exception handling is mixed with 'main' code. It would be better if we could write something like this: /////////////////////////////////////////////////////////// /////////////////////////////////////////////////////////// class app_error: public virtual std::exception { ... }; typedef exc::catcher<app_error> app_catcher; //...exception catcher type typedef std::list<app_catcher> app_catchers; //...container for catchers struct convert_unit1_ex1 { const app_error operator()(const unit1::exception1&); }; struct convert_unit1_ex2 { const app_error operator()(const unit1::exception2&); }; struct convert_unit2_ex { const app_error operator()(const unit2::exception&); }; app_catchers excon; void foo() { ...local state... //...register catchers for possible exceptions excon.push_front( app_catcher::create<unit1::exception1>( convert_unit1_ex1(...local state...))); excon.push_front( app_catcher::create<unit1::exception2>( convert_unit1_ex2(...local state...))); excon.push_front( app_catcher::create<unit2::exception>( convert_unit2_ex(...local state...))); //... unit1::foo(); unit2::foo(); //...good idea is to use RAII to register catchers to avoid this //...manual deregistration: excon.pop_front(); excon.pop_front(); excon.pop_front(); } int main() { try { guard(excon, foo()); } catch(const app_error& ex) { cout << "Error: " << ex.what() << endl; } catch(const std::exception& ex) { cout << "Unknown error: " << ex.what() << endl; } catch(...) { cout << "Unknown error" << endl; } } Pluses of this technique: 1) it encourages developer to implement exception handlers code separatly from 'main' code; 2) it provides framework for detailed exception handling; 3) it offers flexible means for structural arrangement of exception handlers' source code. Very interesting feature of Exception Monitor is ability to sort catchers in "proper" order regarding their inheritance. So catcher for std::runtime_error should be earlier then std::exception. This is what functions exc::insert and exc::replace do. Library source code (it's tested it on gcc 4.3.1): #ifndef EXCEPTION_MONITOR_HEADER_GUARD #define EXCEPTION_MONITOR_HEADER_GUARD /* * Exception Monitor: * allowes dynamic exception handlers registration * Author: Alex Tkachenko * 2009.02.10 */ #include <cassert> #include <boost/function.hpp> #include <boost/static_assert.hpp> #include <boost/type_traits/is_base_of.hpp> #include <boost/shared_ptr.hpp> #include <typeinfo> namespace exc { namespace details { class failed_to_catch_exception {}; //... class try_catcher_base { public: virtual ~try_catcher_base() {} virtual void convert() const = 0; virtual void try_throw_self_exception() const = 0; virtual bool try_catch_self_exception( const try_catcher_base& other) const = 0; virtual const std::type_info& type() const = 0; }; template<typename Texception_to, typename Texception_from> class try_catcher: public try_catcher_base { typedef boost::function<const Texception_to (const Texception_from&)> converter_f; public: try_catcher(const converter_f& iconverter): converter(iconverter) { assert(!converter.empty() && "Null converter"); } private: void convert() const { try { throw; } catch(const Texception_from& ex) { throw converter(ex); } catch(...) { throw failed_to_catch_exception(); } } void try_throw_self_exception() const { throw (Texception_from*)0; } bool try_catch_self_exception(const try_catcher_base& other) const { try { other.try_throw_self_exception(); } catch(Texception_from*) { return true; } catch(...) { return false; } } const std::type_info& type() const { return typeid(Texception_from); } //... converter_f converter; }; }//...namespace details template<typename Texception_to> class catcher { typedef boost::shared_ptr<details::try_catcher_base> impl_t; catcher(const impl_t& iimpl): impl(iimpl) { assert(impl && "NULL catcher implementation"); } void convert() const { impl->convert(); } void try_throw_self_exception() const { impl->try_throw_self_exception(); } bool try_catch_self_exception(const catcher& other) const { return impl->try_catch_self_exception(*other.impl); } public: typedef Texception_to Texception_to_type; template<typename Texception_from> static const catcher create( const boost::function<const Texception_to (const Texception_from&)> converter) { //...it's senseless to convert from derived to base exception, //...or convert exception to its own type BOOST_STATIC_ASSERT( (!boost::is_base_of<Texception_to, Texception_from>::value)); return catcher( impl_t( new details::try_catcher<Texception_to, Texception_from>( converter))); } //... const std::type_info& type() const { return impl->type(); } void swap(catcher& rhs) { impl.swap(rhs.impl); } private: template<typename Treturn, typename Tcatchers> friend Treturn guard( const Tcatchers& catchers, const boost::function<Treturn ()>& func); template<typename TcatchersIterator> friend TcatchersIterator find( TcatchersIterator begin, TcatchersIterator end, const typename std::iterator_traits<TcatchersIterator>::value_type& catcher); //... impl_t impl; }; template<typename Treturn, typename Tcatchers> Treturn guard( const Tcatchers& catchers, const boost::function<Treturn ()>& func) { assert(!func.empty() && "Empty function"); typedef typename Tcatchers::value_type::Texception_to_type Texception_to_type; try { return func(); } catch(...) { const typename Tcatchers::const_iterator end(catchers.end()); for(typename Tcatchers::const_iterator iter(catchers.begin()); end != iter; ++iter) { try { iter->convert(); } catch(const Texception_to_type&) { throw; } catch(details::failed_to_catch_exception) { //...try next handler } } throw; } } template<typename Tcatchers> inline void guard( const Tcatchers& catchers, const boost::function<void ()>& func) { guard<void, Tcatchers>(catchers, func); } template<typename Texception_to> inline bool operator==( const catcher<Texception_to>& lhs, const catcher<Texception_to>& rhs) { return lhs.type() == rhs.type(); } template<typename Texception_to> inline bool operator!=( const catcher<Texception_to>& lhs, const catcher<Texception_to>& rhs) { return !(lhs == rhs); } template<typename Texception_to> inline void swap(catcher<Texception_to>& lhs, catcher<Texception_to>& rhs) { lhs.swap(rhs); } template<typename TcatchersIterator> TcatchersIterator find( TcatchersIterator begin, TcatchersIterator end, const typename std::iterator_traits<TcatchersIterator>::value_type& catcher) { for(;end != begin; ++begin) if(begin->try_catch_self_exception(catcher)) return begin; return end; } template<typename Tcatchers> void insert(Tcatchers& catchers, const typename Tcatchers::value_type& catcher) { typename Tcatchers::iterator iter( exc::find(catchers.begin(), catchers.end(), catcher)); catchers.insert(iter, catcher); } template<typename Tcatchers> void replace(Tcatchers& catchers, const typename Tcatchers::value_type& catcher) { typename Tcatchers::iterator iter( exc::find(catchers.begin(), catchers.end(), catcher)); if(catchers.end() == iter) catchers.push_back(catcher); else if(catcher == *iter) *iter = catcher; else catchers.insert(iter, catcher); } } //...namespace exc #endif /*EXCEPTION_MONITOR_HEADER_GUARD*/

2 1

[test]
by Jochen Heckl 17 May '09

17 May '09

Hi, I think I stumbled over a problem in the boost unit test library. I'm running MSVC 2008 SP1. Maybe also worth mentioning is, that I use _HAS_TR1=0 with any msvc build. Also I compile boost using bjam define=_HAS_TR1=0 ... Well straight to the problem: this code (boost\test\utils\basic_cstring\basic_cstring.hpp, around line 170) template<typename CharT> inline basic_cstring<CharT>::basic_cstring( std_string const& s ) : m_begin( s.c_str() ) , m_end( m_begin + s.size() ) { } will result in a corrupted basic_cstring, if the source string s goes out of scope, which is the case here ( \boost\test\impl\unit_test_main.ipp, around line 179 ) ... int BOOST_TEST_DECL unit_test_main( init_unit_test_func init_func, int argc, char* argv[] ) { try { framework::init( init_func, argc, argv ); if( !runtime_config::test_to_run().is_empty() ) { test_case_filter filter( runtime_config::test_to_run() ); // <--- parameter will become corrupted traverse_test_tree( framework::master_test_suite().p_id, filter ); } ... because of the temporal std::string return from retrieve_parameter (boost\test\impl\unit_test_parameters.ipp, around line 353 ) const_string test_to_run() { return retrieve_parameter( TESTS_TO_RUN, s_cla_parser, s_empty ); } as quick and very very dirty fix I currently use: test_to_run() { static std::string TTR = retrieve_parameter( TESTS_TO_RUN, s_cla_parser, s_empty ); return TTR; } However, I would welcome, if somebody could supply a more suitable solutions. Best Jochen

2 1

Re: [boost] [test] Automatic registration of tests created with BOOST_PARAM_TEST_CASE
by Jan Stolarek 17 May '09

17 May '09

> Here an example that works fine: Awsome, thanks. By the way, I just run into another serious problem, his time with BOOST_CHECK_EQUAL_COLLECTIONS macro that compares values in two collections. When using STL it is very common that elements in the collection are not objects, but pointers to objects. This leads to a serious problem, since people would rather want to compare values of objects that are pointed to, rather than pointer values (i.e. memory adresses). These will practically always be different, except the situation when two collections actually point to same addresses in memory. Now I'm trying to solve this problem. In test_tools.cpp I found : for( ; left_begin != left_end && right_begin != right_end; ++left_begin, ++right_begin, ++pos ) { if( *left_begin != *right_begin ) { res = false; res.message() << "\nMismatch in a position " << pos << ": " << *left_begin << " != " << *right_begin; } } I don't have the time at the moment, but I assume that replacing ( *left_begin != *right_begin ) with (**left_begin != **right_begin) would solve the problem? Jan

2 1

[tuple] swap (also includes question about [sorting])
by Jeremiah Willcock 17 May '09

17 May '09

Thanks to Marcin Zalewski, the problem in my last email has been tracked down to the inability to swap boost::tuples that contain references. There have been a couple of proposals to add that: http://lists.boost.org/Archives/boost/2006/03/102603.php http://lists.boost.org/Archives/boost/2003/05/48488.php but it appears that none of them has made it into Boost. This feature is important because of sorting data structures using zip_iterators as in my previous message: http://www.nabble.com/-iterator--std::sort-on-zip_iterator-td23348384.html and the older posts: http://lists.boost.org/Archives/boost/2004/07/68758.php http://lists.boost.org/boost-users/2009/03/46623.php In particular, std::swap (from GCC 4.0.1) does not work correctly on the result of dereferencing a zip_iterator, which is a Boost tuple of references. The std::swap function does not work at all (fails at compile time) because the result of operator* is not a non-const reference, and std::iter_swap tries to use assignment between the tuples, producing incorrect answers at run time. Is it true that there is no standards-compliant way to solve this problem? If so, would that be a good justification for Boost.Sorting to include an algorithm similar to std::sort but that handles more generalized swappable types? -- Jeremiah Willcock

2 1

[Boost.datetime] Serialization
by Sean Farrow 17 May '09

17 May '09

Hi: Would it be possible to add the funtion Given at the url: http://www.boost.org/doc/libs/1_39_0/doc/html/date_time/serialization.ht ml To the boost.datetime or boost.serialization library for 1.40. Cheers Sean. __________ Information from ESET NOD32 Antivirus, version of virus signature database 4080 (20090515) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com

2 1

[gsoc] Proposal for Generic Trie, Radix Tree, and Suffix Array Data Structures
by Chris Wagner 17 May '09

17 May '09

Hello, I am interested in writing a library consisting of generic implementations of several common data structures and algorithms primarily useful in text-processing. I believe these would be useful additions to Boost and would like to work on them for GSoC. Before I submit my proposal, I would like to hear whether or not the community agrees that this is a good idea, and I would appreciate any suggestions or comments offered. My plan is to implement a trie / prefix tree data structure, STL set/map-like classes implemented over the trie, a radix tree, a suffix tree implemented over the radix tree, and a suffix array. These would be instantiable over arbitrary sequence types, and use iterator traits to determine the contained type. I am a student at Kent State University, working on an M.S. in Computer Science in a combined undergraduate/graduate program. I have a particular interest in computational linguistics, and I will admit that am especially interested in this project because of how it could be applied to my own field, but I believe that these types would be of general utility to the programming community as a whole. Thank you for your time, Chris Wagner

5 5

[futures] is there an updated version of futures
by Yigong Liu 16 May '09

16 May '09

Hello, Is there an updated version of futures lib by Anthony after the review? Is the one dated 20090530 still the latest one publicly avaialble? Thanks Yigong

1 0

[exception] Virtual inheritance with no default constructors
by Adam Badura 16 May '09

16 May '09

The Boost.Exception library mandates that exceptions classes hierarchy should use virtual inheritance (http://www.boost.org/doc/libs/1_39_0/libs/exception/doc/using_virtual_inher…) The document notes that this does not go well with exceptions without default constructors ("(...) Note that virtual bases are initialized directly by the constructor of the most-derived-type (...)") however this should not be a concern as boost::exception provides other means to transport data. What is missing is however documentation that in normal circumstances boost::throw_exception cannot be used with exceptions types which have in their inheritance graph virtual base classes which are not default constructible. This is because boost::enable_current_exception constructs the clone_impl object which inherits the actual exception type and copy-constructs it. However this code will not compile if some base class of the callers exception type is virtual and non-default constructible. In my opinion few changes seem appropriate: 1) Note in the documentation explicitly this requirement (possibility of default construction). 2) Name an entity which should be made friend of exception class to use its non-public default constructor. This entity would be latter used by clone_impl. This way an exception could be default constructible only for this particular use case. 3) Provide means to late-initialize exception object. This would bypass the default construction problem (and goes well with private default constructor as described in 2)). 4) Allow to specify in boost::throw_exception (or similar places) not only the exception type but as well its (virtual) base types so that latter clone_impl could mention them on the initializers list as well and copy-construct them. (As far as I know there is no way of automatic detection of base types thus caller must specify them explicitly - however if I am mistaken such automation would be even better.) Adam Badura

2 11

Re: [boost] [rfc] Unicode GSoC project
by Graham 16 May '09

16 May '09

>What kind of real-world use do people have for random access, anyways? >Even UTF-32 isn't random access for the things I can think of that >people would care about, what with combining codepoints and ligatures >and other such things. I wrote a couple of Unicode text editors that would have been a nightmare if they had not been operating on UTF-32. >As an aside, I'd like to see comparisons between compressed UTF-8 and >compressed UTF-16, since neither one is random-access anyways, and it >seems to me that caring about size of text before compression is about >as important as the performance of a program with the optimizer turned >off. Actually in a few cases I have seen it is not the compressed size but the conversion performance [memory/CPU] that hurts. It is much better to get the correct encoding for the correct use case. Yours, Graham

2 1

Re: [boost] [rfc] Unicode GSoC project
by Graham 15 May '09

15 May '09

>I don't plan on supporting random access for UTF-16. >UTF-16 is still faster than UTF-8 because UTF-8 requires more complex >decoding. >UTF-16 has only two cases, making it easier to optimize branches under >the likely and unlikely case. Dear Mathias, Don't forget surrogates ! Yours, Graham

1 0