March 2009 - Boost - lists.boost.org

[test] Using the Boost Unit Test Framework with shared libs
by Peter 17 May '09

17 May '09

Hi I am using Boost.Test from the current boost 1.38 , on cygwin ( gcc ) and I want to use it with multiple test files and with shared libs ( in order to speed up the compilation time which is too long for me when using the header include variant ). What is the recommended way ? ( I read the doc, several times and I read the _long_ threads on the mailing list concerning the static/shared library issue, but I am not sure that I understood all the details). I did the following: *in mainTest.cpp:* #define BOOST_TEST_DYN_LINK #define BOOST_TEST_MAIN #include "../inc/globalFixture.hpp" #include "../inc/testfile1.hpp" #include "../inc/testfile2.hpp" *testfile1.hpp:* #include "globalFixture.hpp" BOOST_FIXTURE_TEST_SUITE(ATlib1, Fixture) BOOST_AUTO_TEST_CASE(Resource_Manager) { ... ....BOOST_CHECK .... } BOOST_AUTO_TEST_SUITE_END() *testfile2.hpp:* #include "globalFixture.hpp" BOOST_FIXTURE_TEST_SUITE(ATlib2, Fixture) BOOST_AUTO_TEST_CASE(FileManager { ... BOOST_CHECK .... } BOOST_AUTO_TEST_SUITE_END() *globalfixture.hpp: *#ifndef _GLOBALFIXTURE_HPP #define _GLOBALFIXTURE_HPP #define BOOST_TEST_MODULE ATlib #include <iostream> #include <boost/test/unit_test.hpp> #include <boost/test/detail/unit_test_parameters.hpp> #include <boost/bind.hpp> #include <boost/test/output_test_stream.hpp> using namespace boost::unit_test; struct GlobalConfig { GlobalConfig() { std::cout << "GlobalConfig setup\n"; using namespace boost::unit_test; if (runtime_config::log_level() < log_warnings) unit_test_log.set_threshold_level(log_successful_tests); }; ~GlobalConfig() { std::cout << "GlobalConfig teardown\n"; } }; BOOST_GLOBAL_FIXTURE(GlobalConfig); struct Fixture { Fixture() { BOOST_TEST_MESSAGE("setup Fixture"); using namespace boost::unit_test; unit_test_log.set_threshold_level(log_successful_tests); } ~Fixture() { BOOST_TEST_MESSAGE("teardown Fixture"); } }; #endif /* _GLOBALFIXTURE_HPP */* *I then link to boost_unit_test_framework-gcc34-mt-1_38.so The link passes , but I get a warning from gcc++ 3.4.4 that auto-linking has been enabled ( I will provide the exact details if useful ). I can execute the resulting mainTest.exe without problems, but the compiler warnings tells that something is not quite right. Is the above example the right way to use multiple test files ? Are the flags for shared libs correctly set ? Thanks for your help. PS: I think that Boost.Test is not easy to grasp ( at least for me ). I think this is partially due to a lack of complete examples ( involving for examples a test suite with more than one test file ). Also the static/shared library topic and the related macros ( BOOST_TEST_DYN_LINK etc ) could do with a concrete example. Maybe the mentioned case above could serve as an example after clarification. Peter

3 3

[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

[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

[RFC] thread::access_monitor
by Gregory Petrosyan 14 May '09

14 May '09

I would like to hear your comments on the idea behind access_monitor template, which ensures (at compile-time) that data, protected by it, can be accessed only with associated lock held. It can be useful when you want to expose all the native interface of your data type (STL container, for example): in such a case, using ordinary monitor pattern is almost impossible. Example usage: typedef access_monitor<data_type, mutex_type> data_access_monitor; void f(data_access_monitor const& d) { data_access_monitor::value_type const* data; data_access_monitor::lock_type lock; boost::tie(data, lock) = d.const_lock(); // do something with data here } Code: #include <boost/thread.hpp> #include <boost/tuple/tuple.hpp> template <typename T, typename Lockable> struct access_monitor { typedef T value_type; typedef boost::unique_lock<Lockable> lock_type; private: typedef boost::detail::thread_move_t<lock_type> lock_move_type; public: boost::tuple<value_type const*, lock_move_type> const_lock() const { lock_type lock(mutex_); return boost::make_tuple(&data_, lock.move()); } boost::tuple<value_type*, lock_move_type> lock() { lock_type lock(mutex_); return boost::make_tuple(&data_, lock.move()); } private: // mutex_ is guaranteed to be locked when you access data_ mutable Lockable mutex_; T data_; }; Sorry for draft-quality code (however, something like the above compiles with MSVC 9). Please CC me, because I am not subscribed. Gregory

2 1

[scope_exit] Boost.ScopeExit capturing 'this'
by adam.butcher＠selex-comms.com 11 May '09

11 May '09

I wasn't sure whether I had the correct address for Boost.ScopeExit's author Alexander Nasonov, so I've submitted to this list just in case and to get feedback from other users. I have been playing with BOOST_SCOPE_EXIT -- it it very convenient. One thing I would have liked would be to capture 'this' inside member functions. I have created a patch which adds BOOST_SCOPE_EXIT_THIS to do just that. It provides an operator->() in the generated struct which can be used to access the enclosing class's members. The syntax is: BOOST_SCOPE_EXIT_THIS( (&a) (&b) ) { a; b; // local captures (*this)->member; // member access } BOOST_SCOPE_EXIT_END; and can be BOOST_SCOPE_EXIT_THIS() { (*this)->member; } BOOST_SCOPE_EXIT_END; providing the preprocessor allows for empty parameter lists (which gcc does and vc does albeit after disabling a warning to remove noise). The type pointed to by the result of operator->() is correctly cv qualified. It has been tested on gcc 4.3, gcc 4.2, msvc 7.1 and msvc 9.0. I don't have access to other compilers. Boost.Typeof worked fine on gcc for typeof(this) -- mostly because gcc has a native typeof I guess. On visual studio (vc71 and vc90) it was not so good -- a compiler bug ( http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?Feedba… , http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?Feedba… ) that has been marked as 'Won't fix' means that 'this' cannot be used in expressions within template argument lists -- even if those expressions are innocuous typeid()s or sizeof()s for type-inference. The common workaround (capturing a compile-time integer with an enumerator and using the enumerator in the template parameter list) doesn't work with the vc71-specific implementation of Boost.Typeof since it is based on typeid() -- this cannot be captured in a compile-time expression (or I know of no way to that doesn't involve the expression existing in a template argument list). All is not lost though -- the general-purpose sizeof() based approach for the other VC versions works fine for VC71 for determining the typeof 'this'. As such my patch includes a VC>=1300 specific workaround for typeof 'this' determination. This is unfortunate but I couldn't think of any other non-intrusive way of doing it. Please find the attached patch and let me know what you think -- I'm sure this feature would be useful to users -- it saves having to do: TypeOfMyClassWhichCouldBeTedious* self = this BOOST_SCOPE_EXIT( (&self) ) { self->member; } BOOST_SCOPE_EXIT_END; which removes the convenience of BOOST_SCOPE_EXIT in these contexts since something like: struct at_end { TypeOfMyClassWhichCouldBeTedious* self; ~at_end() { self->member; } } at_end = {this}; can be done without any dependencies to achieve the same result. Regards, Adam. ------------------------------------------------------------ This email and any attached files contains company confidential information which may be legally privileged. It is intended only for the person(s) or entity to which it is addressed and solely for the purposes set forth therein. If you are not the intended recipient or have received this email in error please notify the sender by return, delete it from your system and destroy any local copies. It is strictly forbidden to use the information in this email including any attachment or part thereof including copying, disclosing, distributing, amending or using for any other purpose. In addition the sender excludes all liabilities (whether tortious or common law) for damage or breach arising or related to this email including but not limited to viruses and libel. SELEX Communications Limited is a Private Limited Company registered in England and Wales under Company Number 964533 and whose Registered Office is Lambda House, Christopher Martin Rd, Basildon, SS14 3EL. England.

4 8

[Graph] transitive reduction
by boese-wolf＠math.uni-frankfurt.de 30 Apr '09

30 Apr '09

Hi! May I propose the following implementation for a transitive reduction to be added to the boost graph library? I'm a novice and the quality of the code I produced surely does not meet boosts standards, but maybe with some help, I'm able to improve it. So, please don't shoot me. #ifndef MY_OWN_TRANSITIVE_REDUCTION_HPP_INCLUDED #define MY_OWN_TRANSITIVE_REDUCTION_HPP_INCLUDED #include <vector> #include <algorithm> //std::find #include <boost/concept/requires.hpp> #include <boost/concept_check.hpp> #include <boost/graph/topological_sort.hpp> #include <boost/graph/graph_traits.hpp> #include <boost/property_map.hpp> //I actually didn't care which of those heades include some of the //others and whicht could be left out, for this reason, I simply added a //header when I used a function, described to be in this header by the //boost graph documentation //also I didn't got all of the concepts thin. Am I suppose to check //for all concepts, which are needed for functions I call? (As if I //wouldn't do that, the users would see the functions called by //complaining about missings concepts, which would be clearly an error //message revealing internal implementation and should therefore be avoided?) //the pseudocode which I followed implementing this algorithmn was taken //from the german book Algorithmische Graphentheorie by Volker Turau //it is proposed to be of O(n + nm_red ) where n is the number //of vertices and m_red is the number of edges in the transitive //reduction, but I think my implementation spoiled this up at some point //indicated below using namespace boost; template <typename Graph, typename GraphTR, typename G_to_TR_VertexMap, typename VertexIndexMap> BOOST_CONCEPT_REQUIRES( ((VertexListGraphConcept< Graph >)) ((IncidenceGraphConcept< Graph >)) ((MutableGraphConcept< GraphTR >)) ((ReadablePropertyMapConcept< VertexIndexMap, typename graph_traits<Graph>::vertex_descriptor >)) ((Integer< typename property_traits< VertexIndexMap >::value_type >)) ((LvaluePropertyMapConcept< G_to_TR_VertexMap, typename graph_traits<Graph>::vertex_descriptor >)), (void)) transitive_reduction( const Graph& g, GraphTR& tr, G_to_TR_VertexMap g_to_tr_map, const VertexIndexMap & g_index_map ) { typedef typename graph_traits<Graph>::vertex_descriptor Vertex; typedef typename graph_traits<Graph>::vertex_iterator VertexIterator; typedef typename std::vector<Vertex>::size_type size_type; std::vector<Vertex> topo_order; topological_sort( g, std::back_inserter( topo_order ) ); std::vector<size_type> topo_number_storage( num_vertices(g) ); iterator_property_map<size_type*, VertexIndexMap, size_type, size_type&> topo_number( &topo_number_storage[0], g_index_map ); { typename std::vector<Vertex>::reverse_iterator it = topo_order.rbegin(); size_type n = 0; for(; it != topo_order.rend(); ++it,++n ) { topo_number[ *it ] = n; } } std::vector< std::vector< bool > > edge_in_closure(num_vertices(g), std::vector<bool>( num_vertices(g), false)); { typename std::vector<Vertex>::reverse_iterator it = topo_order.rbegin(); for( ; it != topo_order.rend(); ++it ) { g_to_tr_map[*it] = add_vertex(tr); } } for( typename std::vector<Vertex>::iterator it = topo_order.begin(); it != topo_order.end(); ++it ) { size_type i = topo_number[ *it ]; edge_in_closure[i][i] = true; std::vector<Vertex> neighbors; //I have to collect the successors of *it and traverse them in //ascending topological order. I didn't know a better way, how to //do that. So what I'm doint is, collection the successors of *it here { typename Graph::out_edge_iterator oi,oi_end; for( tie(oi, oi_end) = out_edges( *it, g ); oi != oi_end; ++oi ) { neighbors.push_back( target( *oi, g ) ); } } { //and run through all vertices in topological order for( typename std::vector<Vertex>::reverse_iterator rit = topo_order.rbegin(); rit != topo_order.rend(); ++rit ) { //looking if they are successors of *it if( std::find( neighbors.begin(), neighbors.end(), *rit) != neighbors.end() ) { size_type j = topo_number[ *rit ]; if( not edge_in_closure[i][j] ) { for(size_type k = j; k < num_vertices(g); ++k) if( not edge_in_closure[i][k] ) //here we need edge_in_closure to be in topological order, edge_in_closure[i][k] = edge_in_closure[j][k]; //therefore we only access edge_in_closure only through //topo_number property_map add_edge(g_to_tr_map[*it], g_to_tr_map[*rit], tr); } //if ( not edge_in_ } //if (find ( } //for( typename vector<Vertex>::reverse_iterator } // { } //for( typename vector<Vertex>::iterator } //void transitive_reduction #endif //#ifndef MY_OWN_TRANSITIVE_REDUCTION_HPP_INCLUDED Best regards, Eric

2 3

Proposed templated integer_sort
by Steven Ross 25 Apr '09

25 Apr '09

Would there be interest in an integer_sort call that is faster than std::sort? Spreadsort is an in-place hybrid radix-based and comparison-based algorithm with better worst-case and average-case (roughly 20-50%) performance than introsort on random integer data. The worst-case advantage is algorithmic, with Spreadsort taking the better of O(n(square_root(bit_sizeof(data) - log(n)))) and O(nlog(n)) time. For 32-bit integers, that's O(n(square_root(32 - log(n)))), so for a log(n) of 16 (65536 items), it's 4n (plus a small constant times n), vs 16n for introsort. For larger n, the advantage vs. pure comparison-based algorithms increases. In effect, Spreadsort smoothly transitions from pure MSB Radix sort to std::sort with its data cut up by a couple iterations of MSB Radix sort (reducing the size of the log(n) factor), depending upon the distribution and size of the data. I could write a templated version of Spreadsort for the Boost library if there is interest. It would work for anything that supports the << and - operators. It could also handle standard floats sorted as integers. Functors supporting << and - could make it more general. Multi-dimensional sorting is also sped up by Spreadsort. I could also write a similar string_sort, that should also be significantly faster than std::sort. This would look much like postal sort, just using introsort after a certain number of iterations. Is this of interest? http://sourceforge.net/projects/spreadsort

15 118

[thread] atomic
by Sergei Politov 15 Apr '09

15 Apr '09

Hi, I would like to known state of atomic (class/operations) implementation in boost. There are several threads that contains references to atomics, but I cannot find the state of this issue. May be I've overlooked something. I would like to known the following: 1) Is there defined interface for atomics? Where is it if present? 2) What is the state of this work? Currently I use my own implementation of atomic class. It has interface similar to atomic class from intel tbb (also it contains some ideas from tbb, but AFAIK ideas are not under GPL license). Now it is tested on MSVC 9.0 32-bit, and GCC 4.2.4 under Gentoo linux (both 32 and 64-bit). I can boostify and prepare it for review, if there is no such work already in progress. Best Regards, Sergei

4 3

Boost.Process 0.3 released
by Boris 14 Apr '09

14 Apr '09

I've released Boost.Process 0.3. Here's the documentation and a link to download the zip archive: Docs: http://www.highscore.de/boost/process/ Code: http://www.highscore.de/boost/process.zip It's a header-only library and thus pretty easy to use: Just copy the files to your Boost directory. In this release my main goal was to merge various snapshots: * There was my Boost.Process 0.2 version which was based on Boost.Process 0.1 from 2006. * There was a post-0.1 version of Boost.Process in SVN from 2007. * Chris Fairles had modified a Boost.Process snapshot for Unix platforms. * Ion Gaztañaga had also some ideas and bug fixes he sent to this mailing list recently. I just saw that Ilya Sokolov created another snapshot based on Boost.Process in SVN. That means we have again at least two different versions of Boost.Process. :-/ In my Boost.Process 0.3 version I concentrated on merging and overhauling code. I did not change the design but tried to make the code work: All the code which was written since 2006 should become usable. That's why I also concentrated a lot on test cases. There are quite a lot of test cases, and they all can be built and passed successfully on three platforms with four compilers. As it would be great if others run the test cases, too (ideally on new platforms), I'll send another message in a few minutes with a description how to run the test cases yourself. As the documentation was written in 2006 I also updated it. It's not yet really a good documentation: There are some files coming from 2006 while other files I wrote myself only last week. While the documentation can be improved it's at least up-to-date: The examples all work and can be compiled. As the documentation was not my priority for Boost.Process 0.3 it should be ok for now. Boris

9 14