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

[Function] default arguments, member func vs. free func
by Mike Lundy 04 Nov '08

04 Nov '08

I came across a difference in behavior for Boost.Function between g++ 4.2 and 4.3, and I was wondering whether my usage was incorrect. I'm using default parameters in much the same way as the sample test.cc below. It compiles on 4.2, and does not on 4.3. I think I can see why perhaps it shouldn't have worked, but I'm just looking for a security blanket. If my usage is wrong, it might be worth a mention in the docs, since (to me) either answer is non-intuitive. g++-4.2 4.2.4 (4.2.4-3ubuntu4) g++-4.3 4.3.2 (4.3.2-1ubuntu11) boost 1.35 (1.35.0-8ubuntu1) cat << EOF > test.cc #include <iostream> #include <boost/function.hpp> struct add1 { int operator()(int x, int y = 1) const { return x + y; } }; int add2(int x, int y = 1) { return x + y; } int main() { boost::function <int (int x)> adder1 = add1(); boost::function <int (int x)> adder2 = add2; // compile error here std::cout << adder1(1) << adder2(1) << std::endl; return 0; } EOF mike@hyperion:~> g++-4.2 -Wall -Wextra test.cc -o test && ./test 22 mike@hyperion:~> g++-4.3 -Wall -Wextra test.cc -o test && ./test /usr/include/boost/function/function_template.hpp: In static member function 'static R boost::detail::function::function_invoker1<FunctionPtr, R, T0>::invoke(boost::detail::function::function_buffer&, T0) [with FunctionPtr = int (*)(int, int), R = int, T0 = int]': /usr/include/boost/function/function_template.hpp:787: instantiated from 'void boost::function1<R, T0, Allocator>::assign_to(const Functor&) [with Functor = int (*)(int, int), R = int, T0 = int, Allocator = std::allocator<void>]' /usr/include/boost/function/function_template.hpp:624: instantiated from 'boost::function1<R, T0, Allocator>::function1(Functor, typename boost::enable_if_c<boost::type_traits::ice_not::value, int>::type) [with Functor = int (*)(int, int), R = int, T0 = int, Allocator = std::allocator<void>]' /usr/include/boost/function/function_template.hpp:886: instantiated from 'boost::function<R ()(T0), Allocator>::function(Functor, typename boost::enable_if_c<boost::type_traits::ice_not::value, int>::type) [with Functor = int (*)(int, int), R = int, T0 = int, Allocator = std::allocator<void>]' test.cc:13: instantiated from here /usr/include/boost/function/function_template.hpp:100: error: too few arguments to function

1 0

[BGL] how to call Dijkstra
by Sandeep Gupta 04 Nov '08

04 Nov '08

Hi Andrew, THanks for the help..it works now... -sandeep

1 0

units and existing APIs
by Joseph Winston III 03 Nov '08

03 Nov '08

I would like to use boost::units in a new application that must interface to existing APIs that do not provide templated interfaces. What is the easiest way to use these existing functions that minimizes the copying of data from raw C pointers to a container that holds a specific type of boost::units? Thanks, Jody

3 2

Trouble with vector and matrix multiplication
by Philip Goh 03 Nov '08

03 Nov '08

Hi, I'm trying to multiply a vector by a matrix. Pretty simple, but I'm running into problems as the compiler is complaining about the overloaded operator * Here's some code that produces the error. ------------------------------------------------------------------ #include <boost/numeric/ublas/matrix.hpp> #include <boost/numeric/ublas/io.hpp> #include <boost/numeric/ublas/vector.hpp> typedef boost::numeric::ublas::matrix<double> boost_matrix; typedef boost::numeric::ublas::vector<double> boost_vector; int _tmain(int argc, _TCHAR* argv[]) { boost_matrix mat(5,5); boost_vector v1(5), v2(5); v1 = v2 * mat; return 0; } ---------------------------------------------------------------------------------- The error message I'm getting is : "Error 1 error C2666: 'boost::numeric::ublas::operator *' : 2 overloads have similar conversions boost_matrix_multiplication.cpp 18" I'm using Visual Studio 2008 Express and boost 1.36. This looks like a very simple problem, and any help would be greatly appreciated. Phil

2 1

[signals2][review] Fwd: Signals2 Review
by Stjepan Rajko 03 Nov '08

03 Nov '08

I am forwarding the following review submitted by Jesse Williamson: ---------- Forwarded message ---------- From: Jesse Williamson <jesse(a)mind.net> Date: Sun, Nov 2, 2008 at 5:09 PM Subject: Signals2 Review To: Stjepan Rajko <stjepan.rajko(a)gmail.com> * Do you think the library should be accepted as a Boost library? Yes. * What is your evaluation of the design? Note: I only read the tutorial, and wrote my own examples as I followed along. I think this is a very nicely designed library! I like the collector interface, and the general library behavior. Note: I was going to suggest some syntactic sugar with operator overloading, but when I tried it I quickly discovered that there's a problem in determining the proper return type for something like + or +=. It isn't really needed anyway-- and, I also have since discovered that the documentation already addresses this! * What is your evaluation of the implementation? I did not examine the implementation. For the most part, things worked as I expected after reading the tutorial examples. * What is your evaluation of the documentation? Good! The tutorials are on the whole very good, and I came through them feeling like I had a good working understanding of the library. I have a few suggestions and perhaps issues, which I discuss below in more detail. I would like to see more explit examples in a few of the tutorial examples, especially those concerning connection management. * What is your evaluation of the potential usefulness of the library? Event patterns show up in many applications, and a thread-safe version of the long-standing Boost::Signals library would surely greatly extend its usefulness. * Did you try to use the library? With what compiler? Did you have any problems? gcc 4.2.1 on AMD x86-64, I had no problems using the library, although I did run into a compiler issue with the examples as written in the tutorial, it was fixed in the packaged example file. * How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I spent a day reading the tutorial and working through the examples. I had few problems writing my own versions of the tutorial programs, and feel like I came out of them with a good working understanding of the library's use. I believe I worked through all of them. * Are you knowledgeable about the problem domain? Kinda. I've used a fair number of event-driven frameworks, but beyond peeking at it, I've never used the Signals library before. My review is from evaluating the tutorial only. --------------- Some comments and thoughts, mostly written as I went through the tutorial. Documentation: ------------- * Perhaps you should point out the location of the FAQ earlier in the synopsis. I found it at the end, but may not have if I'd been in a hurry. * ToC and main page: The first thing that I notice is that I can infer from the original copyright notice that Douglas Gregor's library appears to have been stable for a really long time! Nice work!! * Introduction: Is it really important that we know Signals2 was formerly known as thread_safe_signals? You might consider pointing this out in the introduction text itself, instead, since it becomes redundant and is more-or-less superfluous information. The introduction gave me a clear idea of what the library is for, and the general abstraction it presents. I've worked with a fair number of event-based systems, and so it already sounds like familiar territory and I felt like I got a good sense of what Signals2 is for. Tutorial: -------- * Do we need "beginner", "intermediate", and "advanced"? I'm not sure why I'm cautioned that the tutorial is not meant to be read linearly, especially since the tutorials typically (and expectedly) progressed from basic to advanced material. Readers tend to pick and choose what they need anyway, and it seemed more visually cluttering than anything. I just followed everything linerally, and did not seem to have many problems. On the other hand, if this is essentially how the documentation has been structured for years, it's unlikely there's any need to change it. * Compiler versions and preferred-form table: I wonder if, instead of maintaining a list of which compilers do support the preferred syntax, it would not be easier to just maintain a list of those which do not support it, especially since it looks to be that only broken compilers don't. * Slot ordering examples: In the intermediate example of ordering slots, I wasn't able to change the order my signal was displayed after reading the material a few times. It always came last, no matter what order I added it in. I was able to do it, but it was by using the numeric ordering I'd learned in the beginner section. In my own test program, I tried: // ... GoodMorning gm; HelloWorld hello; Newline nl; sig.connect(gm); // confused as to why this always comes last sig.connect(2, nl); sig.connect(1, hello); sig.connect(0, gm); // ok, clear why this goes first // ... ...after playing around a while, I understood what the intermediate example was explaining, and it made sense. Maybe it's a pitfall of reading the tutorial out of the recommended order, but the beginner section didn't really seem to explain to me clearly that sig.connect() is actually adding groups and not "individual" signals. (Or, perhaps I'm still confused about how it works? :>) The section where we deal with return values just feels to me like a logical extension of the behavior the beginner tutorial has just discussed, rather than as a seperate tutorial with significantly more advanced behavior-- it seemed natural to want to return values next. * Blocking tutorial: I got a suprise playing with the blocking section when an assertion was triggered: // ... boost::signals2::signal<string (string a, string b)> sig; boost::signals2::connection c = sig.connect(&revcatgoat2); if(c.connected()) cout << *sig("a", "b") << endl; // ... { boost::signals2::shared_connection_block block(c); if(!c.blocked()) { cerr << "something is wrong\n"; throw; } cout << "You shouldn't see this: "; cout << *sig("a", "b"); // SUPRISE abort()! cout << endl; } // ...continue, expecting output when block goes out of scope... ...The tutorial didn't say anything about that happening. Perhaps I was misusing the library..? It worked fine when I checked for c.blocked() again before trying to call sig(). * "Disconnecting Equivilent Slots" example: I didn't feel that the example program for "disconnecting equivilent slots" fully illustrated the library concept. Perhaps that should be made more clear in the example by disconnecting via a pointer to the same function, instead of by using the same identifier that was used to connect(), something like: // ... boost::signals2::signal<int (int a, int b), aggregate_values< vector<int> > > sig; sig.connect(&add); sig.connect(&half); // results of half() seen: { vector<int> results(sig(5, 5)); dump(results); } // Disconnect half() by using an equivilent slot: int (*ptr_to_half)(int a, int b) = half; sig.disconnect(ptr_to_half); // results of half() not seen: { vector<int> results(sig(5, 5)); dump(results); } // ... * Connection Management example: I got a small (but pleasant) suprise when I tried out the connection management: { messageSignal deliver; messageReciever *mr = new messageReciever("message reciever one"); deliver.connect(boost::bind(&messageReciever::show, mr, _1)); { messageReciever *mr2 = new messageReciever("message reciever two"); deliver.connect(boost::bind(&messageReciever::show, mr2, _1)); deliver("message"); } deliver("message"); // SUPRISE: no problem } ...after reading the tutorial section, I had expected the second deliver() call to segfault, but instead it worked nicely. I'm not really going to complain about this, but I'd expected something differently from the tutorial's explanation that it was expected to segfault. It seems reasonable to expect this behavior, given the explaination about shared_ptr<>. Indeed, calling delete explicitly produced mangled output. Perhaps extending the example to show an explosion and how track() gets around it would be worthwhile. Also, maybe it would be nice if the signal_type typedef could be included closer to its actual use in the example? * Automatic Connection Example Problem: There seems to be no get() for NewsMessageArea in the automatic connection management example, and the signature with the application operator appears to probably not be correct. I had to use: // Note second parameter to slot_type ctor: deliver.connect(messageSignal::slot_type(&messageReciever::show, mr2, _1).track(mr2)); * Compiler complaint in "Document-View" example: button.doOnClick(&printCoordinates); ...requires: button.doOnClick(&Button::printCoordinates); ...the example included in the package did not have this issue. (I implemented my own in working through the tutorial.) * Comment on "Passing Slots" example: In the "passing slots" example, Button::f() never appears to get bound. A complete example would be nice. ...on the whole, I enjoyed this tutorial and feel like I can star working with the Slots2 libray! Thanks.

2 1

Member-Function to String conversion.
by Siegfried Kettlitz 03 Nov '08

03 Nov '08

Hello, I'm searching for a good solution for the following problem of making a pair of a string and a pointer to a member function. --- struct foo1 { int bar1( int ); void bar2( ); }; int main() { someobject.set_string( &foo1::bar1, "foobar1" ); someobject.set_string( &foo1::bar2, "foobar2" ); string = someobject.get_string( &foo1::bar1 ); pointer = someobject.get_pointer( "foobar2" ); } --- The conversion of the string to the function pointer is possible, when the function pointer is stored in some wrapper like mem_fn. But the other way is more complicated. Since the member function pointers are each types of their own, the pointers cannot be compared and therefore cannot directly be stored in some list. Mem_fn also doesn't seem to do this job. Using some compiler dependent extension also isn't useful. Using templated overloads does work for the conversion of member function pointer to string - to some extent: --- global template for setting the string: template< typename foobar1_pointer_type, foobar1_pointer_type foobar1_pointer> std::string overloaded_template() { return "foobar1"; } local call for getting the string: string = overloaded_template<foobar1_pointer_type, &foo1::bar1>() --- But this solution has way too much overhead and doesn't provide the call in the form of "someobject.get_string(pointer)" because of the typed template parameter. It is possible to use macros to make it look better and type less, but macros are ugly and don't solve the problem properly. So does anyone know a good way to store a string-pointer-pair, so that it can be accessed by the corresponding member function pointer? The solution should work with GCC4.4 for now and can use the c++0x-extensions since i use them anyways. Kind regards, Siegfried Kettlitz

2 9

[phoenix] accumulate with data member binding
by Christian Henning 03 Nov '08

03 Nov '08

Hi there, the following snippet doesn't compile which surprises me a little. Could somebody tell what's wrong? #include <algorithm> #include <vector> #include <numeric> #include <boost/spirit/include/phoenix_core.hpp> #include <boost/spirit/include/phoenix_operator.hpp> #include <boost/spirit/include/phoenix_bind.hpp> using namespace boost::phoenix; using namespace boost::phoenix::arg_names; using namespace std; struct point { double _prob; double _x; }; int _tmain(int argc, _TCHAR* argv[]) { std::vector< point > d; double sum_prob = std::accumulate( d.begin() , d.end() , 0.0 , bind( &point::_prob, arg1 ) ); return 0; } I'm using Visual Studio 2005. This is the error I'm getting: error C2296: '.*' : illegal, left operand has type 'double' [snip] Thanks ahead, Christian

5 9

Re: [Boost-users] [Graph] newbie to graph (Andrew Sutton) (Phillip Jones)
by Lior Weizman 03 Nov '08

03 Nov '08

Hello, Applying the suggestion below: > > > struct Node { > std::string name; > long index; > boost::default_color_type color; > long distance; > graph_traits<Graph>::edge_descriptor predecessor; > }; > > struct Arc { > long capacity; > long residual; > graph_traits<Graph>::edge_descriptor rev; > }; > > With the following call: > > flow = kolmogorov_max_flow(g, s, t, > capacity_map(get(&Arc::capacity, g)). > residual_capacity_map(get(&Arc::residual, g)). > reverse_edge_map(get(&Arc::rev, g)). > predecessor_map(get(&Node::predecessor, g)). > color_map(get(&Node::color, g)). > distance_map(get(&Node::distance, g)). > vertex_index_map(get(&Node::index, g)) > ); > > Resulted with many errors.But I think I found the right way. The following code compiles without errors or warnings: ----------------CODE---------------------------- #include <boost/config.hpp> #include <iostream> #include <string> #include <boost/graph/kolmogorov_max_flow.hpp> #include <boost/graph/adjacency_list.hpp> #include <boost/graph/write_dimacs.hpp> #include <boost/graph/read_dimacs.hpp> using namespace boost; struct Arc; struct Node; typedef adjacency_list<vecS,vecS,directedS,Node,Arc> Graph; struct Arc { long capacity; long residual_capacity; Graph::edge_descriptor reverse; }; struct Node { std::string name; Graph::edge_descriptor predecessor; default_color_type color; long distance; long index; }; int main() { typedef Graph::vertex_descriptor vertex_descriptor; typedef Graph::edge_descriptor edge_descriptor; typedef std::pair<edge_descriptor, bool> EdgePair; typedef std::pair<int,int> Pair; Graph g; property_map<Graph, long Arc::*>::type capacity = get(&Arc::capacity, g); property_map<Graph, long Arc::*>::type res_capacity = get(&Arc::residual_capacity, g); property_map<Graph, Graph::edge_descriptor Arc::*>::type reverse = get(&Arc::reverse,g); property_map<Graph,Graph::edge_descriptor Node::*>::type predecessor = get(&Node::predecessor,g); property_map<Graph,default_color_type Node::*>::type color = get(&Node::color,g); property_map<Graph,long Node::*>::type distance = get(&Node::distance,g); property_map<Graph,long Node::*>::type index = get(&Node::index,g); long flow; vertex_descriptor s, t; Pair edge_array[6] = { Pair(0,1), Pair(0,2), Pair(0,3), Pair(2,4), Pair(1,3), Pair(4,3), }; EdgePair edge_desc_obj; EdgePair edge_from_first=add_edge(edge_array[0].first,edge_array[0].second,g); g[edge_from_first.first].capacity=1; for (int i = 1; i < 5; ++i){ edge_desc_obj=add_edge(edge_array[i].first, edge_array[i].second,g); g[edge_desc_obj.first].capacity=i+1; } EdgePair edge_to_last=add_edge(edge_array[5].first,edge_array[5].second,g); g[edge_to_last.first].capacity=4; char str[2]; int i=0; vertex_descriptor v1=*vertices(g).first,v2=*vertices(g).second; while (v1!=v2) { sprintf(str,"%d",i); g[v1].name=str; v1++; i++; } edge_descriptor from_s,to_t; from_s=edge_from_first.first; to_t=edge_to_last.first; s=source(from_s,g); t=target(to_t,g); flow = kolmogorov_max_flow(g,capacity,res_capacity,reverse,predecessor,color,distance,index,s,t); return 0; } -----------------------------END OFCODE----------------- However when trying to run this code I receive "Segmentation error". (this error does not appear when I remove the call to kolmogorov) I work under linux and I tried to compile with both g++ and g++-3.3 The valgrind output can be found at: http://www.cs.huji.ac.il/~lweizm45/valgring_output.txt Any suggestions? Lior

3 2

[BGL] how to call Dijkstra
by Sandeep Gupta 03 Nov '08

03 Nov '08

*Hi Tristram Thanks for the reply. I tried the short version too as you suggestedbut the error doesn't go away: Attached below is the new code snippet and the related error. Thanks sandeep std::map<Vertex, Vertex> pred; boost::associative_property_map< std::map<Vertex, Vertex> > pred_map(pred); std::map<Vertex, size_type> dist; boost::associative_property_map< std::map<Vertex, size_type> > dist_map(dist); std::map<Vertex, size_type> weight; boost::associative_property_map< std::map<Vertex, size_type> > weight_map(weight); Vertex v; boost::dijkstra_shortest_paths(G, v, pred_map, dist_map, weight_map); error: no matching function for call to 'dijkstra_shortest_paths(Graph&, leda::node_struct*&, boost::associative_property_map<std::map<leda::node_struct*, leda::node_struct*, std::less<leda::node_struct*>, std::allocator<std::pair<leda::node_struct* const, leda::node_struct*> > > >&, boost::associative_property_map<std::map<leda::node_struct*, int, std::less<leda::node_struct*>, std::allocator<std::pair<leda::node_struct* const, int> > > >&, boost::associative_property_map<std::map<leda::node_struct*, int, std::less<leda::node_struct*>, std::allocator<std::pair<leda::node_struct* const, int> > > >&)' * >Hello >You don't need to call dijkstra and specify all the templates as most >of them have default values, and it's much more convinient to use >named parameters: >boost::dijkstra_shortest_paths(graph, start_node, > boost::predecessor_map(predmap) > .distance_map(distmap) > .weight_map(weightmap) > ); >} On Thu, Oct 30, 2008 at 9:00 PM, Sandeep Gupta <gupta.sandeep_at_[hidden]> wrote: > Hi, > I am missing something regarding the correct calling convention for > Dijkstra algorithm. Here is the relevant part of the code: > > typedef boost::associative_property_map< std::map<Vertex, int> > > intmapt; > typedef boost::associative_property_map< std::map<Vertex, Vertex> >> nodemapt; > dijkstra_visitor<null_visitor> mynullvis; > dijkstra_shortest_paths<Graph, dijkstra_visitor<null_visitor>, > nodemapt, intmapt, intmapt, nodemapt, std::less<int>, > std::plus<int>, std::numeric_limits<int>, std::numeric_limits<int> > > (G, v, predmap, distmap, weightmap, indexmap, std::less<int>(), > std::plus<int>(), std::numeric_limits<int>::max(), 0, mynullvis); > > I get an error as no matching function call dijkstra_shortest_paths. > Appreciate some pointers as what could possibly be wrong. > > Thanks > sandeep >

2 1

Overloading the new and delete operators
by Jacob Holm 03 Nov '08

03 Nov '08

I have overloaded the new and delete operator, then I found this in the source code: // note: this should really be a member of the load_ptr function // below but some compilers still complain about this. template<class T> struct heap_allocator { #if 0 // note: this fails on msvc 7.0 and gcc 3.2 template <class U, U x> struct test; typedef char* yes; typedef int* no; template <class U> yes has_op_new(U*, test<void* (*)(std::size_t), &U::operator new>* = 0); no has_op_new(...); template<class U> T * new_operator(U); T * new_operator(yes){ return (T::operator new)(sizeof(T)); } T * new_operator(no){ return static_cast<T *>(operator new(sizeof(T))); } static T * invoke(){ return new_operator(has_op_new(static_cast<T *>(NULL))); } #else // while this doesn't handle operator new overload for class T static T * invoke(){ return static_cast<T *>(operator new(sizeof(T))); } #endif }; If I am using a msvc that this does not fail on, is there anything wrong with implementing this code, or will I get a bunch of errors or "hidden" bugs? Also, are there any plans on implementing this in a future release(I am guessing it is a work in progress issue)? Thanks in advance. /Jacob Holm

1 0