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

Building 1.33.1 with VC .NET 2003
by D. R. Evans 28 Feb '06

28 Feb '06

As far as I can tell, I followed the instructions exactly: > First you need to change to the directory where you have the Boost distribution you downloaded. OK, I'm in boost_1_33_1. Then execute: bjam "-sTOOLS=vc-7_1" which produces: ----- Jamfile:197: in load-jamfiles *** argument error * rule install-subinclude ( jamfiles + : options * ) * called with: ( : ) * missing argument jamfiles C:\boost\boost_1_33_1\tools/build/v1\boost-base.jam:2855:see definition of rule 'install-subinclude' being called C:\boost\boost_1_33_1\tools\build\v1\bootstrap.jam:21: in boost-build C:\boost\boost_1_33_1\boost-build.jam:16: in module scope ----- What am I doing wrong? Doc Evans

9 16

Boost lambda question
by yinglcs2＠yahoo.com 28 Feb '06

28 Feb '06

Hi I have a Boost lambda question, I appreciate is someone can help me out: I have a class A: class A{ private: B& getB() {return _b;} B& _b; }; vector<A> aList; void aFunction (A& a, B& b); how can I write a loop to walk thru a list of A and call aFunction. for (vector<A>::iterator itr = aList.begin; itr != end; itr++) { A a = (*itr); aFunction (a, a->getB()); } __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 1

Re: [Boost-users] Buggy Prim's minimum spanning tree example
by Olivier Delalleau 27 Feb '06

27 Feb '06

>> Hello, >> >> I have a problem with the example for Prim's minimum spanning tree >> that >> can be found here: >> http://www.boost.org/libs/graph/example/prim-example.cpp >> >> The problem is that when compiled in 32 bits but run on a 64 bits >> computer, and modified with different edges and weights, it does not >> work anymore. >> The modified version that exhibits this behaviour is here: >> http://www.iro.umontreal.ca/~delallea/tmp/prim-example-fail.cpp >> It is a simplified version (I removed some compiler-specific code for >> MSVC) where I replaced the edges and weights by a real-life example I >> have to solve. >Unfortunately, I am unable to duplicate the problem here. On our 64-bit >Opteron machines (running Linux), I get the same results for 64- and >32-bit binaries. >Which version of Boost are you using? What operating system? What >version of GCC? Thanks for the reply. I hope this message will get into the proper thread on the boost mailing-list (had forgotten to turn on my boost digest email...). Here are more detailed information: OS = Fedora Core 4: 'uname -a' -> Linux xxx.yyy 2.6.15-1.1831_FC4 #1 SMP Tue Feb 7 13:37:59 EST 2006 x86_64 x86_64 x86_64 GNU/Linux g++ --version -> g++ (GCC) 4.0.2 20051125 (Red Hat 4.0.2-8) Boost version is 1.33.0. CPU is AMD Athlon(tm) 64 Processor 3500+ Thank again, Olivier PS: just in case, my original post with full details and program output: http://lists.boost.org/boost-users/2006/02/17314.php

2 2

Re: [Boost-users] Serialization : unregistered_cast & otherquestions
by RIVASSEAU Jean Noel 27 Feb '06

27 Feb '06

Hello Robert, Thanks for your reply. However you did not understand the problem. I read the documentation and understood the purpose of BOOST_EXPORT as explained in the documentation, and as reexplained in your last mail. The problem is at linking, but is not one of undefined reference (template not instantiated), but, on the other hand, *a multiple definition problem.* If, as suggested, you move BOOST_EXPORT to the class header, even if you move the archive headers before the serialization/export header, you will have multiple instantiations of the same template. This is because every time you include the serialization class header in your program there is some code instantiation, since the EXPORT is in that file. Since this header is included several times in the program, multiple instantiations of the same code occurs (note: apparently this happens even if there is no definition of the templated code to be instantiated (since the implementation is only in the .cc), only a declaration, because BOOST_EXPORT instantiates some kind of *helper code* that gets multiple defined). Anyway, if you can change the code in order to avoid this multiple definition problem, I'll be glad to test, but I believe it is impossible. However, putting BOOST_EXPORT in the .cc avoids the problem entirely, so this is acceptable. I am sending again code with your suggested changes, in order to show you your method does not work. If you look at the code you will see that each serialization header includes <CommonSerialize.h> which contains the archive headers. Then after <CommonSerialize.h> inclusion comes serialization/export.hpp inclusion, so the archive headers are BEFORE export.hpp. Then follows BOOST_EXPORT. At linking I get the multiple definition problem that I mentioned. If you just move BOOST_EXPORT into the .cc no problems at all. You can check for yourself if you try to compile the code. Thank you!! Jean-Noël Ps: I ran into two other problems that I'll write mail for later... OK - BOOST_EXPORT has some non-obvious behavior which I'll explain. Maybe this will help. BOOST_EXPORT has two functions: a) To associate a class with an external unique name (GUID) b) To instanticiate templated code for archives used. The second is not as obvious as it might seem. Suppose I have: class A { }; class B : public A { } A * aptr = new B; text_archive ar; ar << a; The problem is that the compiler never sees anything like ar << b so it has no way to know that the serialization code for B needs to be instantiated for the archive class text_archive. So each archive class defines a special macro. Then BOOST_EXPORT instantiates code for each combination of the class and archive class. If this were not done, one would get a link error with undefined symbol for load<text_archive, B> or something lke that. Of course the above presumes that the archive classes are included BEFORE the serialization/boost/export.hpp header. So if you make the following changes in your code I believe you will get the desired results. a) Move BOOST_EXPORT to the class header. b) In test.cc - move the headers boost/archive/... above the headers boost/serialization/.. and let me know that happens. Robert Ramey

3 4

graph class creation???
by Alejandro Aragón 27 Feb '06

27 Feb '06

Hi, I've been using the graph library for a while now. I was finally able to run my first Kruskal's algorithm adapted to my own problem. I am not a expert in C++ so I would like to ask something. I was taught that you should keep the definitions in one file and the declarations in another file. Well, working with the boost graph lirary, do we have to do this as well???? It doesn't make sense to me to do this since I am already working with the headers of the boost graph library to have the declarations in a .h file. Therefore, I just created a file graph.cxx where I put the particular implementation that I'm using, the definitions of my own graph properties and so on. Is this correct? Thanks for your help. a^2

2 2

serialization: problem with abstract base class
by RIVASSEAU Jean Noel 27 Feb '06

27 Feb '06

Hello The following code (attached) demonstrate a problem that I have. I am trying to serialize via pointer to base class (MObject) which is abstract. The docs say that a compile error will occur when trying to do that. I don't have any compile time errors emitted but the build fails at link time (it does not instantiate the save/load code for the abstract base class). The solutions provided in the docs are: write BOOST_IS_ABSTRACT(MObject): I did that and nothing changes; Or Implement is_abstract for your compiler. I do not understand what this means. Can you help me out ? Currently the only workaround I have is to not make the base class abstract, but I would like it to be abstract... Jean-Noël

2 1

Re: [Boost-users] Serialization : unregistered_cast & otherquestions
by RIVASSEAU Jean Noel 27 Feb '06

27 Feb '06

Again I forgot to include the code sorry... _____ De : boost-users-bounces(a)lists.boost.org [mailto:boost-users-bounces@lists.boost.org] De la part de Robert Ramey Envoyé : vendredi 24 février 2006 17:53 À : boost-users(a)lists.boost.org Objet : Re: [Boost-users] Serialization : unregistered_cast & otherquestions "RIVASSEAU Jean Noel" <JN.RIVASSEAU(a)oberthurcs.com> wrote in message news:87F60F7FA02FF749AFB02BD9FCAA6B04DA737E@naserv31.nanterre.oberthurcs.com... Thanks for all your help. I have decided to try to reorganize everything into small parts as you have said, in order to better understand. I am in the process of doing this, but I have already some remarks about your comments. I have chosen the organisation principle you have said: in the class.h, nothing about the serialization is present in serialization/class_serialization.hh : I have the serialization declaration code + some traits in serialization/class_serialization.cc : I have the serialization implementation code + BOOST_EXPORT The only thing where I have not followed your advice is the presence of BOOST_EXPORT on the class_serialization.hh rather than class_serialization.cc. If I put it on the header, since I have to include the header on test.cc, one instantation of something is done while encountering BOOST_EXPORT. Later while compiling class_serialization.cc, since it encounters BOOST_EXPORT one more time another instantiation occurs and I had problems with linking (gcc 3.4 reported multiple definitions of something). **** OK - BOOST_EXPORT has some non-obvious behavior which I'll explain. Maybe this will help. BOOST_EXPORT has two functions: a) To associate a class with an external unique name (GUID) b) To instanticiate templated code for archives used. The second is not as obvious as it might seem. Suppose I have: class A { }; class B : public A { } A * aptr = new B; text_archive ar; ar << a; The problem is that the compiler never sees anything like ar << b so it has no way to know that the serialization code for B needs to be instantiated for the archive class text_archive. So each archive class defines a special macro. Then BOOST_EXPORT instantiates code for each combination of the class and archive class. If this were not done, one would get a link error with undefined symbol for load<text_archive, B> or something lke that. Of course the above presumes that the archive classes are included BEFORE the serialization/boost/export.hpp header. So if you make the following changes in your code I believe you will get the desired results. a) Move BOOST_EXPORT to the class header. b) In test.cc - move the headers boost/archive/... above the headers boost/serialization/.. and let me know that happens. Robert Ramey _____ De : boost-users-bounces(a)lists.boost.org [mailto:boost-users-bounces@lists.boost.org] De la part de Robert Ramey Envoyé : jeudi 23 février 2006 17:44 À : boost-users(a)lists.boost.org Objet : Re: [Boost-users] Serialization : unregistered_cast & otherquestions Without actually seeing the code, its hard for me to give intelligent advice. Lucky for you (maybe) that's not going to inhibit me from speculating. Here is what I recommend for anyone making a very large program: a) extended_type_info_no_rtti presumes that all classes serialized as pointers have been exported. Should this not be the case, you'll get the error message indicated. Double check this. b) Serilaization traits should be in the header files so that they are not "missed" anytime something like "ar << x" is invoked. Given you're situation I would recommend a file structure like the following: class.hpp - without seriaiization like you have now. serialization/class.hpp - includes class.hpp. also includes BOOST_EXPORT and any other traits for this "class". serialization/class.cpp c - includes serialization/class.hpp and includes the actual serialization code. Also this should include code instantiation for the archives that you use. Look at demo_pimpl to see how this is done. All the above code should be organized into a library. The reason is that this will generate code for all the archives mentioned but your application may not use all the archives so putting the above code in a library and linking to it will mean that your application will always have what it actuallyuses but nothing it doesn't - avoids "code bloat". Note that in compiling code for the library make sure to specify "function level linking". Take the "least derived class" - that one at the top of the class hierarchy. Make a small test program similar to the tests in the serialization library. This should be a very small job. This code can be class_test.cpp. Run this test on all archives you use. When this test passes, do the same for the other classes until something fails. This might seem to be more work - believe me its not. It will a) guarentee that you make progress toward a robust program b) give you confidence that your program has minimum of hidden bugs c) permit you to re-run the tests automatically when you make future changes. d) should a problem arise with the serialization or other library, it will give a lot more information in order to be helpful. Robert Ramey Now, the problem is where to put the serialization code for these classes. If I just write them on the implementation file (the .cc) for the class, it does not work. At run time I have always errors telling me that either the class is not exported (unregistered_class exception) or an unregistered_cast happens. The only solution I have found is to put *ALL* serialization code into the same big .cc file. If I do just that, it works. However this file is becoming enormous and has to be recompiled every time I change only *one* of the class to be serialized. It is already taking a minute to compile on a fast machine, so I must really break it up into other parts. But everytime I do that everything stops working. Have you any ideas, Robert? I am using extended_type_info_no_rtti, this may be the cause of the problem... Jean-Noël Ps: I still have the std::string bug, which is also uncomprehensible for me. _____ _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users _____ _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

2 1

[BGL] Is it a bug when using random access EdgeList?
by Tux Han 27 Feb '06

27 Feb '06

I wrote a very simple sample using BGL adjacent list and using a random access EdgeList. But when I invoke remove_out_edge method, It seems wrong. My config is Boost 1.33.1 and Visual Studio 2005, here is my code: ------------x-------------------------------Begin here-----------------------------------------x------------- #include <boost/graph/adjacency_list.hpp> #include <string> using namespace boost; using namespace std; namespace boost{ struct vertex_label_t { typedef vertex_property_tag kind; }; } template <class EdgeIter, class Graph> void print_graph(EdgeIter first, EdgeIter last, const Graph& G) { typedef typename property_map<Graph, vertex_label_t>::const_type LabelMap; LabelMap label = get(vertex_label_t(), G); typedef typename boost::property_traits<LabelMap>::value_type LabelType; LabelType src_label, targ_label; while (first != last) { src_label = boost::get(label, source(*first, G)); targ_label = boost::get(label, target(*first, G)); cout << src_label << " <-> " << targ_label << endl; ++first; } } typedef property<vertex_label_t, std::string> LabelProperty; typedef adjacency_list<vecS, vecS, undirectedS, LabelProperty, boost::no_property, boost::no_property, vecS> MyGraphType; bool AnyEdge(MyGraphType::edge_descriptor e) { return true; } int main() { typedef pair<int,int> Pair; Pair edge_array[8] = { Pair(0,1), Pair(0,2), Pair(0,3), Pair(0,4), Pair(2,4), Pair(3,1), Pair(3,4), Pair(4,1) }; MyGraphType G(5); for (int i = 0; i < 8; ++i) add_edge(edge_array[i].first, edge_array[i].second, G); property_map<MyGraphType, vertex_label_t>::type name = get(vertex_label_t(), G); boost::put(name, 0, "0"); boost::put(name, 1, "1"); boost::put(name, 2, "2"); boost::put(name, 3, "3"); boost::put(name, 4, "4"); print_graph(edges(G).first, edges(G).second, G); // Remove out edges of vertex 0 cout << "Remove out edges of vertex 0" << endl; remove_out_edge_if(0, AnyEdge, G); print_graph(edges(G).first, edges(G).second, G); } ------------x-------------------------------End here-----------------------------------------x------------- and the result is: ------------------------------------------------------------------------------------------------------------------ 0 <-> 1 0 <-> 2 0 <-> 3 0 <-> 4 2 <-> 4 3 <-> 1 3 <-> 4 4 <-> 1 Remove out edges of vertex 0 0 <-> 2 0 <-> 4 3 <-> 1 4 <-> 1 ------------------------------------------------------------------------------------------------------------------ Is there something wrong? --------------------------------- Brings words and photos together (easily) with PhotoMail - it's free and works with Yahoo! Mail.

2 1

Buggy Prim's minimum spanning tree example
by Olivier Delalleau 27 Feb '06

27 Feb '06

Hello, I have a problem with the example for Prim's minimum spanning tree that can be found here: http://www.boost.org/libs/graph/example/prim-example.cpp The problem is that when compiled in 32 bits but run on a 64 bits computer, and modified with different edges and weights, it does not work anymore. The modified version that exhibits this behaviour is here: http://www.iro.umontreal.ca/~delallea/tmp/prim-example-fail.cpp It is a simplified version (I removed some compiler-specific code for MSVC) where I replaced the edges and weights by a real-life example I have to solve. Here is the output on a 64 bits computer: -> g++ prim-example-fail.cpp -> ./a.out parent[0] = no parent parent[1] = 9 parent[2] = 19 parent[3] = 4 parent[4] = 0 parent[5] = 26 parent[6] = 27 parent[7] = 4 parent[8] = 0 parent[9] = 3 parent[10] = 0 parent[11] = 0 parent[12] = 6 parent[13] = 12 parent[14] = 17 parent[15] = 28 parent[16] = 4 parent[17] = 15 parent[18] = 1 parent[19] = 24 parent[20] = 12 parent[21] = 10 parent[22] = 5 parent[23] = 1 parent[24] = 22 parent[25] = 0 parent[26] = 4 parent[27] = 7 parent[28] = 13 parent[29] = 4 And when compiled in 32 bits with the -m32 option of g++: -> g++ -m32 prim-example-fail.cpp -> ./a.out parent[0] = no parent parent[1] = no parent parent[2] = no parent parent[3] = no parent parent[4] = no parent parent[5] = no parent parent[6] = no parent parent[7] = no parent parent[8] = no parent parent[9] = no parent parent[10] = no parent parent[11] = no parent parent[12] = no parent parent[13] = no parent parent[14] = no parent parent[15] = no parent parent[16] = no parent parent[17] = no parent parent[18] = no parent parent[19] = no parent parent[20] = no parent parent[21] = no parent parent[22] = no parent parent[23] = no parent parent[24] = no parent parent[25] = no parent parent[26] = no parent parent[27] = no parent parent[28] = no parent parent[29] = no parent I don't know if the problems comes from a faulty example or from the Boost Prim's spanning tree algorithm. Unfortunately I find the graph library quite difficult to understand and this example is the only basis I have to work from. Thanks for any help, Olivier

2 1

[BGL]Problems in the shortest pair algorithms.
by Peter Gerell 27 Feb '06

27 Feb '06

Hi, I have reported some problems with the johnson_all_pairs_shortest_paths and floyd_warshall_all_pairs_shortest_paths algorithms. What is the correct way to report these problems. I made some posts to the list last week, but didn't get any response. Perhaps this should go on the developer mailing list instead? However, the problems I have noticed are: Floyd-Warshall: 1. std::min is used instead of the functor passed to as teh distance_compare parameter at several places 2. The distance map is initialized with 0 instead of zero. Johnson: 3. std::numeric_limits<DT>::max() is used instead of the distance_inf parameter. 4. The distance_combine and distance_compare parameters are not used. The bellman_ford_shortest_paths algorithm is called with std::less and closed_plus. Thanks Peter

2 1