471,089 Members | 1,622 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,089 software developers and data experts.

c++/cli method signature limitation

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.MarshalDirectiveExc eption 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

May 10 '06 #1
10 1460
Hi Sharon
"dotnetchic" <do********@gmail.com> wrote in message
news:11**********************@q12g2000cwa.googlegr oups.com...
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.MarshalDirectiveExc eption 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


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
May 11 '06 #2
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 ...)

May 11 '06 #3
"dotnetchic" wrote:
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
}


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
May 11 '06 #4
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

May 11 '06 #5
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!

May 11 '06 #6
"dotnetchic" <do********@gmail.com> wrote in message
news:11*********************@i39g2000cwa.googlegro ups.com...
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.
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? ??


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

Marcus

May 11 '06 #7
> 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.


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

May 11 '06 #8
Hi Sharon,

"dotnetchic" <do********@gmail.com> wrote in message
news:11**********************@j73g2000cwa.googlegr oups.com...
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.
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?


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.


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
May 11 '06 #9
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


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

May 11 '06 #10
"dotnetchic" <do********@gmail.com> wrote in message
news:11**********************@u72g2000cwu.googlegr oups.com...
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


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.


After you have made me aware of this problem, it will likely be in the book
I am currently witing. Thanks for the info :-)
May 12 '06 #11

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

reply views Thread by Cordell Lawrence | last post: by
19 posts views Thread by Dave Raskin | last post: by
5 posts views Thread by Simon Harris | last post: by
3 posts views Thread by Amin Sobati | last post: by
2 posts views Thread by Richard Jebb | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.