Problem with construction via a function pointer to a local method

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)?

re: Problem with construction via a function pointer to a local method

Hi Peter![color=blue]
> 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:[/color]


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

--
Greetings
Jochen

My blog about Win32 and .NET
http://blog.kalmbachnet.de/

re: Problem with construction via a function pointer to a local method

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

"Jochen Kalmbach [MVP]" <nospam-Jochen.Kalmbach@holzma.de> wrote in message
news:uAu%23NAryFHA.2652@TK2MSFTNGP14.phx.gbl...[color=blue]
> Hi Peter![color=green]
>> 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:[/color]
>
>
> For managed code you should use a delegate!!!
> And no function pointers...
>
> --
> Greetings
> Jochen
>
> My blog about Win32 and .NET
> http://blog.kalmbachnet.de/[/color]

re: Problem with construction via a function pointer to a local method

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 Oliphant" <poliphant@RoundTripInc.com> wrote in message
news:%23XiSdfryFHA.904@tk2msftngp13.phx.gbl...[color=blue]
> 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!).
>
> "Jochen Kalmbach [MVP]" <nospam-Jochen.Kalmbach@holzma.de> wrote in
> message news:uAu%23NAryFHA.2652@TK2MSFTNGP14.phx.gbl...[color=green]
>> Hi Peter![color=darkred]
>>> 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:[/color]
>>
>>
>> For managed code you should use a delegate!!!
>> And no function pointers...
>>
>> --
>> Greetings
>> Jochen
>>
>> My blog about Win32 and .NET
>> http://blog.kalmbachnet.de/[/color]
>
>[/color]

re: Problem with construction via a function pointer to a local method

Peter Oliphant wrote:[color=blue]
> 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?[/color]

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

re: Problem with construction via a function pointer to a local method

Actually, now that I've used them, I really like delegates. Makes the code
look a lot better than the format of function pointers... : )

<adebaene@club-internet.fr> wrote in message
news:1128675977.983013.62470@g44g2000cwa.googlegro ups.com...[color=blue]
>
> Peter Oliphant wrote:[color=green]
>> 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?[/color]
>
> 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
>[/color]

re: Problem with construction via a function pointer to a local method

Peter Oliphant wrote:[color=blue]
> Actually, now that I've used them, I really like delegates. Makes the
> code look a lot better than the format of function pointers... : )[/color]

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