Why Managed C++ and not C#?

[ST]

Hi all

We are about to start a new project from scratch. Performance and
development time are important issues. Thus, we have decided to make
use of .NET with respect to short development time and native
(unmanaged) C++ as the language of the low-level business layer. All
objects of this unmanaged code will be included in a dll.

However, there's one thing that makes me wonder: In order to make use
of .NET, we have to choose between managed C++ and C#, but: What is
the benefit of managed C++ in our scenario?

To make things clearer: Consider an native C++ dynamic class library
allocating memory, making use of C math libraries and performing high
performant calculations. Am I right in thinking that calling this
class by the managed code by

unmanagedScope::BusinessClass* pBs = new std::BusinessClass();

(NOT gcnew) would create performance overhead anyway? If so, the
object must not be created by the managed, but by the unmanaged code,
right? A native wrapper would create the object and pass the data of
the managed stuff. If so, I would not need managed C++ at all and I
would use C# instead.

Do I have missed something? Your oppinions? Hints?

Thanks in advance
ST

[Christian Fröschlin]

Post by ST
However, there's one thing that makes me wonder: In order to make use
of .NET, we have to choose between managed C++ and C#, but: What is
the benefit of managed C++ in our scenario?

note that your unmanaged C++ classes have name mangling and can't
easily be used from C# (it can consume C style APIs via P/Invoke
and COM classes via COM Interop). So managed C++ is the most
convenient way to bridge the gap. However, I'd usually use it
only to create managed wrappers and consume those from C#.

[Ben Voigt [C++ MVP]]

Post by Christian Fröschlin

Post by ST
However, there's one thing that makes me wonder: In order to make use
of .NET, we have to choose between managed C++ and C#, but: What is
the benefit of managed C++ in our scenario?

note that your unmanaged C++ classes have name mangling and can't

Name mangling is the least of your worries when trying to consume full-blown
C++ classes from C#. Don't even try using P/Invoke for that, it has no
concept of default constructors, copy constructors, destructors, etc, and to
do virtual dispatch it needs type libraries which aren't available unless
the C++ class was specifically designed for COM.

Post by Christian Fröschlin
easily be used from C# (it can consume C style APIs via P/Invoke
and COM classes via COM Interop). So managed C++ is the most
convenient way to bridge the gap. However, I'd usually use it
only to create managed wrappers and consume those from C#.

Also please note that C++/CLI has replaced the Managed Extensions for C++.
Under no circumstances should you use the old Managed Extensions available
with VC2002/VC2003.... those compilers produced buggy code with race
conditions during library load.



__________ Information from ESET NOD32 Antivirus, version of virus signature database 4103 (20090525) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com