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

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

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)
 
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?
Click to expand...
No. C# us not more powerfull than C++.
But C# is far easier to create .NET programs than unmanaged C++. Far more
readable and much faster to compile.
C# appears to be designed from the scracth up to be pure .NET programs. C++
still have a need for this backward compatibility issuses, so the language
gets complicated with all these addtion macro's and keywords....

The nice things about the .NET is that all code in VB, C# and managed C++
looks the same except for syntax.

Another reason is maybe that C++ programmers tend to like very optimized
code, even if it takes an few months to create while a C# programmer needs a
day or so to create something like that. So I believe that a lot of C++
programmers don't like the .NET way of programming because they lose their
years of experience and have to relearn everything from scratch becoming a
newbie.
Another reason could be that a lot of C++ programmers get in their 40's and
have a hard time to keep up with the new technology.

Then again, a C++ programmers, like me that don't mind to get scared away of
becoming a newbie again also exist and they are very fond of .NET :-)
2) Is Microsoft intending to support C# and V.B. .NET more than Managed
C++?
Click to expand...
I don't think so, C++ is still very important because of the huge code base.
C++ is still ery important for the next 10 years, so is the MFC.
3) Can C# take the place of standard C++ in terms of performance?
Click to expand...
Not at this moment but it gets pretty close according to my tests.

I discovered that you lose speed in some places, but gain speed in other
places. Especially the .NET framework contains very high optimized code. In
my code I have the feeling that I lose about 5% speed on average compared to
a pure C++ program, but I did make the C# version 7 times faster.

Tests suggests that the .NET match library is actually faster than the
unmanaged C++ library.
Maybe they redesigned the .NET match library for even better performance
gain, while the older C++ library has not been updated.
4) What kind of advantages C# have compare to Managed C++ and Visual C++
.NET?
Click to expand...
See the topic "In need of .NET advocacy" in this news group. Everything you
ever want to know is discussed there.
 
Thank you very much for your response.
Many of the systems that require performance -like image processing, voice
recognition, military software- are developed in C++. In the course of the
time, can C# find a considerable a good place in these areas?
Within the projects that are in C#, using the C++ codes is possible.
Therefore, can C# be used in Performance-Required areas?


:
 
Thank you very much for your response.
Many of the systems that require performance -like image processing, voice
recognition, military software- are developed in C++. In the course of the
time, can C# find a considerable a good place in these areas?
Within the projects that are in C#, using the C++ codes is possible.
Therefore, can C# be used in Performance-Required areas?
Click to expand...
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.

The nice thing about .NET is that I can create components in C#, managed
C++, VB.NET... and freely mix them with each other without any problems.
Just make sure that you avoid case sensitivity in de class naming to make
sure that it can still be used in VB.NET. But you have a program that checks
compatibility called FxCop that analyzes your code assembly and explains
what you might to change things in a very friendly manner.

Now the problem is that you either create a C# assembly or a C++ managed
assembly. You cannot compile C++ code in a C# project. So you end up with
multiple assemblies (dll's), which at first sounds scary for the
installation procedure, but a .NET program is best installed using a setup
so that does not pose any problem. The setup can automatically configure the
computer for enough user rights to run that program across a network and
so... So no more complicated installation and user righst. :-)

One thing I had problems with in the beginning was this MFC thing. I
discovered that I need to compile with MFC in a DLL, and this gave me
problems because I used the assemblies in a subfolder which is a nice system
to avoid dll clashes if one assembly needs v1.2 of a dll and the other
assemblie used in your same program uses that same assebly name but with a
different vesrion v1.1. I discoverd that the subfolder thing was perfect for
none-MFC dll's. The MFC dll's should reside in the same folder of your dll
and executable.

You will lose some speed if you move from managd to unmanaged code and back.
So it is best to concentrate the code into managed or managed code, but try
to avoid the transition as much as possible. But it works greate.

I faced one small problem. one of the projects I created is a dll plugin for
a conventional exe program. The dll is a mixed manged/unmanaged dll that
have the user interface as a managed part. But it turned out that the .NET
framework did not find the correct assemblies even though they were located
in the same folder of the main dll. The reason was because the executable
was located in another folder, the plugin in yet another folder. The .NET
framework tried to locate the dll's in the .EXE folder instead of the plugin
..DLL folder. Since creating a setup is not desired that installs plug-ins in
the program folder of the exe, suppose you have 2 plugins with the same
name? I found a sollution in installing the assemblies into the GAC. I don't
like that but it is the best solution so far I have come up with that is
reliable. Setting the current directory didn't solve the problem.

So I hope that you have now an overview of what is possible. :-)
 
Alper said:
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?
Click to expand...


No, the opposite is true. With the advent of VC++ 2005, C++ becomes the systems
programming language of .NET. Some references:


You may take a look at these:

http://msdn.microsoft.com/msdnmag/issues/05/01/COptimizations/default.aspx

http://pluralsight.com/blogs/hsutter/archive/2004/10/05/2672.aspx

http://blogs.msdn.com/branbray/archive/2003/11/07/51007.aspx

http://www.accu.org/conference/pres...Relevant_on_Modern_Environments_(keynote).pdf


And a page of mine:

http://www23.brinkster.com/noicys/cppcli.htm


2) Is Microsoft intending to support C# and V.B. .NET more than Managed
C++?

No.


3) Can C# take the place of standard C++ in terms of performance?

No!


4) What kind of advantages C# have compare to Managed C++ and Visual C++
.NET?
Click to expand...


By providing less facilities, it makes it easier to learn doing simple applications but of
course it has fewer capabilities.
 
Thank you Baeyens. Your expriences and explanations are important for me.
These comparisons helped me to visualize the logic in my mind.
I thank you again for sharing your time with me.
Best Regards.

:
 
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?

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?


:
 
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?

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

Unmanaged code will usually provide better performance for
time-critical things such as image and signal processing; should you
commit yourself to .NET, you'll probably use both managed and
unmanaged C++.

If standard or portable C++ knowledge is important to you, use
unmanaged C++.
 
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?
Click to expand...
In my opinion, yes.
User interface = managed C++
Performant code = unmanaged C++

Look for the specifications of the new Visual Studio 2005 which includes
C++ and C# standard, it has interesting features.
First of all, it compiles you code (loops) in certain conditions to execute
it as hypethreading even though you do not program with threading. And it
has a featur to analyze the most used functionality by profiling and then it
can optimize even furter depending on the most used functions.

And you can freely mix managed/unmanaged within the same methods. :-)
But much less readable than C#.
 
Will VS 2005 Managed C++ be usable for applications targeting the .NET
Compact Framework?

Jon Gabel
 
Olaf Baeyens said:
And you can freely mix managed/unmanaged within the same methods. :-)
But much less readable than C#.
Click to expand...

I think, we need a special glasses to read the managed/unmanaged C++ codes
more easily :-).
 
Alper said:
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?
Click to expand...


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/t...f=sr_1_7/102-2992266-3703320?v=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?
Click to expand...


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/publications/standards/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 draft 1.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/publications/standards/Ecma-334.htm
 
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
 
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.
Click to expand...

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
compatibility called FxCop that analyzes your code assembly and explains
what you might to change things in a very friendly manner.
Click to expand...

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, 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.
Click to expand...
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.)
Click to expand...
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::IDisposable {
private: sLib::CSkyScanReg *m_pRegistery; // The C++ unmanage
class
private: System::IntPtr __nogc * CSkyScanReg;
private: bool disposed;
public: MRegistery(void) {
disposed=false;
m_pRegistery=new sLib::CSkyScanReg();
};

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

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

public: virtual void Dispose() {
Dispose(true);
System::GC::SuppressFinalize(this);
}

protected: virtual void Dispose(bool disposing) {
if(!disposed) {
if(disposing) {
if (m_pRegistery) delete m_pRegistery;
m_pRegistery=NULL;
}
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_str();
}
public: __property virtual void set_TopicName(System::String __gc
*asTopicName) {

m_pRegistery->TopicName=LPCTSTR((char*)(void*)System::Runtime::InteropServic
es::Marshal::StringToHGlobalAnsi(asTopicName));
}

This is how I process boolean:

public: __property virtual void set_ForceDot(bool abForceDot) {
m_pRegistery->ForceDot=abForceDot;
}
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.
Click to expand...
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.
 
_R said:
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.
Click to expand...

IIRC it's about 50 CPU cycles. Apparently C++/CLI (in VS 2005) has this down
to about 20-30.
 
Olaf said:
I believe yes, but not the Express version.
Click to expand...
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
 
IIRC it's about 50 CPU cycles. Apparently C++/CLI (in VS 2005) has this down
to about 20-30.
Click to expand...

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

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