Introduction
The week before last I popped on over to Redmond to have a chat with the guys at Microsoft on the future of
Visual C++, MFC, and the new .NET world. Instead of presenting a point list of what we can expect
in the future, I wanted to give you guys a taste of what a visit to Redmond is like from a
personal point of view.
Please be aware that this isn't an in-depth technical treatment of .NET - there are a million
magazine articles and a ton of stuff on Microsoft's own site to get the basics. The
.NET specific stuff presented here will mostly be new information that I wasn't
aware of, and that I
felt you guys would be interested in, or was simply a vague thought that came to me
while slurping through tubs of Ben and Jerry's Fudge Chocolate Disaster ice cream.
A quick Thanks goes to Dundas Software and Microsoft for making this trip possible.
Part 5 - The Compilers
This was going to be a discussion on the libraries (namely MFC, WTL, ATL etc) but I wanted to
talk a little bit more about the compiler.
Personally, I would hate to be working on the Visual C++ compiler. The guys who wrote
the C# compiler must, I'm sure, wander around to the dark murky depths of the Visual C++
Compiler Developer's cage and lounge around and talk at length on how nice it is to be able
to develop a compiler from scratch for a language that is so compiler friendly (well, compared
to VC++). Because of the design of the C# language the C# compiler can process up to 3 million
lines of code a minute. I'm also guessing there are no C# compliance hassles for the C# compiler
team - though once ECMA gets through with the language there is, of course, no gaurantee that
non-compliance may sneak in. A standard is merely a standard, and anyone who chooses to implement
a compiler is free to change their implementation to whatever suits them (or their market) best.
This is the main problem with the Visual C++ compiler. It's
up to something like its 13th incarnation, and each version is building on previous
versions, with each new version being backwards compatible with those previous
versions. So if someone, way back in version 2.0 made a bad call on a particular
feature, then too bad - future generations are stuck with it or are forced
to make horrible workarounds to cope with it. Fixing these non-compliance issues
is often non-trivial but the guys at Microsoft are at pains to emphasise that
when dealing with non-compliance they work at fixing the most used features first.
Obviously there are economic (and time) considerations as well. Microsoft has
in the past worked towards imposed deadlines (whether or not they ever met those
deadlines is another story) and as the deadlines loomed certain features that
were deemed, well, optional, were tossed overboard. They no longer want to work
this way, and if it means release dates are strung out a little then that's the
way it will be. The focus is on quality, not timeliness. Compliance was
always on their minds but never as much as some would like, but they do
recognise this and are trying to remedy the situation.
Let me digress and pose a question. Templates seem to be an area where
religious fanaticism on compliance is particularly rife, but is this really an issue to
most developers? Templates can certainly make life easier for a developer, but what about
the developer who takes over the project when the original developer leaves? In the face of
increased labor shortages is it really
wise to be developing apps using specialised techniques for which you or your company will have
serious problems finding developers who can maintain your code? Even if you do find such
a developer, that person may charge a premium on their specialised services, and/or may cost more
in the long run because of the extra time needed to get fully acquainted (and work) with the
templatised code. Maybe I'm just a wuss and like taking the easy route to code writing, so I'd
be interested in hearing your points of view.
I asked Ronald about the compiler internals and he said that the compiler gets full rewrites
only occasionally. There was a rumour that the compiler
code was so spaghetti-like in it's internals that no one - no one - wanted to touch
the thing. He said it wasn't quite that bad. The last rewrite for the compiler was for Visual C++
version 4. Each version after this
has had various revisions, additions, bug fixes, 'feature' additions (you guys know what I'm
talking about) and maybe a #pragma or
two to keep things interesting. All in all though, the versions of the C++ compiler we've
had since Windows 95 development came into vogue are refinements on the original VC4 compiler.
As with each previous incarnation the latest Visual C++ compiler has even undergone further optimisation.
Given that this is around the 13th
review of the compiler, with each version gaining incremental, and smaller performance increases
over the last version, it is amazing that they have tweaked a further 5% performance out of the
compiler.
I've
already mentioned some of the newest improvements to
the Visual C++ compiler: a new crash recovery feature that allows an application to
be restored to its state immediately prior to crashing allowing post mortems to be carried out;
'Edit and Continue' has been improved, and there is now public access to the debug info
file
On top of these, there is also now a new /GL switch that allows the compiler to perform global optimisations
across all files in a project instead of being confined to per-file optimisations. Given varying
applications and files there is expected to be a gain of around 5%-10% speed increase in a typical
app. Note that this switch is only a 'final-build' option, since it significantly increases compile
time.
The compiler also (with the appropriate switch) now inserts buffer overrun checking code into
apps that stops the possibility of
buffer overrun attacks. This is a major source of attacks in applications such as internet
applications and is the subject of many millions of dollars of investment by companies
searching for solutions. By simply recompiling your app in VC7 (with said switch) your application
will be protected.
If you suspect buffer overruns may occur you can simply add your own buffer overrun event handler
as a last-ditch 'I've tried everything' resort. Other problems such as the use of uninitialised
variables are treated in a similar manner, and you can include your own handler in your code to
take care of any uncaught instances of these.
Finally, there are new Processor Packs that you can add to the environment that allow you to
target specific processors, such as Pentium III's, processors with 3D Now! etc. Gone are the days
of convoluted inline assembly to target these cases. As more processors come out, more processor
Packs will be distributed. Any thoughts on why Microsoft would be adding the ability to target
different processors so easily? I'm sure they are just looking after us
.
Next Instalment...
The Libraries.
