- Boost - lists.boost.org

Adding an option to set the name of a boost::thread
by david.hagood＠gmail.com 07 Nov '12

07 Nov '12

Has any thought been given to allowing a name to be set on a boost::thread, such that (if the underlying implementation supports it) that name would show up in things like top and ps? In Linux, you can name a thread via the prctl() call and it will show up in top - dandy for debugging which of the bazillion threads in my app has decided to suck up all the CPU. I don't know if Windows supports such a call, and IMHO it would be acceptable if the call did nothing in such a case. Ideally, I'd want to see it as a property, something like: void boost::thread::set_name(std::string name) std::string boost::thread::get_name() const;

6 11

[algorithm] Knuth-Morris-Pratt Search docs overly terse
by Jeff Flinn 07 Nov '12

07 Nov '12

I'm not sure if this is intentional but: http://www.boost.org/doc/libs/1_52_0/libs/algorithm/doc/html/the_boost_algo… contains only: Overview The header file 'knuth_morris_pratt.hpp' contains an an implementation of the Knuth-Morris-Pratt algorithm for searching sequences of values. I've created Ticket #7656. Jeff

1 0

[functional] Interested in can_be_called<F, Sig> metafunction?
by TONGARI 07 Nov '12

07 Nov '12

Hi there, I've used this metafunction for some time, and it just fitted my need. Recently, I make up my mind to complete it, willing to put it in public. Synopsis -------------- can_be_called<F, Sig> F Any callable type to test, even member-function ptr. Sig The desired calling signature, function-type only. Example ------------- struct X; struct F { void operator()(); }; can_be_called<void(int), void(char)>::type // mpl::true_ can_be_called<int(), void()>::type // mpl::true_, return val can always be discarded can_be_called<int(), int&()>::type // mpl::false_, cannot return as reference can_be_called<void(int&), void(int)>::type // mpl::false_, cannot accept rvalue can_be_called<void(), void(*)()>::type // compile error, "void(*)()" not a function-type can_be_called<F, void()>::type // mpl::true_ can_be_called<F const, void()>::type // mpl::false_, F::operator() is non-const can_be_called<void(X::*)(), void()>::type // mpl::true_, only the signature part is concerned can_be_called<void(X::*)(), void(X*)>::type // mpl::false_, implicit 'this' arg not accounted Repository ---------------- https://github.com/jamboree/boost.functional test files provided, compile well on g++ 4.7.1 & clang 3.2 No docs are written (yet), if you're interested, please let me know and I'll prepare for review or something... Comments are welcome :)

6 19

[1.52] PDF Documentation build available
by John Maddock 07 Nov '12

07 Nov '12

The PDF build of Boost docs is now available for 1.52 from: https://sourceforge.net/projects/boost/files/boost-docs/1.52.0/ John.

1 0

[qvm] scalar_cast
by Nikolay Mladenov 07 Nov '12

07 Nov '12

Hi Emil, I am trying qvm in a small project that uses complex numbers and have expressions of the kind : cv3 = c1*rv3_1 + c2*rv3_2 (the v3's are vectors, the c's are complex and the r's are real). I wrote it as : cv3 = scalar_cast<complex>(rv3_1)*c1 + scalar_cast<complex>(rv3_2)*c2; but this seems to invoke 6 complex constructors (unnecessarily) I have not tested to see if the constructors will be optimized away, but it seems to me that if : v_traits<vector_scalar_cast_>::scalar_type == complex , bit v_traits<vector_scalar_cast_>::r/ir return real the expression will compile and no complex constructors will be invoked. It seems to me that there is a need for another kind of scalar_cast that just adapts the v_traits<>:scalar_type but leaves the r() and ir() unchanged Another question I have is if there is a reason why vector*scalar works but scalar*vector does not? Thanks in advance, Nikolay PS I can send patches if you'd like.

2 3

[release][1.52.0] Release Notes
by Daniel James 06 Nov '12

06 Nov '12

Hello everyone, We're coming up to the beta release, so it's time to put together the release notes (although please don't feel you need to wait for me to start). As always you can send them to me, or if you want update them yourself in subversion. The files are at: https://svn.boost.org/svn/boost/website/public_html/live/feed/history/ The actual site won't get updated until I run the update script. You can see the release notes so far at: http://www.boost.org/users/history/version_1_52_0.html As usual, they're not finished yet, and some of the links might not work as the 1.52 documentation won't be uploaded until after the beta is released. thanks, Daniel

9 22

[clang] Windows toolset support?
by Beman Dawes 06 Nov '12

06 Nov '12

Cygwin has been shipping clang for six months or so. Has anyone gotten the cygwin/clang distribution (or any other clang distribution) to build boost? What toolset did you use? What does your user-config.jam file look like? Do you run bjam/b2 from the Windows command line or the bash command line? Thanks, --Beman

7 16

make_shared_array
by Peter Dimov 06 Nov '12

06 Nov '12

Hello, Glen Fernandes has kindly contributed an implementation of make_shared_array and allocate_shared_array. These are like make_shared and allocate_shared, except that they take a size_t argument N and allocate an array of N elements. Glen has made the functions return a shared_ptr, mostly because they are non-intrusive and it's not possible to return a shared_array without changes to shared_ptr and shared_array. But we can make such changes when we put the functions in Boost. So the question is, should we? It makes almost no sense to have a function called make_shared_array that does not, in fact, make a shared_array. On the other hand, Glen posits that some people may prefer to use shared_ptr instead of shared_array in their code for various reasons, one of which is that shared_array's default constructor can throw. Opinions?

9 40

hierarchy_tree container
by Morgan Freeberg 06 Nov '12

06 Nov '12

Ready to assess the level of interest and look into the possibility of a preliminary submission on my container library. I needed something to organize objects of type T, into a simple tree with parent-child relationships, which could then be filtered and listed. Also needed the container to maintain a "current add" position if you will, much like an output file stream, so I could feed tree structure data into it, for example as when reading from XML. I have the logic for this nicely separated into a header that seems to meet all the Boost coding guidelines, although I know a peer review process would likely yield helpful improvements that aren't immediately obvious to me. The doc file I prepared goes into much greater detail how this all works...would there be interest in looking into such a thing?

2 1

[type_traits] possible regression on is_function trait
by Vicente J. Botet Escriba 06 Nov '12

06 Nov '12

Hi, I don't know if this is a regression on Boost.TypeTraits or if I'm using incorrectly the is_function trait. John, could you confirm there is a bug in is_function? Best, Vicente Test output: Sandia-darwin-4.4 - thread - async__async_p / darwin-4.4 Rev 81191 / Mon, 5 Nov 2012 06:30:00 +0000 *Report Time: *Mon, 5 Nov 2012 14:19:58 +0000 Compile [2012-11-05 07:50:44 UTC]: fail "/opt/local/bin/g++-mp-4.4" -ftemplate-depth-128 -O0 -fno-inline -Wall -pedantic -g -dynamic -gdwarf-2 -fexceptions -fPIC -Wextra -Wno-long-long -fpermissive -pedantic -DBOOST_ALL_NO_LIB=1 -DBOOST_CHRONO_DYN_LINK=1 -DBOOST_SYSTEM_DYN_LINK=1 -DBOOST_SYSTEM_NO_DEPRECATED -DBOOST_THREAD_BUILD_DLL=1 -DBOOST_THREAD_POSIX -DBOOST_THREAD_THROW_IF_PRECONDITION_NOT_SATISFIED -DBOOST_THREAD_USE_DLL=1 -I".." -c -o "/Volumes/scratch/kbelco/boost/results/boost/bin.v2/libs/thread/test/async__async_p.test/darwin-4.4/debug/threading-multi/sync/futures/async/async_pass.o" "../libs/thread/test/sync/futures/async/async_pass.cpp" In file included from ../boost/type_traits/is_convertible.hpp:28, from ../boost/thread/detail/move.hpp:13, from ../boost/thread/future.hpp:20, from ../libs/thread/test/sync/futures/async/async_pass.cpp:28: ../boost/type_traits/is_function.hpp: In instantiation of 'boost::detail::is_function_chooser<false>::result_<boost::rv<boost::rv<boost::packaged_task<int()> > >&>': ../boost/type_traits/is_function.hpp:60: instantiated from 'boost::detail::is_function_impl<boost::rv<boost::rv<boost::packaged_task<int()> > >&>' ../boost/type_traits/is_function.hpp:102: instantiated from 'boost::is_function<boost::rv<boost::rv<boost::packaged_task<int()> > >&>' ../boost/type_traits/is_convertible.hpp:354: instantiated from 'const bool boost::detail::is_convertible_impl<boost::rv<boost::packaged_task<int()> >&, boost::rv<boost::rv<boost::packaged_task<int()> > >&>::value' ../boost/type_traits/is_convertible.hpp:480: instantiated from 'boost::is_convertible<boost::rv<boost::packaged_task<int()> >&, boost::rv<boost::rv<boost::packaged_task<int()> > >&>' ../boost/thread/future.hpp:2717: instantiated from 'boost::future<T> boost::async(boost::launch, R (*)()) [with R = int]' ../libs/thread/test/sync/futures/async/async_pass.cpp:117: instantiated from here ../boost/type_traits/is_function.hpp:52: error: forming pointer to reference type 'boost::rv<boost::rv<boost::packaged_task<int()> > >&'

3 5