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

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 … [View More]

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 … [View More]

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… [View More]

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 … [View More]<< "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. ----------------------------------------------------------------------- [View Less]

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 … [View More]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> >] [View Less]

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). >> >… [View More]> [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 [View Less]

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> … [View More]

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 … [View More]

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-… [View More]

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 … [View More]

1 0

shared_from_this
by Dragan Milenkovic 14 Oct '03

14 Oct '03

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). I wanted to know why are shared_from_this member functions public instead of being protected? Also, I've used the following expression a few times: shared_polymorphic_cast<This>(shared_from_this()) Any thoughts on putting it inside the enable_shared_from_this... shared_from_base<This>() or … [View More]

2 1

Regex++ multiline matching
by Ben Hutchings 14 Oct '03

14 Oct '03

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?

2 1

boost::function compilation
by Terence Ou 14 Oct '03

14 Oct '03

Hi, I'm currently trying to use boost::function with VC++ 7.0 and I get the compilation error stating that function is not a member of boost. I've already included the header <boost/function.hpp> as well as the library path in the project settings but it just doesn't seem to be able to compile. The documentation specifies things about the preferred and portable syntax. Is there even some setting choose the desired syntax, becoz there are no hints or instructions that … [View More]

2 1

[BLL] bind(data_member_ptr,_1) functor won't accept temporaries as arguments
by Eelis van der Weegen 13 Oct '03

13 Oct '03

When Lambda's bind() is used to create a functor for dereferencing a stored data member pointer given an instance pointer, it seems it is not possible to pass the resulting functor a temporary instance pointer. For example: #include <boost/lambda/bind.hpp> #include <boost/lambda/lambda.hpp> struct S { int i; }; S * f (); void g (S * p) { using namespace boost::lambda; bind(&S::i, _1)(p); // ok bind(&S::i, _1)(p + 0); // not ok, "no … [View More]

2 1

enable_shared_from_this::_internal_weak_this initialization
by Cody Batt 13 Oct '03

13 Oct '03

Hello, It seems that classes which inherit from enable_shared_from_this are required to explicitly initialize _internal_weak_this. 1) Is that correct? If not, how is it initialized? 2) Is this detail mentioned anywhere in the documentation? (I couldn't find it.) Thanks, Cody

2 1

Stubbing for unit testing, what approach should I use
by Andrew Syrov 10 Oct '03

10 Oct '03

I am looking for set of techniques for isolation testing. As applications are designed with massive number of dependencies between classes and these dependencies end-up in external systems such as databases and OS, it's hard to extract function or part of class for efficient unit test. Basically I need an advice on what coding techniques should be used to allow flexible (generic?) stubbing: - function of a class may need to be tested in isolation from world (members could be global data … [View More]

1 0

Enhancement to shared_pointer to support pointers to contained objects.
by Ricardo Capurro 09 Oct '03

09 Oct '03

Hello, We are really very happy and impressed with boost's smart_pointers, and we found the section "Smart Pointer Programming Techniques" (http://www.boost.org/libs/smart_ptr/sp_techniques.html) in boost smart_pointer documentation very useful, but we are having this problem: We have two classes X and Y, and each object of class X holds an object of class Y, and we need to implement a method in class X to get a shared_ptr<Y> so we can access Y instance inside X, and we need that X … [View More] objects (that are too referenced by shared_ptr<X>) don't be deleted until all references to the Y object are destroyed. See the problem in this code: class Y {}; class X : public enable_shared_from_this<X> { Y y; public: shared_ptr<Y> ptr_y(); // Oops, how do we do here??? }; Our first approach was "Using a shared_ptr to hold a pointer to a statically allocated object" (http://www.boost.org/libs/smart_ptr/sp_techniques.html#static) but this doesn't work because X objects can be destroyed and we still have pointers to contained Y object, so we try a custom deletor like this: template <typename Z> class delegator_deletor { shared_ptr<Z> ptr; // Internal pointer to father X, wich contains Y public: delegator_deletor( shared_ptr<Z> const & ptrz ) : ptr( ptrz ) {} template <typename T> void operator()( T* ) { ptr.reset(); } // Null deletor, only resets pointer to father X object }; template <typename Z> delegator_deletor<Z> make_delegator_deletor( shared_ptr<Z> ptrz ) { return delegator_deletor<Z>( ptrz ); } class X : public enable_shared_from_this<X> { Y y; public: shared_ptr<Y> ptr_y() { return shared_ptr<Y>( &y, make_delegator_deletor( shared_from_this() ) ); } }; And now the problem was resolved but with one little drawback, we are not sharing the same counter between shared_ptr<X> and shared_ptr<Y>, so start looking boost's code to shange it in a way that it satisfies our needs, and we added this constructor to shared_ptr class: template<class Y,class Z> shared_ptr(Y* y, shared_ptr<Z> const & z): px(z.px ? y : 0), pn( y ? z.pn : detail::shared_count() ) // never throws { detail::sp_enable_shared_from_this(y, y, pn); } then we change X::ptr_y() this way: shared_ptr<Y> X::ptr_y() { return shared_ptr<Y>( &y, shared_from_this() ); } This new constructor instructs to create a shared_ptr<> that uses the same counter that the second's shared_ptr<> parameter, but point's to the first raw pointer paramenter. With this change everithing worked fine. Finally our question is: Is there an easyer way to solve our problem? If the answer is yes we want to know it and if the answer is no we want to know if you can enhace shared_ptr to solve this kind of problem. Thank you very much Ricardo #include <iostream> #include <string> #include <boost/smart_ptr.hpp> #include <boost/enable_shared_from_this.hpp> using namespace ::std; using namespace ::boost; #if !defined( SOLUTION1 ) && !defined( SOLUTION2 ) && !defined( SOLUTION3 ) && !defined( SOLUTION4 ) #define SOLUTION3 #endif #if defined( SOLUTION1 ) class null_deleter { public: template <typename T> void operator()( T* ) {} }; #elif defined( SOLUTION2 ) || defined( SOLUTION3 ) template <typename Z> class delegator_deletor { shared_ptr<Z> ptr; public: delegator_deletor( shared_ptr<Z> const & ptrz ) : ptr( ptrz ) { cerr << "delegator_deletor<" << typeid( Z ).name() << ">()" << endl; } template <typename T> void operator()( T* ) { ptr.reset(); cerr << "delegator_deletor<" << typeid( Z ).name() << ">()( " << typeid( T ).name() << "* )" << endl; } }; template <typename Z> delegator_deletor<Z> make_delegator_deletor( shared_ptr<Z> const & ptrz ) { return delegator_deletor<Z>( ptrz ); } #endif class Y : public enable_shared_from_this<Y> { Y( Y const & ); Y& operator=( Y const & ); public: Y() { cerr << "Y::Y()" << endl; } ~Y() { cerr << "Y::~Y()" << endl; } }; class X : public enable_shared_from_this<X> { Y y; int i; X( X const & ); X& operator=( X const & ); public: X() : y(), i( 7 ) { cerr << "X::X()" << endl; } ~X() { cerr << "X::~X()" << endl; } shared_ptr<Y> ptr_y() { #if defined( SOLUTION1 ) return shared_ptr<Y>( &y, null_deleter() ); #elif defined( SOLUTION2 ) return shared_ptr<Y>( &y, make_delegator_deletor( shared_from_this() ) ); #elif defined( SOLUTION3 ) shared_ptr<Y> py; try { py = y.shared_from_this(); } catch ( const bad_weak_ptr& ) { py.reset( &y, make_delegator_deletor( shared_from_this() ) ); } return py; #elif defined( SOLUTION4 ) return shared_ptr<Y>( &y, shared_from_this() ); #endif } shared_ptr<int> ptr_i() { #if defined( SOLUTION1 ) return shared_ptr<int>( &i, null_deleter() ); #elif defined( SOLUTION2 ) || defined( SOLUTION3 ) return shared_ptr<int>( &i, make_delegator_deletor( shared_from_this() ) ); #elif defined( SOLUTION4 ) return shared_ptr<int>( &i, shared_from_this() ); #endif } }; int main( const int, const char** ) { try { cerr << "(1)" << endl; shared_ptr<X> px( new X() ); cerr << "(2)" << endl; shared_ptr<Y> py = px->ptr_y(); cerr << "(3)" << endl; shared_ptr<int> pi = px->ptr_i(); cerr << "(4)" << endl; px.reset(); cerr << "(5)" << endl; py.reset(); cerr << "(6)" << endl; pi.reset(); cerr << "(7)" << endl; } catch ( const exception& e ) { cerr << "Exception caught: " << e.what() << endl; } catch ( ... ) { cerr << "Exception caught ..." << endl; } return 0; } [View Less]

2 1

Re: [Boost-users] Re: Problem using Boost.thread : Class destructor calledseveral times!
by Huck finn 08 Oct '03

08 Oct '03

Ok, now I see that my object is being copied. But for the lines : FakeClass *item1 = new FakeClass(1);//,item2(2); group.create_thread(*item1); I get : FakeClass #1 says : I'm alive! FakeClass #1 says : Being Copied!! FakeClass #1 says : Being Copied!! FakeClass #1 says : Being Copied!! FakeClass #1 says : I'm being destroyed! FakeClass #1 says : I'm being destroyed! FakeClass #1 says : Being Copied!! FakeClass #1 says : I'm being destroyed! Thread for FakeClass #1 has been started! … [View More]

2 1

Re: compiler warnings...
by David Abrahams 08 Oct '03

08 Oct '03

David Ohlemacher <ohlemacher(a)bbn.com> writes: > Hi all from a boost newbie, > > Given: > Linux RH 8.0 > gcc 3.2 > BOOST_VERSION 103002 > > I created a boost app and it compiles and runs however I am getting > lots of warnings of the form > /usr/lib/boost/boost/iterator_adaptors.hpp:775:43: warning: > "BOOST_MSVC" is not defined. > > What am I not doing correctly? You're using -Wall ;-) We're currently discussing what to do about these warnings … [View More]

3 2

compiler warnings...
by David Ohlemacher 08 Oct '03

08 Oct '03

Hi all from a boost newbie, Given: Linux RH 8.0 gcc 3.2 BOOST_VERSION 103002 I created a boost app and it compiles and runs however I am getting lots of warnings of the form /usr/lib/boost/boost/iterator_adaptors.hpp:775:43: warning: "BOOST_MSVC" is not defined. What am I not doing correctly? I have both included and not included <boost/config.hpp> and I read (http://www.boost.org/libs/config/config.htm#header) that I should not include this. Thanks, -d

1 0

mpl + enum + VC = error
by nagual 06 Oct '03

06 Oct '03

Hello, All! I write simple code: =============mpl_enum.cpp============= #include <boost/mpl/range_c.hpp> #include <boost/mpl/for_each.hpp> #include <iostream> enum test_e {ONE, TWO, THREE}; void f(test_e e) { const char* names[] = {"ONE", "TWO", "THREE"}; std::cout<<names[e]<<std::endl; } typedef boost::mpl::range_c< test_e, ONE, static_cast<test_e>(THREE + 1) > range; int main() { boost::mpl::for_each<range>(f); return 0; } =======… [View More]======mpl_enum.cpp============= MSVC 7 (ver 13.00.9466) =============Command Line============== c:\cl /EHsc /GR /Zc:wchar_t /Zc:forScope /nologo mpl_enum.cpp =============Command Line============== =============Output===================== mpl_enum.cpp C:\Lang\Projects\boost\boost\mpl\aux_\integral_wrapper.hpp(78) : error C2440: 'return' : cannot convert from '' to 'test_e' Conversion to enumeration type requires an explicit cast (static_cast, C-style cast or function-style cast) C:\Lang\Projects\boost\boost\mpl\aux_\integral_wrapper.hpp(78) : while compiling class-template member function 'boost::mpl::integral_c<T,N>::operator`T'(void) const' with [ T=test_e, N=ONE ] C:\Lang\Projects\boost\boost\mpl\aux_\range_c\iterator.hpp(34) : see reference to class template instantiation 'boost::mpl::integral_c<T,N>' being compiled with [ T=test_e, N=ONE ] C:\Lang\Projects\boost\boost\mpl\for_each.hpp(70) : see reference to class template instantiation 'boost::mpl::range_c_iterator<N>' being compiled with [ N=boost::mpl::range_c<test_e,ONE,3>::start ] C:\Lang\Projects\boost\boost\mpl\for_each.hpp(101) : see reference to function template instantiation 'void boost::mpl::aux::for_each_impl<done>::execute(Iterator *,last *,transform_op *,void (__cdecl *)(test_e))' being compiled with [ done=false, Iterator=first ] C:\Lang\Projects\boost\boost\mpl\for_each.hpp(111) : see reference to function template instantiation 'void boost::mpl::for_each(F,range *,boost::mpl::identity<T> *)' being compiled with [ F=void (__cdecl *)(test_e), T=boost::mpl::void_ ] mpl_enum.cpp(15) : see reference to function template instantiation 'void boost::mpl::for_each(F,range *)' being compiled with [ F=void (__cdecl *)(test_e) ] =============Output===================== However gcc v3.2.3, icl v 7.1, bcc32 v5.6.4 compile it. (bcc32 show 3 equivalent warning). How use it in MSVC 7? [View Less]

2 1