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

Re: [Boost-users] [boost] Maintenace Guidelines wiki page
by vicente.botet 23 Nov '08

23 Nov '08

----- Original Message ----- From: "Robert Ramey" <ramey(a)rrsd.com> To: <boost(a)lists.boost.org> Cc: <boost-users(a)lists.boost.org> Sent: Saturday, November 22, 2008 11:28 PM Subject: Re: [boost] [Boost-users] Maintenace Guidelines wiki page > > vicente.botet wrote: >> ----- Original Message ----- >> From: "Robert Ramey" <ramey(a)rrsd.com> >> To: <boost-users(a)lists.boost.org> >> Cc: <boost(a)lists.boost.org> >> Sent: Saturday, November 22, 2008 9:19 PM >> Subject: Re: [Boost-users] Maintenace Guidelines wiki page >> I really think that *we can* achieve this goal. > > I would say 'we COULD' achieve this goal - if there was a > true desire to do so. You don't belive that things COULD change? >>> Your "Maintainence Guidlines" presume a consensus >>> about what should be acceptable practice where no >>> such consensus actually exists. >> >> Which acceptable practice are you referring to for which there is no >> consensus? > > My view is that it is good practice to consider > breaking an interface should be considered a bug. Does your view accepts that exceptionally a well documented breaking change with a reasoable deprecated period could not be considered a bug? > The responses to the posting cited above, indicate > to me that there is no consensus to support > this view point. You are right, there was no consensus at all respect to this point. May be we can reach a consensus in other points that can make Boost more backward compatible if not completly backward compatible. Do you think that the deprecation of a feature should be considered as a bug? If not how long should a reasonable period be for you? <snip> ... >> Please could you participate in the elaboration of this guidelines, > > Basically, the guidelines are fine Thanks. > The guidelines for authors should be separated from those > for users. Yes, I could add an index by author, user, RM. Why not. > For users, "don't use "using" " could be part of a larger list > of suggestions for getting the most benefit from the libraries. I'm sure that you have think about it already. Could you share with us some of these suggestions? Thanks, Vicente

2 4

enable_if on operator type()
by Joel Falcou 23 Nov '08

23 Nov '08

How can I set up SFINAE using enable_if on method like struct foo { template<class T> operator T() { return T(1); } }; I want the operator T() to be ther only if T is arithemtic for example. TIA -- ___________________________________________ Joel Falcou - Assistant Professor PARALL Team - LRI - Universite Paris Sud XI Tel : (+33)1 69 15 66 35

3 3

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