January 2010 - Boost - lists.preview.boost.org

[1.42] The PDF build of the docs for the 1.42 BETA available
by John Maddock 04 Feb '10

04 Feb '10

The PDF build of the docs for 1.42 BETA are now available for download from the sourceforge download page https://sourceforge.net/projects/boost/files/boost-docs/1.42.0/boost_pdf_1_…. Please let me know if you spot any issues, Thanks, John Maddock.

2 1

[gil] trac #3619
by Christian Henning 03 Feb '10

03 Feb '10

Hi there, could someone please tell whether or not this bug still exists. I don't have access to gcc 4.4. This is marked as a showstopper and I would like to get rid of it. Is it a compiler bug maybe? Thanks, Christian

2 1

[multi_index][serialization] save_construct_data not called for multi_index collection
by Felipe Magno de Almeida 03 Feb '10

03 Feb '10

Hi, Boost.Serialization has support for non-default classes using save_construct_data and load_construct_data overloads. These are called before serialization to save and load information that's important for the construction of the object. Unfortunately, multi_index doesn't call these functions when serializing, so serialization of non-default-constructible classes is impossible with multi_index. I wanted to patch it so that it becomes possible, but to be honest I'm a bit lost in the serialization code for multi_index. collections_save_impl calls boost::serialization::save_construct_data_adl before serializing each item in the collection. I'm using boost 1.38.0, is there anyway to do the same for multi_index? Thanks in advance, -- Felipe Magno de Almeida

4 8

crash in boost serialization 1.41
by Est 02 Feb '10

02 Feb '10

Hi All I'm developing an image processing app. In my app, I serialize a boost::ptr_vector of an abstract base class to a polymorphic xml archive. I checked all my polymorphic classes are exported with BOOST_SERIALIZATION_EXPORT and BOOST_SERIALIZATION_ASSUME_ABSTRACT for abstract classes, and it's working correctly with boost 1.38. If I update to boost 1.41, I can save archives without problems. When I try to load the resulting archive, I get a crash: Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x00000000 boost::archive::detail::basic_iarchive_impl::load_pointer (this=0x1b955a00, ar=@0xbfffe598, t=@0xbfffd8d0, bpis_ptr=0x0) at libs/serialization/src/basic_iarchive.cpp:429 429 class_id_type new_cid = register_type(bpis_ptr->get_basic_serializer()); I can read the archive with my app compiled with boost 1.38. I'm using gcc 4.0.1 on OSX and gcc 4.3 on linux, all 32 bits. I'm not using DLLs. I ran the unit tests of the serialization library. All passed. I'm in the process of extracting a small example that reproduces the crash. Do you have any idea how can I fix it? Thank you. Est. Here is the backtrace: node_t is my abstract base class. #0 boost::archive::detail::basic_iarchive_impl::load_pointer (this=0x1b955a00, ar=@0xbfffe598, t=@0xbfffd8d0, bpis_ptr=0x0) at libs/serialization/src/basic_iarchive.cpp:429 #1 0x005a5506 in boost::archive::detail::basic_iarchive::load_pointer (this=0x0, t=@0x0, bpis_ptr=0x0) at libs/serialization/src/basic_iarchive.cpp:538 #2 0x00043f2e in boost::archive::detail::polymorphic_iarchive_route<boost::archive::naked_xml_iarchive>::load_pointer (this=0xbfffe58c, t=@0xbfffd8d0, bpis_ptr=0x0) at polymorphic_iarchive_route.hpp:65 #3 0x0003d0f9 in boost::archive::detail::load_pointer_type<boost::archive::polymorphic_iarchive>::invoke<ramen::node_t*> (ar=@0xbfffe58c, t=@0xbfffd8d0) at iserializer.hpp:486 #4 0x0003d157 in boost::archive::load<boost::archive::polymorphic_iarchive, ramen::node_t*> (ar=@0xbfffe58c, t=@0xbfffd8d0) at iserializer.hpp:554 #5 0x0003d1a6 in boost::archive::polymorphic_iarchive_impl::load_override<ramen::node_t*> (this=0xbfffe58c, t=@0xbfffd8d4) at polymorphic_iarchive.hpp:137 #6 0x0003d1f8 in boost::archive::detail::interface_iarchive<boost::archive::polymorphic_iarchive>::operator>><boost::serialization::nvp<ramen::node_t*> const> (this=0xbfffe58c, t=@0xbfffd8d4) at interface_iarchive.hpp:61 #7 0x0003d253 in boost::ptr_container_detail::load_helper<boost::archive::polymorphic_iarchive, boost::ptr_container_detail::sequence_config<ramen::node_t, std::vector<void*, std::allocator<void*> > >, boost::heap_clone_allocator> (ar=@0xbfffe58c, c=@0x193b1bd8, n=1) at detail/serialize_reversible_cont.hpp:52 #8 0x0003d2e9 in boost::serialization::load<boost::archive::polymorphic_iarchive, ramen::node_t, boost::heap_clone_allocator, std::allocator<void*> > (ar=@0xbfffe58c, c=@0x193b1bd8) at serialize_ptr_vector.hpp:28 #9 0x0003d327 in boost::serialization::free_loader<boost::archive::polymorphic_iarchive, boost::ptr_vector<ramen::node_t, boost::heap_clone_allocator, std::allocator<void*> > >::invoke (ar=@0xbfffe58c, t=@0x193b1bd8, file_version=0) at split_free.hpp:58 #10 0x0003d349 in boost::serialization::split_free<boost::archive::polymorphic_iarchive, boost::ptr_vector<ramen::node_t, boost::heap_clone_allocator, std::allocator<void*> > > (ar=@0xbfffe58c, t=@0x193b1bd8, file_version=0) at split_free.hpp:74 #11 0x0003d36b in boost::serialization::serialize<boost::archive::polymorphic_iarchive, ramen::node_t, boost::heap_clone_allocator, std::allocator<void*> > (ar=@0xbfffe58c, c=@0x193b1bd8, version=0) at serialize_ptr_vector.hpp:34 #12 0x0003d3a9 in boost::serialization::serialize_adl<boost::archive::polymorphic_iarchive, boost::ptr_vector<ramen::node_t, boost::heap_clone_allocator, std::allocator<void*> > > (ar=@0xbfffe58c, t=@0x193b1bd8, file_version=0) at serialization.hpp:133 #13 0x0003d456 in boost::archive::detail::iserializer<boost::archive::polymorphic_iarchive, boost::ptr_vector<ramen::node_t, boost::heap_clone_allocator, std::allocator<void*> > >::load_object_data (this=0xbcc2f0, ar=@0xbfffe598, x=0x193b1bd8, file_version=0) at iserializer.hpp:173 #14 0x005a5423 in boost::archive::object_id_type::operator= () at basic_archive.hpp:390 #15 0x005a5423 in boost::archive::detail::basic_iarchive_impl::load_object () at libs/serialization/src/basic_iarchive.cpp:391 #16 0x005a5423 in boost::archive::detail::basic_iarchive::load_object (this=0xbfffe598, t=0x193b1bd8, bis=@0xbcc2f0) at libs/serialization/src/basic_iarchive.cpp:529 #17 0x00043f0a in boost::archive::detail::polymorphic_iarchive_route<boost::archive::naked_xml_iarchive>::load_object (this=0xbfffe58c, t=0x193b1bd8, bis=@0xbcc2f0) at polymorphic_iarchive_route.hpp:59 #18 0x00039f93 in boost::archive::detail::load_non_pointer_type<boost::archive::polymorphic_iarchive>::load_standard::invoke<boost::ptr_vector<ramen::node_t, boost::heap_clone_allocator, std::allocator<void*> > > (ar=@0xbfffe58c, t=@0x193b1bd8) at iserializer.hpp:363 #19 0x00039fbc in boost::archive::detail::load_non_pointer_type<boost::archive::polymorphic_iarchive>::invoke<boost::ptr_vector<ramen::node_t, boost::heap_clone_allocator, std::allocator<void*> > > (ar=@0xbfffe58c, t=@0x193b1bd8) at iserializer.hpp:415 #20 0x00039fdb in boost::archive::load<boost::archive::polymorphic_iarchive, boost::ptr_vector<ramen::node_t, boost::heap_clone_allocator, std::allocator<void*> > > (ar=@0xbfffe58c, t=@0x193b1bd8) at iserializer.hpp:554 #21 0x0003a02a in boost::archive::polymorphic_iarchive_impl::load_override<boost::ptr_vector<ramen::node_t, boost::heap_clone_allocator, std::allocator<void*> > > (this=0xbfffe58c, t=@0xbfffdbc4) at polymorphic_iarchive.hpp:137 #22 0x0003a07c in boost::archive::detail::interface_iarchive<boost::archive::polymorphic_iarchive>::operator>><boost::serialization::nvp<boost::ptr_vector<ramen::node_t, boost::heap_clone_allocator, std::allocator<void*> > > const> (this=0xbfffe58c, t=@0xbfffdbc4) at interface_iarchive.hpp:61 #23 0x0003a0ac in boost::archive::detail::interface_iarchive<boost::archive::polymorphic_iarchive>::operator&<boost::serialization::nvp<boost::ptr_vector<ramen::node_t, boost::heap_clone_allocator, std::allocator<void*> > > const> (this=0xbfffe58c, t=@0xbfffdbc4) at interface_iarchive.hpp:68 #24 0x0003aa49 in ramen::dataflow::graph<ramen::node_t>::load<boost::archive::polymorphic_iarchive> (this=0x193b1bd8, ar=@0xbfffe58c, version=0) at graph.hpp:168 #25 0x0003ab9b in boost::serialization::access::member_load<boost::archive::polymorphic_iarchive, ramen::dataflow::graph<ramen::node_t> > (ar=@0xbfffe58c, t=@0x193b1bd8, file_version=0) at access.hpp:101 #26 0x0003abbd in boost::serialization::detail::member_loader<boost::archive::polymorphic_iarchive, ramen::dataflow::graph<ramen::node_t> >::invoke (ar=@0xbfffe58c, t=@0x193b1bd8, file_version=0) at split_member.hpp:54 #27 0x0003abdf in boost::serialization::split_member<boost::archive::polymorphic_iarchive, ramen::dataflow::graph<ramen::node_t> > (ar=@0xbfffe58c, t=@0x193b1bd8, file_version=0) at split_member.hpp:69 #28 0x0003ac01 in ramen::dataflow::graph<ramen::node_t>::serialize<boost::archive::polymorphic_iarchive> (this=0x193b1bd8, ar=@0xbfffe58c, file_version=0) at graph.hpp:175 #29 0x0003ac23 in boost::serialization::access::serialize<boost::archive::polymorphic_iarchive, ramen::dataflow::graph<ramen::node_t> > (ar=@0xbfffe58c, t=@0x193b1bd8, file_version=0) at access.hpp:109 #30 0x0003ac45 in boost::serialization::serialize<boost::archive::polymorphic_iarchive, ramen::dataflow::graph<ramen::node_t> > (ar=@0xbfffe58c, t=@0x193b1bd8, file_version=0) at serialization.hpp:74 #31 0x0003ac83 in boost::serialization::serialize_adl<boost::archive::polymorphic_iarchive, ramen::dataflow::graph<ramen::node_t> > (ar=@0xbfffe58c, t=@0x193b1bd8, file_version=0) at serialization.hpp:133 #32 0x0003ad30 in boost::archive::detail::iserializer<boost::archive::polymorphic_iarchive, ramen::dataflow::graph<ramen::node_t> >::load_object_data (this=0xbcc260, ar=@0xbfffe598, x=0x193b1bd8, file_version=0) at iserializer.hpp:173 #33 0x005a5423 in boost::archive::object_id_type::operator= () at basic_archive.hpp:390 #34 0x005a5423 in boost::archive::detail::basic_iarchive_impl::load_object () at libs/serialization/src/basic_iarchive.cpp:391 #35 0x005a5423 in boost::archive::detail::basic_iarchive::load_object (this=0xbfffe598, t=0x193b1bd8, bis=@0xbcc260) at libs/serialization/src/basic_iarchive.cpp:529 #36 0x00043f0a in boost::archive::detail::polymorphic_iarchive_route<boost::archive::naked_xml_iarchive>::load_object (this=0xbfffe58c, t=0x193b1bd8, bis=@0xbcc260) at polymorphic_iarchive_route.hpp:59 #37 0x000365fb in boost::archive::detail::load_non_pointer_type<boost::archive::polymorphic_iarchive>::load_standard::invoke<ramen::dataflow::graph<ramen::node_t> > (ar=@0xbfffe58c, t=@0x193b1bd8) at iserializer.hpp:363 #38 0x00036624 in boost::archive::detail::load_non_pointer_type<boost::archive::polymorphic_iarchive>::invoke<ramen::dataflow::graph<ramen::node_t> > (ar=@0xbfffe58c, t=@0x193b1bd8) at iserializer.hpp:415 #39 0x00036643 in boost::archive::load<boost::archive::polymorphic_iarchive, ramen::dataflow::graph<ramen::node_t> > (ar=@0xbfffe58c, t=@0x193b1bd8) at iserializer.hpp:554 #40 0x00036692 in boost::archive::polymorphic_iarchive_impl::load_override<ramen::dataflow::graph<ramen::node_t> > (this=0xbfffe58c, t=@0xbfffdf8c) at polymorphic_iarchive.hpp:137 #41 0x000366e4 in boost::archive::detail::interface_iarchive<boost::archive::polymorphic_iarchive>::operator>><boost::serialization::nvp<ramen::dataflow::graph<ramen::node_t> > const> (this=0xbfffe58c, t=@0xbfffdf8c) at interface_iarchive.hpp:61 #42 0x00036714 in boost::archive::detail::interface_iarchive<boost::archive::polymorphic_iarchive>::operator&<boost::serialization::nvp<ramen::dataflow::graph<ramen::node_t> > const> (this=0xbfffe58c, t=@0xbfffdf8c) at interface_iarchive.hpp:68 #43 0x0002c3fb in ramen::composition_t::serialize (this=0x193b1bd8, ar=@0xbfffe58c, version=0) at /Users/est/Devel/ramen/trunk/ramen/app/composition.cpp:193 #44 0x0004570f in boost::serialization::access::serialize<boost::archive::polymorphic_iarchive, ramen::composition_t> (ar=@0xbfffe58c, t=@0x193b1bd8, file_version=0) at access.hpp:109 #45 0x00048387 in boost::serialization::serialize<boost::archive::polymorphic_iarchive, ramen::composition_t> (ar=@0xbfffe58c, t=@0x193b1bd8, file_version=0) at serialization.hpp:74 #46 0x0004574f in boost::serialization::serialize_adl<boost::archive::polymorphic_iarchive, ramen::composition_t> (ar=@0xbfffe58c, t=@0x193b1bd8, file_version=0) at serialization.hpp:133 #47 0x00048436 in boost::archive::detail::iserializer<boost::archive::polymorphic_iarchive, ramen::composition_t>::load_object_data (this=0xbcc410, ar=@0xbfffe598, x=0x193b1bd8, file_version=0) at iserializer.hpp:173 #48 0x005a5423 in boost::archive::object_id_type::operator= () at basic_archive.hpp:390 #49 0x005a5423 in boost::archive::detail::basic_iarchive_impl::load_object () at libs/serialization/src/basic_iarchive.cpp:391 #50 0x005a5423 in boost::archive::detail::basic_iarchive::load_object (this=0xbfffe598, t=0x193b1bd8, bis=@0xbcc410) at libs/serialization/src/basic_iarchive.cpp:529 #51 0x00043f0a in boost::archive::detail::polymorphic_iarchive_route<boost::archive::naked_xml_iarchive>::load_object (this=0xbfffe58c, t=0x193b1bd8, bis=@0xbcc410) at polymorphic_iarchive_route.hpp:59 #52 0x0004835f in boost::archive::detail::load_non_pointer_type<boost::archive::polymorphic_iarchive>::load_standard::invoke<ramen::composition_t> (ar=@0xbfffe58c, t=@0x193b1bd8) at iserializer.hpp:363 #53 0x00043692 in boost::archive::detail::load_non_pointer_type<boost::archive::polymorphic_iarchive>::invoke<ramen::composition_t> (ar=@0xbfffe58c, t=@0x193b1bd8) at iserializer.hpp:415 #54 0x000436b1 in boost::archive::load<boost::archive::polymorphic_iarchive, ramen::composition_t> (ar=@0xbfffe58c, t=@0x193b1bd8) at iserializer.hpp:554 #55 0x00043700 in boost::archive::polymorphic_iarchive_impl::load_override<ramen::composition_t> (this=0xbfffe58c, t=@0xbfffe5c8) at polymorphic_iarchive.hpp:137 #56 0x00043752 in boost::archive::detail::interface_iarchive<boost::archive::polymorphic_iarchive>::operator>><boost::serialization::nvp<ramen::composition_t> const> (this=0xbfffe58c, t=@0xbfffe5c8) at interface_iarchive.hpp:61 #57 0x00043782 in boost::archive::detail::interface_iarchive<boost::archive::polymorphic_iarchive>::operator&<boost::serialization::nvp<ramen::composition_t> const> (this=0xbfffe58c, t=@0xbfffe5c8) at interface_iarchive.hpp:68 #58 0x0004379c in boost::archive::detail::polymorphic_iarchive_route<boost::archive::naked_xml_iarchive>::operator&<boost::serialization::nvp<ramen::composition_t> const> (this=0xbfffe58c, t=@0xbfffe5c8) at polymorphic_iarchive_route.hpp:173

1 1

metaprogramming: associating a type with another type
by DE 02 Feb '10

02 Feb '10

hi boosters while solving my own design problems i accidentally discovered an interesting technique let's assume we want to associate some value (a type) to a newly created type so we can easily access the associated type during metaprogramming let's call the associated type a property then we have the following property types: struct property0 {}; struct property1 {}; struct property2 {}; now we want to access the associated property for an arbitrary type in a natural traits manner: property<arbitrary_type>::type it appears we can implement it almost trivially (if know how) (let's assume we have portable typeof() facility) consider the code //the return type of this function appears to be the default property template<typename type> property0 get_prop(type*); //do not implement! template<typename t> struct property { typedef typeof(get_prop((type*)42) type; }; template<typename type, typename p = typename property<type>::type> struct base { friend p get_prop(type*) { return p(); } }; template<typename type> void foo(const base<type>&) //handles ALL types derived from base { typedef typename property<type>::type associated_property; } template<typename type> void bar(const base<type, property2>&) //handles ONLY types with property2 {} struct s : public expression<s> //default property used here {}; struct s1 : public expression<s1, property1> {}; struct s2 : public expression<s2, property2> {}; int main() { foo(s()); foo(s1()); foo(s2()); //bar(s()); //should not compile //bar(s1()); //should not compile bar(s2()); return 0; } even with the lack of typeof(), given a fixed set of properties it is very easy to implement this technique see working example at http://codepad.org/qXkESprl personally i see it as extremely useful for generic lib writers for some designes (of course if appropriately applied) as well as for users of such libs i would appreciate any thoughts on improvement of this technique within C++98 standard also any thoughts on portability are welcome if you have questions about how and/or why does it work feel free to ask -- Pavel

5 17

[transaction] New Boost.Transaction library under discussion
by vicente.botet 02 Feb '10

02 Feb '10

Hi Stefan, Bob, I've created in the sandbox the transaction directory (http://svn.boost.org/svn/boost/sandbox/transaction/) so we can share our work. I've created also a wiki page (http://svn.boost.org/trac/boost/wiki/BoostTransaction) on which we can compile the result of our discussions, requirements for the library, design, ... If you don't have right access to the Boost wiki pages, please request them throught this ML. Of course, anyone is welcome to participate, or comment on this wiki. HTH, _____________________ Vicente Juan Botet Escribá

8 42

[thread] why crash launching a thread?
by David M. Cotter 01 Feb '10

01 Feb '10

i'm launching a new thread from an existing background thread, BUT it is crashing. i don't know if it happens often yet, but was wondering what could possibly cause this? Thread 10 Crashed: 0 libSystem.B.dylib 0x96ce435d usleep$NOCANCEL$UNIX2003 + 0 1 libSystem.B.dylib 0x96d05a50 abort + 105 2 libstdc++.6.dylib 0x96bb2fda __gnu_cxx::__verbose_terminate_handler() + 433 3 libstdc++.6.dylib 0x96bb117a __cxxabiv1::__terminate(void (*)()) + 10 4 libstdc++.6.dylib 0x96bb11ba __cxxabiv1::__unexpected(void (*)()) + 0 5 libstdc++.6.dylib 0x96bb12b8 __gxx_exception_cleanup(_Unwind_Reason_Code, _Unwind_Exception*) + 0 6 libboost_thread.dylib 0x006af933 boost::thread::start_thread() + 195 7 com.kjams.kjams 0x001281d1 CThreads::Fork(APP_ThreadType, long (*)(void*, long), long (*)(void*, long), void*, char const*) + 1521 8 com.kjams.kjams 0x0012858b CT_Preemptive::call(char const*) + 91 9 com.kjams.kjams 0x00139fc2 CSpooler::Fork_Spool(CSpooler*, bool) + 290 10 com.kjams.kjams 0x0027fd05 CSongImporter::EncodeSong(CSI_PersistantQueData*, CSpooler*) + 1109

5 7

[log] Release Candidate 4 released
by Andrey Semashev 01 Feb '10

01 Feb '10

I'm proud to announce that I've released the fourth candidate of Boost.Log for the review. There were many improvements since the passed year of development. Many of them reflect the discussion of RC3. Here's a short list of major changes: * Substantial documentation improvement. The tutorial section has been reorganized. * Removed rotating file stream. As a replacement, a new file sink has been added, which allows to achieve the same results ans adds a few more features. It is now possible to collect rotated log files in a dedicated directory. * Added a new multifile sink backend. * Added a new ordering asynchronous sink frontend. * The syslog sink backend is now supported on Windows, too. The sink no longer requires native support for POSIX API for syslog, but is able to send syslog packets to a remote server over UDP. * Added support for scoped logging. There is now a distinct log record entity, which is returned by the core as a result of filtring. * Added support for exception control. * Added a new mode of logging, called trivial logging. The more complete change log is available here: http://tinyurl.com/ybcghuf The library with docs, tests and examples has been updated in Boost.Vault: http://tinyurl.com/cm9lum There's SVN repository available on SourceForge project page: http://tinyurl.com/ye23wyh The docs are also available online here: http://tinyurl.com/5e4fd7 Comments are welcome.

9 37

Boost.Atomic request for review/inclusion
by Helge Bahmann 01 Feb '10

01 Feb '10

Hello, First of all I would like to thank for the comments that I have received so far, I have incorporated almost all of them I think. Boost.Atomic is now in a form that I consider calling it a release. It has support for "true" atomic variables on: - gcc/x86, 32-bit (tested on Linux, FreeBSD) - gcc/x86, 64-bit (tested on Linux) - gcc/powerpc32 (tested on Linux, Mac OS X) - gcc/powerpc64 (untested) - generic Win32 (tested with Visual Studio Express on Win XP) For all others it falls back gracefully to locked operation. There is proper quickbook documentation, including a hopefully illustrative example section. If you have an unsupported platform, contact me and I will attempt to provide support for it (usually it is just a matter of testing). Otherwise I would like to request considering the library for inclusion and appreciate any further comments. Everything available as usual at: http://www.chaoticmind.net/~hcb/projects/boost.atomic Best regards Helge

6 12

[Serialization] virtual function and virtual inheritance
by fab 31 Jan '10

31 Jan '10

Hi, I have a compilation error with a virtual function inside a virtual base class. For example, I just add a function f() inside the unit test : "test_diamond.cpp". class base { ... virtual void f() =0; ... }; class derived1 { ... virtual void f(){} ... }; gcc 4.3, returns me an error: error: no unique final overrider for `virtual void base::f()' in `boost::detail::is_virtual_base_of_impl<derived1, final, mpl_::bool_< true> >::X' The same code works properly with msvc 2005. Best regards, Fabien Castan

2 2

RFC: Sequence Properties and Boost Algorithm/Functional
by Grant Erickson 31 Jan '10

31 Jan '10

For a recent project, I needed to inquire about a sequence of objects and make a determination as to whether the sequences were: * Increasing * Strictly Increasing * Decreasing * Strictly Decreasing Looking through STL, Boost documentation, Boost sources and headers and the Boost mailing lists I was able to find neither an existing algorithm or stateful unary predicate functor for accomplishing this for a pair of input iterators. However, I was a bit surprised considering that this seems like a sequence property query that would tend to come up fairly often and serve a general utility. Did I just fail to form the proper search/query or am I overestimating the general utility? Regardless, I forged ahead with the rather naïve implementation (see below), which can be used as a predicate with for_each as shown: const int strictlyIncreasingValues[] = { 1, 2, 3, 4, 5 }; bool isStrictlyIncreasing; isStrictlyIncreasing = std::for_each(strictlyIncreasingValues, strictlyIncreasingValues + 5, is_strictly_increasing<int>()); assert(inStrictlyIncreasing == true); However, acknowledging the inefficient and naïveté of the first implementation, this is probably more algorithm than functional in that for_each with a stateful predicate is wasteful in walking the entire sequence (i.e. if any arbitrary subsequence fails to meet the property predicate criteria, the whole sequence fails). Is a smarter realization of this as an algorithm a potential candidate for boost::algorithm? Naïve, inefficient functional implementation to be used with for_each: #include <functional> #include <boost/function.hpp> template <typename T> struct creasing : public unary_function<T, bool> { protected: typedef unary_function<T, bool> base_type; typedef typename base_type::argument_type argument_type; typedef typename base_type::result_type result_type; typedef boost::function<result_type (const argument_type &a, const argument_type &b)> binary_predicate; creasing(const binary_predicate & inPredicate) : base_type(), mPredicate(inPredicate), mCreasing(true), mInited(false), mLast() { return; } public: result_type operator()(const argument_type & x) { if (mCreasing) { if (mInited) { mCreasing = mPredicate(mLast, x); } else { mCreasing = true; mInited = true; } mLast = x; } return (mCreasing); } operator result_type() const { return (mCreasing); } private: const binary_predicate mPredicate; result_type mCreasing; result_type mInited; argument_type mLast; }; template <typename T> struct is_increasing : public creasing<T> { typedef creasing<T> base_type; typedef typename base_type::argument_type argument_type; is_increasing(void) : base_type(std::less_equal<argument_type>()) {} }; template <typename T> struct is_decreasing : public creasing<T> { typedef creasing<T> base_type; typedef typename base_type::argument_type argument_type; is_decreasing(void) : base_type(std::greater_equal<argument_type>()) {} }; template <typename T> struct is_strictly_increasing : public creasing<T> { typedef creasing<T> base_type; typedef typename base_type::argument_type argument_type; is_strictly_increasing(void) : base_type(std::less<argument_type>()) {} }; template <typename T> struct is_strictly_decreasing : public creasing<T> { typedef creasing<T> base_type; typedef typename base_type::argument_type argument_type; is_strictly_decreasing(void) : base_type(std::greater<argument_type>()) {} }; Regards, Grant

5 5

[atomic] Availability detection
by Andrey Semashev 31 Jan '10

31 Jan '10

Hi, Will there be a way to detect if specific operations over a specific type are available atomically on the current platform? That is, if I know that atomic operations are emulated with locks, I want to fall back to another branch of my code with explicit locks, rather than the emulated atomics.

2 4

codepad code longevity ?
by Joel de Guzman 31 Jan '10

31 Jan '10

Hi, We see more and more people post code using Codepad. Is that good? In the Spirit list, we've had this discussion about longevity of code posted to Codepad: http://article.gmane.org/gmane.comp.parsers.spirit.general/18220 I can't see any information regarding policy on how code is retained. Is there? I've heard they say the post is valid for 24 hours. If that's the case, then we should ban the use of codepad. People here, myself included, need pasted code to be permanent for future reference. Thoughts? Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net http://www.facebook.com/djowel Meet me at BoostCon http://www.boostcon.com/home http://www.facebook.com/boostcon

6 27

[circular_buffer] Serialization support for circular_buffer
by Brian Wood 31 Jan '10

31 Jan '10

B"H Shalom, Boost, The C++ Middleware Writer now supports marshalling circular_buffers. This is done by transmitting a circular buffer's capacity, then size, followed by it's elements. An example of the code used when marshalling a circular_buffer is here -- http://webEbenezer.net/posts/cirbuf.hh. -- Brian Wood http://www.webEbenezer.net (651) 251-9384

1 0

[asio] [function] Strange corruption error with boost::function and asio
by Zachary Turner 29 Jan '10

29 Jan '10

I'm not sure if I'm experiencing a bug in boost, bug in compiler (VS 9.0 service pack 1), or bug somewhere else, but I'm having trouble reading boost::function code enough to be able to figure out. A little background: I'm using boost::asio to read from a disk, and then boost::asio to write results to a socket. Everything works completely fine most of the time, but in some cases there's an error on my server (which is largely irrelevant here as it's not even written in C++) and the server crashes unexpectedly. I suspect the error is occuring while I'm in the middle of an asynchronous network write, because the very first odd behavior surfaces in my network write completion routine. I can go into more detail about how I'm using boost::function and boost::asio in conjunction if necessary, but for now I'll just post the bare minimum needed to be able to make any sense at all of what I'm doing (which is still alot, my apologies for the length). Anyway: - my completion routine has the following signature: void async_service_write_network::write_data_handler(asio_handler wrapped_handler, boost::system::error_code error, size_t bytes_transferred) - asio_handler (referenced in the previous signature) is defined as follows: typedef boost::function<void (boost::system::error_code, size_t)> asio_handler; Which is exactly the same but contains a wrapped handler at the front so I can privately intercept the handler at various points along the chain, and then have the private handler do arbitrary work then invoke the wrapped handler. I do this with boost::bind as follows asio_handler wrapped_handler = boost::bind( &async_service_write_network::write_data_handler, this, handler, _1, _2); socket_.async_send( buffer, boost::bind( wrapped_handler, boost::asio::placeholders::error, boost::asio::placeholders::bytes_transferred)); To explain the odd behavior, I've put a breakpoint in write_data_handler. Quick version if you don't feel like reading, the function arguments seem to be being corrupted either by boost::bind or boost::function. Long version, looking at the values of the arguments shows the following: error {m_val=23843184 m_cat=0x000000000000305d } boost::system::error_code m_val 23843184 int m_cat 0x000000000000305d const boost::system::error_category * boost::noncopyable_::noncopyable {...} boost::noncopyable_::noncopyable __vfptr CXX0030: Error: expression cannot be evaluated So I move one level up the callstack. This puts me in: template<class R, class T, class A1, class A2, class A3 BOOST_MEM_FN_CLASS_F> class BOOST_MEM_FN_NAME(mf3) { //Boost 1.39 mem_fn_template.hpp line 384 R operator()(T * p, A1 a1, A2 a2, A3 a3) const { BOOST_MEM_FN_RETURN (p->*f_)(a1, a2, a3); } } Examining a1, a2, and a3 shows that they are what they appear to be. Walking one more level up the callstack and this is no longer the case: template< class A1, class A2, class A3, class A4 > class list4: private storage4< A1, A2, A3, A4 > { //Bind.hpp line 450 template<class F, class A> void operator()(type<void>, F & f, A & a, int) { unwrapper<F>::unwrap(f, 0)(a[base_type::a1_], a[base_type::a2_], a[base_type::a3_], a[base_type::a4_]); } } Examining the contents of 'a', I see this: - a {...} boost::_bi::list2<boost::system::error_code &,unsigned __int64 &> & - boost::_bi::storage2<boost::system::error_code &,unsigned __int64 &> {a2_=12381 } boost::_bi::storage2<boost::system::error_code &,unsigned __int64 &> - boost::_bi::storage1<boost::system::error_code &> {a1_={...} } boost::_bi::storage1<boost::system::error_code &> - a1_ {m_val=0 m_cat=0x000000014000ac48 } boost::system::error_code & m_val 0 int + m_cat 0x000000014000ac48 system_category_const const boost::system::error_category * a2_ 12381 unsigned __int64 & Somehow this error code is becoming corrupted. It is clearly has an m_val of 0 here, and an m_cat of 0x14000ac48 here, and in the very next function on the call stack, it has an m_val of 23843184, and an m_cat of 0x305d. Am I missing something obvious or is there an actual boost/compiler bug going on here?

1 0

doc for is_lvalue_iterator?
by Neal Becker 29 Jan '10

29 Jan '10

I don't see any doc for is_lvalue_iterator (and related metafunctions)

2 1

type of iterator_facade::value_type
by Neal Becker 29 Jan '10

29 Jan '10

According to iterator_facade doc: typedef remove_const<Value>::type value_type; Why remove_const? This makes it hard to detect if the resulting iterator points to a const value. In order to further adapt such an iterator, I needed to use the reference type instead of the value type to detect constness: typename boost::is_const< typename boost::remove_reference< typename std::iterator_traits<BaseIterator>::reference >::type >::type,

3 2

Review Request: Creasing (Sequence Properties)
by Grant Erickson 28 Jan '10

28 Jan '10

The creasing algorithm templates define four template functions for determining the order properties of sequences, specifically: * Increasing * Decreasing * Strictly Increasing * Strictly Decreasing The implementation is a fairly trivial composition of the STL adjacent_find, not2 and {greater,less,greater_equal,less_equal}. For the purposes of sequence ordering validation, using these templates is more efficient and straightforward than creating a temporary, sorted version of some sequence and comparing it against the original sequence. Example: bool CheckPoints(const Points & inPoints) { const bool strictlyIncreasing = is_strictly_increasing(inPoints.begin(), inPoints.end()); if (!strictlyIncreasing) { cerr << "Points must be in increasing order with " "no duplicate values." << endl; } return strictlyIncreasing; } The review files are available in both Sandbox and Vault: Sandbox: boost/algorithm/creasing.hpp libs/algorithm/creasing/example/creasing_ex.cpp libs/algorithm/creasing/example/Jamfile libs/algorithm/creasing/test/creasing_test.cpp libs/algorithm/creasing/test/Jamfile.v2 Vault: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=creasin g.zip&directory=Algorithms Regards, Grant Erickson

8 23

[Boost.Thread]
by Andrew Chinkoff 28 Jan '10

28 Jan '10

Hi. There is a test program I would to be explained to me: *** BEGIN OF TEST PROGRAM *** #include <stdio.h> #include <boost/thread.hpp> #define USE_SPINLOCKS //#define USE_MUTEXES boost::thread th1; boost::thread th2; boost::mutex mutex; int global_int = 0; bool IsNotEven(int code) { boost::mutex::scoped_lock locker(mutex); bool ret = (code & 1); return ret; } void thread_func() { for(int i = 0; i < 1000000; ++i) { #ifdef USE_MUTEXES if(IsNotEven(global_int)) // (1) #elif defined USE_SPINLOCKS if(__sync_fetch_and_and(&global_int, 1)) // (2) #else ERROR__WRONG_COMPILED; #endif global_int+=9; else global_int+=1; } } int main() { th1 = boost::thread(&thread_func); th2 = boost::thread(&thread_func); th1.join(); th2.join(); printf("global_int = %d\n", global_int); return 0; } *** END OF TEST PROGRAM *** Results of test program: 1) Test program compiled with USE_SPINLOCKS. Outputs are always: "global_int = 10" "global_int = 10" "global_int = 10" 2) Test program compiled with USE_MUTEXES. Outputs differ from each other: "global_int = 10000008" "global_int = 10000000" "global_int = 9763210" Could you explain me why outputs produced with USE_SPINLOCKS compilation differ from USE_MUTEXES ones? And what is the difference between (1) and (2) lines? Best, Andrew. P.S.: I use guest Ubuntu-8.04 installed on VirtualBox. Host OS = Vista.

3 2

detecting a constructor with a specific signature
by Kenny Riddile 28 Jan '10

28 Jan '10

I'm trying to create a type trait to detect the presence of a constructor with a very specific signature. Types passed to this trait will *always* have a constructor of the form: T( const std::string& ); but some of them will have this constructor as well: T( const std::string&, Foo& ); // Second parameter will always be a Foo& I would like to create a type trait that returns true when the second constructor is present. I can't simply do: !is_convertible<std::string, T>::value since that will return false when the second constructor is present since all Ts are convertible from std::string. Is it possible to create such a trait?

6 14

Trunk testing broken (Python and Utility)
by K. Noel Belcourt 28 Jan '10

28 Jan '10

Hi, There's at least two separate problems in trunk. Missing files in the Python library. error: Unable to find file or target named error: 'union.cpp' error: referred from project at error: '../libs/python/test' Missing files in the Utility library, error: Unable to find file or target named error: 'noncopyable_adl_barrier.cpp' error: referred from project at error: '../libs/utility/test' -- Noel

2 1

Range-aware version of min and max
by Zachary Turner 28 Jan '10

28 Jan '10

I am often frustrated by the inability of std::min and std::max to deal with data types of different ranges. For example: boost::uint64_t big = 9876543210ULL; boost::uint32_t small = 12345; boost::uint32_t smallest = std::min(big, small); will generate a compiler warning about possible loss of data due to converting from boost::uint64_t to boost::uint32_t. Obviously such a scenario is impossible since by definition the result can be no larger than the maximum value of a uint32. Previously there was a discussion on the list about adding operators such as is_addable, is_multipliable, is_less_comparable, etc. Using such a class, one could re-write min and max as follows (I'm sure someone will come up with a problem with this, or a better implementation, but anyway the idea should be clear): namespace boost { template<class A, class B> struct min_result { typedef mpl::if_c<(integer_traits<A>::const_max < integer_traits<B>::const_max), A, B>::type type; }; template<class A, class B> struct max_result { typedef mpl::if_c<(integer_traits<A>::const_min > integer_traits<B>::const_min), A, B>::type type; }; template<class A, class B> min_result<A,B>::type min(const A& a, const B& b) { return static_cast<min_result<A,B>::type>((a < b) ? a : b); } template<class A, class B> max_result<A,B>::type max(const A& a, const B& b) { return static_cast<max_result<A,B>::type>((a > b) ? a : b); } I'm sure there's some implementation details I haven't considered, but is there any fundamental reason why an approach like this would be flawed or undesirable? Zach

4 6

Please stay on-topic (was: C++ and quality of software)
by David Abrahams 28 Jan '10

28 Jan '10

This discussion is really not relevant to Boost, is it? At Mon, 25 Jan 2010 14:28:34 -0800, Peter Foelsche wrote: > > > "Marshall Clow" <mclow.lists(a)gmail.com> wrote in message > news:D43C711F-03E0-4A3C-BE40-BA99BE379F30@gmail.com... > > > Exceptions > > ▶ We do not use C++ exceptions. > > > > Run-Time Type Information (RTTI) > > ▶ We do not use Run Time Type Information (RTTI). > > > I think this is an embarrasement for google. > Didn't they claim to hire only very good people? > I would not want to work under these conditions. > > If there is again some security hole due to a buffer overflow, > such an institution could claim, that software using fixed-sized-buffers > would not get their stamp of approval. > And that the customer should be looking and asking for this stamp of > approval when buying software. > > How many fixed sized buffers are in the main OSs? -- Dave Abrahams Meet me at BoostCon: http://www.boostcon.com BoostPro Computing http://www.boostpro.com

1 0

[Serialization] memory leak when serialising a map containing shared_ptrs
by richard bradley 28 Jan '10

28 Jan '10

I'm finding that Boost.Serialization is leaking memory when deserialising std::map<string,boost::shared_ptr<X>>. Maybe this is a sign that my data structures are too complicated? ;-) This wouldn't bother me that much, except that I'm also using Boost.Test, which gives lots of angry messages about leaked memory at the end of my tests (I'm using MSCRT). I've attached a simple test case which demonstrates this. Can anyone shed some light on what's going on here? Have I used any of the libraries incorrectly? Is there anything I can do to fix this? I'm using Visual Studio 2008, and boost 1.41.0 The output from the attached test looks like: =========== Running 1 test case... MyClass @3532504 with 1 children MyClass @3532960 with 1 children Detected memory leaks! Dumping objects -> {800} normal block at 0x0035EDE8, 1 bytes long. Data: < > CD Object dump complete. =========== I've also attached a stack trace which I got by breaking on the non-free'd memory allocation,using "--detect_memory_leak=800" Thanks very much, Rich

1 1

unzip .zip file and browse to compressed files
by Andrej van der Zee 28 Jan '10

28 Jan '10

Hi, I am looking for a way to uncompress a zip-file (which contains multiple files/dirs) and browse through the contents. Does boost provide support for the first part? I looked at iostreams with a zlib uncompressor, but as far as I can see it assumes a single zipped file. Thank you, Andrej

7 7