c++/cli method signature limitation

  • Thread starter Thread starter dotnetchic
  • Start date Start date
D

dotnetchic

Anybody know what the "internal limitation" of a method signature is
for c++/cli?

I've got a mixed assembly that throws an exception for one particular
function (very large if-else control). It throws a
System.Runtime.InteropServices.MarshalDirectiveException with the
additional information "Internal limitation: method signature is too
complex or too large." When I compile the function as native, no
problem.

TIA,
Sharon
 
Hi Sharon
dotnetchic said:
Anybody know what the "internal limitation" of a method signature is
for c++/cli?

I've got a mixed assembly that throws an exception for one particular
function (very large if-else control). It throws a
System.Runtime.InteropServices.MarshalDirectiveException with the
additional information "Internal limitation: method signature is too
complex or too large." When I compile the function as native, no
problem.

TIA,
Sharon
Click to expand...

This looks like a very interesting bug.
Can you please tell me what the CallStack of the MarshalDirectiveException
gives you?
Can you please tell me the signature of the critical function?

Marcus
 
Well, let's see...

method signature (open file method) looks like this:
int foo(FILE *file1, FILE *file2, CUSTOMSTRUCT1 custom1, CUSTOMSTRUCT2
custom2, unsigned short parm5, unsigned short parm6, unsigned short
parm7, int parm8, unsigned short &parm9)
{
// function body = 1800+ lines, roughly 1550 lines of executable code
}

and the call stack at the point the exception is thrown is:
KERNEL32.DLL!7c81eb33()
[Frames below may be incorrect and/or missing, no symbols loaded for
KERNEL32.DLL]
KERNEL32.DLL!7c81eb33()
MyApp.exe!foo(...)
[External Code]
MyApp.exe!OnFileOpen() Line 949 + 0x35 bytes
[External Code]
(... then several calls into mfc80d.dll for messaging ...)
 
dotnetchic said:
method signature (open file method) looks like this:
int foo(FILE *file1, FILE *file2, CUSTOMSTRUCT1 custom1, CUSTOMSTRUCT2
custom2, unsigned short parm5, unsigned short parm6, unsigned short
parm7, int parm8, unsigned short &parm9)
{
// function body = 1800+ lines, roughly 1550 lines of executable code
}
Click to expand...

I would try passing pointers to the two custom structures instead of the
entire structures themselves to the function. While the marshaller should be
able to handle a 9-parameter function, it may be choking on the structures.

Sean
 
Well, this is a bit of legacy code that I'm not sure I want to modify.
I'll probably leave it compiled as unmanaged for now, and eventually
get around to re-writing it.

But I will test your hypothesis, once I figure out how...can we pass a
pointer in c++/cli? Don't we have to use IntPtr or something? ??

Thanks,
Sharon
 
dotnetchic said:
Well, this is a bit of legacy code that I'm not sure I want to modify.
I'll probably leave it compiled as unmanaged for now, and eventually
get around to re-writing it.
Click to expand...

Just add a new file to the project that is compiled without /clr. Place the
function into this file. If necessay, you can also write a wrapper function
in this file, that passes all the arguments via one struct pointer or so.

In the file where you want to call the wapper function, just declare it is
usual.
But I will test your hypothesis, once I figure out how...can we pass a
pointer in c++/cli? Don't we have to use IntPtr or something? ??
Click to expand...

No, you can work with pointers in C++/CLI, no need to use IntPtr.

Marcus
 
That was easier than I thought. Pass pointers to the structs instead,
compile as managed, and it appears to run smoothly. Well, the program
crashes :( but it's beyond the scope of this thread.

cheers!
 
Just add a new file to the project that is compiled without /clr. Place the
function into this file. If necessay, you can also write a wrapper function
in this file, that passes all the arguments via one struct pointer or so.
Click to expand...

I've been using the #pragma unmanaged/managed keywords to delimit
native functions, but it looks like a lot of my native code will end up
residing in the same file, so I can in some cases compile the entire
file without /clr.

Is this a bad practice? Should I avoid using the #pragma unmanaged
keyword? I'd really hate to write wrappers for all these native
functions. I'm porting a very large codebase.

Sharon
 
Hi Sharon,

dotnetchic said:
I've been using the #pragma unmanaged/managed keywords to delimit
native functions, but it looks like a lot of my native code will end up
residing in the same file, so I can in some cases compile the entire
file without /clr.

Is this a bad practice? Should I avoid using the #pragma unmanaged
keyword?
Click to expand...

It is a bad practice to use #pragma unmanaged. Native functions should end
up in cpp files compiled to native code and managed functions should end up
in cpp files compiled with /clr.
I'd really hate to write wrappers for all these native functions. I'm
porting a very large codebase.
Click to expand...

There is no need to write wrappers.The only reason why you had to write one
wrapper frunction was because you reached the limits of P/Invoke
 
Duly noted. I suppose it does make more sense to have all the native
code residing in separate units. Many thanks, Marcus.
There is no need to write wrappers.The only reason why you had to write one
wrapper frunction was because you reached the limits of P/Invoke
Click to expand...

Speaking of, is this limitation of P/Invoke documented anywhere? I've
been reading up on the usage of P/Invoke for a couple of weeks now, and
only in debugging did I discover this problem.

Sharon
 
dotnetchic said:
Duly noted. I suppose it does make more sense to have all the native
code residing in separate units. Many thanks, Marcus.


Speaking of, is this limitation of P/Invoke documented anywhere? I've
been reading up on the usage of P/Invoke for a couple of weeks now, and
only in debugging did I discover this problem.
Click to expand...

After you have made me aware of this problem, it will likely be in the book
I am currently witing. Thanks for the info :-)
 
Back
Top