headers
Petr Ferschmann | 1 Oct 2002 10:39
Picon

BUG: intrusive pointer and weak_ptr


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;
	}
(Continue reading)

Permalink | Reply | 3 comments |
headers
John Maddock | 1 Oct 2002 13:01
Picon

Re: [random] Known problems compiling random lib with Dinkumware STL?

> > I'm using the Intel 6.0 compiler under MS Visual Studio 6.0 SP6 and just
> > attempted to plug the Dinkumware STL distribution into the mix. I ran
into a
> > slew of compile-time errors in the random library and am wondering if
anyone
> > has seen this before I ride into battle.

It's likely that the config is all wrong for that compiler-library
combination - sadly it's almost impossible to detect Dinkumware library
variants - can you run the configure script?

John Maddock
http://ourworld.compuserve.com/homepages/john_maddock/index.htm
Permalink | Reply | 1 comment |
headers
David Abrahams | 1 Oct 2002 12:47
Picon

Re: intrusive pointer and weak_ptr

"Petr Ferschmann" <petr <at> ferschmann.cz> wrote in message
news:200210011039.42899 <at> elara.ferschmann.cz...

> 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.

You can't call it a bug until there's documentation which tells you what you
have a right to expect ;-)

In this case, it's not a bug. You can implement the dispose() function on
your class to throw away resources when the last shared_ptr reference goes
away, but weak_ptr references still exist.

--
-----------------------------------------------------------
           David Abrahams * Boost Consulting
dave <at> boost-consulting.com * http://www.boost-consulting.com
Permalink | Reply | 2 comments |
headers
Petr Ferschmann | 1 Oct 2002 14:48
Picon

Re: Re: intrusive pointer and weak_ptr


Thank you for your answer.

I know that intrusive_ptr is not documented yet.

But in documentation of weak_ptr is written that when all shared_ptr are 
destroyed all weak_ptr are set to 0. And it of course works in that style for 
normal shared pointer.

But when I am using weak_ptr with intrusive_ptr it know works like normal 
pointer? 

I think I missed something. Is it bug or feature?

Thank yo for your answer.

> You can't call it a bug until there's documentation which tells you what
> you have a right to expect ;-)
>
> In this case, it's not a bug. You can implement the dispose() function on
> your class to throw away resources when the last shared_ptr reference goes
> away, but weak_ptr references still exist.

--

-- 
                                  Petr "Fers" Ferschmann

 -=[  petr <at> ferschmann.cz  ]==[ http://petr.ferschmann.cz/ ]=-
-=[ Koukni na http://www.postcard.cz/ ]==[ +420 604/781 009 ]=-

GPG Fingerprint:
(Continue reading)

Permalink | Reply | 1 comment |
headers
Peter Dimov | 1 Oct 2002 15:08

Re: Re: intrusive pointer and weak_ptr

From: "Petr Ferschmann" <petr <at> ferschmann.cz>
> Thank you for your answer.
>
> I know that intrusive_ptr is not documented yet.
>
> But in documentation of weak_ptr is written that when all shared_ptr are
> destroyed all weak_ptr are set to 0. And it of course works in that style
for
> normal shared pointer.

If you test the weak_ptr, you'll see that it will properly report that it's
expired(); use_count() will be zero; and if you try to construct a
shared_ptr from it, the construction will fail.

> But when I am using weak_ptr with intrusive_ptr it know works like normal
> pointer?
>
> I think I missed something. Is it bug or feature?

It is a "feature". The reference count is contained in counted_base, and
it's embedded into the object. It is not possible to destroy the object
without also destroying the counted_base, and this cannot happen while there
are still weak pointers to that counted_base. That's why
counted_base::dispose() is invoked when the last shared_ptr is destroyed, to
let you release the resources contained in your object.
Permalink | Reply | 0 comments |
headers
Chris Russell | 2 Oct 2002 06:36

[BGL] vertex_index_t w/VertexList=listS questions

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
Permalink | Reply | 1 comment |
headers
Gennadiy E. Rozental | 2 Oct 2002 09:04
Picon

Re: BOOST_PARAM_TEST_CASE and uncaught exceptions

--- In Boost-Users <at> y..., Alisdair Meredith <yg-boost-users <at> m...> 
wrote:
> 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

Hi, Alisdair

Unfortunately I am not able to reproduce the error you are 
describing. I added paramaterized test_test module that passing all 
test paraticulaly with BCC55 command-line tools. Could you take a 
look and let me know the results. If you still exiriencing the 
problems could you give more detailed description of your test and 
how it's different from what I am testing.

Regards,

Gennadiy.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Chris Russell | 2 Oct 2002 10:23

[BGL] Daisy chaining algorithms using vistor mechanism?

Still up hacking... Without cluttering the question with a ton of detail,
basically I need to perform a DFS on a forest stored in a bidirectionalS
adjacency_list and then perform a subgraph traversal in response to each
finish_vertex invocation in the visitor. (The idea is to push information
down the branches towards the root of a tree in the forest). Calling
in_edges(v,g) from within the finish_vertex method in a dfs_visitor will not
compile however. This is because the graph is passed by const reference into
the visitor method and in_edges requires a non-const graph reference? (this
seems similar in spirit to a question I posted a week or two ago about
boost::get(some_property, Graph) from within a visitor).

Generally, I would like to be able to daisy chain graph algorithms - that is
invoke a sub-algorithm from within a visitor method called by a controlling
algorithm. This would require that the sub-algorithm not change the graph
topology, trample on properties used by its controller (e.g. coloring), or
otherwise invalidate vertex descriptors or iterators so some care would need
to be taken in designing the sub-algorithm. But it seems like a useful
mechanism for extension.

Am I missing something about getting at the in_edges given that I'm working
with a const graph_t& in the context of the "controlling" DFS' visitor
method? Why is this so restrictive? I'm guessing it might have something to
do with having multiple copies of vertex and edge iterators floating around
but I'm not sure. Will you comment on this please Jeremy? Thank you.

- Chris Russell
Permalink | Reply | 6 comments |
headers
Jeremy Siek | 2 Oct 2002 15:21
Picon
Picon
Favicon

Re: [BGL] vertex_index_t w/VertexList=listS questions

Hi Chris,

On Wed, 2 Oct 2002, Chris Russell wrote:

cdr> Hi Jeremy,
cdr>
cdr> Using adjacency_list w/VertexList=listS, I've stuffed a vertex_index_t
cdr> declaration into the internal vertex property map and got my DFS invocation
cdr> to compile. Taking a look at the dijkstra-example-listS.cpp in the examples
cdr> directory on CVS, I see how you manually initialize this property for each
cdr> of the vertices after you build up the graph. p.230 of the book discusses
cdr> the auto-update of the vertex_index_t property upon vertex removal for the
cdr> case of VertexList=vecS but I'll need to affect this update myself for
cdr> VertexList=listS? Also, can you foresee any problems if I register

Yes, you need to do the update yourself in that case.

cdr> vertex_index_t with a value_type of long int instead of int? I'm
cdr> guessing no because I'm passing it as a template parameter but I just
cdr> want to make sure.

That should be fine.

Cheers,
Jeremy

----------------------------------------------------------------------
 Jeremy Siek                          http://php.indiana.edu/~jsiek/
 Ph.D. Student, Indiana Univ. B'ton   email: jsiek <at> osl.iu.edu
 C++ Booster (http://www.boost.org)   office phone: (812) 855-3608
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jeremy Siek | 2 Oct 2002 15:26
Picon
Picon
Favicon

Re: [BGL] Daisy chaining algorithms using vistor mechanism?

Hi Chris,

On Wed, 2 Oct 2002, Chris Russell wrote:
[snip]
cdr> finish_vertex method in a dfs_visitor will not compile however. This
cdr> is because the graph is passed by const reference into the visitor
cdr> method and in_edges requires a non-const graph reference?

No, in_edges is declared const for the graph parameter, at least for
adjacency_list, and it should be for other graph types as well.

cdr> Generally, I would like to be able to daisy chain graph algorithms -
cdr> that is invoke a sub-algorithm from within a visitor method called by
cdr> a controlling algorithm. This would require that the sub-algorithm
cdr> not change the graph topology, trample on properties used by its
cdr> controller (e.g. coloring), or otherwise invalidate vertex
cdr> descriptors or iterators so some care would need to be taken in
cdr> designing the sub-algorithm. But it seems like a useful mechanism for
cdr> extension.

You can do that as long as you use a different color map, etc.

Regards,
Jeremy

----------------------------------------------------------------------
 Jeremy Siek                          http://php.indiana.edu/~jsiek/
 Ph.D. Student, Indiana Univ. B'ton   email: jsiek <at> osl.iu.edu
 C++ Booster (http://www.boost.org)   office phone: (812) 855-3608
----------------------------------------------------------------------
(Continue reading)

Permalink | Reply | 5 comments |

Gmane