Managed code / unmanaged code?

[repstat]

Hi
I have a project which is going to be doing some string manipulation which
needs to be pretty fast. The user interface is going to be written in C#. I
am going to write the string handling functions in a C++ DLL.

My first question is, if I insert a C++ project into my C# solution, how
will VS.NET know that I want it to be unmanaged code? I intend to be calling
the DLLs functions using DllImport. I've heard that you can have unmanaged
code and managed code in a single code file, so I was wondering if the
setting between managed code and unmanaged code is some sort of declaration,
or is it at the project level?

My second question is, if I want to use DllImport to call the DLL's
functions, what is the best way to specify the directory in which to look
for the DLL? I can't get my head round whether to specify the debug
location, the release location, or none - in the DllImport section.

 

[andrea catto']

Here si the deal,

/CLR will create 'by default' managed code only, and will also allow running
certain 'unmanaged code'.

if the unmanaged code in within a .DLL, you can pretty much do anything you
need.
if the code is within the same managed project you'll need to use the
#pragma unmanaged, in case of VC++/CLR.

the thing is that, from what I have seen, CLR is extremely fast in almost
all the circumstances, even in string manipulations, you'll need to do some
million loops of string manipulations to see 'some' difference.

you'll really need the unmanaged code in rare instances, trust me.

but I am a time-critical-optimization freak myself, so I share your concern.

ultimately, a DLL, call is not the faastes anyway, because between the IJW
(it just works) transition clr-unmanaged and the dll-function-call indirect
mapping, you'll lose timing anyway.
consider this too if it helps.

 

[S. Han]

Your best bet is to separate the managed part from the unmanaged
part to multiple files. For the files that contain the managed code, you
would
add #using <mscorlib.dll> and add the compilation switch /clr.
For the unmanaged part is the exactly the opposite, no /clr, no
mscorlib.dll.

For the second question, just drop the dll to the current working directory,
in which your exe resides.

 

[repstat]

Here si the deal,

/CLR will create 'by default' managed code only, and will also allow running
certain 'unmanaged code'.

if the unmanaged code in within a .DLL, you can pretty much do anything you
need.
if the code is within the same managed project you'll need to use the
#pragma unmanaged, in case of VC++/CLR.

Does this mean it can use managed code within the SAME project as unmanaged
code, as long as it's in a different file with #pragma unmanaged??? !!??
Surely not!...?

Oh god, you know what that means!
That means there's a reason for me to use the *dreaded* MANAGED C++!
NOOOOOOOOOO!!! AAAAAAAARRRRGGHHHHHHH!!!

Do I trust that the garbage collector will work correctly in the managed
file?

(Shit! I think I was somehow clinging to the hope that calling u-MC++
code in a DLL from C# was just as quick as this gloomy inevitability)

 

[Steve McLellan]

Does this mean it can use managed code within the SAME project as unmanaged
code, as long as it's in a different file with #pragma unmanaged??? !!??
Surely not!...?

Oh god, you know what that means!
That means there's a reason for me to use the *dreaded* MANAGED C++!
NOOOOOOOOOO!!! AAAAAAAARRRRGGHHHHHHH!!!

Do I trust that the garbage collector will work correctly in the managed
file?

(Shit! I think I was somehow clinging to the hope that calling u-MC++
code in a DLL from C# was just as quick as this gloomy inevitability)

You can use managed code and unmanaged code in the same file without the
#pragma - the limitations between the two only become apparent when you're
trying to mix unmanaged / managed class members. The garbage collector will
tidy up any managed objects. If you create unmanaged objects you need to
ensure they get tidied up, same as normal. This only applies to C++ - you
obviously can't compile C++ and C# together. Managed C++ is fine, it's just
the syntax is a bit crusty at the moment.

Steve