extended stored proc programming

[William DePalo [MVP VC++]]

As I've got in my project. And the unmanaged function is called seamlessly
from the (completely) unmanaged extended proc. DLL project, and it
seamlessly
creates an instance of a managed object (System::String).
But I've heard about this thing called IJW which is whereby they say "you
can take your existing C++ code, but compile it under .NET as managed
code -
no changes to be made".

Where code generation is concerened, the compile is a lot smarter than most
of us who use it. In this article,

http://msdn.microsoft.com/msdnmag/issues/04/05/VisualC2005/default.aspx

Steven Toub says this

<quote>
The only code that is generated as native machine code is code that just
can't be compiled to MSIL, including functions with inline asm blocks and
operations that use CPU-specific intrinsics such as Streaming SIMD
Extensions (SSE). The /clr switch is how the Quake II port to .NET was
accomplished. The Vertigo software team spent a day porting the original C
code for the game to code that successfully compiled as C++ and then threw
the /clr switch. In no time they were up and running on the .NET Framework.
Without adding any additional binaries and simply by including the
appropriate header files, managed C++ and native C++ can call each other
without any additional work on the part of the developer. The compiler
handles the creation of the appropriate thunks to go back and forth between
the two worlds.

Do my unmanaged functions compile to *actual* unmanaged (i.e. non-MSIL)
machine code,

That depends. See above.

So how does it know that's not what I want to do, and
what if I *did* want to do that, how would I do it?

I'm not sure what "it" is here. Where interoperability is concerned, the
details make all the difference so if there is something that you need to do
you might want to ask a detailed question. To be fair, I should point out
that there are "issues" as the article above calls them. That is there are
cases where you might not want to rely on the compiler but rather take
charge yourself.

Regards,
Will

 

[William DePalo [MVP VC++]]

would you mind also lending your expertise to my question about "using COM
in
C++ (either unmanaged or managed)" in vc.language please?

Sorry, but I read the question and nothing came to mind.

Regards,
Will

 

[Guest]

Sigh.
This is getting frustrating.
Do I *really* have to put a blank _asm{} block at the top of a function just
so I can be sure it will go unmanaged?

No - seriously though, what I don't get is....if you've got code that
compiles as unmanaged, why would you want it to compile as managed? IOW, as
far as I can see the only reason to use managed code is to access the wide
range of framework classes. If you can manage without them, then why would
you want to have managed?
(I'm only considering unmanaged to be better in terms of security and speed
of execution... even though it may not be much better in terms of speed) ...
but still, do you not get what I mean?

The /clr switch is how the Quake II port to .NET was
accomplished. The Vertigo software team spent a day porting the original C
code for the game to code that successfully compiled as C++ and then threw
the /clr switch. In no time they were up and running on the .NET Framework.

So? You're talking as if it's better to have MSIL than native machine code,
rather than the other way round.
Maybe if you're a person that considers that it is, then I'm effectively
banging my head against a brick wall.

I'm not sure what "it" is here. Where interoperability is concerned, the
details make all the difference so if there is something that you need to do
you might want to ask a detailed question. To be fair, I should point out
that there are "issues" as the article above calls them. That is there are
cases where you might not want to rely on the compiler but rather take
charge yourself.

"it" is basically taking charge myself. I want to force a specific function
in my .cpp file that is compiled with /clr to compile to native, non-MSIL
machine code, or failing that just to *know* whether it is doing so or not!
I *haven't* got any unmanaged source files written before .NET was invented
that I now want to compile to MSIL. That's the last thing I want. I don't
know many more ways in which I can say that. Please remember my main aim is
speed, and that means having as much unmanaged, native machine code as
possible in my exe, and managed code only where necessary to use the
framework objects. Is that a reasonable want?

 

[Tomas Restrepo \(MVP\)]

Bonj,

Sigh.
This is getting frustrating.
Do I *really* have to put a blank _asm{} block at the top of a function just
so I can be sure it will go unmanaged?

Not at all. THat's what #pragma unmanaged is for.

No - seriously though, what I don't get is....if you've got code that
compiles as unmanaged, why would you want it to compile as managed? IOW, as
far as I can see the only reason to use managed code is to access the wide
range of framework classes. If you can manage without them, then why would
you want to have managed?

Performance. Believe it or not, unmanaged <-> managed transitions are
expensive. So, if the code you're writing forces a lot of transitions, it
will be slower than if everything was just managed (even considering that
managed code might run slightly slower than native code).