typedef scope problem

J

Jun

Hello everyone,

I've two class A and B,

in head file :

=========================
class A{

// A will use type BPtr
}

class B{

// B will use type APtr
}

typedef shared_ptr<A> APtr
typedef shared_ptr<B> BPtr
=========================

Could anyone give me some advices to deal with this scope problem,
thank you in advance.


Jun

=========================
 
A

Alf P. Steinbach

* Jun:
I've two class A and B,

in head file :

=========================
class A{

// A will use type BPtr
}

class B{

// B will use type APtr
}

typedef shared_ptr<A> APtr
typedef shared_ptr<B> BPtr
=========================

Could anyone give me some advices to deal with this scope problem,
thank you in advance.

What you write can match any number of "scope problems", including the
one that the code you have shown has a bunch of syntax errors.

I'm sure that some replies will simply assume you meant one particular
problem, and that may happen to be the problem you actually have.

If not, then just read the FAQ item on how to post a question about Code
That Does Not Work, follow the guidelines there, and repost.


Cheers, & hth.,

- Alf
 
D

David Harmon

On Sun, 25 Nov 2007 08:00:51 -0800 (PST) in comp.lang.c++, Jun
Could anyone give me some advices to deal with this scope problem,
thank you in advance.

Forward declaration of the classes should be sufficient, even with
shared_ptr.

See "[39.11] How can I create two classes that both know about each
other?" in Marshall Cline's C++ FAQ. It is always good to check the
FAQ before posting. You can get the FAQ at:
http://www.parashift.com/c++-faq-lite/
 
J

James Kanze

On Sun, 25 Nov 2007 08:00:51 -0800 (PST) in comp.lang.c++, Jun
Forward declaration of the classes should be sufficient, even with
shared_ptr.
See "[39.11] How can I create two classes that both know about each
other?" in Marshall Cline's C++ FAQ. It is always good to check the
FAQ before posting. You can get the FAQ at:
http://www.parashift.com/c++-faq-lite/

Not a scope problem, but dependency cycles can cause problems
with shared_ptr.

If the only problem is recovering memory, shared_ptr doesn't
work if cycles are involved. If the problem is that the
destructor of A should not be called until B has been
destructed, and the destructor of B should not be called until A
has been destructed, then of course, you can't blame shared_ptr
for not being able to solve the problem. More generally,
shared_ptr indicates some sort of "ownership", and cycles in
ownership are more or less a contradiction: an object cannot be
both owned by and owner of the same other object.
 
D

David Harmon

On Sun, 25 Nov 2007 09:49:29 -0800 (PST) in comp.lang.c++, James
Kanze said:
Not a scope problem, but dependency cycles can cause problems
with shared_ptr.

That's true. I was assuming the classes were being used as a tree;
cycles and/or a general graph won't free memory so simply.
 
J

Jun

On Sun, 25 Nov 2007 09:49:29 -0800 (PST) in comp.lang.c++, James


That's true. I was assuming the classes were being used as a tree;
cycles and/or a general graph won't free memory so simply.

Actually, these classes were being used as a graph which won't free
memory. David , thanks for your help
 
D

David Harmon

On Sun, 25 Nov 2007 14:22:28 -0800 (PST) in comp.lang.c++, Jun
Actually, these classes were being used as a graph which won't free
memory. David , thanks for your help

Thanks to James K. for setting us both straight on that. I don't
get as deep into linked data graphs as I think he often does.

Something not totally unrelated to this, and how garbage collection
doesn't fix bugs, is what may have cost the Princeton team their
chance at the DARPA grand challenge:
http://www.codeproject.com/showcase/IfOnlyWedUsedANTSProfiler.asp
 
B

bob_blaine

Hello everyone,

I've two class A and B,

in head file :

=========================
class A{

// A will use type BPtr

}

class B{

// B will use type APtr

}

typedef shared_ptr<A> APtr
typedef shared_ptr<B> BPtr
=========================

Could anyone give me some advices to deal with this scope problem,
thank you in advance.

Jun

=========================

Jun:

Might I suggest something to you about the above code. You can fix
this by forward references, but you are going to have a problem with
cyclic dependency here that you probably should get used to
identifying and eliminating. Cyclic dependencies cause all types of
headaches in software development and it's best to be able to identify
them and eliminate them. One way is to use dependency inversion or
basically create pure interfaces for your classes that the other one
depends on rather than making it directly dependent on the other
class. So in your case:

class IA // pure virtual interface of A
{
....
};

class IB // pure virtual interface of B
{
....
};

typedef shared_ptr<IA> APtr
typedef shared_ptr<IB> BPtr

class A : public IA
{


// A will use type BPtr



};


class B : public IB
{

// B will use type APtr



};


There are 2 potential reasons not to use this - the interfaces
introduce virtual calls which should only impact you if you are in an
exteremly performance critical area, and the pain of having to update
2 class interfaces when you add a method. After being in the software
industry for a while, the first reason is almost always used as an
excuse for the second. 95% of the time neither are an issue.

Cheers!

Madhacker
 
J

James Kanze

On Sun, 25 Nov 2007 09:49:29 -0800 (PST) in comp.lang.c++, James
That's true. I was assuming the classes were being used as a tree;
cycles and/or a general graph won't free memory so simply.

If it's a tree (an acyclic graph with a single root), then there
should be no problem (except maybe performance, since you will
effectively visit the entire tree each time you drop the final
pointer to root, which is likely to cause a noticeable pause).
As soon as there are cycles, however, you have to manually break
them, using a mixture of shared_ptr and weak_ptr. In general,
I'd look for some other solution; while there are applications
where the choice of pointer type is obvious, and there is no
problem, graphs with potential cycles aren't one of them.
 
J

James Kanze

On Sun, 25 Nov 2007 14:22:28 -0800 (PST) in comp.lang.c++, Jun
Thanks to James K. for setting us both straight on that. I don't
get as deep into linked data graphs as I think he often does.

Not really, at least not as data graphs per se. I do deal with
a lot of business objects, however, and most applications tend
to navigate extensively between the various business objects.
The navigation links do effectively form a complex graph, even
if it isn't managed as one (which makes handling them even more
complex).
Something not totally unrelated to this, and how garbage collection
doesn't fix bugs, is what may have cost the Princeton team their
chance at the DARPA grand challenge:http://www.codeproject.com/showcase/IfOnlyWedUsedANTSProfiler.asp

It's funny how people don't learn. Garbage collection is a very
useful tool for memory management, but it's not a silver bullet.
Early versions of Swing had exactly the same problem (with the
difference that the relevant objects---JButton, etc.---weren't
even notified when the window was disposed).
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
474,189
Messages
2,571,016
Members
47,618
Latest member
Leemorton01

Latest Threads

Top