new to managed c++, interop questions

[Eric Twietmeyer]

Hello,

I'm starting to investigate cs, managed c++ and interoperating with a very
large unmanaged code base. We are going to use Windows Forms (written in
cs) to replace our old fashioned GUI. The guts will remain in unmanaged
c++. So I need to write public managed c++ wrapper classes for the couple
of interfaces the unmanaged stuff needs to expose for the GUI.

Questions:

1) I export a function, say CreateFooInterface, from my unmanaged code
(extern "C"). It my managed wrapper class I have a private pointer object
declared as IFoo* m_pFoo. Call the wrapper class tMgdFoo. In tMgdFoo ctor
I need to create an m_pFoo. If CreateFooInterface returns a pointer to
IFoo, I can successfully write:

m_pFoo = CreateFooInterface();

However, if I declare CreateFooInterface as: long CreateFooInterface( IFoo**
ppFoo ), and attempt to write:

CreateFooInterface( &m_pFoo );

in my tMgdFoo ctor, then I get a compiler error saying it can't convert from
IFoo * __gc * to IFoo**. Why does the former work, but the latter does not?
Is it because I can't take the address of a member variable of a __gc class?
Or is there a mechanism to allow me to do that? I guess I don't understand
the rules about passing around (or back) pointers to memory allocated by the
c run time.

2) In my test app to try all this out I have a cs exe, a dll in which
managed c++ code only resides, and the original unmanaged dll. If I debug
the cs exe and turn on unmanaged code debugging I can place break points in
my unmanaged dll code and I will hit them. The problem is that doing any
debugging there takes a very very long time as the IDE is extremely slow to
respond. Obviously something is going on under the covers when the outer
layer (app) is running in the clr but one is debugging the unmanaged stuff.
So I turned it around and specified that the project I was debugging was the
unmanaged dll and then I specified the cs exe as the app to execute to start
the debugging session. When I did this I was not able to hit breakpoints I
had set in my unmanaged code.

So the question is: How can I reasonably debug unmanaged code when the app
that eventually causes that dll to load is a cs app? It is not really
usable as it is, for instance one line of code of the sort std::cout <<
"line of text" << std::endl; when executed in this manner results in the
characters displaying on the console one by one, extremely slowly. There
must be a better way.

Thanks for the help,

Eric Twietmeyer

[Mahesh Hariharan[MSFT]]

Hi,
Answer to first part of your question
This is because m_pFoo is a member of a gc class , so it exists on the
GC(Managed) heap. Taking its address gives a managed pointer..so the
compiler is complaining (valid)
Imagine u pass this pointer to a unmanaged function, and in the meantime
Garbage collection happens..this may move the object.. and so the address
is no longer valid..

So u need to pin the object..before u can pass the managed pointer to a
unmanaged func..
look up __pin* in MSDN..
--------------------

From: "Eric Twietmeyer" <no******@noisp.com>
Subject: new to managed c++, interop questions
Date: Fri, 3 Oct 2003 13:30:20 -0700
Lines: 54
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Message-ID: <ep**************@TK2MSFTNGP12.phx.gbl>
Newsgroups: microsoft.public.dotnet.languages.vc
NNTP-Posting-Host: s235.207-182-32-net.desert.net 207.182.32.235
Path: cpmsftngxa06.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTN GP12.phx.gbl
Xref: cpmsftngxa06.phx.gbl microsoft.public.dotnet.languages.vc:29008
X-Tomcat-NG: microsoft.public.dotnet.languages.vc

Hello,

I'm starting to investigate cs, managed c++ and interoperating with a very
large unmanaged code base. We are going to use Windows Forms (written in
cs) to replace our old fashioned GUI. The guts will remain in unmanaged
c++. So I need to write public managed c++ wrapper classes for the couple
of interfaces the unmanaged stuff needs to expose for the GUI.

Questions:

1) I export a function, say CreateFooInterface, from my unmanaged code
(extern "C"). It my managed wrapper class I have a private pointer object
declared as IFoo* m_pFoo. Call the wrapper class tMgdFoo. In tMgdFoo ctor
I need to create an m_pFoo. If CreateFooInterface returns a pointer to
IFoo, I can successfully write:

m_pFoo = CreateFooInterface();

However, if I declare CreateFooInterface as: long CreateFooInterface( IFoo**ppFoo ), and attempt to write:

CreateFooInterface( &m_pFoo );

in my tMgdFoo ctor, then I get a compiler error saying it can't convert fromIFoo * __gc * to IFoo**. Why does the former work, but the latter does not?Is it because I can't take the address of a member variable of a __gc class?Or is there a mechanism to allow me to do that? I guess I don't understand
the rules about passing around (or back) pointers to memory allocated by thec run time.

2) In my test app to try all this out I have a cs exe, a dll in which
managed c++ code only resides, and the original unmanaged dll. If I debug
the cs exe and turn on unmanaged code debugging I can place break points in
my unmanaged dll code and I will hit them. The problem is that doing any
debugging there takes a very very long time as the IDE is extremely slow to
respond. Obviously something is going on under the covers when the outer
layer (app) is running in the clr but one is debugging the unmanaged stuff.
So I turned it around and specified that the project I was debugging was theunmanaged dll and then I specified the cs exe as the app to execute to startthe debugging session. When I did this I was not able to hit breakpoints I
had set in my unmanaged code.

So the question is: How can I reasonably debug unmanaged code when the app
that eventually causes that dll to load is a cs app? It is not really
usable as it is, for instance one line of code of the sort std::cout <<
"line of text" << std::endl; when executed in this manner results in the
characters displaying on the console one by one, extremely slowly. There
must be a better way.

Thanks for the help,

Eric Twietmeyer