Thank you for the answer. It was very important for me to know that this
will remain the same in Whidbey. The Quake II .NET effort
(
http://www.codeproject.com/managedcpp/Quake2.asp) is something I've seen
Microsoft demonstrate a couple of times. I found that quite compelling. I
guess the Quake II .NET program suffers from the double P/Invoke on it's
inter-mixed-mode-assembly calls too then? Or did they wrap everything that
is called inter-assembly and then change every call-site to call the wrapped
functions instead?
It seems to me that the suggestion for how to wrap things is backwards. My
implementation methods already exist. I don't want to touch them. I just
want to wrap them as they are. I would think to do it like this instead:
Compile: cl /clr /LD testdll.cpp
// managed interface
public __value class Utils {
public:
static int func(int i, int j) {
myNameSpace::func(i, j);
}
};
namespace myNameSpace {
// native interface
__declspec(dllexport)
int func(int i, int j) {
return i + j;
}
}
After seeing Quake II .NET my thoughts were that I could take our large,
complex and extensible multi-dll program and arrange our build process so
that we could experiment with a /CLR compiled version for a good long time
while we learned the ins and outs of C++ interop and how to begin to
introduce GC types into it's implementation and its documented interfaces.
Furthermore I thought that I could slowly add the /CLR switch to individual
source files as I found time to conquer them. That has turned out to be a
fair amount of work for us because many of our source files are in fact .c
files. When compiling them with /CLR I ran into problems at link time and
ultimately realized that Microsoft was desupporting the /CLR switch for C
source code anyway. Then I realized that modules needed to be converted to
C++ prior to adding the /CLR switch and that's where it begins to take quite
a bit of effort in such a large application.
But since these many .dlls call each other, and since to get decent
inter-assembly call performance I need to wrap all my functions as static
methods of a GC type and, here is the kicker, since I have to then change
each and every call site to functions that have been compiled with /CLR to
instead call the GC wrapped versions of the functions, it now becomes a
rather complex task to effect this transition slowly over time. You have to
leave call-sites that aren't compiled into IL yet alone, yet you have to
alter all the others. The equation of what is IL versus x86 is always
changing as I manage to add the /CLR switch to new modules. I guess I would
have to arrange to use the preprocessor to substitute the right calls with
calls to the wrapped versions. Certainly possible, but a fair amount of
work.
It seems like lots of folks that see Quake II .NET are going to take it to
heart and try the same thing that I have tried and ultimately end up facing
the very same problem. It would be nice if the linker could optionally
generate and include GC wrappers for my exported functions. Imagine that I
supply a namespace::classname for a GC class that I want the linker to
create and then the linker dutifully adds static methods to that class which
simply wrap each of my exports. It could even generate a .h file for me that
mapped the native name to the appropriate method in the generated GC wrapper
class.
Then I could maintain both the tranditional all native build of my
application and a piece-meal mixed-mode build of our application while we
work toward adding the /CLR switch to virtually everything in the
application. I'm trying to follow the Quake II .NET lead, but my app is a
lot larger and more complex and doing it all in one fell swoop isn't
practical.
Bern McCarty
Bentley Systems, Inc.
"Yan-Hong Huang[MSFT]" <yhhuang@online.microsoft.com> wrote in message
news:Ws$lJK8NEHA.3204@cpmsftngxa10.phx.gbl...[color=blue]
> Hello Bern,
>
> I have contacted our VC++ developer on it. Unfortunately, under this
> situation, it will still cost that much even in VS Whidbey. Here is the
> response from the developer.
>
> -----------------------------
>
> It will still cost that much. The problem is that the managed DLL loading
> mechanism only exposes managed types not stand alone functions, and
> exported functions must be callable from native code because of the import
> lib. Then the kicker is that native code cannot use or call to functions
> that are members of native types.
>
> If the API needs to be exposed to both native and managed code through one
> dll, it is possible to do this. Here is my trivial example again, extended
> to expose a managed interface, and a native interface.
>
> File: testdll.cpp
>
> Compile: cl /clr /LD testdll.cpp
> // managed interface
> public __value class Utils {
> public:
> static int func(int i, int j) {
> return i + j;
> }
> };
>
> // native interface
> __declspec(dllexport)
> int func(int i, int j) {
> return Utils::func(i, j);
> }
>
> File: managed.cpp
>
> Compile: cl /clr managed.cpp
> // Use the managed mechanism to access the API. Note that #using pulls in
> types, not standalone functions,
> // so our API must be a member of a managed type, in this case the class
> Utils. Also, we have not linked
> // to the import lib.
> #using <testdll.dll>
>
> int main() {
> return Utils::func(0, 0);
> }
>
> File: native.cpp
>
> Compile: cl native.cpp /link testdll.lib
> // Now we link with the import lib.
> int func(int, int);
> int main() {
> return func(0, 0);
> }
>
> -----------------------------
>
> I totally understand that you need a lot of work to migrate the code to
> managed c++ wrapper class if the performance is quite important for you.
> However, from what we have discussed till now, it seems there is no other
> easy way to implement it yet. As that developer mentioned, managed DLL
> loading mechanism only exposes managed types not stand alone functions.[/color]
For[color=blue]
> the time being, in order to improve the performance of inter-assembly
> calls, we need to implement the exported functions as wrapper class
> functions.
>
> If you have any more concerns on it, please feel free to post here. Thanks
> very much for your understanding.
>
> Best regards,
> Yanhong Huang
> Microsoft Community Support
>
> Get Secure! 每
www.microsoft.com/security
> This posting is provided "AS IS" with no warranties, and confers no[/color]
rights.[color=blue]
>[/color]
