Call A from B | | |
Given class A and class B:
class A
{
public:
void method_for_B_to_call();
....
};
How to make B to call back method_for_B() of A without letting B know the
definition of A (e.g. not using "#include "A.h"), but only know
A::method_for_B_to_call() for calling back?
Thanks! | | | | re: Call A from B
"Ele" <Ele@inter.com> wrote in message
news:IiWsc.29003$fF3.751864@bgtnsc05-news.ops.worldnet.att.net...[color=blue]
> Given class A and class B:
>
> class A
> {
> public:
> void method_for_B_to_call();
> ...
> };
>
> How to make B to call back method_for_B() of A without letting B know the
> definition of A (e.g. not using "#include "A.h"), but only know
> A::method_for_B_to_call() for calling back?
>
> Thanks!
>[/color]
I don't think that is possible unless method_for_B_to_call is a static
method. Is it?
john | | | | re: Call A from B
Ele wrote:[color=blue]
>
> Given class A and class B:
>
> class A
> {
> public:
> void method_for_B_to_call();
> ...
> };
>
> How to make B to call back method_for_B() of A without letting B know the
> definition of A (e.g. not using "#include "A.h"), but only know
> A::method_for_B_to_call() for calling back?
>
> Thanks![/color]
You cannot do it directly in your definitions. You need to find an
abstraction for class B to use; which exactly - depends on the details
of your problem.
Here are two approaches:
0) Delegation:
//////header (used by class B):
class A; //forward declaration
//used by class B:
class C {
A* pa_;
public:
void method_for_B_to_call();
};
//////.cpp file: includes the above header and the definition of class A
void C::method_for_B_to_call() {
return pa_->method_for_B_to_call();
}
1) Abstract base class (interface) for A:
//used by B, implemented by A
class ABase {
public:
virtual ~ABase() = 0;
virtual void method_for_B_to_call() = 0;
//...
};
Denis | | | | re: Call A from B
On Wed, 26 May 2004 05:54:48 GMT, "Ele" <Ele@inter.com> wrote:
[color=blue]
>Given class A and class B:
>
>class A
>{
>public:
> void method_for_B_to_call();
>...
>};
>
>How to make B to call back method_for_B() of A without letting B know the
>definition of A (e.g. not using "#include "A.h"), but only know
>A::method_for_B_to_call() for calling back?[/color]
I seem to have gotten it to work using a pointer-to-member, despite it
being 3am and my never having ever gotten a pointer-to-member to work
before ;-)
Try this (I don't think declaring A as an incomplete type for B's benefit
would qualify as "letting B know the definition of A". At least I hope it
doesn't...):
// b.h:
class A;
class B
{
public:
typedef void (A::*ftype)();
void CallIt(A *ap, ftype f);
};
// b.cpp:
#include "b.h"
void B::CallIt(A *ap, ftype f)
{
(ap->*f)();
}
// amain.cpp:
#include <iostream>
using std::cout;
using std::endl;
#include "b.h"
class A
{
public:
void method_for_B() {
std::cout << "In method_for_B...()" << std::endl;
}
};
int main()
{
void (A::*fp)() = A::method_for_B;
A a1;
B b1;
b1.CallIt(&a1, fp);
return 0;
}
Output:
In method_for_B...()
-leor
[color=blue]
>
>Thanks!
>
>[/color]
--
Leor Zolman --- BD Software --- www.bdsoft.com
On-Site Training in C/C++, Java, Perl and Unix
C++ users: download BD Software's free STL Error Message Decryptor at: www.bdsoft.com/tools/stlfilt.html | | | | re: Call A from B
On Wed, 26 May 2004 07:52:55 +0100, "John Harrison"
<john_andronicus@hotmail.com> wrote:
[color=blue]
>
>"Ele" <Ele@inter.com> wrote in message
>news:IiWsc.29003$fF3.751864@bgtnsc05-news.ops.worldnet.att.net...[color=green]
>> Given class A and class B:
>>
>> class A
>> {
>> public:
>> void method_for_B_to_call();
>> ...
>> };
>>
>> How to make B to call back method_for_B() of A without letting B know the
>> definition of A (e.g. not using "#include "A.h"), but only know
>> A::method_for_B_to_call() for calling back?
>>
>> Thanks!
>>[/color]
>
>I don't think that is possible unless method_for_B_to_call is a static
>method. Is it?[/color]
That's what I thought, after writing up the example almost the way I just
posted it, and getting an error when I tried to invoke that function
through the pointer-to-member (the error message said A was undefined).. I
even had a response all written up saying essentially what you said above,
that it could only be done with a static member function (or some
non-member function).
Then inspiration hit: I put an asterisk after the -> in my call ;-)
If I've "cheated" somehow without knowing what I'm doing, I wouldn't be
surprised. But it /looks/ to me like what I wrote fits the job description.
-leor
--
Leor Zolman --- BD Software --- www.bdsoft.com
On-Site Training in C/C++, Java, Perl and Unix
C++ users: download BD Software's free STL Error Message Decryptor at: www.bdsoft.com/tools/stlfilt.html | | | | re: Call A from B
Leor Zolman wrote:[color=blue]
>
> On Wed, 26 May 2004 05:54:48 GMT, "Ele" <Ele@inter.com> wrote:
>[color=green]
> >Given class A and class B:
> >
> >class A
> >{
> >public:
> > void method_for_B_to_call();
> >...
> >};
> >
> >How to make B to call back method_for_B() of A without letting B know the
> >definition of A (e.g. not using "#include "A.h"), but only know
> >A::method_for_B_to_call() for calling back?[/color]
>
> I seem to have gotten it to work using a pointer-to-member, despite it
> being 3am and my never having ever gotten a pointer-to-member to work
> before ;-)
>[/color]
Thanks for the embarrasment. Everytime I say "cannot do it" someone shows
me how to do it.
[color=blue]
> Try this (I don't think declaring A as an incomplete type for B's benefit
> would qualify as "letting B know the definition of A". At least I hope it
> doesn't...):
>
> // b.h:
> class A;
>
> class B
> {
> public:
> typedef void (A::*ftype)();
> void CallIt(A *ap, ftype f);
> };
>
> // b.cpp:
>
> #include "b.h"
>
> void B::CallIt(A *ap, ftype f)
> {
> (ap->*f)();
> }
>
> // amain.cpp:
>
> #include <iostream>
> using std::cout;
> using std::endl;
>
> #include "b.h"
>
> class A
> {
> public:
> void method_for_B() {
> std::cout << "In method_for_B...()" << std::endl;
> }
>
> };
>
> int main()
> {
> void (A::*fp)() = A::method_for_B;[/color]
The above didn't compile for me (said it was non-standard). I had to change
it to
void (A::*fp)() = &A::method_for_B;
[color=blue]
> A a1;
> B b1;
> b1.CallIt(&a1, fp);
> return 0;
> }
>
> Output:
> In method_for_B...()
>
> -leor
>[/color]
Denis | | | | re: Call A from B
Denis Remezov wrote:[color=blue]
>
> Ele wrote:[color=green]
> >
> > Given class A and class B:
> >
> > class A
> > {
> > public:
> > void method_for_B_to_call();
> > ...
> > };
> >
> > How to make B to call back method_for_B() of A without letting B know the
> > definition of A (e.g. not using "#include "A.h"), but only know
> > A::method_for_B_to_call() for calling back?
> >
> > Thanks![/color]
>
> You cannot do it directly in your definitions. You need to find an
> abstraction for class B to use; which exactly - depends on the details
> of your problem.[/color]
Sorry, I was wrong, you can do it directly (see Leor's post).
(I'd still prefer not to use pointers to member functions, but
that's beyond the point).
Denis | | | | re: Call A from B
"Leor Zolman" <leor@bdsoft.com> wrote in message
news:due8b09cd2lp3kip4ivtcrn2m3nu6jvmuu@4ax.com...[color=blue]
> On Wed, 26 May 2004 05:54:48 GMT, "Ele" <Ele@inter.com> wrote:[/color]
....[color=blue]
> I seem to have gotten it to work using a pointer-to-member, despite it
> being 3am and my never having ever gotten a pointer-to-member to work
> before ;-)[/color]
....[color=blue]
> Try this (I don't think declaring A as an incomplete type for B's benefit
> would qualify as "letting B know the definition of A". At least I hope it
> doesn't...):[/color]
....[color=blue]
> // b.h:
> class A;
>
> class B
> {
> public:
> typedef void (A::*ftype)();
> void CallIt(A *ap, ftype f);
> };
>
>
> // b.cpp:
>
> #include "b.h"
>
> void B::CallIt(A *ap, ftype f)
> {
> (ap->*f)();
> }[/color]
Can be done this way. But I suspect that this is
not guaranteed to work protably by the C++ standard
(calling a member function without having seen the
definition of the class).
If this was an assignment, I think that using a virtual
method call in an abstract base would be the way to go.
A more generic way to do this would be to use a
callback object, such as the one provided by boost: http://www.boost.org/doc/html/function.html
(IIRC, this mechanism is expected to be adopted
in the next C++ standard).
For an example related to your situation, see: http://www.boost.org/doc/html/functi...html#id2511537
Once the function object is created, the calling code
does not need to know anything about the called class.
Cheers,
Ivan
-- http://ivan.vecerina.com/contact/?subject=NG_POST <- e-mail contact form
Brainbench MVP for C++ <> http://www.brainbench.com | | | | re: Call A from B
Denis Remezov wrote:[color=blue]
>
> Denis Remezov wrote:[color=green]
> >
> > Ele wrote:[color=darkred]
> > >
> > > Given class A and class B:
> > >
> > > class A
> > > {
> > > public:
> > > void method_for_B_to_call();
> > > ...
> > > };
> > >
> > > How to make B to call back method_for_B() of A without letting B know the
> > > definition of A (e.g. not using "#include "A.h"), but only know
> > > A::method_for_B_to_call() for calling back?
> > >
> > > Thanks![/color]
> >
> > You cannot do it directly in your definitions. You need to find an
> > abstraction for class B to use; which exactly - depends on the details
> > of your problem.[/color]
>
> Sorry, I was wrong, you can do it directly (see Leor's post).
> (I'd still prefer not to use pointers to member functions, but
> that's beyond the point).
>
> Denis[/color]
On the second (or is it the third) thought, 5.5.3, when describing the
operator ->* , mentions that the class type "is a completely-defined class
type". Does that mean that calling a function through a pointer-to-member
of an incomplete type is [formally] UB?
Denis | | | | re: Call A from B
"John Harrison" <john_andronicus@hotmail.com> wrote in message news:<2hit6dFdle57U1@uni-berlin.de>...[color=blue]
> "Ele" <Ele@inter.com> wrote in message
> news:IiWsc.29003$fF3.751864@bgtnsc05-news.ops.worldnet.att.net...[color=green]
> > Given class A and class B:
> >
> > class A
> > {
> > public:
> > void method_for_B_to_call();
> > ...
> > };
> >
> > How to make B to call back method_for_B() of A without letting B know the
> > definition of A (e.g. not using "#include "A.h"), but only know
> > A::method_for_B_to_call() for calling back?
> >
> > Thanks!
> >[/color]
>
> I don't think that is possible unless method_for_B_to_call is a static
> method. Is it?[/color]
Intermediate, e.g. boost::function? Of course, the code which assigns
&A::method_for_B_to_call must still #include "A.h"
Regards,
Michiel Salters | | | | re: Call A from B
On Wed, 26 May 2004 04:28:58 +0000, Denis Remezov
<REMOVETHISdenis_remezov@yahoo.removethis.ca> wrote:
[color=blue]
>
>On the second (or is it the third) thought, 5.5.3, when describing the
>operator ->* , mentions that the class type "is a completely-defined class
>type". Does that mean that calling a function through a pointer-to-member
>of an incomplete type is [formally] UB?[/color]
As I said in my response to John, I wasn't sure if I'd somehow managed to
cheat the devil here. It would seem likely I have. But even Comeau accepts
it as written (except for the missing & on taking the address of the
function) ...I've put a query in to Greg and EDG. We'll see what
transpires. But right now it's looking to me a lot like undiagnosed UB,
alas. And I was feeling so proud of myself, too ;-)
-leor
[color=blue]
>
>Denis[/color]
--
Leor Zolman --- BD Software --- www.bdsoft.com
On-Site Training in C/C++, Java, Perl and Unix
C++ users: download BD Software's free STL Error Message Decryptor at: www.bdsoft.com/tools/stlfilt.html | | | | re: Call A from B
On Wed, 26 May 2004 03:33:35 +0000, Denis Remezov
<REMOVETHISdenis_remezov@yahoo.removethis.ca> wrote:
[color=blue]
>Leor Zolman wrote:[color=green]
>>
>> On Wed, 26 May 2004 05:54:48 GMT, "Ele" <Ele@inter.com> wrote:
>>[color=darkred]
>> >Given class A and class B:
>> >
>> >class A
>> >{
>> >public:
>> > void method_for_B_to_call();
>> >...
>> >};
>> >
>> >How to make B to call back method_for_B() of A without letting B know the
>> >definition of A (e.g. not using "#include "A.h"), but only know
>> >A::method_for_B_to_call() for calling back?[/color]
>>
>> I seem to have gotten it to work using a pointer-to-member, despite it
>> being 3am and my never having ever gotten a pointer-to-member to work
>> before ;-)
>>[/color]
>
>Thanks for the embarrasment. Everytime I say "cannot do it" someone shows
>me how to do it.
>[/color]
Well, I can now share some of the embarrassment with you. John Spicer at
EDG has informed me that EDG believes an error should be issued in strict
mode for that Stupid Incomplete Type Trick I pulled.
I was rather surprised when it worked, but perhaps the fact it was 3am was
enough to keep me from pursuing my suspicions that I may have been "getting
away with something" by looking up pointer-to-member rules in the Standard.
I just realized something rather funny: when I was testing, I don't believe
I was even configured for strict mode. But sure enough, there's no
diagnostic even when I switch to strict mode. This may be as close as I
ever get to uncovering an EDG "bug" ;-)
-leor
--
Leor Zolman --- BD Software --- www.bdsoft.com
On-Site Training in C/C++, Java, Perl and Unix
C++ users: download BD Software's free STL Error Message Decryptor at: www.bdsoft.com/tools/stlfilt.html | | | | re: Call A from B
Leor Zolman wrote:[color=blue]
>
> On Wed, 26 May 2004 03:33:35 +0000, Denis Remezov
> <REMOVETHISdenis_remezov@yahoo.removethis.ca> wrote:
>[color=green]
> >Leor Zolman wrote:[color=darkred]
> >>
> >> On Wed, 26 May 2004 05:54:48 GMT, "Ele" <Ele@inter.com> wrote:
> >>
> >> >Given class A and class B:
> >> >
> >> >class A
> >> >{
> >> >public:
> >> > void method_for_B_to_call();
> >> >...
> >> >};
> >> >
> >> >How to make B to call back method_for_B() of A without letting B know the
> >> >definition of A (e.g. not using "#include "A.h"), but only know
> >> >A::method_for_B_to_call() for calling back?
> >>
> >> I seem to have gotten it to work using a pointer-to-member, despite it
> >> being 3am and my never having ever gotten a pointer-to-member to work
> >> before ;-)
> >>[/color]
> >
> >Thanks for the embarrasment. Everytime I say "cannot do it" someone shows
> >me how to do it.
> >[/color]
>
> Well, I can now share some of the embarrassment with you. John Spicer at
> EDG has informed me that EDG believes an error should be issued in strict
> mode for that Stupid Incomplete Type Trick I pulled.
>
> I was rather surprised when it worked, but perhaps the fact it was 3am was
> enough to keep me from pursuing my suspicions that I may have been "getting
> away with something" by looking up pointer-to-member rules in the Standard.
>
> I just realized something rather funny: when I was testing, I don't believe
> I was even configured for strict mode. But sure enough, there's no
> diagnostic even when I switch to strict mode. This may be as close as I
> ever get to uncovering an EDG "bug" ;-)
> -leor
>[/color]
It's interesting to learn that.
At first, I didn't even think about a possibility of calling a member on an
incomplete type.
Then, all of a sudden, neither GCC 3.3.3 nor even Comeau Online complained a
bit about your example (corrected for the '&' typo), ansi/pedantic and strict
enabled. That's quite rare for a feature that is non-standard and not (I assume)
a planned extension due to some defect report.
Denis | | | | re: Call A from B
Leor Zolman wrote:[color=blue]
> On Wed, 26 May 2004 04:28:58 +0000, Denis Remezov
> <REMOVETHISdenis_remezov@yahoo.removethis.ca> wrote:
>
>[color=green]
>>On the second (or is it the third) thought, 5.5.3, when describing the
>>operator ->* , mentions that the class type "is a completely-defined class
>>type". Does that mean that calling a function through a pointer-to-member
>>of an incomplete type is [formally] UB?[/color]
>
>
> As I said in my response to John, I wasn't sure if I'd somehow managed to
> cheat the devil here. It would seem likely I have. But even Comeau accepts
> it as written (except for the missing & on taking the address of the
> function) ...I've put a query in to Greg and EDG. We'll see what
> transpires. But right now it's looking to me a lot like undiagnosed UB,
> alas. And I was feeling so proud of myself, too ;-)
> -leor
>[/color]
See : http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15684
It appears that this is controversial. | | | | re: Call A from B
On 27 May 2004 13:10:22 EDT, Gianni Mariani <gi2nospam@mariani.ws> wrote:
[color=blue]
>Leor Zolman wrote:[color=green]
>> On Wed, 26 May 2004 04:28:58 +0000, Denis Remezov
>> <REMOVETHISdenis_remezov@yahoo.removethis.ca> wrote:
>>
>>[color=darkred]
>>>On the second (or is it the third) thought, 5.5.3, when describing the
>>>operator ->* , mentions that the class type "is a completely-defined class
>>>type". Does that mean that calling a function through a pointer-to-member
>>>of an incomplete type is [formally] UB?[/color]
>>
>>
>> As I said in my response to John, I wasn't sure if I'd somehow managed to
>> cheat the devil here. It would seem likely I have. But even Comeau accepts
>> it as written (except for the missing & on taking the address of the
>> function) ...I've put a query in to Greg and EDG. We'll see what
>> transpires. But right now it's looking to me a lot like undiagnosed UB,
>> alas. And I was feeling so proud of myself, too ;-)
>> -leor
>>[/color]
>
>See :
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15684
>
>It appears that this is controversial.[/color]
I just replied to the original reply; I think that guy missed the point
entirely. I suspect it won't end up being all that controversial, just
probably something no one's ever tried to do before. And perhaps folks just
aren't used to seeing gcc and EDG both getting the same thing wrong.
-leor
--
Leor Zolman --- BD Software --- www.bdsoft.com
On-Site Training in C/C++, Java, Perl and Unix
C++ users: download BD Software's free STL Error Message Decryptor at: www.bdsoft.com/tools/stlfilt.html |  | | | | /bytes/about
We are a network of experts and professionals in IT and software development that help one another with answers to tough questions and share insights.
Get the best answers to your questions from over 226,295 network members.
|