- Boost - lists.boost.org

[Heaps] benchmarks
by Phil Endecott 13 Jun '11

13 Jun '11

Dear All, I have done some quick benchmarks; the code can be found here: http://chezphil.org/tmp/bench.tgz This is a "work queue", i.e. it's a queue of boost::function<void(void)> "work items" with float priorities. It's similar to a real application with fast (burst) fill and gradual drain; the pattern here is 10 pushes and 1 pop, repeated until all the work has been added, and then all of the work is popped in sequence. The priorities are essentially random, and there are 100 000 items in total. Currently my real application uses a std::multimap. I've compared that with a std::vector using std::push|pop_heap, std::priority_queue using std::vector and std::deque, and the proposed heap::priority_queue and heap::b_heap. The columns below are median-of-3 runtimes in seconds for: 1. 50 runs on a 32-bit 3 GHz AMD Athlon II Linux system, using g++ 4.4.4 -O4. 2. 10 runs on a 32-bit 1.2 GHz VIA C7-M Linux syste, using g++4.4.2 -O4. 3. 5 runs on a 1.2 GHz ARMv5 Linux system, using g++ 4.4.2 -O4. std::multimap 3.20 3.69 3.37 std::vector + std::push|pop_heap 2.35 3.36 2.71 std::priority_queue<vector> 2.58 3.48 2.84 std::priority_queue<deque> 4.27 5.77 3.72 heap::priority_queue 2.49 3.37 2.74 heap::b_heap 5.14 7.62 5.82 I was unable to try the proposed d_ary_heap because I couldn't find a working syntax for the arity template parameter - any ideas anyone? The 3 implementations based on std::vector perform similarly, as expected. I'm a bit surprised that my one is fastest, but the difference is small. Also as expected the version using multimap is slower, though maybe not by as much as I had expected. I was expecting the b_heap to be faster, but it is not; it is substantially slower. What is going on there? Does it all come down to size of data, cache size, etc? Ideally, an "improved" implementation like this would be able to fall back to the naive implementation in cases where it does not function any better. Or maybe I'm using it wrongly. My understanding is that the fibonacci, binomial and other heaps only improve things when other operations e.g. merging are needed - is that correct? Regards, Phil.

4 11

Is there any interest in a base class which prevents construction during the static initialization phase?
by Ben Robinson 13 Jun '11

13 Jun '11

Hello, Because the order of static initialization is undefined, numerous difficult to detect problems can arise when multiple objects are initialized during the static initialization phase. This base class would guarantee that a class will never be unintentionally constructed during static initialization. This is the same philosophy behind how boost::noncopyable guarantees that a class will never be unintentionally copied. Usage would appear as follows: #include <submission/nonstaticinitializable.hpp> #include <boost/noncopyable.hpp> namespace { class Foo : private submission::nonstaticinitializable, private boost::noncopyable { public: Foo() : nonstaticinitializable() {} }; // Foo } // unnamed namespace Foo fooThatWillAssert; // This instance asserts during static initialization int main() { nonstaticinitializable::enable_initialization(); // Indicates that static initialization is complete. Foo foo; // This instance initializes successfully after static initialization. return 0; } // main What does Boost think about submission::nonstaticinitializable (I chose the name to mirror noncopyable)? Thank you, Ben Robinson

3 2

Even more Boostcon videos
by Marshall Clow 12 Jun '11

12 Jun '11

Bojan (Thursday): http://blip.tv/boostcon/fast-numerical-computation-in-c-expression-template… Joel (Thursday): http://blip.tv/boostcon/practical-simd-acceleration-with-boost-simd-5261117 Matt (Thursday): http://blip.tv/boostcon/boost-generic-concepts-without-concepts-5262126 I will post a couple more over the weekend, then be on holiday for a couple weeks, then post the rest in early July. -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki

6 6

Last of the first batch of Boostcon videos
by Marshall Clow 12 Jun '11

12 Jun '11

Gordon (Thursday): http://blip.tv/boostcon/introducing-mpl-graph-5262812 Bryce (Friday): http://blip.tv/boostcon/ast-construction-with-the-universal-tree-5266608 I am looking into why Bartoz' Haskell preso is not showing up. You can download the mp4 directly here: http://blip.tv/file/get/Boostcon-HaskellThePseudocodeLanguageForCTemplateMe… but the conversion to H.264 seems to time out (I've tried several times) I'll be contacting blip.tv about this in the morning. -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki

1 0

[release][phoenix] Permission to merge to release
by Thomas Heller 12 Jun '11

12 Jun '11

Hi, I would like to ask for permission of merging to changesets i commited during the last week to trunk. The risks should be very minimal. The first change fixes a bug with MSVC 7.1 not being able to parse nested function types correctly. Thus it needs some help. The second change is a small fix to allow non-const and const references as function paramaters in bound functions. Both changes fix bugs that were only realised this week. The affected Changesets are: http://svn.boost.org/trac/boost/changeset/72485 and http://svn.boost.org/trac/boost/changeset/72548 I hope these changes get merged to release. Thanks, Thomas

2 1

[phoenix] Bind member functions with non-const reference parameters
by Sergiu Dotenco 12 Jun '11

12 Jun '11

Using phoenix bind with member functions that have non-const reference parameters results in compile errors. However, free functions with similar signature seem to be supported. This behavior is inconsistent, especially compared to existing bind incarnations. For instance: #include <boost/bind.hpp> #include <boost/lambda/bind.hpp> #include <boost/phoenix/phoenix.hpp> void foo(int&) { } struct Foo { void bar(int&) { } }; int main() { using boost::phoenix::placeholders::arg1; int i = 0; Foo f; boost::phoenix::bind(foo, arg1)(i); // works boost::lambda::bind(&Foo::bar, &f, boost::lambda::_1)(i); // works boost::bind(&Foo::bar, &f, _1)(i); // works boost::phoenix::bind(&Foo::bar, &f, arg1)(i); // compile error } Tested with VC10 and boost trunk (r72541).

2 1

[fusion] Serialization support
by Christian Holmquist 12 Jun '11

12 Jun '11

Hey all, Unless I'm mistaken, there's no support for serializing fusion sequences using Boost.Serialization. I had an hour over at work today and hacked together something.. It can be accessed from here: git@github.com:cholmquist/fusion-serialize.git I only tested it on MSVC-2005, didn't write any docs, but if there's interest I could do the additional work.. Unless there's something fundamentally flawed with my implementation.. I do wonder why this hasn't been added previously (?). Cheers, Christian

2 1

Re: [boost] Is Boost interested in the Boost-based Base64 library
by Denis Shevchenko 11 Jun '11

11 Jun '11

2011/6/10 Robert Ramey <ramey(a)rrsd.com> > I think you'd find it interesting to see how the serialization library does > it. > ../boost/archive/iterators/base64_from_binary > ../boost/archive/iterators/binary_from_base64 Yes, Robert. :-) I took theese iterators (and 'transform_width') and wrap them in one simple and ready-to-use solution. Simple and ready-to-use even for novices. I need a such solution, for this common task. And I definetly know many developers looking for such solution. Solution they can use immediately, without long studying the documentation. Just few lines of code: int main() { std::string text = "TEXT"; std::string encoded = boost::base64().encode( text ); std::string text_again = boost::base64().decode< std::string >( encoded ); } You think such (or similar) solution is not needed for Boost? Well, probably it is not needed, but I think it's useful. If not - I apologize for troubling. - Denis

4 5

Fwd: [Boost C++ Libraries] #4922: memory leak in boost::iostreams::detail::chain_impl::~chain_impl()
by Виктор Шугаев 11 Jun '11

11 Jun '11

Hi, more than a half year ago I found memory leak in boost.iostreams library. I wrote a patch and created a ticket (#4922). But it seems that nobody mantains this library. It is critical for my work. -- Thanks in advance, Victor -------- Исходное сообщение -------- Тема: [Boost C++ Libraries] #4922: memory leak in boost::iostreams::detail::chain_impl::~chain_impl() Дата: Thu, 02 Dec 2010 12:25:38 -0000 От: Boost C++ Libraries <noreply(a)lists.boost.org> Копия: boost-bugs(a)lists.boost.org #4922: memory leak in boost::iostreams::detail::chain_impl::~chain_impl() --------------------------------------+------------------------------------- Reporter: victor.shugaev@… | Owner: turkanis Type: Patches | Status: new Milestone: To Be Determined | Component: iostreams Version: Boost 1.45.0 | Severity: Problem Keywords: | --------------------------------------+------------------------------------- It appears that there are some cases when the ''chain_impl::close()'' ('''boost/iostreams/chain.hpp''') throws an exception. If it is invoked from {{{ ~chain_impl() { try { close(); reset(); } catch (...) { } } }}} the following ''reset()'' method won't be invoked and it results in memory leak because of there is a ''delete buf;'' invokation in the ''reset()''. Patch file is attached. Also I have managed to produce such a situation (example is attached). Below shows that the ''gzip_decompressor'' was constructed 4 times (1 time by default constructor and 3 times by copy constructor), but destroyed only 3 times. Destructor for object at 0x4e46b98 wasn't invoked. ---- $ valgrind ./leak_example[[BR]] ==18153== Memcheck, a memory error detector[[BR]] ==18153== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.[[BR]] ==18153== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info[[BR]] ==18153== Command: ./leak_example[[BR]] ==18153==[[BR]] '''gzip_decompressor has been constructed at: 0x7ff0007c0[[BR]] gzip_decompressor has been copy constructed from: 0x7ff0007c0 at: 0x7ff000450[[BR]] gzip_decompressor has been copy constructed from: 0x7ff000450 at: 0x7ff000320[[BR]] gzip_decompressor has been copy constructed from: 0x7ff000320 at: 0x4e46b98[[BR]] gzip_decompressor has been destroyed at: 0x7ff000320[[BR]] gzip_decompressor has been destroyed at: 0x7ff000450[[BR]] gzip_decompressor has been destroyed at: 0x7ff0007c0'''[[BR]] ==18153==[[BR]] ==18153== HEAP SUMMARY:[[BR]] ==18153== in use at exit: 51,493 bytes in 13 blocks[[BR]] ==18153== total heap usage: 28 allocs, 15 frees, 69,665 bytes allocated[[BR]] ==18153==[[BR]] ==18153== LEAK SUMMARY:[[BR]] ==18153== '''definitely lost: 216 bytes in 1 blocks'''[[BR]] ==18153== indirectly lost: 51,277 bytes in 12 blocks[[BR]] ==18153== possibly lost: 0 bytes in 0 blocks[[BR]] ==18153== still reachable: 0 bytes in 0 blocks[[BR]] ==18153== suppressed: 0 bytes in 0 blocks[[BR]] ==18153== Rerun with --leak-check=full to see details of leaked memory[[BR]] ==18153==[[BR]] ==18153== For counts of detected and suppressed errors, rerun with: -v[[BR]] ==18153== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 4)[[BR]] -- Ticket URL:<https://svn.boost.org/trac/boost/ticket/4922> Boost C++ Libraries<http://www.boost.org/> Boost provides free peer-reviewed portable C++ source libraries.

2 1

[thread] Fix compilation with GCC-MinGW64 for 1.47.0?
by Mikko Vainio 11 Jun '11

11 Jun '11

Hi, The trunk version of Boost.Thread compiles with GCC-MinGW64 but the release branch does not[1]. Is the trunk version going to be merged to release for 1.47.0? Cheers, Mikko [1] Here's the error log: gcc.compile.c++ bin.v2/libs/thread/build/gcc-mingw-4.6.1/release/link-static/target-os-windows/threadapi-win32/threading-multi/win32/thread.o "/usr/bin/x86_64-w64-mingw32-g++" -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -mthreads -Wno-long-long -DBOOST_ALL_NO_LIB=1 -DBOOST_THREAD_BUILD_LIB=1 -DNDEBUG -I"." -c -o "bin.v2/libs/thread/build/gcc-mingw-4.6.1/release/link-static/target-os-windows/threadapi-win32/threading-multi/win32/thread.o" "libs/thread/src/win32/thread.cpp" In file included from ./boost/thread/win32/basic_timed_mutex.hpp:14:0, from ./boost/thread/win32/mutex.hpp:8, from ./boost/thread/mutex.hpp:14, from ./boost/thread/detail/thread.hpp:13, from ./boost/thread/thread.hpp:22, from libs/thread/src/win32/thread.cpp:10: ./boost/thread/win32/interlocked_read.hpp: In function 'void* boost::detail::interlocked_read_acquire(void* volatile*)': ./boost/thread/win32/interlocked_read.hpp:63:20: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] ./boost/thread/win32/interlocked_read.hpp: In function 'void boost::detail::interlocked_write_release(void* volatile*, void*)': ./boost/thread/win32/interlocked_read.hpp:71:13: error: cast from 'void*' to 'long int' loses precision [-fpermissive] ./boost/thread/win32/interlocked_read.hpp:71:13: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] In file included from ./boost/thread/win32/mutex.hpp:8:0, from ./boost/thread/mutex.hpp:14, from ./boost/thread/detail/thread.hpp:13, from ./boost/thread/thread.hpp:22, from libs/thread/src/win32/thread.cpp:10: ./boost/thread/win32/basic_timed_mutex.hpp: In member function 'void boost::detail::basic_timed_mutex::destroy()': ./boost/thread/win32/basic_timed_mutex.hpp:46:39: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] In file included from ./boost/thread/win32/mutex.hpp:8:0, from ./boost/thread/mutex.hpp:14, from ./boost/thread/detail/thread.hpp:13, from ./boost/thread/thread.hpp:22, from libs/thread/src/win32/thread.cpp:10: ./boost/thread/win32/basic_timed_mutex.hpp: In member function 'void* boost::detail::basic_timed_mutex::get_event()': ./boost/thread/win32/basic_timed_mutex.hpp:183:43: error: cast from 'void*' to 'long int' loses precision [-fpermissive] ./boost/thread/win32/basic_timed_mutex.hpp:183:43: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] In file included from ./boost/thread/shared_mutex.hpp:14:0, from ./boost/thread/detail/thread_group.hpp:9, from ./boost/thread/thread.hpp:24, from libs/thread/src/win32/thread.cpp:10: ./boost/thread/win32/shared_mutex.hpp: In member function 'T boost::shared_mutex::interlocked_compare_exchange(T*, T, T) [with T = boost::shared_mutex::state_data]': ./boost/thread/win32/shared_mutex.hpp:110:103: instantiated from here ./boost/thread/win32/shared_mutex.hpp:50:99: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] ./boost/thread/win32/shared_mutex.hpp:50:99: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] ./boost/thread/win32/shared_mutex.hpp:51:52: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] ./boost/thread/win32/shared_mutex.hpp:51:52: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] ...failed gcc.compile.c++ bin.v2/libs/thread/build/gcc-mingw-4.6.1/release/link-static/target-os-windows/threadapi-win32/threading-multi/win32/thread.o... ...skipped <pbin.v2/libs/thread/build/gcc-mingw-4.6.1/release/link-static/target-os-windows/threadapi-win32/threading-multi>libboost_thread_win32-mgw46-mt-1_47.a(clean) for lack of <pbin.v2/libs/thread/build/gcc-mingw-4.6.1/release/link-static/target-os-windows/threadapi-win32/threading-multi>win32/thread.o... ...skipped <pbin.v2/libs/thread/build/gcc-mingw-4.6.1/release/link-static/target-os-windows/threadapi-win32/threading-multi>libboost_thread_win32-mgw46-mt-1_47.a for lack of <pbin.v2/libs/thread/build/gcc-mingw-4.6.1/release/link-static/target-os-windows/threadapi-win32/threading-multi>win32/thread.o... ...skipped <pstage/lib>libboost_thread_win32-mgw46-mt-1_47.a for lack of <pbin.v2/libs/thread/build/gcc-mingw-4.6.1/release/link-static/target-os-windows/threadapi-win32/threading-multi>libboost_thread_win32-mgw46-mt-1_47.a... ...failed updating 1 target...

1 0