- Boost - lists.boost.org

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

enable_shared_from_this::weak_from_this() request
by Marat Abrarov 11 Jun '11

11 Jun '11

Hi, boost users and experts. I often use boost::enable_shared_from_this. I know - it contains boost::weak_ptr, which is initiated in the details of boost::shared_ptr's constructor. Also sometimes I need function weak_from_this() at the classes derived from boost::enable_shared_from_this. I currently use something like: ... class my_class : public boost::enable_shared_from_this<my_class> , private boost::noncopyable { ...somewhere in my_class details... private: typedef my_class this_type; typedef boost::weak_ptr<this_type> this_type_weak_ptr; this_type_weak_ptr weak_from_this() { return this_type_weak_ptr(shared_from_this()); } }; // my_class ... But as I know restoring shared_ptr from weak_ptr (done in shared_from_this()) is quite expensive. So my_class::weak_from_this() does unnecessary work instead of just copy internal weak_ptr stored in enable_shared_from_this. So the question is - why there is no weak_from_this() member function in boost::enable_shared_from_this class? May be it would be useful to add such member function? Regards, Marat Abrarov.

1 0

[heap] A few questions
by Andrew Hundt 10 Jun '11

10 Jun '11

I was looking through the Boost.Heap documentation, and I came up with a couple questions: 1) Is it possible to iterate through the heap in order of priority with an iterator? 2) What advantages to the increase() and decrease() functions provide? I also have a few suggestions for improving the documentation: In http://tim.klingt.org/boost_heap/heap/concepts.html the note: boost.heap implements priority queues as max-heaps. While many textbooks and papers are formulated for min-heaps. Using max-heaps is consistent with the STL heap functions, though. would be better written as: boost.heap implements priority queues as max-heaps to be consistent with the STL heap functions. This is in contrast with the typical textbook design, which uses min-heaps. http://tim.klingt.org/boost_heap/heap/data_structures.html Can you provide runtime complexity constraints for each of these data structures? Particularly if the mutable version has different performance from the standard version of each. spelling: For a low arity, the h[e]ight of the heap is larger improved wording: In analogy to d-ary heaps, boost-heaps also provides an mutable version at the cost of an indirection. would be better as: The b_heap_mutable<http://tim.klingt.org/boost_heap/boost/heap/d_ary_heap_mutable.html> class stores the values inside a std::list in order to achieve mutability. You mentioned: | please note, that you *have* to call update before modifying any other node. This should be made more explicit in the documentation Overall this library looks extremely useful. Good work! Cheers! Andrew Hundt

4 7