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

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

Re: [Boost-users] Inconsistency in graph Example Code, Documentation
by Jeremy Siek 15 Oct '03

15 Oct '03

Hi Thomas, Thanks for the bug report. Since the BGL book uses '-', and I can't change that, I've instead change the documentation and source file to also use '-' instead of '_'. Cheers, Jeremy On Tue, 14 Oct 2003, Thomas F. O'Connell wrote: tfo> This is a minor point but one worth correcting for the sake of tfo> correctness and ease of following the examples. tfo> tfo> In the boost-1.30.2 distribution, the file tfo> tfo> libs/graph/example/kevin-bacon.cpp tfo> tfo> makes a reference to a "./kevin-bacon.dat" file, but the file in both tfo> the distribution and the documentation is actually kevin_bacon.dat. tfo> tfo> The only difference being '_' vs. '-'. tfo> tfo> This is easily fixed by an end-user, but it would be nice to have the tfo> examples work out of the box. tfo> tfo> -tfo ---------------------------------------------------------------------- Jeremy Siek http://php.indiana.edu/~jsiek/ Ph.D. Student, Indiana Univ. B'ton email: jsiek(a)osl.iu.edu C++ Booster (http://www.boost.org) office phone: (812) 855-3608 ----------------------------------------------------------------------

1 0

Missing default constructor for shared_count?
by Andrew Duncan 14 Oct '03

14 Oct '03

At line 109 of share_ptr (version 1.30.2) is the init list shared_ptr(): px(0), pn() which uses the default constructor for pn, which has type shared_count. However, there appears to be no such default constructor in shared_count. Am I missing something? Andrew P.S.: Forgive me if the answer appears somewhere easily searchable. I was unable to find an archive for bug reports or for this list. Pointers to such resources will be welcome.

1 0

How to know wheter a Boost.thread has ended ?
by Huck finn 14 Oct '03

14 Oct '03

Hi, I need a way to find out if the threads that I created are done or not. I'm creating a somekind of thread_group that must clean the threads that have ended from the vector that keeps the threads within. void function () {} void main () { boost::thread thrd1(&function); //I'd need a function here to tell me that the thread has ended... if(thread1.IsDone()) { ... } } How can I do such a thing, any ideas? Thanks, Simon _________________________________________________________________ MSN Search, le moteur de recherche qui pense comme vous ! http://fr.ca.search.msn.com/

2 1

RE: [Boost-users] Regex++ multiline matching
by Ben Hutchings 14 Oct '03

14 Oct '03

I wrote: > John Maddock <john(a)johnmaddock.co.uk> wrote: > > > I see that Regex++ always treats ^ and $ as start and end of line > > > rather than start and end of buffer. Perl does this only if the > > > /m switch is used. Is there a simple way to switch between these > > > two interpretations when compiling a regex? > > > > No but you can use \A and \z for that purpose. > > I know that, but I want to be able to interpret user-supplied regexes > either way. Maybe I can pre-process them to substitute ^ and $, but > that seems awkward. Alternately I could have the traits object return different interpretations for them, but that would require either: - switching between two specialisations of reg_expression at run-time (resulting in code bloat) or - changing reg_expression's constructors to allow the client to pass a traits object into it rather than always using the default constructor (unusual usage of a traits class)

1 0

RE: [Boost-users] Regex++ multiline matching
by Ben Hutchings 14 Oct '03

14 Oct '03

John Maddock <john(a)johnmaddock.co.uk> wrote: > > I see that Regex++ always treats ^ and $ as start and end of line > > rather than start and end of buffer. Perl does this only if the /m > > switch is used. Is there a simple way to switch between these two > > interpretations when compiling a regex? > > No but you can use \A and \z for that purpose. I know that, but I want to be able to interpret user-supplied regexes either way. Maybe I can pre-process them to substitute ^ and $, but that seems awkward.

1 0