nested native class in managed class in VC8 not allowed??

  • Thread starter Thread starter Lonewolf
  • Start date Start date
L

Lonewolf

Hi everyone..

I was trying to implement callback fucntions in native codes in my
VC8 class, and referred to some online codes which use native class
nested within managed class. basically of the form,

__gc class CManagedClass
{
__nogc CNativeClass
{
//blah blah blah
};
};

I tried to replocate the same thing using C++/CLI, but failed. I force
the compiler to use /clr::oldsyntax and was able to compile with
problem. So it seems the problem only appear in VC8 and worked on VC7.
my C++/CLI equivalent of the same code is as follows,

public ref class CManagedClass
{
class CNativeClass
{
//blah blah blah
};
};

setting to value also does not work. And I need it in ref as this is a
..NET wrapper for the native codes, and it compiled into a .NET assembly.
The compilation failed with the error, C2814: A native type cannot be
nested within a managed type. So obviously, by not putting the __nogc,
it is treating the CNativeClass as a native class indeed and the
compiler is complaining about it. So, in VC8, what is the work around
for this issue? It cannot be that the change to VC8 prevents callback
mechanism from native codes to managed codes. Doing so will break many
old codes which use things like event sinks and even the win32 API
EnumWindow which is often used as an example of native callback in .NET.
Can someone please enlighten me ?
 
Lonewolf said:
Hi everyone..

I was trying to implement callback fucntions in native codes in my
VC8 class, and referred to some online codes which use native class
nested within managed class. basically of the form,

__gc class CManagedClass
{
__nogc CNativeClass
{
//blah blah blah
};
};
[...]
Click to expand...

Try the following:

class CNativeClass {};
ref class CManagedClass{
CNativeClass* a;
//CNativeClass a; -> fails
};

AFAIK embedding a native class is not (yet) possible. IIRC it will be
supported in the next version of VC. Meanwhile you have to create and
destroy the native objects manually.

Hope that helps.

Andre
 
Andre said:
Lonewolf said:
Hi everyone..

I was trying to implement callback fucntions in native codes in my
VC8 class, and referred to some online codes which use native class
nested within managed class. basically of the form,

__gc class CManagedClass
{
__nogc CNativeClass
{
//blah blah blah
};
};
[...]
Click to expand...


Try the following:

class CNativeClass {};
ref class CManagedClass{
CNativeClass* a;
//CNativeClass a; -> fails
};

AFAIK embedding a native class is not (yet) possible. IIRC it will be
supported in the next version of VC. Meanwhile you have to create and
destroy the native objects manually.

Hope that helps.

Andre
Click to expand...


hi,
thanx for taking the trouble to enlighten me. I have indeed done just
that. However, as i mentioned, this method can't work for callback
fucntions and event sinks to native class which I need to propagate to
the managed class via delegate. I knew this is possible and supported in
VC7 as I already have the code running using oldsyntax in VC8, However,
I would like to know the VC8 equivalent of this technique. It has to be
possible, otherwise, native class' event sink can never propagate to
managed side and the whole thing would be useless. You can refer to this
link to see the VC7 implementation.
http://www.codeproject.com/managedcpp/cbwijw.asp

What is MS answer to this? no more callback in VC8?? it cannot be that
idiotic.
 
Lonewolf said:
hi,
thanx for taking the trouble to enlighten me. I have indeed done just
that. However, as i mentioned, this method can't work for callback
fucntions and event sinks to native class which I need to propagate to
the managed class via delegate. I knew this is possible and supported
in VC7 as I already have the code running using oldsyntax in VC8,
However, I would like to know the VC8 equivalent of this technique.
It has to be possible, otherwise, native class' event sink can never
propagate to managed side and the whole thing would be useless. You
can refer to this link to see the VC7 implementation.
http://www.codeproject.com/managedcpp/cbwijw.asp

What is MS answer to this? no more callback in VC8?? it cannot be that
idiotic.
Click to expand...

Why require the native class to be nested? Just un-nest it and you should
be fine. You might have to make a function public that you otherwise
wouldn't have, but it should work.

It does seem like a rather pointless restriction in C++/CLI though.
Embedding a native class in a ref class is one thing (clearly not
supported), but why not support the lexical nesting? That has no runtime
significance at all since the nested class would not be visible to the CLR,
and nesting of is no consequence past compile time in the native case.

-cd
 
Lonewolf said:
thanx for taking the trouble to enlighten me. I have indeed done just
that. However, as i mentioned, this method can't work for callback
fucntions and event sinks to native class which I need to propagate to the
managed class via delegate. I knew this is possible and supported in VC7
as I already have the code running using oldsyntax in VC8, However, I
would like to know the VC8 equivalent of this technique. It has to be
possible, otherwise, native class' event sink can never propagate to
managed side and the whole thing would be useless. You can refer to this
link to see the VC7 implementation.
http://www.codeproject.com/managedcpp/cbwijw.asp

What is MS answer to this? no more callback in VC8?? it cannot be that
idiotic.
Click to expand...

Is this what you wanted?

http://msdn2.microsoft.com/en-us/library/367eeye0.aspx
 
James said:
Is this what you wanted?

http://msdn2.microsoft.com/en-us/library/367eeye0.aspx
Click to expand...

Hi,
thanx for the succor. It's working now. However, I do find htis method
a lot more complicated compared to the nested native class method
allowed in VC7. Is there a reason why MS is making this breaking change?
btw, I also realize the String class behaves very differently from VC7
and VC8. I did this,

VC8
~~~~

String^ s;
int a=12;
s="This is a string displaying a number, a="+a;
Debug::Write(s);
//output >> This is a string displaying a number, a=12

VC7
~~~~
String* s;
int a=12;
s="This is a string displaying a number, a="+a; //not allowed ! why?
Debug::Write(s);

it's probably due to me not being familiar with MC++. I came from VC6
and prev experience with .NET was in C# using VS2003. Only now then I
play with VC8's C++/CLI which made things more C++ than MC did. However,
the function ptrs and delegate can be irritating when it broke.
 
Lonewolf said:
Andre said:
Lonewolf wrote:
[...]


Try the following:

class CNativeClass {};
ref class CManagedClass{
CNativeClass* a;
//CNativeClass a; -> fails
};
[...]
Andre
Click to expand...


hi,
thanx for taking the trouble to enlighten me. I have indeed done
just that. However, as i mentioned, this method can't work for callback
fucntions and event sinks to native class which I need to propagate to
the managed class via delegate. [...]
Click to expand...

Ok, I haven't dealt with member function pointers that much. When I
needed callback functions into native code I commonly used interface
pointers for that purpose. Surely they don't map to delegates directly,
as, if I understood it correctly, it could be done in managed C++ by
using a nested class declaration ?

Perhaps the restriction of nested class declaration is a side effect of
the embedded class restrictions introduced in C++/CLI.

You can read more about this issue in:

http://blogs.msdn.com/branbray/archive/2005/07/20/441099.aspx

Andre
 
Carl said:
It does seem like a rather pointless restriction in C++/CLI though.
Embedding a native class in a ref class is one thing (clearly not
supported), but why not support the lexical nesting?
Click to expand...

The reason is accessibility. As of now, all the member functions for native
classes are implemented as global functions -- they're not really members of
the value class used to encodes the native class. Since they aren't members,
they don't have access to non-public members of the containing class.

As we build better technology, we may move towards emitting member functions
as members of the encoding class. When that happens, we'll lift the
restriction that native classes cannot nest in managed types.

Hope that helps!
 
Brandon Bray said:
The reason is accessibility. As of now, all the member functions for
native classes are implemented as global functions -- they're not really
members of the value class used to encodes the native class. Since they
aren't members, they don't have access to non-public members of the
containing class.

As we build better technology, we may move towards emitting member
functions as members of the encoding class. When that happens, we'll lift
the restriction that native classes cannot nest in managed types.
Click to expand...

That makes sense - and I figured the answer would be something like that.
Personally, I'd rather have 'em supported but simply lacking accessibility -
afterall, the current C++ standard grants no special access to the enclosing
class to members of a nested class. Granted, the next standard (and/or next
TC) removes that oversight.

Thanks for the explanation.

-cd
 
Back
Top