Tagged as

A Visit to Redmond - Part 4

For those who are curious as to what a hastily scheduled trip to Redmond is like.

Introduction

Last week 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, and I'm dead keen on having feedback from you on your own personal experiences.

A quick Thanks goes to Dundas Software and Microsoft for making this trip possible.

Part 4 - Visual C++

As I mentioned in part 3, and most important thing I got out of the meeting was that Visual C++ and MFC is alive and well. PDC 2000 was a launch of the new technologies surrounding .NET, and unfortunately the message that was delivered was a little murky on the future of C++/MFC.

There were a number of reasons this happened. PDC 2000 was not the 'header file' conference of past years, where loads of Microsoft guys would walk through the new libraries on offer, the new header files you needed to use these libraries, and the new API's available for whatever version of Windows was flavour of the month. PDC 2000 was more about the explaining, and demonstrating, the future directions of Microsoft's vision rather than trying to show every single change that had been made in the move to .NET.

Another reason C++ and MFC lacked exposure is that it was hopelessly overshadowed by the new kid on the block: C#. Internet applications are the big thing in .NET, and C++ programmers will most likely feel more comfortable writing their ASP+ apps in C# rather than in VB. Then there was the "Is C# Cool" (depends how you look at it), and "Is C# Microsoft's answer to Java" (you decide ) controversies.

But most of all, C++, and MFC in particular, no longer has an evangelist like Mike Blasczak. When you think of MFC who do you think of? George Shepherd, Jeff Prosise and others certainly spring to mind as prominant book authors, and Paul DiLascia writes great code, but who is there to stand up, be opinionated, possibly obnoxious, insightful, and hugely entertaining in their quest to enlighten the peasants about the magic that is MFC?

So, sadly, MFC was a was a bit of a wallflower at the PDC bash, but the guys at Microsoft would very much like to make up for that.

So what's the deal with Visual C++ and MFC in .NET?

Visual C++ is still the development language of choice for many applications. Managed extensions for Visual C++ allow you to create applications that interact with the .NET framework in a way that makes programming simple, quick, and intuitive. Visual Studio is mostly written in C++, as is Microsoft Office (managed wrappers will be provided for .NET). There is simply too much legacy code out there to even think of abandoning or downgrading the language.

Visual C++ has also been improved in a number of different ways. The debugger in Visual Studio.NET is from Visual C++. There is 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 (all the guys at NuMega will be cheering on this one).

C++ conformance has also been improved. My notes are a little smudged on whether the VC++ compiler is the most conformant compiler, or merely the second most conformant (there is a mysterious, unidentifiable, beer-coloured stain on that page of my notes). The Microsoft guys claim that the compiler is so conformant that other compiler manufacturers no longer bother to publish conformance tests.

(brief pause as the din dies down)

No - I never said Visual C++ was 100% conformant, and this seems to be a serious source of aggravation among developers. There were even a number of wry looks among the product managers when discussing VC++'s conformance, but Ronald Laerman, Lead Program Manager for MFC/ATL was very candid on this point. He freely admits that the compiler is not 100% conformant, but what would developers rather have - a new compiler that is 100% conformant and will most likely break legacy code (or fill it with untraceable bugs), or a compiler that is so, so close, but which works seamlessly with all your current and previous code bases. Another point Ronald bought up is that while many developers point to other compilers as being more conformant, what is actually meant by these developers is that the particular compiler they use supports their pet feature. Microsoft would rather keep most of the people happy most of the time than a few of the people happy all of the time. And that "most" is a really big "most". They really are doing their best to make life as easy as possible for us developers.

C++ will always be the language that gives you the most power and flexibility. Microsoft has made a significant investment into the future of the language, and it has been enhanced to work seamlessly in the new .NET environment. While VB and C# may become the GUI application programming language of choice, C++ will the language of choice for writing drivers and components.

I'll talk more about MFC 7, ATL, WTL and STL in a later instalment. The news is all good.

The Microsoft guys felt that they were making Visual C++ more complicated, but for programmers who wish to continue writing non-managed native mode apps in VC++ there is no change. Managed extensions are just that - they are extensions. All your old code will work, and you can continue creating apps the same way until the cows come home (do you have that expression over here?). If you want to dip your toes into .NET then you can. If you want to dive-bomb in and do a big belly-landing then managed extensions allow you to do whatever you want, and the new classes in MFC and ATL will make this even easier.

Share

About the Author

Chris is the Co-founder, Administrator, Architect, Chief Editor and Shameless Hack who wrote and runs The Code Project. He's been programming since 1988 while pretending to be, in various guises, an astrophysicist, mathematician, physicist, hydrologist, geomorphologist, defence intelligence researcher and then, when all that got a bit rough on the nerves, a web developer. He is a Microsoft Visual C++ MVP both globally and for Canada locally.

His programming experience includes C/C++, C#, SQL, MFC, ASP, ASP.NET, and far, far too much FORTRAN. He has worked on PocketPCs, AIX mainframes, Sun workstations, and a CRAY YMP C90 behemoth but finds notebooks take up less desk space.

He dodges, he weaves, and he never gets enough sleep. He is kind to small animals.

Chris was born and bred in Australia but splits his time between Toronto and Melbourne, depending on the weather. For relaxation he is into road cycling, snowboarding, rock climbing, and storm chasing.

Partial specialization ? Hell I'd be happy if they could make the compiler able to even function with the Microsoft extensions switch turned off. In VC++ 6.0 it is impossible (in my experience) to compile even the simplest "Hello World" program without the MS extensions turned on. I assume this is another casualty in .NET as wel

There are several new switches which give fine tuned ISO compliance. For instance, you can turn on or off the new for scoping specifically, and you can turn on or off native wchar_t support (wide characters as their own type).

You probably won't be able to completely turn off MS extensions, because the standard library and other MS headers depend on certain extensions for things like exporting into DLL's and #pragma once and such.

It would be nice if you could turn off MS extensions in your code only (not the library code).

In light of your previous installments I was actually expecting a humorous tale of the trials and tribulations of VC++ - but I guess it is kinda important that we hear about what is probably very important news for our future.

I just felt a sudden urge to do a Homer Simpson:
<Homer>Stupid TV (bang!) Be More Funny! (bang)</Homer>

From the following URL
http://www.devx.com/free/press/2000/vs-qalist.asp

We have the following quote

Does VC.NET support ANSI/ISO C++? Can VC.NET use Blitz++? http://www.oonumerics.org/blitz

VC.Net will not, I am sad to report. We are addressing compliance issues with both the compiler and with the standard library in VC.Net, some of the enhancements are in the bits distributed at the PDC, some we are still working on. However we were not able to do all the work needed to compile Blitz or its competitors that are based on expression templates in this release. E.g. we did not have sufficient time/resources to implement partial specialization. We did significant work on the standard library and on improved diagnostics for template errors, one of the main causes of frustration and hair pulling for many C++ developers trying to use templates. We are looking very hard at what it takes to fully support expression templates and other advanced template-based libraries for the next release. Ronald Laeremans, Microsoft.

Now, according to most C++ people, support for partial specialization is one of the key features of ANSI compliance. In fact, without partial specialization, a lot of hacks are necessary to get the STL to work. Unless Microsoft changed their mind after the above mentioned piece, VC.NET won't have partial specialization. Without partial specialization, VC is way way down the list of compliant compilers ( EDG, GNU, Borland, KAI are ahead of it), and Microsoft is doing a bunch of marketing hype.

Does anybody have anymore information on whether partial specialization will be in the next version of VC++, and the article I saw was outdated? If so, please post a reply and correct me.

To the best of my knowledge, no, VC++ 7 (VC.Net) won't include support for partial template specialization. Nearly everything else appears to be "fixed", so a fully compliant STL is possible (as long as other advanced template features work it's possible to work around lack of partial template specialization in the STL). However, expression templates, lambda libraries and other such "advanced" libraries which are quickly becoming the bread and butter of the language, won't be possible with out partial specialization. MS's failure to include this "feature" is, frankly, unforgivable at this point in time.

They crawled up from the bottom to be on top of the pack for a while, but, unfortunately, as far as the compiler itself is concerned they are nearly back to being on the bottom of the heap. To claim that they are the most compliant, or even the second most, is not only poor marketing, it's a bald faced lie that insults the intelligence of their customers.

(Would you believe that less than 6 months ago I was as strong in my feelings as I appear to be here when *supporting* the VC++ compiler?

Hmmm - that's interesting. I'll fire off an email to Ronald and get his reaction on this. He was quite passionate about compliance, but was equally accepting that a number of advanced features where indeed missing.

Maybe his/Microsoft's view of 'specialised' doesn't necessarily synch with the common developers view on this...

Unfortunately, Ronald is out of the office for a few weeks and probably won't be responding to many emails (he posted to a newsgroup that he frequents).

Ronald's a great guy, and he's very earnest and up front. But I think he can be a little blinded by what the Microsoft culture feeds him at times. I can't imagine that he would say that the compiler is the most conforming or even second most conforming, since he knows it's not even close. That comment must have come from someone else.

I think MS is often blinded by it's peer group and usability studies. They poll a few dozen people, and assume that this is an accurate represenation of their audience.

The problem with such polls is that they typically only give you the information you're looking for.

Most novice to intermediate developers will probably say B (or maybe C and might not even know what PTS is. But in 6 months or a year when they aren't novices anymore, their answers change and suddenly, they're wondering why they can't use PTS.

While maybe it's true that only 10% of MS's customers care about full compliance, that 10% probably writes 70% of the code in major applications (or at least is influential in it's design).

In any event, the decisions about what VC7 will and will not be are made already and they aren't going to change.

To be perfectly honest I find C++ templates pretty daunting. Having worked on many C++ projects with numerous groups of programmers I have yet to find one who is really happy even using templates let alone writing them. This may be because you have to be an idiot to work with me, but I suspect that templates really are hard to understand (note they have yet to be included in Java and I don't think C# includes them).

Given this then the lack of partial template specialization is hardly a major issue for most programmers even after 6 years of C++ programming. If the compiler comes with a good STL out of the box then it is compliant enough for me.

Once you've worked with the STL, I doubt you'd retain that viewpoint. My experience with STL from both a usability standpoint and a design standpoint, is that this is the future of powerful programming. The whole concept of generic programming.. absolutely luv it! The only drawback that I can see to working with templates is in debugging them and that's the compiler's domain. What this particular framework offers far outweighs the drawbacks

I agree with you about STL and in fact I do use it extensively in my C++ programming (I tend to do more Java now). My point was that you can manage a good STL without partial template specialization. It may not meet the purists demands but I find the DinkumWare STL more than adequate for my needs.

There are many people who seem to be saying that templates are hard to use and that partial specialization does not matter. In fact, partial specialization makes templates easier to use not harder. Without partial specialization, you have to go through many tricks to do certain stuff. In addition, partial specialization does not add to the complexity of user code. It instead makes it easier for the library provider to write more efficient and usable code

There are many people who seem to be saying that templates are hard to use and that partial specialization does not matter. In fact, partial specialization makes templates easier to use not harder. Without partial specialization, you have to go through many tricks to do certain stuff. In addition, partial specialization does not add to the complexity of user code. It instead makes it easier for the library provider to write more efficient and usable code

There are many people who seem to be saying that templates are hard to use and that partial specialization does not matter. In fact, partial specialization makes templates easier to use not harder. Without partial specialization, you have to go through many tricks to do certain stuff. In addition, partial specialization does not add to the complexity of user code. It instead makes it easier for the library provider to write more efficient and usable code

Your are right if you say templates are hard to handle (especially if you get some errors) and most important is that STL works quite well. It's really nice that MS is working on better "template debugging".

Templates and using PTS is really, really for advanced developers. It's the whole philosophy of generic programming and C++ meta programming. Libraries like Blitz are made of this stuff. And they will be much more libraries like this, iff one day most compilers support the whole template stuff. It's a great technique and STL is only the beginnig of it.

One problem, as I have mentioned before, is that you can't learn templates if you can't use them. A great way to learn about templates and to master their use would be to buy a copy of "Generic Programming," and work through it, seeing the power that templates give you. The problem is that you can't do that with VC++, since it does not support templates fully.

As long as VC++ does not support templates, VC++ users will not understand templates well enough to take good advantage of them. It's a chicken-and-egg problem.

In my work, this is a real frustration, because for heavily numerical code, FORTRAN vastly outperforms C and C++. The Blitz++ library, mentioned at the top of this thread, promises finally to make C and C++ produce machine code that performs comparably to FORTRAN, but MS doesn't think its customers care about performance on Engineering applications---as they see it, the VC++ market is mostly developers writing client-server database applications for business.

If this is true, they probably don't lose much by ignoring us engineers and scientists, but as 3D-graphics performance becomes increasingly important, they will find that the same kinds of performance drags we see today in engineering applications will bog down tomorrow's mass-market applications and the temperature will heat up around PTS.

Might I add, friends, that compliance to the ANSI C++ standard, regardless of the level of the user, is of extreme importance. Things like this especially are troubling when you want to compile programs for scientific computation or even industry-scale programs such as Web server software and other high-performing code.

To make a compiler that doesn't comply to standards is very reprehensible on Microsoft's part. It doesn't matter whether or not you like or hate C++ templates, or that you can or can't use whatever else feature. The heart of the matter is that without standardization, software becomes proprietary and incompatible, and if Microsoft thinks it's OK to not make compliant software, then that could lead us on a very slippery path. This behavior from Microsoft all the more justifies suspicions that they use their monopoly power to work against interoperability and cooperation in the industry.

Plus, I don't buy the argument that Microsoft doesn't have the resources necessary to implement such features in their compilers. Bulls**t!! Microsoft has the most money in the entire world. Plus, they have a lot of very bright people there. As well, if the GNU compiler and other open-source compilers implement full compliance, or at least better compliance to the standard, then can't they use the source code from those implementations as bases from which to weave those features into their own compilers?

While I agree that people usually tend not to care whether or not advanced language features are there in the compiler, if the software is not compliant with standards, then there really is no point in using it because it might not give you either the power or the flexibility you need when you need it.

Then again, might Microsoft be just getting all of us ready to pay through the nose for "upgrades,", i.e. withholding features that they can very well put in to this software when instead they're going to make us wait and pay again? Maybe the best course is to wait out a few more versions of Visual C++, and keep on using what you have in the meantime. This way, when you're ready to upgrade, less money will have been given to Microsoft, in total, than it deserves.

While you have some very valid concerns, you aren't looking at the whole picture.

First, While MS does indeed have the money to put into doing anything it wishes, like most companies, it allocates a certain number of resources to do a job and can't just throw more people at it whenever it wants. Those people are already committed to other projects and we all know that hiring compentant new people, especially in the compiler design arena is difficult.

Further, it seems clear that MS really is stretched thin on resources, since they can't even get all the .NET features into VC that they want. For instance, VC7 will ship without a WinForms designer because there weren't enough resources to get that done. Clearly, you are attributing to malice that which has other explanations.

(snip)
Ronald's a great guy, and he's very earnest and up front. But I think he can be a little blinded by what the Microsoft culture feeds him at times. I can't imagine that he would say that the compiler is the most conforming or even second most conforming, since he knows it's not even close. That comment must have come from someone else.
(/snip)

Erik, I enjoy your style

As I recall, using my admittedly non-photographic memory, is that during the discussion about compiler conformance, the majority of comments were coming from another MS program manager, and not in-fact from Ronald.

The discussion went something like: (feel free to jump in here at any time Chris)

If you look at *all* features that should be in a compiler for true compliance, Microsoft is way, way up the list, either with the largest number of covered features, or maybe second in the list. The community however doesn't focus on the overall landscape of compliance, but zone in on particular features in the spec that they would like to see implemented (their favorites), and Partial Template Specialization was specifically mentioned here.

There's no question that they would like it to be in there, and I got from Ronald in particular that this was very high on his list of important features.

On a personal note, I certainly fall into the templates are interesting group, but professionally discourage their use (unless really really justified) because it makes the code written unmaintainable by 90% of the already ridiculously hard to find C++ developers out there.

I know the response to this is that *real* C++ developers should know all of C++ intimately (including templates), but that is unfortunately not reality.

The 90% / 10% rule is a red herring. How many developers who _use_ ATL really understand templates ? What percentage of them understand the Barton and Nackman Trick that ATL plays with templates ?

The fact is that a developer does not have to fully understand tmplates to make good use of a template library - but the compiler definitely _does_ have to understand them.

The problem isn't that VC++ does/doesn't do feature X or Y, it is what it does in comparison with other compilers. If VC++ doesn't support something that most other compilers do, then it is a problem - people happily using that feature will find they have to "port" their (correct, standard) code to VC++ instead of just build it. My impression is that VC++ template support is now definitely lagging in this way.

Whether or not you can hack around the lack of partial specialisation to get STL (or whatever library) working is not the point - if VC++ is the only compiler which requires that work, it may be that you just don't support VC++.

Rightly or wrongly, the fact that MS clearly invests a lot in producing non-standard extensions to C++ before it has implemented the standard parts of the language, gives the impression that it is not interested in portable code - and if you are trying to write portable code that seems to imply MS is not interested in supporting you.

Perhaps if you don't care about writing portable C++ then everything is fine - but then you also must not care about _using_ portable C++, because some of the small percentage of developers writing portable code are writing libraries like STL which many others use.

My worry is that among the minority complaining about missing "favourite features" are actually many of the gurus who write the libraries - and if they finally give up hacking their library to work around VC++, the rest of us are without not only feature X, but also library Z (or at least all later versions of it).

A final note - I don't think templates are that hard, but that most people haven't been able to learn them because of lack of compiler support. If you get an example out of a textbook and the compiler just gives an obscure error - _then_ it is hard to learn.

A few years ago when learning C++ I found templates very frustrating for just this reason - with g++. VC++ (v4) was wonderful by comparison, all of a sudden my textbook code worked. Pick up a current textbook and try with current versions of those compilers, and it would be the other way round.

There is no question that Microsoft has a responsiblity in their position of market leadership in this space to actually 'lead', and to me that means that they should support the latest features of the language including templates and PTS.

Tony Goodhew has come forward and set the record straight (thank you Tony) regarding the appearantly incorrect impression that both Chris and I were left with after our meeting, and so it appears that as far as compiler conformance is concerned, MS still has a long way to go.

FWIW, I think that having VC++ support portable code is important to Microsoft, at least in having that code portable to Windows

I'm not party to the research on which Microsoft makes its product decisions, but I'd have to believe they factor the Guru's in highly when considering their next steps. At every insider's meeting I've been party to Microsoft listens very, very closely to the opinions expressed.

Has anyone used a third party replacement compiler like the one offered by Intel? I'd be curious to know how popular something like that is, and whether it offers a solution to this while still allowing use of the VC IDE.

PTS isn't in VC.NET. Sorry. Frankly its embarrassing to many of us. Our compiler team had a ton of work to do this time around and we simply won't be able to do it.

We do have a new STL, still from Plauger. The only place where we really needed it for his library was for bitset<> and we have a workaround for that template.

We _really_ want to do this, there are other factors in place which prevented it this time.

The claim about "the most compliant compiler" I believe came from one of our marketing guys that was in the meeting who, as I recall, said that some external company ran some conformance test (I think from Plum Hall, or Perennial...don't remember who) which had the VC6 compiler at the highest or second highest in percentage of passed tests. Something like 94%.

That is when we pointed out that this number is somewhat artificial because to the person who needs a feature that the failing 6% tests, non-conformance is a big issue.

I may have a few of the details wrong, which is why a reply from Ronald would have been better since he works on the compiler, but I think the general gist of what was discussed is conveyed here accurately.