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

grid graph for BGL
by toddgleason 24 Sep '02

24 Sep '02

Hi, I'm new to using the BGL, and have been working on a problem that uses a directed acyclic grid graph and subgraphs, and computes shortest paths. In my problem, the subgraphs are determined by paths from one end to the other. It is possible to determine in constant time whether a grid point or edge is within the graph, by looking at the paths bounding the subgraph. I started out using adjacency_list and filtered_graph to limit the graph, but this is not optimal because adjacency_list iterates over all vertices in the original graph to filter them. Ideally I'd like to use the indices from the master graph but be able to dynamically iterate over them according to the computations the code performs to limit the scope of the graphs. However, I'm not sure if anyone has done anything like this, and I'm a little frightened of trying to write my own graph class into the BGL structure. (I've never dealt with such heavily templated code before, and am even more confused than when looking at the STL!) Are there any pointers anyone can give me that would make it easier to construct such a class? Another option I'll throw out: Might it be simpler to hack one of the shortest paths algorithms to do a better job of restricting itself based on the dynamic subgraph filtering? I considered this (the code looks shorter and simpler), but it'd be cleaner to have a new graph class. Thanks to any who can help me. Also, I'm using VC++ 6 so all the problems with partial template specialization (which I don't even understand) apply to me. --Todd C. Gleason

3 3

None
by Antonio Piccolboni 24 Sep '02

24 Sep '02

Dear Boosters Suppose you have a matrix represented raw-wise with a vector< vector <float > > and you want to iterate over the coloumns. Easy with the projection adaptor. But life is never so easy. My matrix is represented raw wise by a map <vector <float> > and I need the same kind of iterator. There is no way I can get my code to compile. I think the problem is that vector iterators return values, map iterators retun pairs <key,value> (that is, references to the above). And this seems not only to doom my attempt at defining this n-th dim projection iterator, but even more so and fundamentally, it seem to preclude my ultimate goal of defining a projection for any container1 <containr2 < element_type > > where container2 two is random access. Any help would be appreciated and if I make it to the larger goal, I will return it to the community. Thanks Antonio Header #ifndef GRAPH_H #define GRAPH_H #include <boost/config.hpp> #include <vector> #include <iostream> #include <iterator> #include <algorithm> #include <boost/iterator_adaptors.hpp> //typedef pair<long, vector<float> > graph_element; typedef vector<float> graph_element; template <int index> struct select_component { typedef pair < long, graph_element > argument_type; typedef float result_type; const float & operator()(const graph_element & r) const { return r.second[index]; } float & operator()(graph_element & r) const { return r.second[index]; } }; #endif Would be test code #include "graph.h" #include <map> #include<vector> int main(int, char*[]) { typedef map < long, graph_element > graph; graph aGraph; aGraph[0].push_back(0.00); aGraph[0].push_back(0.01); aGraph[0].push_back(0.02); aGraph[1].push_back(0.10); aGraph[1].push_back(0.11); aGraph[1].push_back(0.12); aGraph[2].push_back(0.20); aGraph[2].push_back(0.21); aGraph[2].push_back(0.22); aGraph[3].push_back(0.30); aGraph[3].push_back(0.31); aGraph[3].push_back(0.32); boost::projection_iterator_generator < select_component < 0 >, graph::iterator >::type graph_first(aGraph.begin()), graph_last(aGraph.end()); copy(graph_first, graph_last, ostream_iterator<float>(cout, "\n")); cout << endl; } Post-modern error message cd /home/apicco/src/analysis/transcriptome/transmap/ g++ -g -I/home/apicco/install/boost_1_28_0 -o graph-test graph-test.C /home/apicco/install/boost_1_28_0/boost/iterator_adaptors.hpp: In method `typename IteratorAdaptor::reference boost::projection_iterator_policies<AdaptableUnaryFunction>::dereferen ce (const IteratorAdaptor &) const [with IteratorAdaptor = boost::iterator_adaptor<_Rb_tree_iterator<pair<const long int, graph_element>, pair<const long int, graph_element> &, pair<const long int, graph_element> *>, boost::projection_iterator_policies<select_component<0> >, float, float &, float *, boost::detail::default_argument, boost::detail::default_argument>, AdaptableUnaryFunction = select_component<0>]': /home/apicco/install/boost_1_28_0/boost/iterator_adaptors.hpp:867: instantiated from `boost::iterator_adaptor<Base, Policies, Value, Reference, Pointer, Category, Distance>::operator* () const [with Base = _Rb_tree_iterator<pair<const long int, graph_element>, pair<const long int, graph_element> &, pair<const long int, graph_element> *>, Policies = boost::projection_iterator_policies<select_component<0> >, Value = float, Reference = float &, Pointer = float *, Category = boost::detail::default_argument, Distance = boost::detail::default_argument]' /usr/include/g++-3/stl_algobase.h:129: instantiated from `__copy (_InputIter, _InputIter, _OutputIter, input_iterator_tag, _Distance *) [with _InputIter = boost::iterator_adaptor<_Rb_tree_iterator<pair<const long int, graph_element>, pair<const long int, graph_element> &, pair<const long int, graph_element> *>, boost::projection_iterator_policies<select_component<0> >, float, float &, float *, boost::detail::default_argument, boost::detail::default_argument>, _OutputIter = ostream_iterator<float>, _Distance = ptrdiff_t]' /usr/include/g++-3/stl_algobase.h:161: instantiated from `__copy_dispatch<_InputIter, _OutputIter, _BoolType>::copy (_InputIter, _InputIter, _OutputIter) [with _InputIter = boost::iterator_adaptor<_Rb_tree_iterator<pair<const long int, graph_element>, pair<const long int, graph_element> &, pair<const long int, graph_element> *>, boost::projection_iterator_policies<select_component<0> >, float, float &, float *, boost::detail::default_argument, boost::detail::default_argument>, _OutputIter = ostream_iterator<float>, _BoolType = __true_type]' /usr/include/g++-3/stl_algobase.h:188: instantiated from `copy (_InputIter, _InputIter, _OutputIter) [with _InputIter = boost::iterator_adaptor<_Rb_tree_iterator<pair<const long int, graph_element>, pair<const long int, graph_element> &, pair<const long int, graph_element> *>, boost::projection_iterator_policies<select_component<0> >, float, float &, float *, boost::detail::default_argument, boost::detail::default_argument>, _OutputIter = ostream_iterator<float>]' graph-test.C:30: instantiated from here /home/apicco/install/boost_1_28_0/boost/iterator_adaptors.hpp:1247: no match for call to `(const select_component<0>) (pair<const long int, graph_element> &)' graph.h:19: candidates are: const float &select_component<index>::operator() (const graph_element &) const [with int index = 0] graph.h:22: float &select_component<index>::operator () (graph_element &) const [with int index = 0] Compilation exited abnormally with code 1 at Tue Sep 24 11:14:11

1 0

Borland C++ Builder 5.5 & scoped_ptr
by Brian Neal 24 Sep '02

24 Sep '02

I'm new here; I searched the Yahoo archive and didn't see anything about this so I apologize if this has been discussed before. Today I learned (the hard and painful way) that there is a bug in Borland C++ Builder 5.5 such that when compiling with debug support, the compiler thinks it needs to generate destructors in the wrong translation units. We noticed this because we were using the "handle-body" idiom with auto_ptr's (taking all the precautions from Herb Sutter's Exceptional C++ books) and our destructors were not getting called. We switched over to boost::shared_ptr's and the handy-dandy compile time check in the destructor for incomplete types was firing...but in the code that uses and declares objects of the classes that have the handle-body idiom...a pretty serious bug in my view. We then tried to compile the example code from boost for scoped_ptr and it would not compile for the same reason. A quick search of the newsgroups reveals that others have found this bug, and C++ Builder is the only major compiler that has this flaw. I've heard that it has been fixed in version 6. Can others verify this? So I am posting this for 2 reasons: 1) to let others know about it (in case you don't know already), and 2) I noticed that in the Boost compiler status web-page it says that smart_ptr passed all its tests with C++ Builder 5.5.1. I didn't look at the tests, but was this handle-body type usage tested to make sure the destructor was called? Or perhaps it was but without debug support turned on? Thanks, Brian Neal

6 12

Using regex++ with non-standard character types
by miles_gould 24 Sep '02

24 Sep '02

Our application stores all characters internally as XMLCh, which is a typedef to either wchar_t or unsigned short, depending on platform and various other things. My questions are 1) Is it even possible to use regex++ with types which are not char or wchar_t? The documentation gives no examples of any other types, and at one point says "the character type, ie char or wchar_t". When I try to construct a reg_expression<XMLCh>, I get the following error message: ../../src/boost/boost/regex.hpp: In instantiation of `boost::regex_traits<unsigned int>': ../../src/boost/boost/regex.hpp:461: instantiated from `boost::reg_expression<unsigned int, boost::regex_traits<unsigned int>, allocator<size_t> >' regex.cpp:33: instantiated from here ../../src/boost/boost/regex.hpp:461: base class `boost::c_regex_traits<unsigned int>' has incomplete type ../../src/boost/boost/regex.hpp: In instantiation of `boost::reg_expression<unsigned int, boost::regex_traits<unsigned int>, allocator<size_t> >': regex.cpp:33: instantiated from here ../../src/boost/boost/regex.hpp:461: no type named `size_type' in `class boost::regex_traits<unsigned int>' ../../src/boost/boost/regex.hpp:462: no type named `uchar_type' in `class boost::regex_traits<unsigned int>' ../../src/boost/boost/regex.hpp:463: no type named `string_type' in `class boost::regex_traits<unsigned int>' ../../src/boost/boost/regex.hpp:471: no type named `locale_type' in `class boost::regex_traits<unsigned int>' [compilation is on GCC 2.96 under Red Hat Linux 7.2] 2) Does this mean I need to define a custom traits class? (or rather a custom traits class for every possible definition of XMLCh?) Is there anything else I need to do?

3 2

VxWorks was Re: shared_ptr documentation suggestion
by Brian Neal 23 Sep '02

23 Sep '02

> From: "Peter Dimov" <pdimov(a)mmltd.net> > From: "Brian" <bneal(a)zeus.ia.net> > >... > > BTW, can I submit a VxWorks version of shared_count? Does boost have > > an interest in expanding beyond Win32/Posix/Linux? > > Yes. Platform-specific implementations of detail::atomic_count (used by > 1.27) and detail::lightweight_mutex (used by the later versions) are > welcome. Please take the time to read the comments in (the latest versions > of) atomic_count.hpp and lightweight_mutex.hpp, though, as > writing optimized > threading primitives by hand is very difficult and error prone, > as I learned > the hard way. Of course a realtime OS should already have such primitives; > I'm not familiar with VxWorks. I am interested in doing this. I will take a look at those files. VxWorks has primitives for these operations already. I would also like to take on getting boost threads running under VxWorks, but I am not sure if I have the time right now. I'll look into it. We already have thread classes that wrap both VxWorks and Win32 so our software runs on both. Last time I looked, boost threads were pretty simplistic (understandably at this point in time). Why is the boost 1.28.0 zip distro 5.6 Megs COMPRESSED! Is it really that big or is it all those pictures and documentation files? Thanks, Brian

1 0

Compiling boost under gcc 2.95.3/solaris
by Wen Yu 23 Sep '02

23 Sep '02

Hi! I'm running into the brickwall now while trying to port "boost" containing codes from VC7 to gcc. Anyone has a pointer to a makefile for this combination. The codes works flawlessly inside Microsoft .NET IDE. I've tried ./configure script, manually edit the "user.hpp" and many fruitless hours to no aval. The "bjam" build of the library seems to be at least partially sucesful. Please help before I had to abandon the ship. Thanks! Wen

2 2

pointer traints ?
by Bohdan 23 Sep '02

23 Sep '02

I have following code: template < typename PointerT > void f( PointerT ptr ) { ReferenceT ref = *ptr; // ... do something with ref ... } The problem is that ReferenceT is unknown inside f( ... ). If i had similar code for InteratorT instead of PointerT i was using iterator_traits. AFAIK there is no pointer traits for a raw and smart pointers and i can not use type_traits for smart pointers. So, the question is: "Is there some simple solution for this problem or this is just lack of pointer_traits in boost (std?) ?" regards, bohdan

1 0

what's the purpose of the typedef in check_delete.hpp?
by zhangwusheng 23 Sep '02

23 Sep '02

Why?And for what purpose? I cannot understand the following words: // verify that types are complete for increased safety thanks

4 4

Bind problems
by judoka1981 23 Sep '02

23 Sep '02

Hi, I'm trying to find the first non-space character of a string using boost::bind, but I simply can't get this to compile: --- static void Trim(std::string& stringToTrim) { std::string::iterator firstNonSpace = std::find_if(stringToTrim.begin(), stringToTrim.end(), boost::bind(std::not_equal_to<int>(), boost::bind(&isspace, _1), 0)); .... --- Am I doing something seriously wrong, or is this a compiler limitation (VC.NET)? (If anyone has a method to do this without using isspace, I'd be happy to see it). Thanks // Johan

3 4

Include directories
by sashang＠ihug.co.nz 23 Sep '02

23 Sep '02

This is a silly question. I feel silly asking it. How do I tell the compiler via the jamfile about extra directories to look in for include files? I've tried adding "-sHDRS=e:/mystuff/include" to the command line when invoking bjam. I've tried placing : <include>e:/mystuff/include at various places withing the jam file. Thanks Sashan

1 0