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

Re: [Boost-users] [graph] [python] Python vertex vs. C++ Vertex
by Nat Goodspeed 28 Feb '06

28 Feb '06

> -----Original Message----- > From: boost-users-bounces(a)lists.boost.org [mailto:boost-users- > bounces(a)lists.boost.org] On Behalf Of David E. Konerding > Sent: Monday, February 27, 2006 5:09 PM > To: boost-users(a)lists.boost.org > Subject: Re: [Boost-users] [graph] [python] > > Doug Gregor wrote: > > > > Your guess is correct. We don't cache the Python objects corresponding > > to vertex and edge descriptors. > > my idea was to keep the > mapping between on-screen widgets and the graph vertices they corresponded > to in a dictionary: > > self._widgetmap[vertex] = widget > > However, since Vertex objects aren't cached, placing the vertex object I > get back from add_vertex obviously isn't going to work. [Nat] Maybe twiddle the hash function of the Python vertex object so that it derives its return value from the underlying C++ Vertex?

1 0

[program_options]Iterator decremented past begin of container
by Peter Gerell 28 Feb '06

28 Feb '06

Hi, I have filed the following bug in the SF tracker. In format_paragraph the following code appears: string::const_iterator line_begin = par.begin(); <snip> string::const_iterator last_space = find(reverse_iterator<string::const_iterator>(line_end - 1), reverse_iterator<string::const_iterator>(line_begin - 1), ' ') .base(); This generates a run-time assertion if compiled with VC8 and debug/checked iterators. /Peter

1 1

Re: [Boost-users] serialization: again a problem, failing to serialize a std::vector of pointers
by RIVASSEAU Jean Noel 28 Feb '06

28 Feb '06

I added this into the ClassSpecification_serialization.cc : typedef std::vector< MemberVariableSpecification * , std::allocator<MemberVariableSpecification*> > my_vector; BOOST_CLASS_IMPLEMENTATION(my_vector, boost::serialization::object_serializable) But I still get the same error... help! Jean-Noël Ps: the typedef was necessary, else gcc parsing would recognize 3 arguments to the macro BOOST_CLASS_IMPLEMENTATION -----Message d'origine----- De : boost-users-bounces(a)lists.boost.org [mailto:boost-users-bounces@lists.boost.org] De la part de Robert Ramey Envoyé : lundi 27 février 2006 18:25 À : boost-users(a)lists.boost.org Objet : Re: [Boost-users] serialization: again a problem,failing to serialize a std::vector of pointers "RIVASSEAU Jean Noel" <JN.RIVASSEAU(a)oberthurcs.com> wrote in message news:87F60F7FA02FF749AFB02BD9FCAA6B04DA7ABF@naserv31.nanterre.oberthurcs.com... Hello This is my last problem with the BSL but the most important one (because there is no workaround). I am trying to serialize a class (whose name is "ClassSpecification") which has a std::vector of pointers. The code for serializing the class the pointer refer to (MemberVariableSpecification) is written and instantiated correctly. However I cannot correctly serialize the std::vector. It fails with a message complaining about: C:/Boost/include/boost-1_33_1/boost/archive/detail/iserializer.hpp:115: error: incomplete type `boost::serialization::extended_type_info_null<std::vector<MemberVariableSpecification*, std::allocator<MemberVariableSpecification*> > >' used in nested name specifier I do not understand why I need an extended_type_info for this vector. I sure need it for the class the pointers refer to (and I did specify it), but the std::vector itself is serialized as such, not as a pointer. *** hmmm - can sympathise with you here. I suspect that this is a mistake. It might be an accidental side effect of the fact that the default serialization trait for any class is tracked with class information. You might try the following: BOOST_CLASS_IMPLEMENTATION( std::vector<MemberVariableSpecification*, std::allocator<MemberVariableSpecification*>, boost::serialization::object_serializable ) Why do I get this error ??? I would have to look into it. Can you please check the attached code and help me? Thanks Jean-Noël Ps: using gcc 3.4.2 _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

1 0

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

28 Feb '06

Hello I agree with you, and currently have the same comprehension of the problem than you. I am currently also including BOOST_EXPORT_CLASS in only one implementation file *per class*. This seems to work. Robert is saying however, that even that can cause problem, but as written on a previous message, I cannot manage to follow his advice on including the archive headers in only one instantiation module (except putting all serialization code into that module, which I did previously: this is a maintenance nightmare, to the point that I ended up trying to break my code into smaller places). I'll chime in, as I'm having exactly the same issue, but on darwin/ gcc-4 with code in multiple dynamically loaded libraries... (I have other issues too, I get to those later) The problem is that although export.hpp is only included once per generated .o file, there are multiple .o files all including the same headers - and each therefore generates the same template instantiations, thereby causing the multiple definitions during linking. Also - the same headers may be included in multiple shared libraries, exacerbating the problem with the same code instantiated into multiple libraries - a serious problem if there are singletons. I may not be understanding this correctly - here's what >I< think needs to happen - please correct me. For any derived class, there is a set of code (templates) that need to be instantiated for each archive type (specifically, the list boost::archive::detail::known_archive_types::type, for the templates guid_initializer<T> and export_instantiate<T, archive_list>) From what I see, these are NOT declarations required by the other serialization code, but singletons that, during construction, register the serializers to the derived classes with the extended_type_info class registry. Is that incorrect? If the above is correct, then the BOOST_EXPORT_CLASS should only be in exactly one implementation file (.cpp, .C, .cc, whatever). And also, THAT implementation file should ONLY be linked into one shared library. _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

1 0

Re: [Boost-users] serialization: problem with abstract base class
by RIVASSEAU Jean Noel 28 Feb '06

28 Feb '06

I have included <boost/serialization/base_object.hpp> where it should be, it did not change anything... Anyway what is "implementing is_abstract for your compiler" ?? Jean-Noël *** its hard for me to follow what's going on here. One thing I did notice is that the I didn't see <boost/serialization/base_object.hpp> included in the places where it is used. I'm not sure if that's significant. Robert Ramey _______________________________________________ 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

1 0

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