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

Re: [Boost-users] serialization: again a problem, failing to serializeastd::vector of pointers
by RIVASSEAU Jean Noel 10 Mar '06

10 Mar '06

Joaquín, Unfortunately, my example code which does not compile on my platform (gcc 3.4.2 on Win 2000 Pro) seems to compile with Robert's platform (same compiler !!), so it is very strange... Thus Robert has not been able to help further. Jean-Noël _____ De : boost-users-bounces(a)lists.boost.org [mailto:boost-users-bounces@lists.boost.org] De la part de Joaquín Mª López Muñoz Envoyé : vendredi 10 mars 2006 16:15 À : boost-users(a)lists.boost.org Objet : Re: [Boost-users] serialization: again a problem, failing to serializeastd::vector of pointers RIVASSEAU Jean Noel ha escrito: Hi Joaquin Jean-Noël, maybe you can try using the proposed patch at http://lists.boost.org/Archives/boost/2006/02/101539.php and report your results. I've got the hunch your problem might be related to the issue dealt with at that post. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users I replied to this, but did not hear from you again... Here was my reply below: Hello Jean-Noël, my apologies for not answering before, but I'm without a clue as to what the problem might be with your code... I suggested you applied the patches because the error messages seemed to be related to the problem I had been investigating in parallel, but looks like it is something else. Hasn't Robert assisted you? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

Re: [Boost-users] serialization: again a problem, failing to serializeastd::vector of pointers
by Joaquín Mª López Muñoz 10 Mar '06

10 Mar '06

RIVASSEAU Jean Noel ha escrito: > Hi Joaquin > > Jean-Noël, maybe you can try using the proposed patch at > > http://lists.boost.org/Archives/boost/2006/02/101539.php > > and report your results. I've got the hunch your problem might > > be related to the issue dealt with at that post. > > Joaquín M López Muñoz > > Telefónica, Investigación y Desarrollo > > _______________________________________________ > > Boost-users mailing list > > Boost-users(a)lists.boost.org > > http://lists.boost.org/mailman/listinfo.cgi/boost-users > > I replied to this, but did not hear from you again... Here was my > reply below: > Hello Jean-Noël, my apologies for not answering before, but I'm without a clue as to what the problem might be with your code... I suggested you applied the patches because the error messages seemed to be related to the problem I had been investigating in parallel, but looks like it is something else. Hasn't Robert assisted you? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

[BGL] Graph properties and dynamic properties
by Martin Palkovic 10 Mar '06

10 Mar '06

Hi, The example in http://www.boost.org/libs/graph/example/graphviz.cpp gives a hint how to use edge properties and vertex properties with dynamic properties when writing out the dot file. However, I would like to write out also graph properties, i.e. I have get_property(g, graph_overlap_t()) = "false"; dynamic_properties dp; dp.property("overlap", ?); dp.property("node_id", get(vertex_name_t(), g)); dp.property("strength", get(edge_strength_t(), g)); Thanks in advance for any help. Kind regards, Martin Palkovic

1 0

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

10 Mar '06

Hi Joaquin Jean-Noël, maybe you can try using the proposed patch at http://lists.boost.org/Archives/boost/2006/02/101539.php and report your results. I've got the hunch your problem might be related to the issue dealt with at that post. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users I replied to this, but did not hear from you again... Here was my reply below: At this url, I have found two hpp files. I replaced the ones that originally came with the Boost 1.3.1 distribution with these ones. I still have an error, at the same line, however it is: C:/Boost/include/boost-1_33_1/boost/archive/detail/iserializer.hpp:115: error: no type named `type' in `struct boost::serialization::type_info_implementation<std::vector<MemberVariableSpecification*, std::allocator<MemberVariableSpecification*> > >' C:/Boost/include/boost-1_33_1/boost/archive/detail/iserializer.hpp:115: error: `get_instance' is not a member of `<declaration error>' While it was: 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 with the original code from Boost 1.33.1. So this patch effectively changed something, but it still not working. I've not read the entire thread at your url since I did not understand it (it was about a specific compiler issue ??). Any ideas? Jean-Noël

1 0

Re: [Boost-users] serialization: can someone compile this code with gcc 3.4 ?
by RIVASSEAU Jean Noel 10 Mar '06

10 Mar '06

Hello I am using gcc 3.4.2 (MinGW) and Boost 1.33.1 on Windows 2000 Professional. I am quite surprised that you manage to compile this code correctly, even with gcc. I still have the error; I tried your hints - I completely removed any header inclusion to _typeid.hpp, and included _no_rtti.hpp before any serialization or header archive, but it still fails exactly on the same problem as before (with the same error message). I am including my code here, if someone can try to compile it and report problems / successes it would be nice. Jean-Noël -----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é : vendredi 3 mars 2006 17:53 À : boost-users(a)lists.boost.org Objet : Re: [Boost-users] serialization: again a problem,failing to serialize a std::vector of pointers OK - after changing some #include < to include "... I managed to compile all the modules - including ClassSpecification_serialization.cc - with the following compilers: VC 7.1, gcc 3.4, Comeau, Borland 5.64 and Borland 5.51 I compiled against my more recent version which may be different than the one you are using - I presume you're using 1.33? I did find a minor problem with gcc in some code I recently added but it is not related to this issue. So I can't reproduce your exact problem. I might give some hints though. The current system needs an extended_type_info implementation. This is specified by including a header - either extended_type_info_typeid.hpp or extended_type_info_no_rtti - which was just an example but I guess its been found to be useful now. If neither of these is expliclty #included, the system will #include extended_type_info_typeid.hpp and mark it as the "default". Its possible that in some of your files you're including "...no-rtti.pp" while in others nothing has been specified so that "..._typeid.hpp" is being included. As a test you might try including "..._no_rtti.hpp" above any serialization or archive headers. and see if that makes a difference. Robert Ramey RIVASSEAU Jean Noel wrote: > Sorry, I removed the QString stuff, so it should make more sense to > you now. I have attached the cleaned up code. If you try to compile > it, it will fail on the file > > ClassSpecification_serialization.cc > > with a message saying that there is a problem with the > extended_type_info of std::vector< MemberVariableSpecification *> > (since a member of ClassSpecification, which I serialize, is of this > type). > > Don't pay attention as to what are my real intentions on this example > code, this comes from my real project, and it would be long to > explain. Just let's say that, no, I am not trying to store class id > information into the archive, it is just that one data member of one > of object that I need to serialize has the name class_id (but it > could be named "walnut_field", the code would be the same). > > This small example code is just there to show you the bug that > occurs. > > As for the mixing of type systems (no_rtti and type_id), it was just > a test to see if that would change things. I have reverted it back in > the attached code (only no_rtti used) but it still does not work. > > Thank you > > Jean-Noël > > > > -----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é : jeudi 2 mars 2006 18:06 > À : boost-users(a)lists.boost.org > Objet : Re: [Boost-users] serialization: again a problem,failing to > serialize a std::vector of pointers > > I took a look at this and it made no sense to me. > > I couldn't compile it as it needed a file QString to compile. > > I did have occasion to look into the code and Its not obvious to me > what > your intention here. > > It looks like you're trying to store class id information into the > archive > so that the proper > class can be reconstructed. But that can't be it as the serialization > library already does that. > > Also I notice that you're using extended_type_info_typeid as well as > extended_type_info_no_rtti. > This is very odd to me as I would expect that one's environment > either has > rtti enable or it doesn't. > so I would expect either one or the other but not both. > > Anyway, sorrty I couldn't be more help. > > Robert Ramey > > "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. Why do I > get > this error ??? > > 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 > > > > > > > > > >> _______________________________________________ >> Boost-users mailing list >> Boost-users(a)lists.boost.org >> http://lists.boost.org/mailman/listinfo.cgi/boost-users

1 0

Re: [Boost-users] How to retrieve a value from a thread
by Sliwa, Przemyslaw (London) 09 Mar '06

09 Mar '06

I was though thread is created by a pointer to a function, e.g. Int foo(int x, int y, int z) { // do something with a,b,c return a+b+c; } Boost::thread pop(boost::bind(&foo, a, b, c)); // do something else pop.join(); The question is how to retrieve the result from foo running in pop. Thanks for ideas. Kind regards Pshemek Przemyslaw Sliwa Global Foreign Exchange FX Risk Engine Development Merrill Lynch ( +44 (0)20 7995 4182 ) +44 (0)79 6325 2319 * Email: przemyslaw_sliwa(a)ml.com -----Original Message----- From: boost-users-bounces(a)lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Nat Goodspeed Sent: 09 March 2006 15:15 To: boost-users(a)lists.boost.org Subject: Re: [Boost-users] How to retrieve a value from a thread ________________________________________ From: boost-users-bounces(a)lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Sliwa, Przemyslaw (London) Sent: Thursday, March 09, 2006 9:47 AM To: boost-users(a)lists.boost.org Subject: [Boost-users] How to retrieve a value from a thread I would like to know if it is possible to retrieve a value returned from a function which is called by a thread. [Nat] Is this thread running continuously, doing other things? Or did you start it for the purpose of calling that function, so that when the function is done the thread terminates? In Java, I've always kind of liked Doug Lea's FutureResult idiom: http://gee.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/Future Result.html I don't know of anything similar in the existing library. _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users -------------------------------------------------------- If you are not an intended recipient of this e-mail, please notify the sender, delete it and do not read, act upon, print, disclose, copy, retain or redistribute it. Click here for important additional terms relating to this e-mail. http://www.ml.com/email_terms/ --------------------------------------------------------

3 2

Bug in boost/graph/detail/array_binary_tree.hpp ? [Boost 1_33_1]
by Marc Sturm 09 Mar '06

09 Mar '06

Hello, We use gcc 3.4 and 4.0 to compile our project OpenMS, which is based on boost. boost/graph/detail/array_binary_tree.hpp causes the following errors: ---------------------------------------------------- ../boost/graph/detail/array_binary_tree.hpp:157: error: no matching function for call to 'get(OpenMS::IteratorOffset<__gnu_cxx::__normal_iterator<double*, std::vector<double, std::allocator<double> > > >&, __gnu_cxx::__normal_iterator<double*, std::vector<double, std::allocator<double> > >&)' .../boost/graph/detail/array_binary_tree.hpp:158: error: no matching function for call to 'get(OpenMS::IteratorOffset<__gnu_cxx::__normal_iterator<double*, std::vector<double, std::allocator<double> > > >&, __gnu_cxx::__normal_iterator<double*, std::vector<double, std::allocator<double> > >&)' ---------------------------------------------------- This can be fixed by replacing the original lines: 157: edata[ boost::get(id, tmp) ] = i; 158: edata[ boost::get(id, value()) ] = x.i; by: 157: edata[ get(id, tmp) ] = i; 158: edata[ get(id, value()) ] = x.i; Is this a bug, or are we doing something wrong? Cheers, Marc -- ################################################## Marc Sturm University of Tuebingen Simulation of Biological Systems Sand 14, Room C323 D-72076 Tuebingen phone: +49 7071 29 70462 email: sturm(a)informatik.uni-tuebingen.de ##################################################

2 1

Re: [Boost-users] BGL connected_components for directed graphs
by Gavin Band 09 Mar '06

09 Mar '06

> Message: 1 > Date: Thu, 2 Mar 2006 15:53:40 -0500 > From: Doug Gregor <dgregor(a)cs.indiana.edu> > Subject: Re: [Boost-users] BGL connected_components for directed > graphs > To: boost-users(a)lists.boost.org > Message-ID: <a3b58932f7664328bbd614fec82f1a0e(a)cs.indiana.edu> > Content-Type: text/plain; charset=US-ASCII; format=flowed > > > On Feb 28, 2006, at 4:28 AM, Gavin Band wrote: <snip> > > Presumably this is some meta-program's way of telling me that my graph > > isn't undirected. > > Yes, that's what it's doing. connected_components() only works on > undirected graphs. > > > Is there any way to make this work for an directed > > graph? > > You can use the facilities for incremental connected components. Those > will work on an undirected graph. > In truth, our connected_components() should be modified to decide > between the DFS-based algorithm for undirected graphs and the > incremental algorithm for directed graphs. > Doug > Thank you for your answer - I will try that. However, I have some comments - forgive me if these have been made before or are just wishful thinking. As a mathematician, I tend to think of a directed graph as being also an undirected graph, just by forgetting the orientation of the edges. Then it should make sense to take connected_components() of any graph, directed or undirected, just by treating it as an undirected graph. However, I realise this conception may be naive in the context of the BGL, which has to deal with ways to store edges and their directions. Still - my graph seems to meet all of the formal requirements for connected_components, but to fail the (apparently informal) requirement that it be undirected (Under "Graph Concepts" in the documentation there is a discussion of directed vs. undirected graphs, but this stops short of a formal definition, unless I have misunderstood). Do think it is possible 1) to formalise the requirements for directed and undirected graphs, and 2) to write a graph adaptor undirected_graph<> which turns a directed graph G into its corresponding undirected graph H? Better yet, to use this (or some other method) to make the algorithms work for all graphs that they make (mathematical) sense for? Perhaps there are good reasons why this is not possible. Anyway, thanks again, Gavin.

2 1

[graph] [python]
by David E. Konerding 09 Mar '06

09 Mar '06

Hi folks, The bgl-python documentation says that the _graph.Graph.add_vertex() function returns a Vertex object. From my testing, the Vertex object that gets returned doesn't actually seem to be a member of the graph. Is this intentional? I was hoping that the returned Vertex object was valid, since I need access to it immediately. Here's a test program. I woudl expect the values for v1 and v2 to be in the graph, but they are not: =================== import boost.graph as bgl graph = bgl.Graph() v1 = graph.add_vertex() print "new v1=", v1 v2 = graph.add_vertex() print "new v2=", v2 e = graph.add_edge(v1, v2) print "new edge=", e for vertex in graph.vertices: print "vertex: ", vertex for edge in graph.edges: print "edge: ", edge print "edge source:", graph.source(e) ========================= Here's what I see: new v1= <boost.graph._graph.Vertex object at 0x40168a04> new v2= <boost.graph._graph.Vertex object at 0x40168aac> new edge= <boost.graph._graph.Edge object at 0x40164dec> vertex: <boost.graph._graph.Vertex object at 0x40168ae4> vertex: <boost.graph._graph.Vertex object at 0x40168b54> edge: <boost.graph._graph.Edge object at 0x40164d6c> edge source: <boost.graph._graph.Vertex object at 0x40168ae4> As you can see, v1 and v2 return and have different addresses than the Vertex objects that are listed by the vertices iterator. My guess here is that the Vertex objects do point to the same underlying vertex in the C++ implementation of the graph.

4 4

Re: [Boost-users] How to retrieve a value from a thread
by Nat Goodspeed 09 Mar '06

09 Mar '06

________________________________________ From: boost-users-bounces(a)lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Sliwa, Przemyslaw (London) Sent: Thursday, March 09, 2006 9:47 AM To: boost-users(a)lists.boost.org Subject: [Boost-users] How to retrieve a value from a thread I would like to know if it is possible to retrieve a value returned from a function which is called by a thread. [Nat] Is this thread running continuously, doing other things? Or did you start it for the purpose of calling that function, so that when the function is done the thread terminates? In Java, I've always kind of liked Doug Lea's FutureResult idiom: http://gee.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/Future Result.html I don't know of anything similar in the existing library.

1 0