Click here to Skip to main content
13,452,991 members (50,570 online)
Click here to Skip to main content
Add your own
alternative version


34 bookmarked
Posted 8 Sep 2002

Semicolon - .NET's Angels

, 8 Sep 2002
Rate this:
Please Sign up or sign in to vote.
A monthly column by Microsoft's Visual C++ .NET Product Manager.

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.

.NET's Angels

<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…)


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?


This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.

A list of licenses authors might use can be found here


About the Author

Nick Hodapp
Web Developer
United States United States
No Biography provided

You may also be interested in...

Comments and Discussions

QuestionMessage Closed Pin
10-Aug-17 11:14
memberSalman Sajjad10-Aug-17 11:14 
GeneralSemicolon Pin
Toasty022-Oct-04 5:18
memberToasty022-Oct-04 5:18 
GeneralSome true, most are not Pin
mirano15-Jul-03 1:19
membermirano15-Jul-03 1:19 
Generaledit binaries resx files Pin
mloibl18-Feb-03 0:17
membermloibl18-Feb-03 0:17 
GeneralCode Colorizer Pin
abd123515-Jan-03 9:59
memberabd123515-Jan-03 9:59 
GeneralRe: Code Colorizer Pin
lordofscripts30-Oct-04 2:35
memberlordofscripts30-Oct-04 2:35 
QuestionWhat happening with MTS/COM+ Pin
Edward210-Oct-02 8:15
memberEdward210-Oct-02 8:15 
AnswerRe: What happening with MTS/COM+ Pin
George10-Oct-02 18:13
memberGeorge10-Oct-02 18:13 
QuestionResource editor fixes? Pin
Jim A. Johnson9-Oct-02 14:10
memberJim A. Johnson9-Oct-02 14:10 
GeneralDebugging on a laptop Pin
Anonymous9-Oct-02 5:53
sussAnonymous9-Oct-02 5:53 
GeneralRe: Debugging on a laptop Pin
Daniel Turini9-Oct-02 6:00
memberDaniel Turini9-Oct-02 6:00 
GeneralRe: Debugging on a laptop Pin
Nick Hodapp (MSFT)9-Oct-02 6:21
sitebuilderNick Hodapp (MSFT)9-Oct-02 6:21 
GeneralRe: Debugging on a laptop Pin
Anonymous9-Oct-02 21:16
sussAnonymous9-Oct-02 21:16 
GeneralRe: Debugging on a laptop Pin
Thomas Freudenberg9-Oct-02 10:57
memberThomas Freudenberg9-Oct-02 10:57 
GeneralRe: Debugging on a laptop Pin
Anonymous9-Oct-02 21:19
sussAnonymous9-Oct-02 21:19 
GeneralRe: Debugging on a laptop Pin
Thomas Freudenberg10-Oct-02 7:27
memberThomas Freudenberg10-Oct-02 7:27 
GeneralRe: Debugging on a laptop Pin
GISnet5-Feb-05 18:58
memberGISnet5-Feb-05 18:58 
QuestionMFC improvements? Pin
Anonymous9-Oct-02 5:42
sussAnonymous9-Oct-02 5:42 
AnswerRe: MFC improvements? Pin
Anonymous10-Oct-02 22:20
sussAnonymous10-Oct-02 22:20 
GeneralRe: MFC improvements? Pin
Nick Hodapp (MSFT)11-Oct-02 5:55
sitebuilderNick Hodapp (MSFT)11-Oct-02 5:55 
QuestionVC++ Motorcycle Jacket? Pin
John Simmons / outlaw programmer7-Oct-02 8:21
memberJohn Simmons / outlaw programmer7-Oct-02 8:21 
AnswerRe: VC++ Motorcycle Jacket? Pin
Nick Hodapp (MSFT)8-Oct-02 8:15
sitebuilderNick Hodapp (MSFT)8-Oct-02 8:15 
GeneralRe: VC++ Motorcycle Jacket? Pin
John Simmons / outlaw programmer9-Oct-02 3:48
memberJohn Simmons / outlaw programmer9-Oct-02 3:48 
GeneralWussie developers Pin
Anonymous2-Oct-02 10:08
sussAnonymous2-Oct-02 10:08 
GeneralRe: Wussie developers Pin
Christian Graus2-Oct-02 10:56
memberChristian Graus2-Oct-02 10:56 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

Permalink | Advertise | Privacy | Terms of Use | Mobile
Web02-2016 | 2.8.180318.3 | Last Updated 9 Sep 2002
Article Copyright 2002 by Nick Hodapp
Everything else Copyright © CodeProject, 1999-2018
Layout: fixed | fluid