Neophyte Question(s)

[James]

Complete neophyte to VC++. I do have a base knowledge of how API calls work
and the general structure of these applications, but I'm getting bogged down
with details. Just a few, relatively simple questions.

Using VS2005, if I'm looking to build a "standard" windows app, it appears
my best option is MFC? Gets me drag and drop functionality, etc. In the
event that I had finalized an application using MFC, do I need to distribute
anything other than the EXE file, or is it still unmanaged and framework
free?

Very simple "event handler" type question. I've created an MFC application
which has a dialog. Just called it WinMFC. I want to do something as
simple as changing the background color of the default dialog. There
doesn't seem to be a property, so I assume I have to handle an event like
WM_ERASEBKGND...but where exactly do I handle this? Is this even the right
approach?

Sorry for the ridiculously simple questions, just trying to learn something
new.

Thanks,
James

 

[Ben Voigt]

It would be free of the .NET framework, but you'd still need the MFC
framework DLLs.

I believe that ATL on the other hand, since it is based on templates which
work at compile time, leaves you with no additional dependencies.

There is nothing wrong with learning something new.

What type of app would you want to build?
Personally, for most types of windows based application, I would use a
Windows Forms application, and program it in C#, not in C++.

Not if you're worried about dependency footprint, which the OP seems to be.

I have onyl used MFC for simple dialog based applications. I have never
mastered MFC because I don't really like it.

I agree, don't use MFC for new code. It isn't likely to be supported for
much longer.

 

[James]

Ok. So eliminate MFC from my vocabulary, don't have a problem with that. I
guess what I'm really trying to determine is what the true benefit of using
VC++ over C# is. Smaller footprint and CLR independence, but what's a
practical type of application that VC++ would be a better alternative than
C#?

 

[Bruno van Dooren [MVP VC++]]

Ok. So eliminate MFC from my vocabulary, don't have a problem with that.

I guess what I'm really trying to determine is what the true benefit of
using VC++ over C# is. Smaller footprint and CLR independence, but what's
a practical type of application that VC++ would be a better alternative
than C#?

You would use C++ if
- you need absolute control over runtime behavior (e.g. real-time systems)
- you have to maintain an existing x million line codebase
- you need a very small memory footprint.
- you need to limit external dependencies.
- you need raw performance in specific algorithms
- you need to write device drivers or windows explorer plug-ins.
- you need cross-platform compilation.

I have used C++ for device drivers, interop dlls and realtime apps.

C++ is powerful and flexible, but this comes at the cost of
- being more difficult to learn
- making it very easy to screw up
- needing more time for development, debugging and testing

C# otoh is easy to learn, easy to use and is like a child-safe version of
C++.
personally, I prefer to use C# for GUI style apps, and apps that do not have
a requirement that would make me use C++.
simply because with C#, it is a lot easier to get the job done without
worrying about all the things that C++ makes you think about.
time == money

Don't get me wrong. I love C++, but these days, using C++ for simple apps is
like using assembler to write apps. you can do it, but what's the point?

--

Kind regards,
Bruno van Dooren
(e-mail address removed)
Remove only "_nos_pam"

 

[David Wilkinson]

I agree, don't use MFC for new code. It isn't likely to be supported for
much longer.

Ben:

What is the basis for this statement? There has no reduction of MFC
support in recent Visual Studio offerings (other than the much less
convenient IDE than in VC6).

And I hear rumors of increased support for native code (including MFC)
in future versions of VC++.

Personally, I am not sure that the entire MC++ and C++/CLI (not to
mention VB.NET) was not misguided. .NET is nice, and C# is a great
language, but the duplication in the three languages (VC, C#, VB) was a
huge effort with somewhat marginal rewards, IMHO.

David Wilkinson

 

[Bruno van Dooren [MVP VC++]]

Personally, I am not sure that the entire MC++ and C++/CLI (not to mention

VB.NET) was not misguided. .NET is nice, and C# is a great language, but
the duplication in the three languages (VC, C#, VB) was a huge effort with
somewhat marginal rewards, IMHO.

I agree that C++ should not emulate C#. I have no desire to see things like
LINQ in VC++, simply because there is only so much engineering time
available, and it would better be used on native and interop features.
But in order to have the perfect interop tool you really need C++/CLI to
give you access to the .NET framework.
MC++ was indeed one ugly language perversion, but C++/CLI is quite elegant
imo.

it requires a lot of engineering effort, but it is indispensible.

--

Kind regards,
Bruno van Dooren
(e-mail address removed)
Remove only "_nos_pam"

 

[James]

Thank you, makes sense. Realizing that I'm a C++ neophyte, and assuming I
have the mental capacity to undertake such an endeavor, where would you
recommend I start if I were interested in understanding how to create device
drivers? I realize it's a very large uphill fight, but I have a lot of time
on my hands and I'd like to add it to my list of things I know.

So assume I'm completely competent developing Windows based CLR apps in
C#/VB.NET and I want to start from absolute "Square 1" in VC++ (i.e. I know
what int x; does!), where would you recommend I start? Writing basic
console applications to start? Any good web references for people that have
a general knowledge of programming paradigms but very very little C++
knowledge?

Thanks for your help thus far!

 

[Ben Voigt]

Ben:

What is the basis for this statement? There has no reduction of MFC
support in recent Visual Studio offerings (other than the much less
convenient IDE than in VC6).

The fact that a gazillion new APIs have been introduced in Win32 without
being added to MFC. The fact that MFC can't support the 2006 look-and-feel.
The fact that MFC hasn't kept up with the C++ standard and as a result is
far less efficient than template and native-exception-based frameworks.

Given that development of WTL, the intended replacement for MFC, seems to
have been dropped, I don't see a high likelihood of further MFC improvements
either.

 

[Ben Voigt]

Thank you, makes sense. Realizing that I'm a C++ neophyte, and assuming I
have the mental capacity to undertake such an endeavor, where would you
recommend I start if I were interested in understanding how to create
device drivers? I realize it's a very large uphill fight, but I have a
lot of time on my hands and I'd like to add it to my list of things I
know.

So assume I'm completely competent developing Windows based CLR apps in
C#/VB.NET and I want to start from absolute "Square 1" in VC++ (i.e. I
know what int x; does!), where would you recommend I start? Writing basic
console applications to start? Any good web references for people that
have a general knowledge of programming paradigms but very very little C++
knowledge?

If you want to do device drivers:

Definitely start with some number crunching and bit twiddling, a console app
is best for this.
Then write some code for microcontrollers like Microchip's PIC or the
Rabbit, where the system is small enough to easily understand and you get
some practice with interrupt handling.
Also write some multi-threaded user-mode Win32 code and use interprocess
communication to get data between a processing app and a front-end display.
And use only the pure Win32 API (kernel32, user32), no wrapper frameworks.
Then you will be ready to try some kernel-mode drivers.

 

[David Wilkinson]

Replies inline:

The fact that a gazillion new APIs have been introduced in Win32 without
being added to MFC. The fact that MFC can't support the 2006 look-and-feel.
The fact that MFC hasn't kept up with the C++ standard and as a result is
far less efficient than template and native-exception-based frameworks.

Yes it's true there have not been too many improvements. But it's not
like what happened to VB6 (RIP). MFC still provides the application
framework, and the great thing about it is that it can seamlessly call
the underlying Windows API. You can wrap new API's in your own classes
if you wish. Take the file dialog for example. I'm sure everybody thinks
they could have done a better job than the CDocManager/CFileDialog
fiasco in MFC. Now's your chance ...

Given that development of WTL, the intended replacement for MFC, seems to
have been dropped, I don't see a high likelihood of further MFC improvements
either.

Was WTL the intended replacement for MFC? I didn't know that. Even as it
is I have thought of looking into WTL, but I just have so much invested
in MFC. I know MFC has a lot of warts, but I know most of them by now.

David Wilkinson