Using managed c++ ptr from unmanaged c++

[Andrew]

I want to use a managed c++ class from an unmanaged class. Here is my
code:

// *** Unmanaged Code

// .h file
class UnmanagedClass
{
public:
// Other stuff here
private:

std::string mMessage;
nogc_ManagedClass* mNogc_ManagedClass;
};
// .cpp file
UnmanagedClass::UnmanagedClass(void)
{
mNogc_ManagedClass = nogc_ManagedClass::create();
}

// *** Managed Code

// .h file
class nogc_ManagedClass
{
public:

// some other non static stuff
static nogc_ManagedClass* create(void);
};
// .cpp file

#using <mscorlib.dll>
#include ".\nogc_ManagedClass.h"

nogc_ManagedClass* nogc_ManagedClass::create(void)
{
return new nogc_ManagedClass();
}

I am fairly new to managed c++. I have seen some posting suggesting
that the pointer to the managed class should be wrapped in gcroot<T>,
but I think this is only true if the managed class is marked as __gc.
Is this a safe way to create and use a managed class from an unmanaged
class?

[Tomas Restrepo \(MVP\)]

Andrew,

I want to use a managed c++ class from an unmanaged class. Here is my
code:

// *** Unmanaged Code

// .h file
class UnmanagedClass
{
public:
// Other stuff here
private:

std::string mMessage;
nogc_ManagedClass* mNogc_ManagedClass;
};
// .cpp file
UnmanagedClass::UnmanagedClass(void)
{
mNogc_ManagedClass = nogc_ManagedClass::create();
}

// *** Managed Code

// .h file
class nogc_ManagedClass
{
public:

// some other non static stuff
static nogc_ManagedClass* create(void);
};
// .cpp file

#using <mscorlib.dll>
#include ".\nogc_ManagedClass.h"

nogc_ManagedClass* nogc_ManagedClass::create(void)
{
return new nogc_ManagedClass();
}

I am fairly new to managed c++. I have seen some posting suggesting
that the pointer to the managed class should be wrapped in gcroot<T>,
but I think this is only true if the managed class is marked as __gc.
A Managed class *is* marked as __gc. Otherwise you've got an unmananged
class. I think you're confusing what a managed class is with an unmanaged
class that happens to have managed methods. Two entirely different things.

In you're case, it seems you're only dealing with __nogc (unmanaged)
classes, so you should be fine, in general (basically, the usual C++ rules
should apply in these cases).

--
Tomas Restrepo
to****@mvps.org
Is this a safe way to create and use a managed class from an unmanaged
class?

[Andrew]

"Tomas Restrepo \(MVP\)" <to****@mvps.org> wrote in message news:<OB**************@TK2MSFTNGP11.phx.gbl>...

Andrew,

A Managed class *is* marked as __gc. Otherwise you've got an unmananged
class. I think you're confusing what a managed class is with an unmanaged
class that happens to have managed methods. Two entirely different things.

In you're case, it seems you're only dealing with __nogc (unmanaged)
classes, so you should be fine, in general (basically, the usual C++ rules
should apply in these cases).

Thanks for you response Tomas.

For some reason I was under the impression that a managed class was a
class that was compiled with the /CLR options and #using
<mscorlib.dll>. I have a couple more questions:

1. So will the "nogc_ManagedClass" that I had in the example compile
to CIL, and the "UnmanagedClass" complile to x86 code?

2. If I want to use a __gc class from my "nogc_ManagedClass" I will
need to have the pointer to that class wrapped with gcroot<T>?

[Tomas Restrepo \(MVP\)]

Hi Andrew,

Thanks for you response Tomas.

For some reason I was under the impression that a managed class was a
class that was compiled with the /CLR options and #using
<mscorlib.dll>. I have a couple more questions:

1. So will the "nogc_ManagedClass" that I had in the example compile
to CIL, and the "UnmanagedClass" complile to x86 code?
A class does not compile to code. *Methods* in the class, will, though.

That's the key point. MC++ makes a very explicit exception about what is
managed data (i.e. __gc/__nogc classes) and what is managed code (methods
that compile to CIL or x86).

So you can have a __nogc class whose *methods* are compiled to CIL, but the
class itself is still unmanaged (meaning it gets allocated in the stack or
the unmananged heap), or __nogc classes that contain both managed and
unmanaged methods. A __gc class, on the other hand, only has managed
methods.

So, when you compile code with /clr, classes by default remain __nogc, but
the methods they contain might be compiled as managed code. That's perfectly
valid.
2. If I want to use a __gc class from my "nogc_ManagedClass" I will
need to have the pointer to that class wrapped with gcroot<T>?

Depends on what you mean by "use". If you mean contain a reference to the
__gc class as a field of your __nogc class, then the answer is yes. However,
any managed methods the __nogc class have can manipulate a __gc class
directly, without gcroot.

--
Tomas Restrepo
to****@mvps.org

[Andrew]

"Tomas Restrepo \(MVP\)" <to****@mvps.org> wrote in message news:<u9**************@tk2msftngp13.phx.gbl>...

Hi Andrew,

Thanks for you response Tomas.

For some reason I was under the impression that a managed class was a
class that was compiled with the /CLR options and #using
<mscorlib.dll>. I have a couple more questions:

1. So will the "nogc_ManagedClass" that I had in the example compile
to CIL, and the "UnmanagedClass" complile to x86 code?

A class does not compile to code. *Methods* in the class, will, though.

That's the key point. MC++ makes a very explicit exception about what is
managed data (i.e. __gc/__nogc classes) and what is managed code (methods
that compile to CIL or x86).

So you can have a __nogc class whose *methods* are compiled to CIL, but the
class itself is still unmanaged (meaning it gets allocated in the stack or
the unmananged heap), or __nogc classes that contain both managed and
unmanaged methods. A __gc class, on the other hand, only has managed
methods.

So, when you compile code with /clr, classes by default remain __nogc, but
the methods they contain might be compiled as managed code. That's perfectly
valid.

2. If I want to use a __gc class from my "nogc_ManagedClass" I will
need to have the pointer to that class wrapped with gcroot<T>?

Depends on what you mean by "use". If you mean contain a reference to the
__gc class as a field of your __nogc class, then the answer is yes. However,
any managed methods the __nogc class have can manipulate a __gc class
directly, without gcroot.

Tomas,

I am working a project that is currently written in c++. I need to
modify this project so that it uses some components written in c#.
This modification needs to be done with as little effect in the
existing code as possible. I am considering have my current c++ code
have a pointer to a nogc class and the nogc class have a pointer to a
gc class. This gc class will then communicate with some c#
assemblies.

Is there any value in only including the /clr compile option on the
nogc and gc classes and leaving it off the rest of the classes in the
project? Based on your last response, it seems that including the
/clr option on the entire project should have little effect on the old
c++ classes.

If I include the /clr option on either a subset of classes or the
entire project what effect does this have on linking? Can incremental
links still be done? I heard from a co-worker that adding the /clr
option to a project means incremental links can no longer be done.
This is a large project, so this could slow down development
considerably.

[Tomas Restrepo \(MVP\)]

Hi Andrew,

I am working a project that is currently written in c++. I need to
modify this project so that it uses some components written in c#.
This modification needs to be done with as little effect in the
existing code as possible. I am considering have my current c++ code
have a pointer to a nogc class and the nogc class have a pointer to a
gc class. This gc class will then communicate with some c#
assemblies.

Is there any value in only including the /clr compile option on the
nogc and gc classes and leaving it off the rest of the classes in the
project? Based on your last response, it seems that including the
/clr option on the entire project should have little effect on the old
c++ classes.
It might have little impact on the source code, but it might have an impact
on performance, in some cases (depends a lot on what your code is like, so
it's not easy to say upfront). I suggest you do a few tests to see what
works best for you.
If I include the /clr option on either a subset of classes or the
entire project what effect does this have on linking? Can incremental
links still be done? I heard from a co-worker that adding the /clr
option to a project means incremental links can no longer be done.
This is a large project, so this could slow down development
considerably.

If this is an issue, then I'd recommend moving the code you're compiling
with /clr to a different module (i.e. isolate it to it's own DLL). That way,
it would be easier to maintain. In general, in cases like this, keeping the
code isolated will mean the minimal impact on your compiling process.

--
Tomas Restrepo
to****@mvps.org