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

Boost/Python: Solaris build errors
by Bruce Lowery <bruce_lowery＠yahoo.com> 15 Jan '03

15 Jan '03

In building the boost/python library on solaris using v6.2.p2 of the sunpro compiler, two compile-time errors occur, one in 'cast.hpp' and the other in 'inheritance.hpp'. Details are below. --bruce ----------------- 1 -------------------- boost/boost/python/cast.hpp: line 65: Error: Default arguments cannot be added in later declarations of the template function in the same scope. 57 template <class Target, class Source> 58 inline Target* downcast(Source* p, yes_convertible) 59 { 60 return static_cast<Target*>(p); 61 } 62 63 template <class Target, class Source> 64 inline Target* downcast(Source* p, no_convertible, boost::type<Target>* = 0) *** 65 { *** 66 typedef typename base_type_traits<Source>::type base; 67 return (Target*)detail::downcast<base>(p, convertible<Source*>::check((base*)0)); 68 } ----------------- 2 -------------------- boost/boost/python/object/inheritance.hpp: line 134: Error: ")" expected instead of ">". 130 template <class Source, class Target> 131 inline void register_conversion( 132 // We need this parameter because CWPro7 can't determine 133 // which is the base reliably. *** 134 bool is_downcast = !cast_generator<Source,Target>::is_upcast *** 132 133 // These parameters shouldn't be used, they're an MSVC bug workaround 134 , Source* = 0, Target* = 0) 135 { 136 typedef typename cast_generator<Source,Target>::type generator; 137 138 add_cast(python::type_id<Source>() 139 , python::type_id<Target>() 140 , &generator::execute 141 , is_downcast); 142 }

2 2

RE: [Boost-Users] [BGL] missing include in boost/graph/kruskal_mi n_spanning_tree.hpp
by bjorn.karlsson＠readsoft.com 13 Jan '03

13 Jan '03

> From: Jeppe N. Madsen [mailto:yg-boost-users@m.gmane.org] > > Hi, > > kruskal_min_spanning_tree uses bgl_named_params defined in > boost/graph/named_function_params.hpp, which is not included.... Fixed in CVS. Thanks! Bjorn

1 0

BGL: filtered graphs, write_graphviz, and out of memory messages
by sa3h1n <sa3h1n＠yahoo.com> 13 Jan '03

13 Jan '03

Hi all: I am seeing a strange interaction between filtered graphs and write_graphviz. Briefly, if I try to write out a filtered graph via write_graphviz, compilation ends with an out-of-memory message. A necessary condition for this to happen is that the value_type of the property map I am filtering cannot be of a native type -- int is ok, std::string is not. Example code is appended below. I am using Codewarrior Dev Tools 8.0 on WinXP Pro. Given that the code does not even compile, I am not sure how to move beyond this point. Any ideas? TIA, - S ----------------------------------------------------------------- #include "boost/config.hpp" #include <fstream.h> #include <iostream> // for std::cout #include <utility> // for std::pair #include <algorithm> // for std::for_each #include "boost/utility.hpp" // for boost::tie #include "boost/graph/graph_traits.hpp" // for boost::graph_traits #include "boost/graph/adjacency_list.hpp" #include "boost/graph/graphviz.hpp" #include "boost/graph/filtered_graph.hpp" using namespace boost; namespace boost { enum edge_prop_t { edge_prop = 389457 }; BOOST_INSTALL_PROPERTY(edge, prop); } template <typename T> struct positive_edge_prop { positive_edge_prop() {}; positive_edge_prop(T t) : m_prop(t) {}; template <typename Edge> bool operator() (const Edge& e) const { return "foo" == get(m_prop, e); } T m_prop; }; int main(void) { // create an edge property // if std::string is replaced with int, and some attendant changes are made, the code compiles typedef property<edge_prop_t, std::string> EdgeProperty; // create a simple graph type typedef adjacency_list<vecS, vecS, bidirectionalS, no_property, EdgeProperty> Pgraph; enum { A, B, C, D, E, F, N }; const int num_vertices = N; typedef std::pair<int, int> Edge; Edge edge_array[] = { Edge(A, B), Edge(B, C), Edge(C, D), Edge(D, E), Edge(E, F), Edge(F, A), }; const int num_edges = sizeof(edge_array)/sizeof(edge_array[0]); Pgraph pg(edge_array, edge_array + num_edges, num_vertices); // Add edge properties typedef boost::property_map<Pgraph, edge_prop_t>::type ewt; ewt ew = get(edge_prop_t(), pg); boost::graph_traits<Pgraph>::edge_iterator ei, ei_end; boost::tie(ei, ei_end) = edges(pg); for (ei; ei != ei_end; ei++) put(ew, *ei, "bar"); std::map<std::string,std::string> graph_attr, vertex_attr, edge_attr; boost::write_graphviz(std::cout, pg); positive_edge_prop<ewt> filter(get(edge_prop_t(), pg)); filtered_graph<Pgraph, positive_edge_prop<ewt> > fg(pg, filter); boost::write_graphviz(std::cout, fg); // if this line is commented out, the code compiles just fine return 0; } -----------------------------------------------------------------

1 0

Next release date???
by Alejandro Escalante Medina 13 Jan '03

13 Jan '03

Does anyone have an idea for the date of the next release??? Thanks, Alex _________________________________________________________ Do You Yahoo!? La mejor conexión a internet y 25MB extra a tu correo por $100 al mes. http://net.yahoo.com.mx

2 1

Problem with g++ 2.95.3 and boost-example file_dependencies.cpp
by Michael Brinkmann 12 Jan '03

12 Jan '03

Hi, I am trying to get the "file_dependencies"-example compiled and running with the g++-version mentioned above. But, in the function "dijkstra_shortest_paths_no_init()" an exception is thrown and the program terminates prematurely. When hunting the bug with gdb, I get the message "Cannot access memory at address ..." for the parameter "weight", perhaps this is the reason for the exception. Is this a known problem? Will an upgrade to a higher g++-version help me, or has someone another hint? Thanks in advance Michael

1 0

threads - using boost.threads in win32 without use of dll?
by Phil Nash 12 Jan '03

12 Jan '03

Hi, I understand that on the win32 platforms boost.threads requires a dll to be build - threadmon. I seem to remember that this is there as a workaround to help support thread local storage (but I can't seem to find mention of it in the docs now, so I am not 100% sure of this). If this is the case, is it possible to use boost.threads *without* the dll if thread local storage is not being used? Regards, [)o IhIL..

1 0

boost::signal and thread-safety
by svanechel <svanechel＠yahoo.com> 11 Jan '03

11 Jan '03

Hi, The signal FAQ says that currently boost::signals aren't thread-safe. I'm guessing this applies to connecting/disconnecting slots from different threads and calling a signal from multiple threadsl, right? If synchronize access when connecting slots and make sure that only a single thread calls a certain signal, can I then use boost::signal to fire events from objects that do processing in a worker thread? As a secondary question: how far in the future will this thread- safety support be added? Thanks in advance, Sven

2 2

[BGL] missing include in boost/graph/kruskal_min_spanning_tree.hpp
by Jeppe N. Madsen 11 Jan '03

11 Jan '03

Hi, kruskal_min_spanning_tree uses bgl_named_params defined in boost/graph/named_function_params.hpp, which is not included.... rgds Jeppe

1 0

(no subject)
by Wilken, Marc 11 Jan '03

11 Jan '03

Hello, does anyone knows, if a construct like out(blitz::Range(0,2))=inp(blitz::Range(0,2)); (that means accesing and assigning of matrix/vector ranges) exist for boost::numeric::ublas too? Marc This e-mail contains confidential information for the exclusive attention of the intended addressee. Any access of third parties to this e-mail is unauthorised. Any use of this e-mail by unintended recipients such as copying, distribution, disclosure etc. is prohibited and may be unlawful. When addressed to our clients the content of this e-mail is subject to the General Terms and Conditions of GL's Group of Companies applicable at the date of this e-mail. GL's Group of Companies does not warrant and/or guarantee that this message at the moment of receipt is authentic, correct and its communication free of errors, interruption etc.

2 1

BGL, vertex_iterators, listS vs vecS
by sa3h1n <sa3h1n＠yahoo.com> 11 Jan '03

11 Jan '03

BGL gurus: I would like to use listS for vertex and edge lists because of iterator stability. However, if I run the following code: ------------ // use listS typedef adjacency_list<listS, listS> Pgraph; // use vecS typedef adjacency_list<vecS, vecS> Pgraph2; int num_vertices = 2; Pgraph pg (num_vertices); boost::graph_traits<Pgraph>::vertex_iterator vi, vi_end; boost::tie(vi, vi_end) = vertices(pg); Pgraph2 pg2 (num_vertices); boost::graph_traits<Pgraph2>::vertex_iterator vi2, vi_end2; boost::tie(vi2, vi_end2) = vertices(pg2); for (vi, vi2; vi != vi_end && vi2 != vi_end2; vi++, vi2++) { std::cout << *vi << std::endl; std::cout << *vi2 << std::endl; } ------------ I get the following output: ------------ 0x00146e60 <- this is *vi which uses listS 0 <- this is *vi2 which uses vecS 0x00146e78 <- this is *vi which uses listS 1 <- this is *vi2 which uses vecS ------------ One of the problems with this is when I try to display the graph using write_graphviz. Vertex indices turn out be 0x0014e60 etc instead of nice numbers like 0, 1, etc. Tracing execution through the debugger, it appears that vi and vi_end are of type generic_iterator(), whereas vi2 and vi2_end are of type iterator_adaptor() defined in boost/iterator_adaptors.hpp . Unfortunately, this is where my c++ expertise peters out. So what is happenning here? And is there anything I can do to ensure iterator stability while using vecS? Any help will be much appreciated, S

2 2