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

[bgl] undirected_dfs to find cut-vertices
by Stephan Höfer 20 Oct '03

20 Oct '03

Hello, I build a visitor for an undirected graph which finds the cut-vertices of a given undireted graph or subgraph. I haven't found an implementation of the algorithm in the bgl. Maybe it would have been possible to use the predecessor_recorder for that. But then all the information which can be found directly while doing the df-search we have to find after having performed that search first. The interface of the undirected_dfs function doesn't take visitors via reference, so it wasn't possible to use that function. I had to call the detail::undir_dfv_impl function instead because that function takes a visitor reference and I had to recreate a function with the behaviour of the undirected_dfs. What reasons lead to the decision to disable passing a visitor by reference directly to undirected_dfs? What reasons lead to the decision to pass a const graph to a visitor function? Some useful things are disabled by that (but maybe also some bad things). Cheers, Stephan

2 1

Inconsistency in graph Example Code, Documentation
by Thomas F. O'Connell 20 Oct '03

20 Oct '03

This is a minor point but one worth correcting for the sake of correctness and ease of following the examples. In the boost-1.30.2 distribution, the file libs/graph/example/kevin-bacon.cpp makes a reference to a "./kevin-bacon.dat" file, but the file in both the distribution and the documentation is actually kevin_bacon.dat. The only difference being '_' vs. '-'. This is easily fixed by an end-user, but it would be nice to have the examples work out of the box. -tfo

3 3

Bug in graph library transitive closure algorithm?
by Watson, Jean-paul 20 Oct '03

20 Oct '03

Is anyone aware of any bugs in the graph library 'transitive_closure' algorithm? I believe I have a concrete example that exhibits an obvious bug (in particular, missing vertices that are reachable from certain source vertices), but (1) wasn't sure if there was a work-around or some well-known avoidance tactic and (2) whether anyone was actively supporting the graph library components. Thanks! Jean-Paul Watson E-mail: jwatson(a)sandia.gov Discrete Math Dept (9215), MS 1110 Phone: (505) 845-8887 P.O. Box 5800, Sandia National Labs FAX: (505) 845-7442 Albuquerque, NM 87185-1110 USA (Old) URL: http://www.cs.colostate.edu/~watsonj <http://www.cs.colostate.edu/~watsonj>

3 2

novice question: LAPACK & uBLAS
by Derek 18 Oct '03

18 Oct '03

Hi, I am a novice to all this. I am looking for a C++ library that would let me interface with BLAS/LAPACK. The immediate problem I have is the diagonalization of a large dense symmetric (possibly hermitian) matrix. (Speed will be a consideration eventually.) I would like to use the eigenproblem solvers in LAPACK. I understand that uBLAS does not have a full interface to LAPACK yet, but it looks like it is possible to use lapack at some level. (Does anyone have an example program excerpt?) I would be grateful for any advice about whether uBLAS is suitable for this. I am also considering other libraries such as MTL and Blitz++. I will be using Intel C++ compiler and/or GNU g++ on a Linux PC. Regards Derek

2 2

Necessity of assert in iterators (as called from graph)?
by Thomas F. O'Connell 17 Oct '03

17 Oct '03

In trying to compile and run the Kevin Bacon example for graph in the 1.30.2 distribution of Boost, I was able to compile, but when I ran the executable, I got: kevin-bacon: /usr/local/boost-1.30.2/boost/token_iterator.hpp:75: void boost::detail::tokenizer_policy<Type, TokenizerFunc>::increment(Iterator&) [with Iterator = boost::iterator_adaptor<boost::detail::token_iterator_base<__gnu_cxx::__normal_iterator<const char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > > >, boost::detail::tokenizer_policy<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, boost::char_delimiters_separator<char, std::char_traits<char> > >, std::basic_string<char, std::char_traits<char>, std::allocator<char> >, const std::basic_string<char, std::char_traits<char>, std::allocator<char> >&, const std::basic_string<char, std::char_traits<char>, std::allocator<char> >*, std::forward_iterator_tag, ptrdiff_t>, Type = std::basic_string<char, std::char_traits<char>, std::allocator<char> >, TokenizerFunc = boost::char_delimiters_separator<char, std::char_traits<char> >]: Assertion `b.base().valid_' failed. Aborted Investigating led me to comment out the asserts on lines 69 and 75 of boost/token_iterator.hpp just to test. When I rebuilt without the asserts, I was able to run my executable with no problem with seemingly correct output. What purpose do the asserts serve, and why would they be failing? -tfo

2 2

RE: [Boost-users] [Q] shared_ptr c'tor
by Tom Matelich 17 Oct '03

17 Oct '03

The shared_ptr constructor from raw pointer is marked explicit (quick explanation: http://www.glenmccl.com/tip_023.htm) This is because once you put a pointer into a shared_pointer, it's lifetime is now managed by the shared_ptr. The authors feel it is very important that this is completely intentional, and rightly so. It can have nasty side effects if you don't. //untested code void foo(boost::shared_ptr<int> p) { (*p)++; } int main() { int* p = new int(5); foo(p); std::cerr << "p is now " << *p << std::endl; //oops, p has been deleted!!! return 0; } > -----Original Message----- > From: Marcel Loose [mailto:loose@astron.nl] > Sent: Friday, October 17, 2003 4:39 AM > To: boost-users(a)lists.boost.org > Subject: [Boost-users] [Q] shared_ptr c'tor > > > Hi, > > I have a question related to the boost::shared_ptr constructor. > I want to be able to store boost::shared_ptr<Base> objects in > a std::vector. However, I don't want to bother my users with > the fact (implementation detail) that I'm using shared_ptrs > instead of raw pointers. > > The simplified sample code below more or less clarifies what > I want. The code in line 27 is the code I would like to be > able to use. Below that line, several attempts to get the > code to compile can be found. I understand that line 32 won't > compile, because it is equivalent to line 27. However, line > 37 left me puzzled. I would expect that the conversion of B* > to shared_ptr<B> would be trivial. Not so. > > Is it really true that the only way to use shared_ptr in the > way I want is as in lines 46, 47? Or am I overlooking > something? And is line 41 equivalent to line 46? > Thanks in advance. > > Regards, > > Marcel Loose. > > P.S.: I noticed that all code will compile if I omit the > "explicit" keyword in the constructor of shared_ptr, but I > don't consider that the proper way to solve the problem. > > > 1:#include <boost/shared_ptr.hpp> > 2:#include <vector> > 3: > 4:using namespace std; > 5:using namespace boost; > 6: > 7:class Base > 8:{ > 9:public: > 10: Base() { /* ... */ } > 11: virtual ~Base() {} > 12:}; > 13: > 14:class Derived : public Base > 15:{ > 16:public: > 17: Derived() { /* ... */ } > 18: virtual ~Derived() {} > 19:}; > 20: > 21: > 22:int main() > 23:{ > 24: vector<shared_ptr<Base> > v; > 25: > 26: { // failes to compile: > 27: v.push_back(new Derived()); // cannot > convert Derived*& > 28: } // to > shared_ptr<Base>. Why? > 29: > 30: { // failes to compile: > 31: Derived* d(new Derived()); // cannot > convert Derived*& > 32: v.push_back(d); // to > shared_ptr<Base>. Why? > 33: } > 34: > 35: { // failes to compile: > 36: Base* b(new Derived()); // cannot convert Base*& > 37: v.push_back(b); // to > shared_ptr<Base>. Huh? > 38: } // Seems a > trivial conversion. > 39: > 40: { // OK, this > compiles, but is > 41: shared_ptr<Derived> d(new Derived()); // it correct? > I.e. is conversion > 42: v.push_back(d); // > shared_ptr<Derived> to > 43: } // > shared_ptr<Base> trivial? > 44: > 45: { // OK, this > compiles, and is > 46: shared_ptr<Base> b(new Derived()); // probably > what I meant. > 47: v.push_back(b); // However, I > dislike the > 48: } // verbosity. > 49: > 50: return 0; > 51:} > > Just to be complete, please find the compiler diagnostics below. > > tBoost.cc: In function `int main()': > tBoost.cc:27: no matching function for call to ` > std::vector<boost::shared_ptr<Base>, > std::allocator<boost::shared_ptr<Base> > > >::push_back(Derived*&)' > /usr/local/gcc-3.2.1/include/c++/3.2.1/bits/stl_vector.h:490: > candidates are: > void std::vector<_Tp, _Alloc>::push_back(const _Tp&) [with _Tp = > boost::shared_ptr<Base>, _Alloc = > std::allocator<boost::shared_ptr<Base> >] > tBoost.cc:32: no matching function for call to ` > std::vector<boost::shared_ptr<Base>, > std::allocator<boost::shared_ptr<Base> > > >::push_back(Derived*&)' > /usr/local/gcc-3.2.1/include/c++/3.2.1/bits/stl_vector.h:490: > candidates are: > void std::vector<_Tp, _Alloc>::push_back(const _Tp&) [with _Tp = > boost::shared_ptr<Base>, _Alloc = > std::allocator<boost::shared_ptr<Base> >] > tBoost.cc:37: no matching function for call to ` > std::vector<boost::shared_ptr<Base>, > std::allocator<boost::shared_ptr<Base> > > >::push_back(Base*&)' > /usr/local/gcc-3.2.1/include/c++/3.2.1/bits/stl_vector.h:490: > candidates are: > void std::vector<_Tp, _Alloc>::push_back(const _Tp&) [with _Tp = > boost::shared_ptr<Base>, _Alloc = > std::allocator<boost::shared_ptr<Base> >] > > _______________________________________________ > Boost-users mailing list > Boost-users(a)lists.boost.org > http://lists.boost.org/mailman/listinfo.cgi/boost-users > ----------------------------------------------------------------------- DISCLAIMER: Information contained in this message and/or attachment(s) may contain confidential information of Zetec, Inc. If you have received this transmission in error, please notify the sender by return email. -----------------------------------------------------------------------

1 0

[Q] shared_ptr c'tor
by Marcel Loose 17 Oct '03

17 Oct '03

Hi, I have a question related to the boost::shared_ptr constructor. I want to be able to store boost::shared_ptr<Base> objects in a std::vector. However, I don't want to bother my users with the fact (implementation detail) that I'm using shared_ptrs instead of raw pointers. The simplified sample code below more or less clarifies what I want. The code in line 27 is the code I would like to be able to use. Below that line, several attempts to get the code to compile can be found. I understand that line 32 won't compile, because it is equivalent to line 27. However, line 37 left me puzzled. I would expect that the conversion of B* to shared_ptr<B> would be trivial. Not so. Is it really true that the only way to use shared_ptr in the way I want is as in lines 46, 47? Or am I overlooking something? And is line 41 equivalent to line 46? Thanks in advance. Regards, Marcel Loose. P.S.: I noticed that all code will compile if I omit the "explicit" keyword in the constructor of shared_ptr, but I don't consider that the proper way to solve the problem. 1:#include <boost/shared_ptr.hpp> 2:#include <vector> 3: 4:using namespace std; 5:using namespace boost; 6: 7:class Base 8:{ 9:public: 10: Base() { /* ... */ } 11: virtual ~Base() {} 12:}; 13: 14:class Derived : public Base 15:{ 16:public: 17: Derived() { /* ... */ } 18: virtual ~Derived() {} 19:}; 20: 21: 22:int main() 23:{ 24: vector<shared_ptr<Base> > v; 25: 26: { // failes to compile: 27: v.push_back(new Derived()); // cannot convert Derived*& 28: } // to shared_ptr<Base>. Why? 29: 30: { // failes to compile: 31: Derived* d(new Derived()); // cannot convert Derived*& 32: v.push_back(d); // to shared_ptr<Base>. Why? 33: } 34: 35: { // failes to compile: 36: Base* b(new Derived()); // cannot convert Base*& 37: v.push_back(b); // to shared_ptr<Base>. Huh? 38: } // Seems a trivial conversion. 39: 40: { // OK, this compiles, but is 41: shared_ptr<Derived> d(new Derived()); // it correct? I.e. is conversion 42: v.push_back(d); // shared_ptr<Derived> to 43: } // shared_ptr<Base> trivial? 44: 45: { // OK, this compiles, and is 46: shared_ptr<Base> b(new Derived()); // probably what I meant. 47: v.push_back(b); // However, I dislike the 48: } // verbosity. 49: 50: return 0; 51:} Just to be complete, please find the compiler diagnostics below. tBoost.cc: In function `int main()': tBoost.cc:27: no matching function for call to ` std::vector<boost::shared_ptr<Base>, std::allocator<boost::shared_ptr<Base> > >::push_back(Derived*&)' /usr/local/gcc-3.2.1/include/c++/3.2.1/bits/stl_vector.h:490: candidates are: void std::vector<_Tp, _Alloc>::push_back(const _Tp&) [with _Tp = boost::shared_ptr<Base>, _Alloc = std::allocator<boost::shared_ptr<Base> >] tBoost.cc:32: no matching function for call to ` std::vector<boost::shared_ptr<Base>, std::allocator<boost::shared_ptr<Base> > >::push_back(Derived*&)' /usr/local/gcc-3.2.1/include/c++/3.2.1/bits/stl_vector.h:490: candidates are: void std::vector<_Tp, _Alloc>::push_back(const _Tp&) [with _Tp = boost::shared_ptr<Base>, _Alloc = std::allocator<boost::shared_ptr<Base> >] tBoost.cc:37: no matching function for call to ` std::vector<boost::shared_ptr<Base>, std::allocator<boost::shared_ptr<Base> > >::push_back(Base*&)' /usr/local/gcc-3.2.1/include/c++/3.2.1/bits/stl_vector.h:490: candidates are: void std::vector<_Tp, _Alloc>::push_back(const _Tp&) [with _Tp = boost::shared_ptr<Base>, _Alloc = std::allocator<boost::shared_ptr<Base> >]

1 0

Using boost::mutex in a boost::shared_ptr
by Anders Hybertz 17 Oct '03

17 Oct '03

Hi Can I store boost::mutex'es in a map using the following constuct typedef boost::shared_ptr<boost::mutex> MutexPtr; typedef map< std::string, MutexPtr> MutexMap; MutextMap mmap; mmap["foo"] = MutexPtr( new boost::mutex ); I'm not sure that this is safe to do - the boost::mutex is boost::noncopyable which might indicate that there could be a potentional problem. Thanks in advance

1 0

Re: shared_from_this
by Dragan Milenkovic 16 Oct '03

16 Oct '03

> > >Date: Tue, 14 Oct 2003 16:02:25 +0300 >From: "Peter Dimov" <pdimov(a)mmltd.net> >To: "Boost Users mailing list" <boost-users(a)lists.boost.org> >Subject: Re: [Boost-users] shared_from_this > >Dragan Milenkovic wrote: > > >>Hello, people, >> >>I've been using enable_shared_from_this a LOT, mostly for implementing >>the Observer pattern (an object holds a list of weak pointers to it's >>observers). >> >> [snip] >>Also, any comments on the designs I used? Better observers? >> >> > >It is hard to say; you'll need to go into more detail about the observers. >If they are only notified on destruction of the observed entity, the typical >shared_ptr approach is to reverse/eliminate the dependency and make the >observers store weak pointers to the "observee". > >For other notification scenarios, there is the usual tradeoff between >polling and messaging. I prefer polling most of the time since this >eliminates the need to store an observer list and makes it possible to >"observe" classes that weren't specifically designed for this, but there may >be a performance cost. > > Well this (new) question is about observers in general, concurrent programming and C++. I believe to be making my way up the learning curve, but this seems to be a bit of problem. The proper destruction... Here is what I've been thinking. First the destruction of the subject (observee). As proposed in "Design Patterns", the subject could notify the observers about being destroyed, so the observers can handle that situation. But in my (more or less limited) experience, most often the observer is the one that controls the life-time of the subject (possibly by the means of shared_ptr). So this really presents no problem... But how to synchronize the destruction of the observer with a nofication originating from another thread? The observer's destructor would most likely perform Subject::unregister... But a call to Observer::update might have already been dispatched... The possible solutions I can think of are: 1. Make Subject::unregister have a postcodition stating that the observer will receive notifications no more (as of the moment the function returns). The words that come into my mind while thinking of possible implementations are: mutex, condition, dead-lock, inconsistency... What should the observer be allowed to do from inside the update function? Inspect only? I guess that could work... 2. Subject holds weak_ptr<Observer> and removes dead observers. I like it because of simplicity, but it (possibly) requires that Observer inherits enable_shared_from_this. In my design, the subject usualy passes a pointer to itself in the Observer::update method... Better yet - a shared_ptr, as it is more clean to compare shared pointer, especially inside the container. And how does it get shared_ptr to itself? shared_from_this() again. Is it really necessary? Although it does make the code easier to maintain. I might be wrong, but I get the impression that there is not much information on multithreading and destruction in C++. Destruction the way it is, makes C++ my language of preference. The lectures usually starts with a queue or a buffer with one mutex and one (or two) conditional variables, but it doesn't get any better. How is the queue destroyed? What about consumer which is waiting on a conditional variable? What is the common way of dealing with all this? Java-like interrupt? That's basically what I've been doing. Many thanks, Dragan Milenkovic

2 2

ublas - solving linear systems
by sashan 15 Oct '03

15 Oct '03

I was looking for a way to solve a linear system using ublas and came upon this thread http://article.gmane.org/gmane.comp.lib.boost.user/1632 So does this mean I have to decompose my matrix? Can I do it using ublas?

3 2