What is Place of Managed C++ in .NET?

[Alper AKCAYOZ]

Hello Esteemed Developers and Experts,

I have been using Microsoft Visual C++ .NET for 1 year. During this time,
I have searhed some topics over internets. Most of the topics about .NET is
related to C# and Visual Basic .NET. There are less documents about Visual
C++ .NET or Managed C++.

I wonder the reasons of below questions:
1) Is C# more powerful than Managed C++ and Visual C++ .NET?
2) Is Microsoft intending to support C# and V.B. .NET more than Managed
C++?
3) Can C# take the place of standard C++ in terms of performance?
4) What kind of advantages C# have compare to Managed C++ and Visual C++
..NET?

I thank your kind responses and guidances in advance.

Best Regards
--
~~~~~~~~~~~~~~~ ~~~~
İyi Çalışmalar
Alper AKÇAYÖZ (Bil Muh)

Wish You Good Work
Alper AKCAYOZ (Bil Muh)

[Olaf Baeyens]

> Will VS 2005 Managed C++ be usable for applications targeting the .NET

Compact Framework?

I believe yes, but not the Express version.

--
http://www.skyscan.be

[Alper AKCAYOZ]

"Olaf Baeyens" wrote:

And you can freely mix managed/unmanaged within the same methods. :-)
But much less readable than C#.

I think, we need a special glasses to read the managed/unmanaged C++ codes
more easily :-).

[Ioannis Vranos]

Alper AKCAYOZ wrote:

Hello Vranos,
I would like to advance much further on a programming language. Therefore, I
wonder the differences of prog. lang. in .NET.
With your explanations, can we say that C++ will keep its popularity,
performance and its other advantages for a long time both in .NET technology
and other Performance-Required fields?

Yes, definitely. C++ produces the best optimised managed code and the best optimised
native code. Also C++ has access to low level CLR features that other languages lack.

And also it provides features that no other languages provide. An example is both template
and generics support for managed types in VS 2005, while other languages will have only
generics. Another example is implicit deterministic destruction by using objects with
stack semantics.
In few words it goes like this in terms of power/simplicity.
Visual Basic .NET the simplest programming language and the less powerful.

C# provides more features and thus more power.

C++ provides the most features and has the most power.

IL Assembly, the assembly of .NET. The second thing that one should know along with C++ in
the .NET world ,according to my opinion. A book on this:
http://www.amazon.com/exec/obidos/tg...glance&s=books

:-)

My aim is to work on Performance-Required software. Therefore, is it
possible to say that Visual C++ .NET/Managed C++ is the correct choice?

Yes. In the upcoming VS 2005, "managed extensions" are replaced with C++/CLI, the newly
standardised set of extensions. The switch is not difficult, for example instead of writing

__gc class SomeClass;
for managed classes, you will be writing
ref class SomeClass;
The .NET APIs are not affected from this, that is they remain the same.
So in summary, .NET is a CLI compliant VM. The CLI standard is publicly available from
here (the standard contains the assembly language of the VM, so it is interesting to
download it and take a look):

http://www.ecma-international.org/pu...s/Ecma-335.htm
C++/CLI is a standardised set of extensions for taking advantage of a CLI machine,
replacing current "managed extensions". The latest C++/CLI draft is this:
http://www.plumhall.com/C++-CLI%20draft%201.10.pdf
The ECMA working group of C++/CLI:

http://www.ecma-international.org/memento/TC39-TG5.htm
Also VC++ 2005 works with OpenMP 2 multithreading, in addition to the .NET multithreading.
OpenMP standard can be downloaded from here:

http://www.openmp.org

And since we are on it, the current C# standard (which more accurately is named C#/CLI)
can be downloaded from here:
http://www.ecma-international.org/pu...s/Ecma-334.htm

[ismailp]

Integrating C++ with CLR is not a simple job. The first shot was
"managed extensions for C++. However, this was not what C++ community
expected. Visual C++, in Visual Studio 2005 release, aims to be the
"systems programming language of CLR", or "closer to the metal" (it is
close to both managed and unmanaged metal). Because C++ exposes more
(low-level) CLR features than other .NET languages does. C++ has no
problem integrating managed and unmanaged worlds, C++ has templates, we
already had them, C# met with "generics" with .NET framework 2.0.
Templates and generics are not interchangable - they are dealing about
different (but closer) concepts. However, if you take a look at "what's
new with Visual C++ 2005", you can see we have both templates, AND,
generics. We have deterministic destruction, stack semantics, we have
STL.NET. Conclusion: we have a very rich language that is a bridge
between managed and unmanaged worlds.

On the other hand, it is not wise/right to compare languages. C# is a
productive language, it is simpler. On simplicity, C++ may not provide
as much facilities as C# does. C# may not provide lower level
facilities to programmers as much as C++ does. So, for me, for example,
C++ is better. But my coworker next to my table thinks C# does better.
That depends on what you expect and what language gives.

Managed extensions for C++ will be deprecated by C++/CLI soon (I mean,
totally). I don't know famous projects written with mc++, but I expect
serious projects with C++/CLI.

C++ is a mature language, it has been 20 years. Now, compilers perform
better optimization (see Visual C++ 2005's POGO), they generate "better
code" (better may mean either faster, or shorter, depending on what you
expect), they understand more keywords, they have more directives, they
are more compliant with ISO C++ standard, etc.

Ismail

[_R]

On Mon, 4 Apr 2005 15:04:10 +0200, "Olaf Baeyens"
<ol**********@s kyscan.be> wrote:

I create imaging software, and I try to create the user interface part and
the stuff that is less performance critical in C# because I can create that
part much faster.

But a huge part of my code base is unmanaged C++ using MFC. And I simply do
not have the time to port it to C# or managed C++ at this moment, so I have
created a mixed C++ assembly that has both managed as unmanaged code acting
as wrappers.
Olaf, I'm not the OP of this thread, but thanks for the interesting
post. I've been wondering how others do the C#->mgdC++->unmgdC++
transition. It sounds like you have had time to optimise your
approach. Do you happen to have a small 'test-subset' of your code
that will compile and transition from C# to C++? I'd love to see that,
especially if you've marshaled some data in the process.

Where did you find the original template for your code? (I am
assuming that you're using 'C++ Interop', not P-Invode/attributes.)
But you have a program that checks
compatibilit y called FxCop that analyzes your code assembly and explains
what you might to change things in a very friendly manner.

First I've heard of FxCop. I'll look for info.

I take it that the transition between managed / unmanaged is where you
take the greatest performance hit. Do you have any feel for how much
time is spent in the transition? I know, it is probably very
difficult to quantify.

_R

[Olaf Baeyens]

> Olaf, I'm not the OP of this thread, but thanks for the interesting

post. I've been wondering how others do the C#->mgdC++->unmgdC++
transition. It sounds like you have had time to optimise your
approach. Do you happen to have a small 'test-subset' of your code
that will compile and transition from C# to C++? I'd love to see that,
especially if you've marshaled some data in the process.
Two things: I created a managed C++ wrapper to my unmanaged classes.
So using the managed C++ classes is very simple from C#. Just like any other
C# class.
Where did you find the original template for your code? (I am
assuming that you're using 'C++ Interop', not P-Invode/attributes.)
I didn't! Looked at examples including this newsgroup and created my own
version that works.
The managed C++ to unmanaged C++ is performed by the C++ compiler. :-)

I cannot give you our code but I can give you the important parts that
works;
(This can be found on the Internet)

public __gc class MRegistery : public System::IDispos able {
private: sLib::CSkyScanR eg *m_pRegistery; // The C++ unmanage
class
private: System::IntPtr __nogc * CSkyScanReg;
private: bool disposed;
public: MRegistery(void ) {
disposed=false;
m_pRegistery=ne w sLib::CSkyScanR eg();
};

public: virtual ~MRegistery(voi d) {
Dispose(true);
};

public: virtual void Init() {
m_pRegistery->Init();
};

public: virtual void Dispose() {
Dispose(true);
System::GC::Sup pressFinalize(t his);
}

protected: virtual void Dispose(bool disposing) {
if(!disposed) {
if(disposing) {
if (m_pRegistery) delete m_pRegistery;
m_pRegistery=NU LL;
}
CSkyScanReg = 0;
disposed = true;
}
}
}

Only a big problems with the string stuff and boolean but I found this to do
the trick.
This is how I process string: (not CString!)

public: __property virtual System::String __gc * get_TopicName() {
return m_pRegistery->TopicName.c_st r();
}
public: __property virtual void set_TopicName(S ystem::String __gc
*asTopicName) {

m_pRegistery->TopicName=LPCT STR((char*)(voi d*)System::Runt ime::InteropSer vic
es::Marshal::St ringToHGlobalAn si(asTopicName) );
}

This is how I process boolean:

public: __property virtual void set_ForceDot(bo ol abForceDot) {
m_pRegistery->ForceDot=abFor ceDot;
}
public: __property virtual bool get_ForceDot() {
return m_pRegistery->ForceDot!=0;
}

I take it that the transition between managed / unmanaged is where you
take the greatest performance hit. Do you have any feel for how much
time is spent in the transition? I know, it is probably very
difficult to quantify.

I have no idea, I try to avoid it as much as possible.
I either operate internally the unmanaged code or I keep outside in the
managed code, but I avoid the transition as much as I can.
I have duplicate functionality. So the unmanaged parts gets replaced in type
by the managed types. Only the really performance critical code is kept in
unmanaged C++ code right now.

--
http://www.skyscan.be

[Sean Hederman]

"_R" <[e-mail] g> wrote in message
news:au******** *************** *********@4ax.c om...

I take it that the transition between managed / unmanaged is where you
take the greatest performance hit. Do you have any feel for how much
time is spent in the transition? I know, it is probably very
difficult to quantify.

IIRC it's about 50 CPU cycles. Apparently C++/CLI (in VS 2005) has this down
to about 20-30.

[Ronald Laeremans [MSFT]]

Olaf Baeyens wrote:

Will VS 2005 Managed C++ be usable for applications targeting the .NET
Compact Framework?

I believe yes, but not the Express version.

Only when writing "safe"mode applications (compiled with /clr:safe). The
current CF implementation lacks several features of the desktop version
that the Visual C++ compielr uses to enable native classes and native
code to interoperate.

Ronald Laeremans
Visual C++ team

[_R]

On Wed, 6 Apr 2005 16:18:31 +0200, "Sean Hederman"
<em*******@codi ngsanity.blogsp ot.com> wrote:

"_R" <[e-mail] g> wrote in message
news:au******* *************** **********@4ax. com...

I take it that the transition between managed / unmanaged is where you
take the greatest performance hit. Do you have any feel for how much
time is spent in the transition? I know, it is probably very
difficult to quantify.

IIRC it's about 50 CPU cycles. Apparently C++/CLI (in VS 2005) has this down
to about 20-30.

Even 50 doesn't sound extraordinarily high. I've always heard that
the transition was a limiting runtime factor, but that sounds like the
equivalent of calling a tiny subroutine.

Strange thing though, I've worked with code that didn't transition
smoothly when translated to VC++ with a managed wrapper/bridge.
I had assumed that it was the transition cycles. I guess I should
look elsewhere.

[Sean Hederman]

"_R" <[e-mail] g> wrote in message
news:ll******** *************** *********@4ax.c om...
[Snip]

Even 50 doesn't sound extraordinarily high. I've always heard that
the transition was a limiting runtime factor, but that sounds like the
equivalent of calling a tiny subroutine.

Strange thing though, I've worked with code that didn't transition
smoothly when translated to VC++ with a managed wrapper/bridge.
I had assumed that it was the transition cycles. I guess I should
look elsewhere.

50 cycles inside a tight loop can get nasty fast. Also, this is just the
transition and does not include marshalling.