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

[Linker error] undefined reference to `boost::gregorian::greg_month::as_short_string() const'
by Zhoujie Mao 28 Sep '04

28 Sep '04

Hi everyone, I just downloaded boost, built it on windows using cygwin. However, when I tried to run an example program. I got a the following link error [Linker error] undefined reference to `boost::gregorian::greg_month::as_short_string() const' I have added the corresponding lib and include directories to my make file. Is there anything I am missing? Any help will be greatly appreciated. George __________________________________ Do you Yahoo!? Y! Messenger - Communicate in real time. Download now. http://messenger.yahoo.com

3 9

newbie: build support for HP-UX and aCC compiler
by arno.schaefer＠sqs.de 28 Sep '04

28 Sep '04

Hi all, I want to use the boost libraries an HP-UX 11.xx with Compiler aCC version "A.03.45". Because I found til now no hint, that the aCC compiler is directly supported by your tools list, I want to ask, if there are some experience with this compiler and the actual boost version and perhaps a reference to a description how to build the library with aCC. Thanks for your help Arno

4 3

not working after upgrade
by Fred J. 27 Sep '04

27 Sep '04

Hello I am having a problem compiling a simple program with some boost lib. the problem happend after I apt-get update && apt-get upgrade my testing debian. my program #include "/usr/include/boost/filesystem/operations.hpp" #include "/usr/include/boost/filesystem/fstream.hpp" #include "/usr/include/boost/filesystem/path.hpp" ... on compileing I get g++ -g -Wall -c -o main.o main.cpp In file included from /usr/include/boost/filesystem/operations.hpp:18, from main.cpp:1: /usr/include/boost/filesystem/path.hpp:15:39: boost/filesystem/config.hpp: No such file or directory In file included from /usr/include/boost/filesystem/operations.hpp:18, from main.cpp:1: $locate config.hpp /usr/include/boost/config.hpp /usr/include/boost/config/select_compiler_config.hpp /usr/include/boost/config/select_platform_config.hpp /usr/include/boost/config/select_stdlib_config.hpp /usr/include/boost/lambda/detail/lambda_config.hpp /usr/include/boost/numeric/ublas/config.hpp /usr/include/boost/preprocessor/config/config.hpp /usr/include/boost/spirit/core/config.hpp /usr/include/boost/type_traits/config.hpp /usr/include/boost/variant/detail/config.hpp /var/boost/boost_1_31_0/boost/config.hpp /var/boost/boost_1_31_0/boost/config/select_compiler_config.hpp /var/boost/boost_1_31_0/boost/config/select_platform_config.hpp /var/boost/boost_1_31_0/boost/config/select_stdlib_config.hpp /var/boost/boost_1_31_0/boost/date_time/compiler_config.hpp /var/boost/boost_1_31_0/boost/date_time/locale_config.hpp /var/boost/boost_1_31_0/boost/date_time/posix_time/posix_time_config.hpp /var/boost/boost_1_31_0/boost/filesystem/config.hpp /var/boost/boost_1_31_0/boost/lambda/detail/lambda_config.hpp /var/boost/boost_1_31_0/boost/numeric/ublas/config.hpp /var/boost/boost_1_31_0/boost/preprocessor/config/config.hpp /var/boost/boost_1_31_0/boost/python/detail/config.hpp /var/boost/boost_1_31_0/boost/regex/config.hpp /var/boost/boost_1_31_0/boost/signals/detail/config.hpp /var/boost/boost_1_31_0/boost/spirit/core/config.hpp /var/boost/boost_1_31_0/boost/test/detail/unit_test_config.hpp /var/boost/boost_1_31_0/boost/thread/detail/config.hpp /var/boost/boost_1_31_0/boost/type_traits/config.hpp /var/boost/boost_1_31_0/boost/variant/detail/config.hpp thanks __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 1

Bad interaction between boost::bind and Boost.Python?
by Nat Goodspeed 24 Sep '04

24 Sep '04

With the files newly unpacked from boost_1_31_0.zip, using MS VS .NET 2003 (aka 7.1), the following two-line source file: #include <boost/bind.hpp> #include <boost/python.hpp> compiled with the following command line: cl /c /I "c:/Dev/boost_1_31_0" /I "$PYTHONDIR/include" /EHsc test.cpp produces these errors: Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.10.3077 for 80x86 Copyright (C) Microsoft Corporation 1984-2002. All rights reserved. test.cpp c:/Dev\boost_1_31_0\boost\mpl\less.hpp(39) : error C2760: syntax error : expected ',' not ';' c:/Dev\boost_1_31_0\boost\mpl\less.hpp(51) : see reference to class template instantiation 'boost::mpl::less<T1,T2>' being compiled c:/Dev\boost_1_31_0\boost\mpl\less.hpp(39) : error C2144: syntax error : 'const bool' should be preceded by '}' c:/Dev\boost_1_31_0\boost\mpl\less.hpp(39) : error C2062: type 'const bool' unexpected c:/Dev\boost_1_31_0\boost\mpl\less.hpp(39) : error C2238: unexpected token(s) preceding ';' c:/Dev\boost_1_31_0\boost\mpl\less.hpp(42) : error C2065: 'value' : undeclared identifier Reversing the order of 'bind.hpp' and 'python.hpp' results in a clean compile. I'm trying to upgrade from Boost 1.30.2 to 1.31.0 today, but this bug is turning into quite a problem because of deep nesting of our own #include files. It hasn't yet become a show-stopper; but it's certainly taking me a great deal of effort to try to propagate every #include <boost/python*> -- and every file that includes it! - higher in its includer's #include list than any #include <boost/bind.hpp>. Please tell me there's a better way.

3 2

using graph_property_iter_range::const_iterator
by Jeffrey Holle 24 Sep '04

24 Sep '04

I'm using boost 1_31_0 and gcc 3.4.2. I'm adding an iterator interface to my class that abstracts use of internal boost graph properties and have had success with one exception that involves const_iterator. Here is how this class looks: struct VertexData { typedef boost::graph_property_iter_range <DataGraphT,vertex_Datum_t>::iterator iterator; typedef boost::graph_property_iter_range <DataGraphT,vertex_Datum_t>::const_iterator const_iterator; typedef Vertex_Datum value_type; VertexData(DataGraphT& dataGraph); iterator begin(void) {return boost::get_property_iter_range(dataGraph_,vertex_Datum).first;} // const_iterator begin(void) const {return boost::get_property_iter_range(dataGraph_,vertex_Datum).first;} iterator end(void) {return boost::get_property_iter_range(dataGraph_,vertex_Datum).second;} // const_iterator end(void) const {return boost::get_property_iter_range(dataGraph_,vertex_Datum).second;} When I uncomment the const begin method, I get the following compilation error: dataGraph.h:30: error: conversion from `boost::detail::lvalue_pmap_iter<boost::counting_iterator<size_t, boost::use_default, boost::use_default>, boost::subgraph_global_property_map<DataGraphT*, boost::vec_adj_list_vertex_property_map<boost::adjacency_list<boost::vecS, boost::vecS, boost::bidirectionalS, boost::property<boost::vertex_index_t, int, VertexProperty>, EdgeProperty, boost::no_property, boost::listS>, boost::adjacency_list<boost::vecS, boost::vecS, boost::bidirectionalS, boost::property<boost::vertex_index_t, int, VertexProperty>, EdgeProperty, boost::no_property, boost::listS>*, Vertex_Datum, Vertex_Datum&, vertex_Datum_t> > >' to non-scalar type `boost::detail::lvalue_pmap_iter<boost::counting_iterator<size_t, boost::use_default, boost::use_default>, boost::subgraph_global_property_map<const DataGraphT*, boost::vec_adj_list_vertex_property_map<boost::adjacency_list<boost::vecS, boost::vecS, boost::bidirectionalS, boost::property<boost::vertex_index_t, int, VertexProperty>, EdgeProperty, boost::no_property, boost::listS>, const boost::adjacency_list<boost::vecS, boost::vecS, boost::bidirectionalS, boost::property<boost::vertex_index_t, int, VertexProperty>, EdgeProperty, boost::no_property, boost::listS>*, Vertex_Datum, const Vertex_Datum&, vertex_Datum_t> > >' requested Could somebody point out the problem here?

2 2

Using Boost Tuple Library instead of variadic macros
by Barak Simon 24 Sep '04

24 Sep '04

Hi, I am trying to use the Tuple library in order to provide a logging interface which can get a variable number of parameters and handle them in a type-safe manner. However, though constructing a tuple by make_tuple seems easy enough (from a logging's user point of view) implementation wise, I am not sure how to actually iterate on the make_tuple_mapper which is being provided to my logging method, as generically getting the length and using invoking "get" on it does not work due to compile-time reasons (and there are no iterators available). I am sure it must be possible to do it somehow, or else the ostream serialisation capabilities would not have been possible to implement, but I guess I am just not sophisticated enough to fully grasp the MP intricacies... My logging method currently looks like that: template<class TheTuple> inline void logTuple(TheTuple theTuple) { } which might not be the correct way about it, but I was not sure how to explicitly provide a tuple type that's created by make_tuple, let alone how to iterate on the values. Any help with this would be greatly appreciated. Thanks, Barak _________________ Barak Simon GED IT Core Platform Deutsche Bank 190 George St. Sydney, 2000 Phone +61 2 925 85070 Fax +61 2 925 95050 -- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

2 1

Does BGL support hypergraph?
by Peng Yu 24 Sep '04

24 Sep '04

Hi, I notices that there is some discussion about hypergraph in the mailing list archives 2 years ago. Is hypergraph implementation in BGL now? Best wishes, Peng

2 1

RE: [Boost-users] Re: Bad interaction between boost::bindandBoost.Python?
by Nat Goodspeed 23 Sep '04

23 Sep '04

> -----Original Message----- > From: David Abrahams [mailto:dave@boost-consulting.com] > Sent: Thursday, September 23, 2004 8:24 AM > To: boost-users(a)lists.boost.org > Subject: [Boost-users] Re: Bad interaction between > boost::bindandBoost.Python? > > In principle your boost/python header has to be #included first [before boost/bind] > anyway, at least if you intend your code to run on POSIX. [Nat] ? I don't understand why that would be? Shouldn't each header #include everything to make it self-sufficient, rather than depending on the includer's prior #includes? > All I can > suggest is that you try the latest Boost CVS state, which doesn't have > this problem. A new release of Boost is imminent anyway. [Nat] That's fair, and thanks for testing it. But given the amount of time I've spent so far on this 1.31.0 upgrade, I'm going to lay low for a few days before announcing that I intend to upgrade to yet another version of Boost... ;-)

2 1

Re: A boost.graph edge problem
by Lars Kunert 23 Sep '04

23 Sep '04

Have a look at your compare operator! It orders two pairs of values (A,B)(C,D) like this: (A<B) || (!(A<B) && (C<D)) this expession equals: (A<B) || (C<D) lets consider the test case: (1,2) (2,1) Your operator will return return true in whatever order this pair is compared... I think an operator like (A<B) || ((A==B) && (C<D)) will help > ... > typedef multiset<DataEdge,ltSubgraph> Edges; > ... > struct ltSubgraph : public > std::binary_function<DataEdge,DataEdge,bool> > { > bool operator() (const DataEdge& s1, const DataEdge& s2) const > { > return s1.m_source < s2.m_source || > (!(s1.m_source < s2.m_source) && s1.m_target < s2.m_target); > } > };

1 0

A boost.graph edge problem
by Jeffrey Holle 23 Sep '04

23 Sep '04

I'm using boost 1.31.0 and gcc 3.4.2. While this problem is more of an application code problem, since I got no help on other lists, I trying this one with hopes of a response. I need to identify parallel edges from my graph, which is defined as: typedef subgraph<adjacency_list<vecS, vecS, bidirectionalS, property<vertex_index_t,int,VertexProperty>, EdgeProperty> > DataGraphT; typedef boost::graph_traits <DataGraphT>::edge_descriptor DataEdge; In the test case that I'm working on, I know I have parallel edges, actually 4 sets of 3. I'd like to use this code: DataGraph::handleParallelEdges(void) { typedef multiset<DataEdge,ltSubgraph> Edges; Edges edges; graph_traits<DataGraphT>::edge_iterator ei,ei_end; for (tie(ei,ei_end)=boost::edges(dataGraph_);ei!=ei_end;++ei) edges.insert(*ei); for (Edges::const_iterator iter = edges.begin(); iter != edges.end(); advance(iter,edges.count(*iter))) if (edges.count(*iter)>1) cout << "See duplicate" << endl; } However, when count never returns. The likely cause of this (I suspect) is the ltSubgraph functor. Its definition is: struct ltSubgraph : public std::binary_function<DataEdge,DataEdge,bool> { bool operator() (const DataEdge& s1, const DataEdge& s2) const { return s1.m_source < s2.m_source || (!(s1.m_source < s2.m_source) && s1.m_target < s2.m_target); } }; I say this because I can see that this functor is being continuously called in this infinite loop. Note that I use this functor in multiple other cases, but not with an associate container that allows duplicate keys. Is there a problem with this code?

1 1