- Boost - lists.boost.org

phoenix for_each and std::cout
by Sandeep Gupta 23 Mar '09

23 Mar '09

Hi, I am trying to use phoenix::for_each to print each element of iterator range. Would appreciate if any clarification as to why statements 1 and 2 are giving compile errors. Thanks sandeep //-------------code snippet int x; counting_iterator<int> first(0), last(10); iterator_range<counting_iterator<int> > ir(first, last); phoenix::for_each(ir, std::cout<<x<<' ')(); //stmt 1 ; compile error phoenix::for_each(ir, std::cout<<arg1<<' ')(); //stmt 2; compile error

1 0

How to submit bjam patches?
by Steven Solie 22 Mar '09

22 Mar '09

How do I go about submitting patches for bjam? Thanks, --Steven

3 2

Re: [boost] [Smart Ptr][Bind] Implementaion of Weak Callback Function
by Artyom 22 Mar '09

22 Mar '09

> weak_ptr< A > p; > > bind(&A::foo, throw_if_invalid(p)); > bind(&A::foo, ignore_if_invalid(p)); > bind(&A::foo, call_if_invalid(p, bar)); // bar I think this is little bit problematic, because proxy weak_ptr_caller should know the signature of A::foo to provide correct "R operator()(args...)" Maybe, additional policy for weak_fn would be better void A::foo(int); function<void(int)> bar; bind(weak_fn(&A::foo,p),_1); // default ignore bind(weak_fn(&A::foo,p,throw_on_invalid()),_1); bind(weak_fn(&A::foo,p,bar),_1); // call bar on invalid This would not require changes in bind and also weak_fn would be useful without bind as well. Like function<void(int)> foobar=weak_fn(&A::foo,p); It would be simple to update weak_fn to add policy Artyom

2 1

[circular buffer] logic behind set_capacity vs rset_capacity?
by Ross Levine 22 Mar '09

22 Mar '09

I was using Boost.Circular_buffer for the first time today, and noticed that the set_capacity and rset_capacity methods did the opposite of what I expect; namely, set_capacity will clip elements from the back and rset_capacity from the front, despite the fact that insertion using push_back will overwrite elements from the front. Is there any rationale for this operation?

3 2

puzzle for gcc gurus
by Robert Ramey 22 Mar '09

22 Mar '09

I'm trying use gdb under cygwin to debug one of the tests in the serialization library. I've done the before but only with static linking. This time, the failure only occurs when using the serialization library as a shared library. So I want to trap/trace inside the boost_serialization DLL. Using the cygwin bash shell, I get the following. $ set | grep LD LD_LIBRARY_PATH=C:/BoostRelease/bin.v2/libs/serialization/build/gcc-3.4.4/debug OLDPWD=/cygdrive/c/boostrelease Robert Ramey@rrsd01 /cygdrive/c/boostrelease/libs/serialization/test $ cat t.g file C:/BoostRelease/bin.v2/libs/serialization/test/test_diamond_text_archive.te st/gcc-3.4.4/debug/test_diamond_text_archive.exe sharedlibrary C:/BoostRelease/bin.v2/libs/serialization/build/gcc-3.4.4/debug/bo ost_serialization-gcc34-d-1_39.dll Robert Ramey@rrsd01 /cygdrive/c/boostrelease/libs/serialization/test $ gdb -x t.g GNU gdb 6.8.0.20080328-cvs (cygwin-special) Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i686-pc-cygwin". (gdb) r Starting program: /cygdrive/c/BoostRelease/bin.v2/libs/serialization/test/test_d iamond_text_archive.test/gcc-3.4.4/debug/test_diamond_text_archive.exe [New thread 3952.0xb10] gdb: unknown target exception 0xc0000135 at 0x7c964ed1 Program exited with code 030000000465. You can't do that without a process to debug. (gdb) (gdb) l main 169 int test_main(int argc, char * argv[]); 170 171 #include <boost/serialization/singleton.hpp> 172 173 int 174 main(int argc, char * argv[]){ 175 176 boost::serialization::singleton_module::lock(); 177 178 BOOST_TRY{ (gdb) Things crash immediately. I believe that the exception 0xc0000135 at 0x7c964ed1 refers to the inability to load some required DLL. Note that I can list the source code of the mainline program so things do seem to get loaded. I realize that his might be off topic - but I'm sort of desparate. Any help appreciated. Robert Ramey

2 3

[Smart Ptr][Bind] Implementaion of Weak Callback Function "weak_fn"
by Artyom 22 Mar '09

22 Mar '09

Hello, Today boost::bind allows to use shared_ptr to ensure that when the function is called the object exists: shared_ptr<bar> bar_ptr; function<void()> foo; foo=bind(&bar::slot,bar_ptr) Now even if we call bar_ptr.reset() the object is still owned by foo. But in some cases this is not good enough. This may create cyclic dependecies if A has shared_ptr to B and gives it a callback to A cyclic dependecy is created, so sometimes it would be useful to be able to provide weak bind function that is called iff the object exists -- that uses weak_ptr insteas of shared one. I has written a small draft of boost::weak_fn template<T> boost::weak_fn(void (T::*p)(...), weak_ptr<T> ptr) That creates such callback, it can be used with boost::bind similary to mem_fn: class foo { void bar(int x); }; Like: function<void(int x,int y)> f2=bind(weak_fn(&foo::bar,bar_ptr),_1+_2); function<void(int x)> f1=weak_fn(&foo::bar,bar_ptr); function<void()> f1=bind(weak_fn(&foo::bar,bar_ptr),0); The code availible from: http://art-blog.no-ip.info/files/weak_fn.tar.gz It is very initial implementation that gives functions from 0 to 3 parameters. - I just want to be sure if this is correct direction? - Comments on implementaions? Can it be done better? - Do I miss something? Thanks, Artyom

4 3

Re: [boost] [Smart Ptr][Bind] Implementaion of Weak Callback Function
by Artyom 22 Mar '09

22 Mar '09

> foo = bind( &bar::slot, bind( > &weak_ptr<bar>::lock, weak_ptr<bar>( > bar_ptr ) ) ); > Such solution may work if you would write void bar::slot() { if(!this) return; // or if(!this) throw something(); } But I this is just a hack. More then that, throwing is not good idea because generally I do not want this situation be treated as a error. > However, one of those binds must be persisting the smart > pointer > somewhere, because calling foo always has an effect for me, > where I > would expect it to segfault after the shared_ptr is reset, > since > lock() would return a null shared_ptr. You might be able to > see the > problem though, and get where you want to be. Such "second" bind should return a "void" function that does nothing, that what I solve in weak_fn. Actually the code of weak_fn is quite simple (when using variadic templates, otherwise it is just many copies of same code for 0, 1 and N parameters). Suggestions? Comments? Artyom > > HTH, > Christopher > _______________________________________________ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

[gsoc]
by Matt 22 Mar '09

22 Mar '09

Hello, All I am Matthew Chandler, and I am looking to help out for the Google summer of code. I've looked through the ideas page and am interested in working on the Devector container. -Matt

2 1

[C++0x] The cpp0x branch has been merged into trunk
by Beman Dawes 21 Mar '09

21 Mar '09

The cpp0x branch has been merged into trunk, enabling a bunch of BOOST_NO_* macros for C++0x feature tests. This should have no impact on existing code, so be sure to let me know if it causes any problems. --Beman

7 19

[asio] possible multi-threaded bug with async_write_some()
by Brian and Victoria 21 Mar '09

21 Mar '09

I'm running asio (boost 1.38) multi-threaded, and noticed that on a context switch between threads, my handler for async_write_some() will sometimes get invoked with no data transferred. My handler would call async_write_some() again if there was remaining data, but this caused (most of) the data to get sent twice since there appears to still be a call to the handler pending in the work queue. I'm not sure if this behavior is a bug or not, but the solution was to check for 0 data transferred and exit the handler if so. -Brian

1 1