Problem with construction via a function pointer to a local method

  • Thread starter Thread starter Peter Oliphant
  • Start date Start date
P

Peter Oliphant

Here is a simplification of my code. Basically, I have a class (A) that can
be constructed using a function pointer to a function that returns a bool
with no parameters. I then want to create an instance of this class (A) in
another class (B) which uses one of its own methods of the 'proper form' to
initialize the instance. But I get an error:

__gc class ClassA
{
public:
ClassA( bool (*func)(void) ) {//---some code---//} // constructor
} ;


__gc class ClassB
{
public:
void Method_B1( )
{
class_a = new ClassA( Method_B2 ) ; // error C2664
}

private:
bool Method_B2( ) {{//---some code---//}

ClassA* class_a ;
} ;

error C2664: 'ClassA::ClassA(bool (__cdecl *)(void))' : cannot convert
parameter 1 from 'bool (void)' to 'bool (__cdecl *)(void)

What is going on here, and what do I need to fix this (i.e., allow me to
pass such a method)?
 
Hi Peter!
Here is a simplification of my code. Basically, I have a class (A) that can
be constructed using a function pointer to a function that returns a bool
with no parameters. I then want to create an instance of this class (A) in
another class (B) which uses one of its own methods of the 'proper form' to
initialize the instance. But I get an error:
Click to expand...


For managed code you should use a delegate!!!
And no function pointers...

--
Greetings
Jochen

My blog about Win32 and .NET
http://blog.kalmbachnet.de/
 
Ok, cool, and thanks! I should use 'delegates'. However, since I've never
even heard of a 'delegate' before, could you give me an idea HOW to use
them? : )

And what's wrong with function pointers and managed code? So far it seems
managed stuff doesn't support many things, like 'const', 'static', etc, and
now function pointers? It seems like a whole new language should create
instead of trying to keep managed and unmanaged together if there are so
many incompatibilities between the two. I like managed stuff, but the more I
use it the more I keep falling into 'traps' (stuff I think should work
(since it does in unmanaged code) that generates errors)...

PS - I looked 'delegates' up in the on-line MSDN, but it doesn't seem to say
anything remotely like about how to pass a function of a given form to a
method (and I NEED to PASS different functions, I can't just hard code each
case, there are an inifinte number of such cases!).
 
Actually, I re-read the MSDN stuff on delegates, and I think I'm getting the
hang of them. A delegate IS a function form, and you can create instances of
a delegate that are associated with a function of that form that executes
that function. Now one can pass a pointer to the delegate, and this is
equivalent to passing a 'function pointer' of the original function.

Did that make sense?
 
Peter said:
Actually, I re-read the MSDN stuff on delegates, and I think I'm getting the
hang of them. A delegate IS a function form, and you can create instances of
a delegate that are associated with a function of that form that executes
that function. Now one can pass a pointer to the delegate, and this is
equivalent to passing a 'function pointer' of the original function.

Did that make sense?
Click to expand...

That's basically the idea... A delegate is an object that is callable
using a given signature, and the delegate can really represent a "call"
to a member function (static or not) or another "callable" entity (such
as another delegate).

Also, you code was wrong because it is buggy in *unmanaged* C++, this
has nothingto do with manged stuff : you can't use a non-static member
fuction pointer instead of a free function pointer (they do not have
the same representation : a non-static member function pointer is most
of the time bigger).
You can use a pointer to a static member function instead of a free
function pointer (although it is not guaranteed to work by the
standard, it is ok on all architectures I am aware of).

Concerning managed code, you *can* use function pointers in managed
code (well, pointers to unmanged functions that is), but you must obey
the rules of unmanaged C++.

Arnaud
MVP - VC
 
Actually, now that I've used them, I really like delegates. Makes the code
look a lot better than the format of function pointers... : )
 
Peter said:
Actually, now that I've used them, I really like delegates. Makes the
code look a lot better than the format of function pointers... : )
Click to expand...

I agree that delegates (or "closures" or whatever you like to call them) are
a great thing that should be part of C++ IMHO. In unmanaged C++, there are
alternatives using libraries such as boost::signal or LibSigC++ that provide
the same facilities.

Arnaud
MVP - VC
 
Back
Top