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

[BGL] vertex_index_t w/VertexList=listS questions
by Chris Russell 02 Oct '02

02 Oct '02

Hi Jeremy, Using adjacency_list w/VertexList=listS, I've stuffed a vertex_index_t declaration into the internal vertex property map and got my DFS invocation to compile. Taking a look at the dijkstra-example-listS.cpp in the examples directory on CVS, I see how you manually initialize this property for each of the vertices after you build up the graph. p.230 of the book discusses the auto-update of the vertex_index_t property upon vertex removal for the case of VertexList=vecS but I'll need to affect this update myself for VertexList=listS? Also, can you foresee any problems if I register vertex_index_t with a value_type of long int instead of int? I'm guessing no because I'm passing it as a template parameter but I just want to make sure. - Thanks and regards Chris Russell

2 1

BOOST_PARAM_TEST_CASE and uncaught exceptions
by Alisdair Meredith 02 Oct '02

02 Oct '02

I have a case where my test case passed to BOOST_PARAM_TEST_CASE is throwing an exception I was not expecting. This seems to still result in the correct number of calls to the test case, but the first parameter in the list is passed every time. Is this a feature of my compiler, or an issue with the library? Using Borland C++ Builder 5 (should be same as free command-line compiler) -- AlisdairM

2 1

BUG: intrusive pointer and weak_ptr
by Petr Ferschmann 01 Oct '02

01 Oct '02

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, I think I found BUG. Let we have this program: - -- cut here -- #include <boost/shared_ptr.hpp> #include <boost/weak_ptr.hpp> #include <boost/intrusive_ptr.hpp> #include <cstdio> using namespace std; #define INTR class MujObjekt #ifdef INTR : public boost::counted_base #endif { public: MujObjekt() { printf( "MujObjekt::MujObjekt()\n" ); } void setThis( boost::shared_ptr<MujObjekt> obj ) { m_this = obj; } virtual ~MujObjekt() { printf( "MujObjekt::~MujObjekt()\n" ); } boost::weak_ptr<MujObjekt> m_this; }; int main() { boost::shared_ptr<MujObjekt> obj( new MujObjekt() ); obj->setThis( obj ); return( 0 ); } - --- cut here --- But in case of usage of intrusive pointer it doesn't call destructor - because there is weak pointer. But when I undefine INTR and it uses non-intrusive it works as expected. This is only modelling case to simulate bug. - -- Petr "Fers" Ferschmann -=[ petr(a)ferschmann.cz ]==[ http://petr.ferschmann.cz/ ]=- - -=[ Koukni na http://www.postcard.cz/ ]==[ +420 604/781 009 ]=- GPG Fingerprint: [83B0 6378 7A9D D993 035E 60BD FEEC F665 D2C8 1B9A] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9mV9O/uz2ZdLIG5oRArF/AJ9LGfWTXfy69zNTsbiEKThTPQnWcwCeOWgj 0tX9AxdWJ8u/L1MkdZHjOPk= =7A3i -----END PGP SIGNATURE-----

3 3

RE: [Boost-Users] Re: Use a shared_ptr as a 'backpointer'?
by dick.bridges＠tais.com 30 Sep '02

30 Sep '02

1) There are circumstances where the 'creator' should stick around as long as one or more 'creations' still exist (e.g., a [network] session that's created various asynchronous conversations). 2) I haven't had time to check, but I think this is the as-yet-not-but-soon-to-be-released implementation of intrusive pointers. Interesting: search google for "intrusive pointer" (quotes not required). I got five hits - all of the URLs start with www.boost.org/. BTW: Really slick. Trying to figure out where to keep "THE POINTER" was driving me nuts. I'd completely forgotten about intrusive pointers. Thanks. A *LOT*. Mark Storer <mstorer@cardiff To: "'Boost-Users(a)yahoogroups.com'" <Boost-Users(a)yahoogroups.com> .com> cc: Subject: RE: [Boost-Users] Re: Use a shared_ptr as a 'backpointer'? 09/30/2002 09:36 AM Please respond to Boost-Users I've got a comment and a question... 1) Couldn't the "backpointer" just be a constant reference? Backpointers, in my mind, don't have anything to do with ownership, so a shared_ptr woulnd't be appropriate. 2) shared_from_this? I can't find that one in any of the headers or docs I downloaded with 1.28. I did find shared_count in (oddly enough) shared_count.hpp, which looks like it would prevent two seperate shared_ptr's from causing a double-delete... pretty slick, but I couldn't find any docs on it. --Mark Storer Software Engineer Cardiff Software #include <disclaimer> typedef std::disclaimer<Cardiff> Discard; -----Original Message----- From: David Abrahams [mailto:yg-boost-users@m.gmane.org] Sent: Sunday, September 29, 2002 4:12 PM To: boost-users(a)yahoogroups.com Subject: [Boost-Users] Re: Use a shared_ptr as a 'backpointer'? <dick.bridges(a)tais.com> wrote in message news:OF699D7956.EED22A4F-ON88256C43.00722AD0@tais.net... > I run into situations where it's useful for an object to have a > 'backpointer' to the object instance that created it (example below). Is > there a pattern/idiom for doing this using shared_ptr? Or maybe I need to > re-think the idea of the backpointer in the first place? > class Bar; class Foo { public: Foo(shared_ptr<Bar>); private: shared_ptr<Bar> p; }; class Bar : boost::shared_count { void doit() { new Foo(boost::shared_from_this(this)); // <<< new Foo(this) obviously won't work. } }; HTH, Dave -- ----------------------------------------------------------- David Abrahams * Boost Consulting dave(a)boost-consulting.com * http://www.boost-consulting.com Info: <http://www.boost.org> Wiki: <http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl> Unsubscribe: <mailto:boost-users-unsubscribe@yahoogroups.com> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ Info: <http://www.boost.org> Wiki: <http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl> Unsubscribe: <mailto:boost-users-unsubscribe@yahoogroups.com> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

1 0

RE: [Boost-Users] Re: Use a shared_ptr as a 'backpointer'?
by Mark Storer 30 Sep '02

30 Sep '02

I've got a comment and a question... 1) Couldn't the "backpointer" just be a constant reference? Backpointers, in my mind, don't have anything to do with ownership, so a shared_ptr woulnd't be appropriate. 2) shared_from_this? I can't find that one in any of the headers or docs I downloaded with 1.28. I did find shared_count in (oddly enough) shared_count.hpp, which looks like it would prevent two seperate shared_ptr's from causing a double-delete... pretty slick, but I couldn't find any docs on it. --Mark Storer Software Engineer Cardiff Software #include <disclaimer> typedef std::disclaimer<Cardiff> Discard; -----Original Message----- From: David Abrahams [mailto:yg-boost-users@m.gmane.org] Sent: Sunday, September 29, 2002 4:12 PM To: boost-users(a)yahoogroups.com Subject: [Boost-Users] Re: Use a shared_ptr as a 'backpointer'? <dick.bridges(a)tais.com> wrote in message news:OF699D7956.EED22A4F-ON88256C43.00722AD0@tais.net... > I run into situations where it's useful for an object to have a > 'backpointer' to the object instance that created it (example below). Is > there a pattern/idiom for doing this using shared_ptr? Or maybe I need to > re-think the idea of the backpointer in the first place? > class Bar; class Foo { public: Foo(shared_ptr<Bar>); private: shared_ptr<Bar> p; }; class Bar : boost::shared_count { void doit() { new Foo(boost::shared_from_this(this)); // <<< new Foo(this) obviously won't work. } }; HTH, Dave -- ----------------------------------------------------------- David Abrahams * Boost Consulting dave(a)boost-consulting.com * http://www.boost-consulting.com Info: <http://www.boost.org> Wiki: <http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl> Unsubscribe: <mailto:boost-users-unsubscribe@yahoogroups.com> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

1 0

RE: [Boost-Users] shared_ptr and counted_base
by Hickman, Greg 30 Sep '02

30 Sep '02

> I was looking through the latest boost documentation, trying Where is the documentation to which you refer? Is this a development doc or part of the ordinary user docs (if the latter, I don't know where to find it)? -Greg

2 1

Problem using 'shared_ptr<T>::operator impl-defined-type()'
by Hickman, Greg 30 Sep '02

30 Sep '02

With Borland 5.5.1, I'm not having any luck using a shared_ptr in a boolean context. The compiler complains that the 'if' condition below contains an "Illegal structure operation". Is this a known deficiency with my compiler? -Greg Hickman #include <boost/shared_ptr.hpp> int main(int argc, char* argv[]) { boost::shared_ptr<int> intp; if (intp) // error here ; return 0; }

5 10

RE: [Boost-Users] Returning a boost::scoped_lock by value
by Darryl Green 30 Sep '02

30 Sep '02

This issue has come up before on the development list (search for Boost.Threads Locking Delima). I'm not sure that it was resolved satisfactorily - move semantics for scoped_locks seemed to be the answer, but I think there were problems actually implementing that. The intent was that if move couldn't be implemented, then the mutex lock methods would have to be exposed. > -----Original Message----- > From: Raoul Gough [mailto:yg-boost-users@m.gmane.org] > Sent: Friday, 27 September 2002 9:44 PM > To: boost-users(a)yahoogroups.com > Subject: [Boost-Users] Returning a boost::scoped_lock by value > > > > boost::scoped_lock is non-copyable, so it is impossible to > return one from a function by value. However, I would like to > be able to do something like this: > > mt::holder<std::ostream> logStream; > > logStream() << "Hello world\n"; > > where the operator() returns a proxy object that contains a > scoped_lock and a pointer to the data (the ostream). What I > currently have is this: > > (mt::proxy<std::ostream> (logStream)) << "Hello world\n"; > > So the client code has to know what type the proxy object is > and construct one itself. If scoped_lock would provide access > to its associated mutex object, this wouldn't be a necessary, > because the proxy object could then have a copy-constructor, > and operator() in the holder template would look like this: > > proxy<T> operator() () > { > proxy<T> temp (*this); > return temp; > } > > The proxy copy constructor would unlock() the original lock > and construct the copy using the original's mutex (which is > the part that can't currently work, because there is no > public access to a lock's mutex). Assuming that the compiler > implements the NRVO, the unlock/lock sequence wouldn't > actually happen, and the client code just gets its proxy > object constructed for it. If the compiler doesn't implement > the NRVO, the code still works, but is less efficient. > > I guess exposing the raw mutex from scoped_lock would break > an important level of encapsulation. Still, it would be kind > of nice in this case. Maybe if proxy<T> were part of the > library and made a friend of scoped_lock? The only other > alternative I've come up with is to allocate the lock on the > heap and return an object containing a std::auto_ptr (which > makes usage easier, but less efficient). Any comments or suggestions? > > Regards, > Raoul Gough. > > > // Returnable proxy template > > template<typename T> > class proxy > { > boost::mutex::scoped_lock mLock; > T *mPtr; > > boost::mutex &release() > { > mLock.unlock(); > return mLock.mutex(); // <<<< doesn't work > } > > public: > > proxy (proxy &other) > : mLock (other.release()) > , mPtr (other.mPtr) > { > } > > // ... > }; > > > > > > > ------------------------ Yahoo! Groups Sponsor > ---------------------~--> Home Selling? Try Us! > http://us.click.yahoo.com/QrPZMC/iTmEAA/MVfIAA> /EbFolB/TM > > > -------------------------------------------------------------- > -------~-> > > Info: <http://www.boost.org> > Wiki: <http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl> > Unsubscribe: <mailto:boost-users-unsubscribe@yahoogroups.com> > > > Your use of Yahoo! Groups is subject to > http://docs.yahoo.com/info/terms/ > >

2 1

RE: [Boost-Users] newbie Question about the macro BOOST_JOIN
by scleary＠jerviswebb.com 28 Sep '02

28 Sep '02

> From: zhangwusheng [mailto:yg-boost-users@m.gmane.org] > > Hi,all, > In file suffix.hpp there are lines: > > #define BOOST_JOIN( X, Y ) BOOST_DO_JOIN( X, Y ) > #define BOOST_DO_JOIN( X, Y ) BOOST_DO_JOIN2(X,Y) > #define BOOST_DO_JOIN2( X, Y ) X##Y > > > why donot we define such macro instead: > #define BOOST_JOIN( X, Y ) X##Y The idea behind BOOST_JOIN is to force the preprocessor to scan the macro parameters for replacement before merging the results with ##. So, it changes the meaning if one of the parameters is a macro: #define Z_BOOST_JOIN(X, Y) X##Y Z_BOOST_JOIN(id_, __LINE__) // Expands to "id___LINE__" BOOST_JOIN(id_, __LINE__) // Expands to "id_13" if __LINE__ is 13 However, I'm not sure why BOOST_DO_JOIN2 is used; it seems to me that only one layer of indirection should work. I assume it's to work around some compiler's non-conforming preprocessor. -Steve

3 2

Boost::UBLAS problems
by pecos_outwest 27 Sep '02

27 Sep '02

Hi Folks, I have been experimenting with the new BOOST linear algebra section boost/numeric/ublas I have been running the examples and benchmark programs bench1 and test1 provided with the distribution. Both programs compile and link perfectly they also run to completion; but they only run one time ! I cannot run a second time. It looks like the executable isn't even starting. Has anyone found this problem and found the solution I am using Microsoft VC6 compiler on a PC Thanks...Pecos

1 0