C++, MFC etc...

sfx · 22 Feb 2006 at 19:47

Hi,

Just a general question really. I have been programming VB and C# for while now but have never touched C++ and have no intention to either, not that I don;t want to I just have no need to.

One thing I have never really understood... What is the different between Windows Forms C++, MFC Application C++, Unmanaged C++, Managed C++ etc...?

Many Thanks,

sfx

NathanE · 22 Feb 2006 at 19:59

Windows Forms is an object oriented .NET wrapper around existing Win32 GUI programming resources.

MFC, or Microsoft Foundation Classes, was an attempt to simplify C++ programming on Windows. It wraps up commonly used Win32 APIs into object oriented C++ classes.

Unmanaged C++ is, well, C++. The type of C++ that would compile in non-Windows environments. The type that is usually regarded as being the fastest executing language.

Managed C++ is compiled to .NET MSIL (not x86) and therefore can use the .NET framework and is platform independant just like any other .NET program. However it is possible to still use "unsafe" code such as pointers.

WinFX is a completely new API subsystem on Windows Vista. It obsoletes the Win32 APIs and will be used at the core of the next .NET release wave. WinFX has all new GUI components that have a similar design to Java Swing classes. Everything in WinFX is either managed .NET code, a call to another managed framework (such as WPF/Avalon) or a call to a native function (e.g. a kernel function.)

Inquisitor · 22 Feb 2006 at 20:03

I don't know all that much about C++ admittedly, I'm a C# man myself

Basically, as I understand it, a managed programming language is where the program is compiled into machine-readable code when executed, in C#'s case, by the CLR (Common Language Runtime). This would mean that things like managing memory etc. is handled for you (as the GC does in .NET languages).

In contrast, an unmanaged language is where the language interacts directly in a low-level fashion with the computer. An example of this would be the use of pointers in C++ (or C#, when using unsafe code).

This is probably riddled with inaccuracies, so someone feel free to correct me

NathanE · 22 Feb 2006 at 20:20

Inquisitor said:
Basically, as I understand it, a managed programming language is where the program is compiled into machine-readable code when executed, in C#'s case, by the CLR (Common Language Runtime).

You're pretty much right, but I'll explain a little further... A managed language compiles to an intermediate machine code. Intermediate meaning it doesn't match the machine code required by the processor. This is called MSIL in .NET, short for Microsoft Intermediate Language. When the program is executed, the CLR's JIT'er (just-in-time compiler) will compile this MSIL into the code that is required for it to natively execute. However it doesn't compile the whole program, it only compiles the bits as it needs them (hence, just-in-time). This means it can perform optimisations on-the-fly, to suit system and program demands. The amount of optimisation it can do far exceeds what any C++ compiler can do - simply because it is able to perform the optimisations at run time rather than compile time. Being an exclusively managed environment helps too. .NET's JIT'er also performs instrumentation/profiling (e.g. how many times a method is being called per minute) of the program in real-time so it can make better optimisation judgements.

Inquisitor said:
This would mean that things like managing memory etc. is handled for you (as the GC does in .NET languages).

The GC is more a product of the .NET framework rather than being related to MSIL and the JIT'er. But yes, automatic memory management is a key feature of any managed programming environment like .NET. With .NET you can write a few lines of code that would make any veteran C++ programmer's brain implode and still come out of it as the winner.

Inquisitor said:
In contrast, an unmanaged language is where the language interacts directly in a low-level fashion with the computer. An example of this would be the use of pointers in C++ (or C#, when using unsafe code).

Exactly right. Unmanaged means you don't get any fancy garbage collector or easy to use framework. The program compiles to native machine code (e.g. x86) and there is no intermediate language or JIT'ing occuring. Net result = buffer overflows.

Inquisitor · 22 Feb 2006 at 20:39

NathanE said:
Exactly right. Unmanaged means you don't get any fancy garbage collector or easy to use framework. The program compiles to native machine code (e.g. x86) and there is no intermediate language or JIT'ing occuring. Net result = buffer overflows.

One thing I've always wondered about compiling directly to native code... does it mean you have to compile a separate build for each architecture you're planning to use it on?

NathanE · 22 Feb 2006 at 21:03

Yup. One for x86, one for AMD64, and so on. Although you can "merge" all the binaries into a single executable at the expense of file size.

sfx · 22 Feb 2006 at 21:03

Thanks guys quite interesting stuff there. I have always been tempted to give C++ a bash but with all the different variations I though I would give it a miss as I don't really understand what they all are and I know a fair bit when it comes to VB and C#.

I have Visual Studio 6 and .NET 2005 and I am tempted to have a play about with C++ where do you think it would be best to start VS6 or VS.NET also should I go for a Windows Form Application or MFC Application? Or not bother and get stuck into C#?

Cheers,

sfx

Inquisitor · 22 Feb 2006 at 22:15

If you already know C#, then I'd recommend going for unmanaged C++, rather than managed C++, as it'd be more worth your while learning an unmanaged and a managed language than just two managed languages. One of the main benefits of unmanaged C++ is that it is very fast in comparison with the likes of C# et al - you wouldn't get this benefit (to such an extent at least) with managed C++ (.NET, VS2005).

NathanE · 22 Feb 2006 at 22:30

sfx said:
Thanks guys quite interesting stuff there. I have always been tempted to give C++ a bash but with all the different variations I though I would give it a miss as I don't really understand what they all are and I know a fair bit when it comes to VB and C#.

I have Visual Studio 6 and .NET 2005 and I am tempted to have a play about with C++ where do you think it would be best to start VS6 or VS.NET also should I go for a Windows Form Application or MFC Application? Or not bother and get stuck into C#?

Cheers,

sfx

Unless you've got some specific reason to learn C++ then I wouldn't bother. Get stuck into C# as that language is really picking up speed whereas C++ has been pretty dormant for the past 5 years. Managed code is where the party is at these days.

Since C# and VB is all you know, I think you'd have a real hard time getting to grips with C++. It's like learning to drive an Automatic car, and then learning to drive a Manual

happytechie · 22 Feb 2006 at 23:10

NathanE said:
Unless you've got some specific reason to learn C++ then I wouldn't bother. Get stuck into C# as that language is really picking up speed whereas C++ has been pretty dormant for the past 5 years. Managed code is where the party is at these days.

Since C# and VB is all you know, I think you'd have a real hard time getting to grips with C++. It's like learning to drive an Automatic car, and then learning to drive a Manual

I'd say it was more like being tought to drive an automatic car and then trying to build one from scratch :eek:

seriously, unless you need it for work (games, multiplatform work, OS devlopment or high end data warehousing stuff really) I can't see any point in learning C++ today. Java yes C++ not really.

As a long time C / C++ developer who'd migrated to .net in the last few years I've found it a godsend, it's easier than writing java code but having the app execute as fast as a C++ one but with fewer memory leaks and odd buggettes that take a day or more to track down. Add to that the fact that all recent windows OSs have the .net runtime installed and the ease of working in the VS2005 enviroment

Has anyone done any speed comparisons of identical C++ code running in a managed and non managed enviroment?

HT

sfx · 22 Feb 2006 at 23:39

Cheers guys, I do not need C++ for any reason at all I was just interested. I will stick with what I know and hopefully get better.

sfx

Visage · 23 Feb 2006 at 09:41

NathanE said:
whereas C++ has been pretty dormant for the past 5 years.

Not at all. The language was standardised in 1998, and, after a few years to allow developers to get used to the 'standard form', the process of the next revision of the language started. The process is now completed, and the next version of c++ will be standardised in 2009, and is expected to be known as C++09....

Una · 23 Feb 2006 at 09:59

The problem I have at the moment while writing assembly is seeing how it relates to the Java programming I have done in the past (lack of pointers etc). I think learning a language like C/C++ would help understand how things work a little better. My professor said that in order to be a really good programmer, you should write a compiler, an OS and a programming language. :-)

It all depends on what sort of software you want to write at the end of the day.

Visage · 23 Feb 2006 at 10:08

Una said:
The problem I have at the moment while writing assembly is seeing how it relates to the Java programming I have done in the past (lack of pointers etc). I think learning a language like C/C++ would help understand how things work a little better. My professor said that in order to be a really good programmer, you should write a compiler, an OS and a programming language.
It all depends on what sort of software you want to write at the end of the day.

WHy would anyone in this day and age write assembler?

That kind of micro-optimisation is a bad thing for so many reasons:

1) Modern compilers can do a damn sight better job of optimisation than most programmers
2) You lose portability
3) Longer development times - i've seen estimates that asm code takes up to 10 times longer to code and debug than high level code.

Una · 23 Feb 2006 at 10:24

Im not talking about in a job, of course development time is critical. Im just saying if you want to understand how things work a bit better. You dont get that knowledge from high level languages.

Visage · 23 Feb 2006 at 10:29

Una said:
Im not talking about in a job, of course development time is critical. Im just saying if you want to understand how things work a bit better. You dont get that knowledge from high level languages.

But as a developer, if i create a vector<SomeClass> then, as long as i know the performance characteristics of the type, and any issues such as iterator validity etc, then i dont need to know assembler to copmprehend the lowest level workings of the vector<> code.

happytechie · 23 Feb 2006 at 10:35

this is all true. YES you should understand how a compiler works, YES assembler and low level code is usefull for you to understand how code is executed inside the CPU wrt registers and memory BUT this is 2006 and unless you are trying to get the last 1% of performance out of your code C# running in a managed enviroment is probably faster running, less buggy and MUCH faster to write. Optomising compilers have pretty much removed the need for assembler completely imho.

It's horses for courses again. luckily you don't have to be able to understand the inner workings of the x86 CPUs to write high perfomance code for the platform any more and I for one am grateful. If I never have to write any more assembler I'll ba a happy programmer. Oh I've written a comiler (at uni), worked on OSs (Oracle filesystem stuff) but not a programming language of my own

HT

NathanE · 23 Feb 2006 at 12:05

Visage said:
Not at all. The language was standardised in 1998, and, after a few years to allow developers to get used to the 'standard form', the process of the next revision of the language started. The process is now completed, and the next version of c++ will be standardised in 2009, and is expected to be known as C++09....

I was speaking in real world terms - i.e. the number of C++ jobs. Over the past 5 years there has been almost no change at all.

I don't think anybody really cares if there is some new C++ standard coming in 2009. It will take years before it is actually used in the real world. By that time I imagine C++/CLI will have gained a substantial amount of ground.

Visage · 23 Feb 2006 at 12:20

NathanE said:
I was speaking in real world terms - i.e. the number of C++ jobs. Over the past 5 years there has been almost no change at all.

I don't think anybody really cares if there is some new C++ standard coming in 2009. It will take years before it is actually used in the real world. By that time I imagine C++/CLI will have gained a substantial amount of ground.

There's not a lot of demand for managed c++ at the enterprise level, especially for security/safety critical systems and/or unix development.

Lets not forget that its only in the last 5 years that the US DoD/UK MoD have moved away from mandating Ada for all security/safety critical work. And when they did, they only went as far as adding c++ to the list.

DOnt get me wrong, there will always be scope for new languages, new features etc, but when it comes to things that absolutely MUST work, whether that be for safety, security, or business reasons, companies will always go for the safe option, rather than the 'new kid on the block'.

Of course, in, say 5/10 years time I fully expect managed c++, or other 'similar' things such as c# to be widespread enough to enter common usage.

The fact of the matter is that if you've got an important project you want to have experienced developers who know how to write bulletproof code. And its obvious that experienced developers cannot exist for a language thats only a few years old.....no matter how good that language is.

If I wanted to lay my hands on 100 experienced (5 years+) c++ developers at short notice, its doable. Can anyone say the same for c#?

NathanE · 23 Feb 2006 at 15:05

Visage said:
but when it comes to things that absolutely MUST work, whether that be for safety, security, or business reasons, companies will always go for the safe option, rather than the 'new kid on the block'.

And you believe that safe option to be C++? C++ does not check any of those boxes. I certainly wouldn't consider C++ to be suitable for safety critical systems, nor is it an inherently secure language. It certainly doesn't qualify for rapid application development so it's not going to be selected for business reasons either. The one possible advantage it does have over managed languages is the ability to work seamlessly with the native hardware which makes it indispensable for certain projects.

Visage said:
The fact of the matter is that if you've got an important project you want to have experienced developers who know how to write bulletproof code. And its obvious that experienced developers cannot exist for a language thats only a few years old.....no matter how good that language is.

An experienced developer is just that, an experienced developer. You don't have to be writing code in a certain language for years on end before you learn to stop making school boy mistakes.

So considering the vast majority of C# developers have directly migrated from previously working with C++ - yes I do think you could easily find 100 experienced C# developers at short notice.