Re: VCL

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

From: Daniel James (wastebasket_at_nospam.aaisp.org)
Date: 08/16/04 

Date: Mon, 16 Aug 2004 10:52:35 +0100

In article news:<839d9bab.0408151843.6cc31c8a@posting.google.com>,
Curtis wrote:
> I'm sure this is has came up before but can someone give an honest and
> in-depth review of differences between using MFC and VCL with Borland
> C++ and with Delphi?

MFC and VCL were designed with quite different goals in mind. Each does
its job quite well, but each has shortcomings.

VCL was designed as a class library to support the RAD features of
Borland's Delphi environment. VCL is also available in Borland's C++
Builder product, but that still uses the Object Pascal (now called
"Delphi Language") source from Delphi. VCL is very good for knocking out
basic functional small-to-middling aplications in a very short time. It
does not, however, scale very well to larger projects, or cope well with
any sort of GUI design that doesn't fit the VCL model. VCL omes with a
large number of visual (and non-visual) controls that can be a huge help
in rapid development *if* what you need to do is what those controls do
do. The behaviour of supplied controls is generally not easy to modify
(e.g. by sub/superclassing) so if you want different behaviour you have
to write completely new controls (though the VCL (Pascal) source is
available as a starting point.

Because VCL is quite a thick wrapper around the underlying Win32 API one
might hope that it would be easy to port to other platforms (Mac, linux,
etc.), but apparently this is not the case. Borland's own kylix
environment for linux uses a new library that is quite different from
VCL.

MFC, in contrast, was designed to be a thin wrapper around the Win32
API. It had two original goals: one was to make Windows (Win16)
programming easier, and the other was to ease the transition from Win16
to Win32 by providing a simplified API that was (mostly) the same on
both platforms. MFC was limited in scope by the fact that Microsoft'
existing Win16 compiler was quite primitive (no templates, no
exceptions) and this meant that the framework could not have as pure an
object-oriented design as one might like. It did succeed in it its
orignial goals, though, and continues to be a useful tool for writers of
Win32 apps.

It is one of MFC's strengths that it wraps the Win32 API only thinly,
because that means that an application can mix direct API calls with MFC
without fear of breaking things. (There was an earlier Borland class
library called OWL which, at least in its early versions, stored the
state of Windows objects within classes. If direct Windows calls changed
the actual state of the Windows objects so that the stored state got out
of synch with reality the framework could get seriously confused!) MFC
is generally much more scalable than VCL, and can be used for very large
projects (though for projects with large complex GUIs the document/view
classes will probably be inadequate).

> But, I was under the impressoin when I learned MFC that the VCL was
> superior.

For small, simple, GUI-centric projects that have to be completed
quickly (and that won't need much in the way of maintenance) the
combination of VCL and the Delphi/C++ Builder environment can be a great
help. For large projects, and for projects in which the GUI plays only a
small part, the advantage of this RAD approach is minimal.

> I think it is obvious that MFC is outdated and was designed by C
> programmers or at least programmers new to OOP.

I think that's unfair. Yes, MFC is now quite an old framework, and some
of its original design goals (especially Win16/Win32 migration) and
limitations (support for the old 16-bit MSVC compiler) are no longer
relevant, I agree there. I don't think it's fair to say that its
designers were "C programmers" or new to OOP. The design goals and
limitations they faced when MFC was new explain the nature of the
framework.

> However, it is also obvious that is extrmely valuable. I'd probably
> not be able to do what I'm able to do in MFC in Win32 API.

It's certainly more tedious, time-consuming, and error-prone to write a
Windows application in bare Win32 API calls than on MFC.

> * Harder to learn then Win32 API but can build certain types of
> programs faster.

I disagree. MFC hides some of the more tiresome details of Win32
programming and is consequently easier to learn.

> * Designed for small to mid-sized projects. The lack of portability
> and doc-view make it not as suitable to large-huge projects

Smaller projects are always going to be the ones to benefit most from
libraries that simplify the APIs of the OS and GUI, because they are the
projects in which the OS and GUI coding is most significant. Projects
with extensive back-end logic will always benefit less from frameworks
of this type than smaller applications. MFC's doc/view support is good
for any size of project whose GUI conveniently fits MFC's doc/view model
- if you need a more complex GUI there's nothing to stop you writing one
within the MFC framework - you just may not be able to use the doc/view
parts.

> * Does best where it wraps Win32 in simple classes but on flip side
> this doesn't buy a huge amount

It buys a useful abstraction of the Win32 API which leads to simpler
coding and less programmer confusion. No, it's not a huge amount, but
it's worth having.

> * Borrows a lot of problems from Win32 itself and creates many on its
> own

Yes, at the end of the day an MFC program is a Windows program. If you
want to do something that Windows doesn't support then you shouldn't
expect MFC to support it either (though MFC did provide support for some
Win32 primitives - such as property sheets - under Win16 where they were
not natively available, as one of its migration aids).

> The claims I've hard regarding VCL are that it is a better class
> design (even Petzoldi claimed it was better) and easier to use.

VCL itself is not really easier to use than MFC - it's a but higher
level, so you may have less code to write, but it isn't easier. VCL also
has a few "gotchas" for C++ programmers because it is written in Pascal
and not everything translated perfectly between Pascal and C++.

Where VCL does win -- at least for quick-and-dirty GUI-heavy projects --
is when it is used in conjunction with Borland's RAD tools. For most
large projects, though, the step-up that this provides is not
significant.

> I used the borland enviroment a little and got the impression the RAD
> was better but the compiler IDE sucked.

Borland used to have a much better environment for C++, but the
Delphi/Builder one is rather poor. It doesn't handle large projects with
multiple build targets or multiple sets of options well, and the
debugger in particular is flaky.

If you're interested in a C++ framework that works at a slightly higher
level than MFC and that can target multiple platforms why not take a
look at Trolltech's Qt (commercial and expensive, except for open-source
projects) or wxWidets (OS/Free)?

Cheers,
 Daniel.
 

Quantcast