Semicolon is a new monthly column from Microsoft's Visual C++ .NET Product Manager - our very own Nick Hodapp. The column is intended to be a direct line to Microsoft for you to ask those questions that no-one else can answer. If you've ever wondered about the internal machinations of the VC++ compiler, or ever wanted to know why a particular design decision was made, or want the inside story on a curly Visual C++ question that has been stumping you then post your questions here. Each installment will cover the best or the most interesting question. The rules are simple: Make it interesting, make it about Visual C++, and don't ever mention Visual Basic.
<FONT size=+1>C++ developers are a tough crowd. We (and I'm shamelessly going to include myself) are often viewed as rocket-scientists, although some days I think we're considered by many to be more of the reckless motorcycle-gang, dregs of society, type. As such, although we're often highly intelligent, we insist on playing with powerful, high-performing and dangerous equipment. And, more often than not, we have a large chip on our shoulder.
We're also a surprisingly sentimental crew. To continue the analogy further, as a rule we relentlessly compare new bike models to our timeless classics and debate whether their features would in fact improve our lifestyle - or are better left untouched. When a new freeway opens we won't even think about riding on it if there are any posted speed limits (or if it allows travel by 4-wheeled yuppie-mobiles).
Obviously, I'm talking about Visual C++ .NET and the .NET platform. (And maybe, just maybe, Visual Basic and C# are 4-wheeled yuppie-mobiles).
The .NET superhighway has a special lane reserved for C++. It is a lane that is thankfully littered with on-and-off ramps to our well navigated and un-policed roads, where we can continue to whoop it up and cause mayhem. But, contrary to the fancy new name, Visual C++ .NET is not only about .NET. In fact, I spend a great deal of time informing developers about the new features in Visual C++ that are applicable today, to the code they've been developing for years with Visual C++ 6.0.
Perhaps it has something to do with how I personally write code (no wisecracks, please) but one of my favorite updated features is the Visual Studio .NET debugger. This is one bad-a$$ accessory, the full power of which applies only to Visual C++.
Some developers argue that the styling of the VS.NET IDE is a step down from the MFC-clad 6.0 IDE. But even they will usually admit that the GUI and usability enhancements to the debugger are alone the equivalent to hours of spit-and-polish applied to neglected chrome and leather. For the first time we can open multiple memory-view windows, dock modeless thread, breakpoint and modules windows to the IDE, and set breakpoints by simply clicking in the left margin of the editor.
GUI schmooey? How about enabling your application to produce a minidump if it croaks on some sorry-pathetic user's machine? (Likely due to someone else's code, of course.) Now you'll be able to load the dump file with Visual Studio and see a snapshot of the application's moment of death - complete with the offending line of code and a stack trace. Microsoft did this with Windows XP and found (and fixed) the sole culprit of 30% of all blue-screens (it wasn't us…)
<TABLE style="FLOAT: right" cellPadding=10 width=250 align=right bgColor=#fbedbb border=0>
Here's an undocumented debugger goodie: type '$handles' into the watch window and set the value to '0' (it will pop back to some other value). Then look in the output window to see a list of all the open handles (and their types) in your process. File handles are accompanied by the file path. Smooth.
Another high-octane feature has fingers in the compiler, the CRT, and the debugger. Runtime Checks for debug-builds catch four common sources of programmer (for shame!) error: shortened converts, calling-convention mismatches, usage of un-initialized variables, and of course buffer overruns. The way this works is simple: build with /RTC and be ready when the debugger pops up a message telling you something is amiss in your code. Fix the problem right then and there (shhhh - don't tell anyone: Visual C++ is the only language with Edit & Continue) and you won't have to tell anyone your dirty little secret.
Okay, so unlike me you don't rely on the debugger. Make your application run faster then with Whole Program Optimization, a new feature that ekes out performance by allowing the optimizer a second-go once the linker has figured out how your code is all interconnected. Think of a turbocharged engine - this is nearly the same concept. The Ages of Empires team at Ensemble tells me they got a 10% performance boost on their game engine simply by recompiling. Talk about pure horsepower.
If you haven't realized it by now, let me point out that these features are extremely high-torque. You simply don't find Whole Program Optimization in Visual Basic. The reason for this is simple - Microsoft designs languages and developer tools for different sets of developers, who solve different classes of problems. We all see life from different angles - do I buy a Honda, a BMW, or a Harley?
A key aspect of my day job is to define the product positioning for Visual C++. Product positioning attempts to set boundaries that define who a product is for, and how the product is supposed to be used. 'Product Managers' define product positioning, and in my group we have 4 key products: Visual Basic (Ari Bixhorn and Mike Iem), Visual C++ (that's me), Visual C# (Prashant Sridharan), and Visual J# (Brian Keller). Each morning we come to work ready to battle it out in a death-match arena. No kidding. It's a good thing I've got my biker-gang backing me up because I weigh in at only 150lbs. Don't worry though; I can be pretty fierce when I wear leather and chains. (Everyone feels sorry for Brian, who's new and weighs in at something like 125lbs.)
In a nutshell: Visual Basic is the 'easy' language. Its focus is on productivity and ease of use. Your kid sister uses Visual Basic to do her homework. You yourself have used Visual Basic for quick-and-dirty testing of the ActiveX components you build with ATL. Visual C# is the 'modern, innovative language' for Pragmatic developers (I prefer the term 'Wussie developers'), appropriate for building most '.NET-connected applications and components' (I'm tempted to place quotes around all official marketing jargon). C# also focuses on RAD, and it sometimes appeals to our crowd because it has semicolons. But from where I'm sitting, it is only 500cc and is way under powered. Visual J#…is, well, this.
And I think you'll like this: Visual C++ is a systems-level language - both for Windows and .NET. It is the language that exposes at the lowest level (and admittedly sometimes in the most difficult and convoluted manner possible) the core services of the platform. But along with this difficulty and convolution, Visual C++ offers developers the best opportunity for performance and flexibility. Who cares if you get your hands a little greasy? For what it's worth, practically all current Microsoft products are, and will continue to be, written in Visual C++ (it is the only Visual Studio language that targets native Windows). But then, you know all this.
By the way, keep in mind that Visual Basic has the largest market share (thus 2 Product Managers…). We're in second place. Go teach your kid sister to program in C++ and I'll be a very happy man.
I think the coolest thing about C++ on .NET is that it is very easy to expose the code and components we write to other languages on the platform. All that's required is a thin layer of managed code and a compile with /CLR. Unlike VB and C#, which are .NET-all-or-nothing, Visual C++ doesn't force us to swallow the entire .NET pie - we can enable portions of our applications to run on the CLR in a very granular manner.
Wisecracks and ribbing aside, the fact of the matter is that our industry is evolving. In the last ten years we've seen new languages (VB, C#) and technologies (managed runtimes) emerge that do enhance our ability to build quality software. For Visual C++ developers, the '.NET' part of the product is simply a new tire-tread that enables our code to roam freely in the CLR interstate.
By now I think that most Visual C++ developers are at least peripherally aware of Everett, the next release of Visual Studio and Visual C++ .NET. By some miracle it turns out that this release (date yet unannounced) will nearly coincide with the 10th Birthday of Visual C++. (Version 1.0 was launched in February 1993. I'm planning a party and you'll all be invited.) This is sweet irony, considering that Everett is poised to be one of the most significant upgrades ever for Visual C++, and will include several major new features. Our product roadmap mentions the first of these: ISO C++ standards conformance. Watch this space and I'll keep you informed on the latest Everett related announcements.
I think I'm going to make up some Visual C++ motorcycle jackets. Who wants one?