MFC discontinued ; a bit lost

[PadexArt]

However, C++/CLI doesn't strip anything from C++, it adds something - the ability to write managed code. However, you're not required to use the CLI extensions: you can continue using C++ as usual for writing native code (and in fact, there will always be many situations where this is the correct decision).

Well, I'm sure MS invested time & effort & money in C++/Cli for a very good reason, its just that I don't see it.

[gstercken]

Well, I'm sure MS invested time & effort & money in C++/Cli for a very good reason

Not only MS - also, among others: Dinkumware, IBM, the Edison Design Group, Bjarne Stroustrup and other participants of the Ecma comittee which prepared C++/CLI for standardization.

its just that I see no reason whatsoever to use it.

Not yet... Reminds me of the situation back in the late eighties, when many C programmers saw no reason for using C++.

[PadexArt]

Not yet... Reminds me of the situation back in the late eighties, when many C programmers saw no reason for using C++.

Makes me feel like a grumpy old man. "Darned kids with your fancy C# and stuff"

[Garrett Headley]

One thing I have been curious about... is it true that creating applications using visual studio.net REQUIRE you to install the .NET framework on the target PC? Or is that only the case if you write managed code? I'm speaking for Visual Studio.NET 2005, since that is the one due to be released.

Garrett

[gstercken]

is it true that creating applications using visual studio.net REQUIRE you to install the .NET framework on the target PC? Or is that only the case if you write managed code?

No, the .NET framework is only required for executing managed code.

[darwen]

To add my 2 cents...

Personally I see managed code as the next "tier" of development languages. I consider it this way :

(1) First came assembler. Lots of mov, add, inc, dec, cmp statements - direct access to the processor, interrupts etc. Really, really quick. Especially when you consider the MMX and SSE extensions which (and correct me if I'm wrong) no compiler actually uses.

(2) Then came higher level languages like C. They were aimed at a more "developer friendly" interface : i.e. the ability to write english-looking code.

(3) Object orientated C++. Lots of other object orientation languages abound like smalltalk etc, but C++ was really the first OOB language to be used for commercial applications (not strictly true of course, but in general).

Focus was now shifting from the implementation to the design of large applications. Took some people a long time to get to grips with C++ (how many C-looking classes has everyone seen in their time) but I think pretty much now the norm.

(4) Managed languages - Java and .NET. A real an concerted shift towards writing better designed and more stable code with unit testing tools, refactoring tools, garbage collection for the elimination of memory leaks etc all being made available.

So what we effectively have nowadays is right tool for the right job, and certainly with the ability to write a dll in whichever language you feel like the ability for one language paradigm to talk to another.

So let's consider the effects.

I would estimate that at least 90% of development, certainly on desktop systems, are user interface applications : either user interfaces to databases or user interfaces to create data files. Word is an example of the latter.

With these applications speed isn't really an issue. Who cares if a button press takes 5ms longer to process in one paradigm than another ? It doesn't matter.

Here's where the .NET languages flourish. Complex user interfaces can be produced far easier than ever before. Besides the fact that .NET isn't particularly slow : if it's slow for you then you're doing something wrong. I've written a large amount of .NET code and have only found its speed limiting in a very small number of occasions. But then again, that's ok because : yep you guessed it !

For speed critical applications you can just write C++ code. But generally speaking 90% of all applications aren't speed critical, or computationally intensive, so you can still write all your UI in managed code with a little bit in C++.

And for the odd occasion (like heavy bitmap processing, which is what I use it for) where you've got something REALLY nasty to do in a VERY short space of time there's assembler.

That's what we have now in my opinion. Right tool for right job. If you're a stick in the mud and insist that you have to write everything in MFC then so be it. But that's throwing the baby out with the bathwater in my opinion. You're missing out on all the niceties of managed code.

Of course there are still huge applications which are written in MFC and it doesn't make much sense to rewrite them in managed code : or at least not yet. So of course MFC will continue.

VB6 is dead. Thank God.

I've got a great analogy here : how would you knock down a house - would you use a bulldozer, a pickaxe, or a toothpick ?

The bulldozer is managed code : very quick to write and flexible and has the advantage of being a truly object oriented language, but you don't have the level of control over the UI as you have in C++.

The pickaxe is C++. Yes you can do it, but it's going to take you a while. However you gain more accuracy and certainly control using a pickaxe than using a bulldozer.

Assembler, of course, is the toothpick. Very good for very small parts of the application, and it has its advantages, but nobody would really consider knocking a whole house down with a toothpick would they ? Just as nobody in their right minds would consider writing an entire commercial application in assembler.

So it all boils down to speed of development/nicety of design versus level on control over what's going on "down below" at processor level and speed.

At least in my opinion.

I'm glad that .NET has been produced by Microsoft. And even if you never intend to use it, you have to at least learn enough about .NET and the class framework to make a concious decision NOT to use it. Because the world is changing once again : and certainly judging by the job vacancies in the UK managed code is starting to take over from C++/MFC development.

Darwen.

[PadexArt]

And even if you never intend to use it, you have to at least learn enough about .NET and the class framework to make a concious decision NOT to use it.

I for one haven't argued about the usefulness of the .NET platform. I totally agree that it is way faster/easier to write applications in C# than in any C++/GUI Lib. I'm doing one right now and I praise God I've droped the original C++/CLI approach.

My doubt is related to the C++/Cli. What is its point? Who is using it and why? IMHO you either stick to C++ or you move to C#. I don't think you can have the cake and eat it at the same time.

[efkefk]

Thank you for your post darwen. It seems you have a good impartial global view. May be you could tell me more for my personal requirement.

- I am using Visual c++ 6.0 with mfc for 7 years (only around 2 hours a day). So my programming knowledge is really poor, but I like making code and this is a part of my job
- 4 years ago, I made 3 small programs (user interface application ; DialogBox type)
- periodically, I have to add new functions to these programs, and I have also to change their looking, in order to give them each time a new youth, matching with the current Windows operating system
- my programs do not need high speed

The most important for me is to possibility to re-draw all controls (button, listbox, combobox, ...) with pictures and text. And now I would like to create and resize them dynamically, in order to adapt to the re-sizable window (DialogBox).

I feel VC++ 6.0 a bit old to keep fresh looking for my controls (I already use other classes which are a bit old to). So I think it is time to re-do my programs. I just would like to find the right programming language, and keep it for as many years as possible.

I am actually sharing my mind between these possibilities:
VS .NET and c#
- a bit difficult because new syntax
- as you said "looks like a bulldozer" for my small requirement
c++ without mfc
- good because same language
- not sure is it a safety solution for the next 10 years (because many c++ programmers will go for another language like c#, then I would find less and less c++ fresh code)
- may be this language is also too powerful for my small requirement
PureBasic (an alternative choice)
- difficult because new language and new syntax
- I will classify it as "pickaxe": so powerful as c++ and light
- may be these new kind of evoluated "Basic" languages could be an alternative choice for me

Bob.

[darwen]

I agree with you PadexArt, using C++/CLI is rather like banging your head against a brick wall compared to using C#.

I suppose it's major advantage is the ability to mix managed and native code, but as we've seen from the C++/CLI forums that just ends up confusing the heck out of people. "Why can't I pass a System::String to ::SetWindowText" ? Laugh.

I stopped using managed C++ at least a year ago now and have never looked back. I write C++ COM dlls and use P/Invoke to do everything now, keeping native and managed completely seperate. And I've never looked back.

Darwen.

[darwen]

Actually Efkef, I didn't mean C# "looks like a bulldozer" - it was just an analogy refering to development times vs level of control.

In your circumstances I'd use C# without question. It's what WinForms was designed to do : UIs.

Darwen.

[efkefk]

Thank you for your advice darwen.
Regarding level of control, with VC++6.0 mfc, during my first days of code, I was surprised how difficult for instance to get the Windows message "right-click" on a simple button. So many code to add to catch this message, and it seems so easy to implement in PureBasic language (or c++ without mfc I guess), with some code like:

WaitWindowEvent()
if(EventGadget())
switch(EventType())
case RightClick
DoTheJobHere

It seems like I am too far from the operating system. So when I need something not available (like rightclick Windows message on button in VC++ 6.0), it is of course possible to do, but it takes so long time for a low level programmer like me.

Do you think when we need to do something not available in Visual c#, it is same problem like it was with VC++ 6.0 ?

Do you recommand me to use Visual Studio c#, or another c# ?

efkefk.

[Marc G]

(1) First came assembler. Lots of mov, add, inc, dec, cmp statements - direct access to the processor, interrupts etc. Really, really quick. Especially when you consider the MMX and SSE extensions which (and correct me if I'm wrong) no compiler actually uses.

Wrong, actually the Microsoft C++ Compiler in VS.NET 2003 can optimize using SSE, SSE2. The Intel compiler supports MMX and SSE and I'm sure the GCC compiler supports it to.

[darwen]

Thanks Marc, I wasn't sure (which is why I said correct me if I'm wrong).

Darwen.

[darwen]

Efkefk,

Why don't you just download the Visual Studio 2005 Beta ? It's free (for now - not for much longer though !) and then you can have a good look at C# and the IDE.

As with any IDE there's going to be a learning curve. But you should soon get the hang of it.

Just to let you know the way messages are handled in .NET isn't the same as in VC++. You have the concept of an 'event', which is basically a list of methods which get called when the event is fired (aka observer pattern). So you have a Click event on a button, but also MouseDown with parameters determining which button.

It's a lot simpler and cleaner to use than MFC's message maps. Just one advantage.

However one of the things which makes .NET truly usable is the ability to go "under the hood" when necessary. You have access to each window's message loop (or even the message loop for the entire application). You also have access to the underlying system window handles (i.e. HWNDs) if you want to make raw Win32 calls on them. Not advisable, but you can do it.

There's also a very powerful interop mechanism which (once you've learned the ins and outs of it) allows you to call native dlls, both COM and static.

I think you really need to go off and try it out for yourself. Depending on your experience and expertise with VC++ you might consider buying a book on C#. Personally I picked it up in no time whatsoever, like most of my MFC/C++-based collegues, but like I said it depends on how much experience you have.

Darwen.

[Marc G]

Thanks Marc, I wasn't sure (which is why I said correct me if I'm wrong).

Darwen.

You're welcome