extended stored proc programming

  • Thread starter Thread starter Guest
  • Start date Start date
Bonj said:
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".
Click to expand...

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,
Click to expand...

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?
Click to expand...

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
 
Bonj said:
would you mind also lending your expertise to my question about "using COM
in
C++ (either unmanaged or managed)" in vc.language please?
Click to expand...

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

Regards,
Will
 
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.
Click to expand...

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.
Click to expand...

"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?
 
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?
Click to expand...

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?
Click to expand...

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).
 
Back
Top