 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / Languages / Managed C++ / May 2006c++/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.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 > Anybody know what the "internal limitation" of a method signature is > for c++/cli? [quoted text clipped - 8 lines] > 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 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 ...) > method signature (open file method) looks like this: > int foo(FILE *file1, FILE *file2, CUSTOMSTRUCT1 custom1, CUSTOMSTRUCT2 [quoted text clipped - 3 lines] > // 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 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 > 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 > 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 Hi Sharon, >> Just add a new file to the project that is compiled without /clr. Place >> the [quoted text clipped - 9 lines] > 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 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 > Duly noted. I suppose it does make more sense to have all the native > code residing in separate units. Many thanks, Marcus. [quoted text clipped - 6 lines] > 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 :-) 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! Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.