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

Boost.Asio, An invalid argument was supplied.
by stefys 23 Nov '08

23 Nov '08

Hello. I am trying to write a simple server, and I am using an asynchronous acceptor to get clients: acceptor.async_accept(crtclient->getSocket(), boost::bind(&Server::gotClient, this, boost::asio::placeholders::error)); As soon as this is executed, my Server::gotClient gets called with ec.message()="An invalid argument was supplied." Apparently the problem is that I am supplying an invalid socket with crtClient->getSocket(), but I can't understand how can this be. crtClient is a boost::shared_ptr<Client>. class Client { ... public: Client (boost::asio::io_service &ioserv, Server &server) : socket_(ioserv), ... {} ... boost::asio::ip::tcp::socket &getSocket () { return socket_; } ... private: boost::asio::ip::tcp::socket socket_; ... }; What could be wrong? Am I constructing socket incorrectly with socket_(ioserv)? Because if I construct it with socket_(ioserv, boost::asio::ip::tcp::v4()), I get the error "Already open" in ec.message(), rather than "An invalid argument was supplied".

2 1

[Property Tree] Compilation issue with Boost 1.37.0 Beta 1 issue
by Johan Råde 23 Nov '08

23 Nov '08

The property tree version in the trunk works with Boost 1.36 but not with 1.37 Beta 1. When I compile the following code istream is; ptree pt; read_xml(is, pt); with MSVS 9.0 I get the following error: 3>C:\Boost\include\boost-1_37\boost/iterator/iterator_adaptor.hpp(230) : error C2027: use of undefined type 'boost::STATIC_ASSERTION_FAILURE<x>' 3> with 3> [ 3> x=false 3> ] 3> C:\Boost\include\boost-1_37\boost/iterator/iterator_adaptor.hpp(335) : see reference to function template instantiation 'void boost::detail::iterator_adaptor_assert_traversal<boost::forward_traversal_tag,boost::random_access_traversal_tag>(void)' being compiled 3> C:\Boost\include\boost-1_37\boost/iterator/iterator_adaptor.hpp(334) : while compiling class template member function 'void boost::iterator_adaptor<Derived,Base,Value,Traversal>::advance(__w64 int)' 3> with 3> [ 3> Derived=boost::spirit::position_iterator<std::_Vector_const_iterator<Ch,std::allocator<char>>>, 3> Base=std::_Vector_const_iterator<Ch,std::allocator<char>>, 3> Value=const char, 3> Traversal=boost::forward_traversal_tag 3> ] 3> C:\Boost\include\boost-1_37\boost/spirit/home/classic/iterator/position_iterator.hpp(156) : see reference to class template instantiation 'boost::iterator_adaptor<Derived,Base,Value,Traversal>' being compiled 3> with 3> [ 3> Derived=boost::spirit::position_iterator<std::_Vector_const_iterator<Ch,std::allocator<char>>>, 3> Base=std::_Vector_const_iterator<Ch,std::allocator<char>>, 3> Value=const char, 3> Traversal=boost::forward_traversal_tag 3> ] 3> C:\Program Files\Boost\Unofficial\boost/property_tree/detail/xml_parser_read_spirit.hpp(709) : see reference to class template instantiation 'boost::spirit::position_iterator<ForwardIteratorT>' being compiled 3> with 3> [ 3> ForwardIteratorT=std::_Vector_const_iterator<Ch,std::allocator<char>> 3> ] 3> C:\Program Files\Boost\Unofficial\boost/property_tree/xml_parser.hpp(45) : see reference to function template instantiation 'void boost::property_tree::xml_parser::read_xml_internal<Ptree>(std::basic_istream<_Elem,_Traits> &,Ptree &,int,const std::string &)' being compiled 3> with 3> [ 3> Ptree=boost::property_tree::ptree, 3> _Elem=char, 3> _Traits=std::char_traits<char> 3> ] 3> .\GeneAuxParser.cpp(33) : see reference to function template instantiation 'void boost::property_tree::xml_parser::read_xml<boost::property_tree::ptree>(std::basic_istream<_Elem,_Traits> &,Ptree &,int)' being compiled 3> with 3> [ 3> _Elem=char, 3> _Traits=std::char_traits<char>, 3> Ptree=boost::property_tree::ptree 3> ] --Johan Råde

2 3

Re: [Boost-users] [boost] Maintenace Guidelines wiki page
by Vicente Botet 23 Nov '08

23 Nov '08

----- Original Message ----- From: "Henrik Sundberg" <storangen(a)gmail.com> To: <boost(a)lists.boost.org> Sent: Sunday, November 23, 2008 3:13 PM Subject: Re: [boost] [Boost-users] Maintenace Guidelines wiki page > > On Sun, Nov 23, 2008 at 2:37 PM, vicente.botet <vicente.botet(a)wanadoo.fr> wrote: >> Do you know if the author can change himself the permision on his own SVN files? > > Subversion is not meant to be used that way, as I understand it. Locks > would give the effect you describe, but they aren't meant to be used > for this. Oh, as a last resort he could change the permission in its own SVN copy. <snip> > I think you say that files that has been copied to tags, shall not be > edited in trunk. That seems like hindering development. I see no real > difference between bugs/changes in test code and bugs/changes in C++ > code. Ok, I see now your concern. Of course if there is a bug on the test file it must be modified, but it is a good practice to let them unchanged when there is no bug in. >> I hope that it is clear that I don't want to impose any rule to the authors, release manager or users. Guidelines that are used could incite other to use them. If some of the guidelines seems no useful at all, I have no problem to remove them from this Maintenance Guidelines. > > I think you're doing a very good thing by writing this guideline. I > believe in guidelines too. I actually believe in some rules as well. Me too.

1 0

Patch for push_relabel_max_flow
by Tim Keitt 23 Nov '08

23 Nov '08

I am working with custom graph classes in the Graph library. These classes construct out edge iterators on the fly. This caused problems with push_relabel_max_flow as it uses repeated calls to out_edges to retrieve the end iterator. I've modified the code to store iterator pairs, rather than repeatedly call out_edges. Here's the diff: 124c124 < current(num_vertices(g_), out_edges(*vertices(g_).first, g_).second), --- > current(num_vertices(g_), out_edges(*vertices(g_).first, g_)), 152c152 < current[u] = out_edges(u, g).first; --- > current[u] = out_edges(u, g); 243c243 < current[v] = out_edges(v, g).first; --- > current[v] = out_edges(v, g); 265c265 < for (ai = current[u], ai_end = out_edges(u, g).second; --- > for (ai = current[u].first, ai_end = current[u].second; 294c294 < current[u] = ai; --- > current[u].first = ai; 353c353 < current[u] = min_edge_iter; --- > current[u].first = min_edge_iter; 447c447 < current[u] = out_edges(u, g).first; --- > current[u] = out_edges(u, g); 458,459c458,459 < for (; current[u] != out_edges(u, g).second; ++current[u]) { < edge_descriptor a = *current[u]; --- > for (; current[u].first != current[u].second; ++current[u].first) { > edge_descriptor a = *current[u].first; 472c472 < delta = min BOOST_PREVENT_MACRO_SUBSTITUTION(delta, residual_capacity[*current[v]]); --- > delta = min BOOST_PREVENT_MACRO_SUBSTITUTION(delta, residual_capacity[*current[v].first]); 476c476 < v = target(*current[v], g); --- > v = target(*current[v].first, g); 481c481 < a = *current[v]; --- > a = *current[v].first; 491,492c491,492 < for (v = target(*current[u], g); v != u; v = target(a, g)){ < a = *current[v]; --- > for (v = target(*current[u].first, g); v != u; v = target(a, g)){ > a = *current[v].first; 495c495 < color[target(*current[v], g)] = ColorTraits::white(); --- > color[target(*current[v].first, g)] = ColorTraits::white(); 502c502 < ++current[u]; --- > ++current[u].first; 509c509 < if (current[u] == out_edges(u, g).second) { --- > if (current[u].first == current[u].second) { 524c524 < ++current[u]; --- > ++current[u].first; 635c635 < std::vector< out_edge_iterator > current; --- > std::vector< std::pair<out_edge_iterator, out_edge_iterator> > current; -- Timothy H. Keitt http://www.keittlab.org/

1 0

Random: Using random generators with runtime parameters
by Hans Mull 23 Nov '08

23 Nov '08

Hi! How can I use random generators with multiple parameters such as linear_congruential with parameters that are only known at runtime? Thanks in advance, Hans

3 4

MultiPassInputIterator concept
by Tim Keitt 22 Nov '08

22 Nov '08

I have a question about the requirements of the MultiPassInputIterator concept as used in the Boost Graph Library. Does the ++first_iter == ++second_iter requirement hold across calls to out_edges(vertex, g)? Or put another way, does out_edges always have to return an iterator with same ordering of returned edges? The difference is between: graph_traits<graph>::out_edge_iterator i = out_edges(vertex, g); graph_traits<graph>::out_edge_iterator j = i; ++i == ++j; // clearly required, but sufficient? and graph_traits<graph>::out_edge_iterator i = out_edges(vertex, g); graph_traits<graph>::out_edge_iterator j = out_edges(vertex, g); ++i == ++j; // also required? Strangely enough, I have an application where the second case is (currently) not guaranteed (its a custom graph class where the out_edge_iterator is constructed on-the-fly). THK -- Timothy H. Keitt http://www.keittlab.org/

3 2

[Regex] subexpressions
by Carsten Witzel 22 Nov '08

22 Nov '08

Hi, I'm using the Regex library for the first time with Visual Studio 2008. I've created a simple win32 console project, which works fine. The code is ------------------------------------- const char *pattern = "^(\\w*)\\s*=\\s*(\\w*).*"; const char *text = "Key = Value; Comment"; boost::regex re(pattern); boost::cmatch match; std::cout << pattern << std::endl; std::cout << text << std::endl; if (regex_match(text, match, re)) { std::cout << "--> " << match.size() << std::endl; for (int i = 0; i < match.size(); ++i) { std::cout << i << ": " << match[i] << std::endl; } } ------------------------------------- And the output is as expected: -------------------------------------- ^(\w*)\s*=\s*(\w*).* Key = Value; Comment --> 3 0: Key = Value; Comment 1: Key 2: Value -------------------------------------- However, I've tried to use the same code with the C/C++-API of a commercial software, and here I get the following output: -------------------------------------- ^(\w*)\s*=\s*(\w*).* Key = Value; Comment --> 3 - 0: Key = Value; Comment - 1: Key = Value; Comment - 2: Value; Comment -------------------------------------- Does anybody have an idea what's wrong here? Unfortunately, I'm not allowed to post any header files, so I need some hints where to look for a solution by myself. Thanks for any help! Regards Carsten Witzel

5 11

Boost.Function and Boost.Bind
by Yang Zhang 22 Nov '08

22 Nov '08

I have the following simple test case: #include <boost/bind.hpp> #include <boost/function.hpp> #include <iostream> using namespace boost; using namespace std; void show(int x) { cout << x << endl; } void twice(function0<void> f) { f(); f(); } int main() { // This works... function<void()> f = bind(show, 0); bind(twice, f)(); // ...but this does not compile. // bind(twice, bind(show, 0))(); return 0; } When uncommenting the problematic line and attempting to build, I get: $ g++ -Wall -o boost_function{,.cc} /opt/armed/include/boost/bind.hpp: In member function ‘void boost::_bi::list1<A1>::operator()(boost::_bi::type<void>, F&, A&, int) [with F = void (*)(boost::function0<void, std::allocator<boost::function_base> >), A = boost::_bi::list0, A1 = boost::_bi::bind_t<void, void (*)(int), boost::_bi::list1<boost::_bi::value<int> > >]’: /opt/armed/include/boost/bind/bind_template.hpp:20: instantiated from ‘typename boost::_bi::result_traits<R, F>::type boost::_bi::bind_t<R, F, L>::operator()() [with R = void, F = void (*)(boost::function0<void, std::allocator<boost::function_base> >), L = boost::_bi::list1<boost::_bi::bind_t<void, void (*)(int), boost::_bi::list1<boost::_bi::value<int> > > >]’ boost_function.cc:13: instantiated from here /opt/armed/include/boost/bind.hpp:232: error: conversion from ‘void’ to non-scalar type ‘boost::function0<void, std::allocator<boost::function_base> >’ requested Why can't I put the two on the same line? (I also tried using template<typename T> void twice(T f) { f(); f() }, but that didn't work either.) Thanks in advance for any tips. -- Yang Zhang http://www.mit.edu/~y_z/

4 5

[regex] segfault from construction
by Andrew Troschinetz 22 Nov '08

22 Nov '08

Hello all, I've got what I suspect is a relatively unique problem that's resulting in a segfault whenever I try to construct a boost::regex. First some machine information: Red Hat Enterprise Linux Server release 5.1 (Tikanga) Linux 2.6.18-53.el5, SMP, x86_64 gcc 4.1.2 20070626 (Red Hat 4.1.2-14) boost 1.33.1-10 Here's a small example that shows the problem: #include <boost/algorithm/string/regex.hpp> #include <iostream> #include <string> using namespace std; int main() { string input ("test test1 test2 test3"); string pattern ("\\btest\\b"); erase_regex (input, boost::regex (pattern)); cout << input << endl; // expecting " test1 test2 test3" return 0; } Compile flags (and this is getting to the heart of the problem, I think): -g -m32 -malign-double -O3 -Wall -lboost_regex Put all the above together in a bag, shake it up, and you get this segfault: 0x08066beb in boost::re_detail::basic_regex_parser<char, boost::regex_traits<char, boost::cpp_regex_traits<char> > >::parse_extended (this=0xffde311c) at /usr/include/boost/regex/v4/basic_regex_parser.hpp:235 235 switch*this->m_traits.syntax_type(*m_position)) (gdb) print m_position $1 = 0x0 (gdb) bt #0 0x08066beb in boost::re_detail::basic_regex_parser<char, boost::regex_traits<char, boost::cpp_regex_traits<char> > >::parse_extended at /usr/include/boost/regex/v4/basic_regex_parser.hpp:235 #1 0xf7f9e364 in boost ::re_detail::basic_regex_parser<char, boost::regex_traits<char, boost::cpp_regex_traits<char> > >::parse () from /usr/lib/libboost_regex.so.2 #2 0xf7fa0eba in boost::basic_regex<char, boost::regex_traits<char, boost::cpp_regex_traits<char> > >::do_assign () from /usr/lib/ libboost_regex.so.2 #3 0x08050789 in main () at /usr/include/boost/regex/v4/ basic_regex.hpp:254 So the immediate culprit is a dereferencing-null problem. Interestingly, the problem goes away at -O, -O1, and -O2. Or -O3 but without -malign-double. I was wondering if this is a known problem, and if anyone else who's hand is forced to compile with -malign-double has seen this problem and been able to work around it? -- Andrew Troschinetz Applied Research Laboratories

4 4

Boost.Test with a static library
by Moritz Beber 22 Nov '08

22 Nov '08

Hello everyone, after prying for any hints in the documentation and reading frustrating mails in the archives for a while now, I get the feeling that this is a very confusing topic. My aim is to use a static library of boost.test because I need to compile it a lot and the waiting time when using the header is just frustrating. So I added to the "Jamfile.v2" in "libs/test/build" under "requirements" the following line: <define>BOOST_TEST_ALTERNATIVE_INIT_API=1 Then I used boost.build and apart from a few warnings like: ./boost/test/detail/config.hpp:85:1: warning: "BOOST_TEST_ALTERNATIVE_INIT_API" redefined <command-line>: warning: this is the location of the previous definition everything seemed alright. So I'm assuming I now have a static library with this macro defined so it should use the alternative initialiser. Then I tried the following code, which I mostly copied from the documentation, except for adding two macros: #define BOOST_TEST_NO_LIB #define BOOST_TEST_ALTERNATIVE_INIT_API #define BOOST_TEST_MODULE example #include <boost/test/unit_test.hpp> BOOST_AUTO_TEST_SUITE( test_suite1 ) BOOST_AUTO_TEST_CASE( test_case1 ) { BOOST_WARN( sizeof(int) < 4 ); } BOOST_AUTO_TEST_CASE( test_case2 ) { BOOST_REQUIRE_EQUAL( 1, 2 ); BOOST_FAIL( "Should never reach this line" ); } BOOST_AUTO_TEST_SUITE_END() BOOST_AUTO_TEST_SUITE( test_suite2 ) BOOST_AUTO_TEST_CASE( test_case3 ) { BOOST_CHECK( true ); } BOOST_AUTO_TEST_CASE( test_case4 ) { BOOST_CHECK( false ); } BOOST_AUTO_TEST_SUITE_END() When I try to compile, however, I get the following error: /home/engineer/libs/boost/lib/libboost_unit_test_framework-gcc43-mt-1_37.a(unit_test_main.o): In function `main': unit_test_main.cpp:(.text+0x2229): undefined reference to `init_unit_test()' collect2: ld returned 1 exit status Which I thought the macro BOOST_TEST_MODULE would take care of. I also tried using the BOOST_TEST_MAIN and took out the BOOST_TEST_NO_LIB. Nothing made a change to the compiler error. Can anyone help? Or give me a link to some proper documentation of how to resolve this issue? Thanks, Moritz

3 5