November 2008 - Boost-users - lists.preview.boost.org

[phoenix] [math] operator<< confusion
by Christian Henning 12 Nov '08

12 Nov '08

Hi there, the following code creates an compiler error since the operator<< is ambiguous. #include <boost/math/distributions/gamma.hpp> #include <boost/spirit/include/phoenix_bind.hpp> #include <boost/spirit/include/phoenix_operator.hpp> #include <iostream> #include <vector> struct point { double _prob; double _x; }; int _tmain(int argc, _TCHAR* argv[]) { using namespace boost::phoenix; std::cout << bind( &point::_prob, point() ); return 0; } The error is: 1>.\test.cpp(25) : error C2593: 'operator <<' is ambiguous 1> c:\boost\boost/spirit/home/phoenix/operator/io.hpp(21): could be 'boost::phoenix::actor<Eval> boost::phoenix::operator <<<std::ostream,boost::phoenix::composite<EvalPolicy,EvalTuple>>(T0 &,const boost::phoenix::actor<boost::phoenix::composite<EvalPolicy,EvalTuple>> &)' [found using argument-dependent lookup] [snip] 1> c:\boost\boost/fusion/sequence/io/out.hpp(36): or 'std::basic_ostream<_Elem,_Traits> &boost::fusion::operators::operator <<<boost::phoenix::actor<Eval>>(std::ostream &,const Sequence &)' [found using argument-dependent lookup] [snip] I'm using Visual Studio 2005. Regards, Christian

3 3

[phoenix] binding member_functions
by Christian Henning 12 Nov '08

12 Nov '08

Hi there, I think there are some problems with binding functions if the class has a const and a non-const version of the same member. Please consider the following code: #include <boost/spirit/include/phoenix_algorithm.hpp> #include <boost/spirit/include/phoenix_bind.hpp> #include <boost/spirit/include/phoenix_container.hpp> #include <boost/spirit/include/phoenix_core.hpp> #include <boost/spirit/include/phoenix_function.hpp> #include <boost/spirit/include/phoenix_fusion.hpp> #include <boost/spirit/include/phoenix_object.hpp> #include <boost/spirit/include/phoenix_operator.hpp> #include <boost/spirit/include/phoenix_scope.hpp> #include <boost/spirit/include/phoenix_statement.hpp> #include <boost/spirit/include/phoenix_stl.hpp> #include <algorithm> #include <iostream> #include <fstream> #include <vector> using namespace std; using namespace boost::phoenix; using namespace boost::phoenix::arg_names; struct point { point() {} point( double prob, double x ) : _prob( prob ), _x( x ) {} double& prob() { return _prob; } double& x() { return _x; } const double& prob() const { return _prob; } const double& x() const { return _x; } void set_prob( const double& prob ) { _prob = prob; } void set_x ( const double& x ) { _x = x; } private: double _prob; double _x; }; int _tmain(int argc, _TCHAR* argv[]) { typedef vector< point > distribution_t; distribution_t d( 1 ); const distribution_t& dr = d; // works typedef const double& ( point::* pp_t )() const; double sum_prob = std::accumulate( dr.begin() , dr.end() , 0.0 , arg1 + bind( static_cast<pp_t>(&point::prob), arg2 ) ); // doesn't work sum_prob = std::accumulate( dr.begin() , dr.end() , 0.0 , arg1 + bind( &point::prob, arg2 ) ); return 0; } Only when I explicitly state which member phoenix is swallowing it. I don't think that should be required. Steven. When do you think you will apply the patches? Thanks, Christian

2 3

[config] policy for setting BOOST_HAS_THREADS?
by JOAQUIN M. LOPEZ MUÑOZ 11 Nov '08

11 Nov '08

Hello, What is the policy by which BOOST_HAS_THREADS gets defined or not? I used to think this macro is somehow affected by the selection of a single-threaded or multithreaded runtime library as done in bjam with threading=single and threading=multi, but some experiments in Linux suggest that this is not the case, as discussed in the following thread: http://lists.boost.org/boost-build/2008/11/20641.php Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

5 11

brandes centrality example
by Matthew Galati 11 Nov '08

11 Nov '08

Newbie... Does anyone have a small hand example of using http://www.boost.org/doc/libs/1_37_0/libs/graph/doc/betweenness_centrality.… on a weighted graph? I am having trouble creating one. Thanks, Matt

1 0

[Proto] terminal class acting as Pod
by Joel Falcou 11 Nov '08

11 Nov '08

I remember seeing a example code where terminal where treated as POD thanks to some macro. basically, if i have a foo_expr in a foo_domain, how can I build a special terminal class which acts as a POD if foo_expr is generated using pod_generator so I can write stuff like : foo x = { ... soem value }; where foo is a terminal extending foo_expr -- ___________________________________________ Joel Falcou - Assistant Professor PARALL Team - LRI - Universite Paris Sud XI Tel : (+33)1 69 15 66 35

2 4

Fwd: [signals2][review] little REVIEW
by Stjepan Rajko 11 Nov '08

11 Nov '08

I am forwarding the review below: ---------- Forwarded message ---------- From: <Jean-Christophe.BENOIST(a)fr.thalesgroup.com> Date: Tue, Nov 4, 2008 at 8:43 AM Subject: [signals2][review] The review of the signals2 library (formerly t hread_safe_signals) begins today, Nov 1st : little REVIEW To: stjepan.rajko(a)gmail.com (first of all please excuse my weak english, I am not a native english speaker) I am a regular user of boost::signals, so I am very interested by signals2. I'll review from a user standpoint. * On the documentation : - I am surprised to find very little information or rationale about multi-threading in documentation. We know the library is now "thread safe" but we don't know exactly what it means. There is only one MT use case (just) detailed in "tutorial" : what happens when a thread disconnect a slot from a signal, while another thread calls it. But there are another interesting MT use cases : - what if 2 threads simultaneously calls the same signal ? How to mutex slots in this case ? Are slots automatically excluded by an hidden mutex ? - What if a thread adds a slot to a signal while another calls it ? Is the slot added after signal call ? There should be tutorials and explanations for these cases, IMO. - About rationale : why is there special signals2::mutex ? May we use boost::thread::mutex for mutex template ? What are advantages/drawbacks of choosing signals2::mutex or boost::thread::mutex ? - Use of "postconstructible" or "predestructible" classes is rather obscure, and should be tutorialized / better documented. * On interface : - Very close from original signals interface : no particular comment. * On test suite / test cases : - I cannot see any MT test case (from the documentation, in "acceptance tests" section at least). It's rather surprising. I cannot imagine there is no test case for MT (calling a signal while disconnecting slot etc..). In particular, I'd whish to see if this library is robust in a multi-core environment and run test cases in this environment (I know cases where a library is perfectly thread safe on mono-core, even hyperthreading, but fails on multi-core). At least, there should be a rationale explaining why this library should be robust in a multi-core environment (especially with a proprietary signals2::mutex). * Final statement : All in all, I think this library is very close to be accepted as a Boost library, but without MT test cases and MT documentation, I can't give a total agreement for now. I have little doubt this library is MT tested and robust, even in a multi-core environment, but I have no real clue to assert it. Feel free to ask me further details. Best regards Jean-Christophe BENOIST Software Engineer THALES Communications France

1 0

ICC and _syn_lock bug again
by Joel Falcou 11 Nov '08

11 Nov '08

As shown here : http://lists.boost.org/Archives/boost/2008/06/138322.php There *was* a bug with intel Compiler and shared_ptr using the __sync_lock intrinsic. It has been fixed on ICC 9.x but today I tried to sue this with latest ICC 10.1.018 on ubuntu linux and got the very same error than in the original topic. Is there something I miss ? -- ___________________________________________ Joel Falcou - Assistant Professor PARALL Team - LRI - Universite Paris Sud XI Tel : (+33)1 69 15 66 35

2 4

boost 1.37, tr1 and gcc 4.x
by Acsoft Acsoft 11 Nov '08

11 Nov '08

Hello, I am using boost 1.37 and gcc 4.3.2. I am getting a very nasty error when I mix up boost headers and tr1 headers in one compilation unit. Here is my code: #include <functional> using namespace std; using namespace tr1; #include <boost/program_options.hpp> using namespace boost; void blub() { } function<void()> i1(blub); //error: expected constructor, destructor, or type conversion before '<' token std::function<void()> i2(blub); //Compiles fine tr1::function<void()> i3(blub); //Compiles fine boost::function<void()> i4(blub); //Compiles fine I did add the 'boost/tr1/tr1/' folder to the very beginning of global include list. What is wrong?

2 1

Asio acceptor : Multiple client connections on single port
by Amit Sonawane 11 Nov '08

11 Nov '08

I have a acceptor server which listens to various connections from clients. It creates one server object per client connection. I need the clients to connect to only one IP port of the server. Following the examples in boost I do this: (sample code) boost::asio::ip::tcp::acceptor m_acceptor; boost::asio::ip::tcp::resolver resolver(iosvr); boost::asio::ip::tcp::resolver::query query(host.c_str(),boost::lexical_cast<std::string>(port)); boost::asio::ip::tcp::endpoint endpoint = *resolver.resolve(query); m_acceptor.open(endpoint.protocol()); m_acceptor.set_option(boost::asio::socket_base::reuse_address(true)); if( bNoDelay ) m_acceptor.set_option(boost::asio::ip::tcp::no_delay(true)); else m_acceptor.set_option(boost::asio::ip::tcp::no_delay(false)); m_acceptor.bind(endpoint); m_acceptor.listen(); At runtime the server listens to one and only one client connection, the others are not connected at all. What is wrong in the implementation? OR How do I make acceptor to accept multiple connections on the same server port? Any help is highly appreciated. Esta mensagem pode conter informação confidencial e/ou privilegiada. Se você não for o destinatário ou a pessoa autorizada a receber esta mensagem, não deverá utilizar, copiar, alterar, divulgar a informação nela contida ou tomar qualquer ação baseada nessas informações. Se você recebeu esta mensagem por engano, por favor avise imediatamente o remetente, respondendo o e-mail e em seguida apague-o. Agradecemos sua cooperação. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, change, take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation.

1 0

boost::unordered_map thread safety
by Kenny Riddile 11 Nov '08

11 Nov '08

This is a simple question, but a quick search didn't turn up any answers. Is it safe for multiple readers to access a boost::unordered_map concurrently? -Kenny Riddile

4 4