Managed
Extensions for C++
Host: Kumar Gaurav Khanna – Analyst Developer with Dryden
Technologies, Australia | MCSE 2K, MCP+I
July
27, 2002
KunalS_MS: Good Afternoon to all and welcome to today's eXPerienceDotNet
Expert Chat Session
KunalS_MS: Today's chat session is on Managed Extensions for C++
KunalS_MS: And our expert is - Kumar Gaurav Khanna
KunalS_MS: Kumar is an Analyst Developer with Dryden Technologies
and is based in Chandigarh.
KunalS_MS: He has under his belt certifications like - MCSE 2K, MCP+I
KunalS_MS: So now over to you Kumar and Managed Extensions for C++
Kumar: In this session, I shall be having two parts
Kumar: in the first, I shall be giving a brief overview
of MC++,
Kumar: and how it fits in the scenarios of managed and
unmanaged development
Kumar: and how it can, at times, save life!!
Kumar: The second part will be the Q/A session.
Kumar: So, here we go.
Kumar: With the advent of .NET.
Kumar: MS has definitely redefined the way we program
for Windows.
Kumar: Infact, a lot of development philosophies and strategies
have changed in this new paradigm of development.
Kumar: while C#, and the likes have got the prominence
Kumar: the legacy which .NET Platform development brings
Kumar: is VC++.NET
Kumar: This is a legacy since it supports the unmanaged
development, using frameworks.
Kumar: like MFC and ATL
Kumar: no letting the C++ codebase out there orphaned
Kumar: and also, an asset in the managed development,
since it brings
Kumar: the managed extensions for C++.
Kumar: Basically, MC++ is a subset to the VC++ programming
that supports interaction with the .NET framework, and all that it
has to offer.
Kumar: and this is made possible, by not writing code
in some special manner.
Kumar: Infact, MC++ code can very easily co-exist and
mix up with the unmanaged C++ code
Kumar: giving you an ease of transition to .NET.
Kumar: For instance, you maybe having an enterprise wide
application
Kumar: a good amount of which is written in C++.
Kumar: Instead of re-writing it in VC#, you could go about.
Kumar: wrapping it in MC++ such that managed code could
have access to its functionality.
Kumar: Also, since the core of the application is unmanaged,
it enjoys the benefit of the unmanaged world too.
Kumar: A good example of this will be a COM component.
Kumar: Say, you have a SMTP component, in ATL that is
to be ported to .NET.
Kumar: Using MC++, all you have to do is, write a managed
C++ class, the definition of which is syntactically identical to the
way unmanaged C++ class's goes
Kumar: and make its methods delegate calls to the unmanaged
C++ class that is the core of the ATL component.
Kumar: Now, the same code base is available to:
Kumar: 1) The existing legacy clients which use COM to
invoke the component
Kumar: 2) Managed applications, which use the MC++ wrapper
to utilize the functionality
Kumar: without re-writing it.
Kumar: And this is precisely, one of the main goals of
introducing MC++:
Kumar: save on the existing investments made, to the max.
extent possible.
Kumar: That said, there are also scenarios when some functionality
isn't provided by the .NET framework
Kumar: but is present in the unmanaged world, say in form
of a DLL, and you would want to us that.
Kumar: Of course, a ready solution will be to use PInvoke.
Kumar: And many would go for it, but when the issue of
performance, and better efficiency.
Kumar: MC++ comes to the rescue.
Kumar: By simply writing a MC++ class, that invokes the
required unmanaged DLL function, and returns the result back to the
managed caller,
Kumar: will take care of the lacks in the .NET framework.
Kumar: An example of this was the time
Kumar: when I was writing Registry Editor.NET.
Kumar: Starting with WinXP.
Kumar: the registry defines a new data-type
Kumar: REG_EXPAND_SZ
Kumar: essentially, a value of this type will contain
an environment variable
Kumar: and when its value is to be retrieved, it has to
be parsed using the environment variables defined.
Kumar: However, when I fetched the value of this type
Kumar: the framework returned it as a REG_SZ
Kumar: and automatically returning its value.
Kumar: The issue was there was no way to distinguish between
a standard
Kumar: REG_SZ and the returned REG_SZ which was actually
a REG_EXPAND_SZ
Kumar: So, I had to write a managed C++ class that used
the Win32 Registry API
Kumar: and from there, the difference could be made out
between the two.
Kumar: Hence, MC++ is a great tool. and mind you
Kumar: a tool, a utility, to get efficiency.
Kumar: to enhance on performance.
Kumar: not to indulge in full blown MC++ code, because
that would be quite complicated
Kumar: for those who have now loved to write code in C#,
VB.NET etc
Kumar: MC++ is also a good way for having interoperability
scenarios
Kumar: actually tackling the high performance interoperability
scenarios
Kumar: Traditionally, one will use the TLBIMP to create
the RCW
Kumar: which the managed code will call.
Kumar: Hence, COM component access is feasible.
Kumar: this is okay for most scenarios, but it should
be kept in mind
Kumar: that this very usage has some limitations:
Kumar: 1) marshalling occurs when going thru RCW
Kumar: and then from RCW to the COM client
Kumar: COM component
Kumar: However, if MC++ is used to directly wrap the underlying
COM component class
Kumar: the intermediate access of RCW goes out
Kumar: and you get a more efficient means of invoking
and interacting
Kumar: with the component
Kumar: This holds true incase of PInvoke as well
Kumar: Because a single PInvoke call will incur the marshalling
overhead
Kumar: + instructional overhead of using PInvoke.
Kumar: for mission critical apps
Kumar: using MC++ will remove the PInvoke layer.
Kumar: and will just have the marshalling overhead
Kumar: hence, you have a better and faster access to the
calls
Kumar: But does that mean MC++ should be used quite often
?
Kumar: Well, that's a decision which involves a lot of
factors and design decisions too.
Kumar: Incase your codebase is majorly in C++, and you
wish to port, functionality by functionality to .NET
Kumar: use MC++
Kumar: especially since your idea is to get it access
to the unmanaged functionality.
Kumar: for the managed apps, which will serve as clients.
Kumar: But maybe your codebase is having C++ code in minority.
Kumar: then keeping in mind the issues of how much the
C++ code contribute to efficiency of the app
Kumar: what role it has to play. et al
Kumar: is important to think about. before getting a decision
done on MC++ usage.
Kumar: That said I am now ready for your queries
Moderator: (Zinger) How similar is the unsafe of C# and pointers in
MC++?
Kumar: Assuming that we are using pointers in a MC++ class.
Kumar: they are the same.
Kumar: Since both pointers are to address in managed heap
Kumar: both need to be pinned
Kumar: else the GC may relocate the data at the pointed
address
Kumar: and hence, if not pinned, the pointer will get
invalidated.
Kumar: But if the pointer is in an unmanaged C++ class.
Kumar: to which the MC++ class delegates its calls
Kumar: then that pointer is like any other pointer we
use in traditional C++/VC++,
Kumar: that points to the unmanaged heap
Kumar: so the rules of the unmanaged world apply to it
Moderator: (Zinger) Can I make Mananged C++ App part of multi app
domain process?
Kumar: Sure, enough.
Kumar: remember, MC++ is C++, but managed
Kumar: and anything that is managed can do anything which
the managed world lets it do
Moderator: (Saurabh_MVP) I am a bit confused here you said" using
MC++ will remove the PInvoke" were you refering to writing managed
code in MC++ or Unmanaged code in MC++ ?? "
Kumar: Well, "using MC++ will remove PInvoke" refers to
the use of unmanaged code calls
Kumar: from the MC++ class
Moderator: (Ravikanth_MVP) What are the security concerns of MC++?
Does the .NET Framework apply same level of security for MC++?
Kumar: Well, so long as you are in the MC++ class, you
are bound by the .NET framework security.
Kumar: Hence, whatever issues relate to a VC# app, will
also be application to the MC++ part of your application as well
Kumar: Hence, yes the same level of security applies to
MC++ code as well
Moderator: (ashok) Can I define an MC++ class and inherit this class
from C#? Any overheads?
Kumar: Well, no overheads
Kumar: you would be doing an inheritance that is similar
to a C# class inheriting from a VB.NET class
Moderator: (ashok) What is the difference of writing a COM Client
in C# or VB.NET against MC++?
Kumar: Well, if you are MC++ application uses the RCW
to go thru the access of the COM component
Kumar: then no difference the same overheads apply as
I discussed in the chat.
Kumar: however, if you write a MC++ wrapper to the underlying
CoClass of the component, then
Kumar: you are bypassing the RCW, simply because there
is no RCW!!
Kumar: Hence, an enhanced performance is obtained
Moderator: (Saurabh_MVP) But then you are crossing the Managed World
boundary right, then isn't there an Interop? How much of a performance
difference do you get when ypu skip PInvoke as you say?
Kumar: Yes Saurabh. the cross over does occur.
Kumar: However, when using PInvoke, this cross over involves
the marshalling overhead and PInvoke invocation overhead.
Kumar: However, if you directly make the calls, you just
have the marshalling overhead
Kumar: on the average a single PInvoke call takes between
20-30 instructions per call
Kumar: so if you have many PInvoke calls, you can understand
why your app maybe experiencing performance issues
Kumar: You are welcome!
KunalS_MS: Well, thank you very much Kumar
KunalS_MS: For taking time out and sharing your experiences of implementing
Managed Extensions for C++
