Interview with Stanley Lippman, Mr. Visual C++ 20
Bender writes "Stanley Lippman, who is best known for his work on the C++ language, recently became the head honcho for Microsoft's Visual C++ product. This is a link to a recent interview in which he discusses standards conformance and Microsoft's policy towards C99."
Favourite Quote: (Score:2, Insightful)
Hardly news, guys.
Obscure? Theoretical? (Score:4, Insightful)
How can the 'export' keyword be considered anything less than highly useful? It allows template classes to be separated into a header and an implementation file. I've wished more than once that that was implemented.
The GCC take on 'export' is this:
Supporting the export keyword is certainly a goal, since it is a very valuable feature, and mandated by the standard. found here [gnu.org]
On Visual C++ as a Windows development platform (Score:4, Insightful)
Speaking as a professional who uses it every day, but also others...
VC++ produces pretty good output compared to the field. If the optimisations in VC++.NET work as well as they should, it's likely to maintain that position for the foreseeable future.
However (speaking only of VC++ 6 now) it has numerous rather pathetic bugs and lots of needless standards non-compliance. Nearly all other major C++ compilers do much better on both the "irritating bugs" and the "supporting portable code" scales. These rather taint the package.
Most of the gratuitous incompatibilities are as a result of its continued support for MFC, which is by far the worst mainstream class library I have ever seen. Alternative libraries (such as Borland's VCL or Trolltech's Qt) are considerably easier to use and more powerful. However, many programmers out there learned their Windows programming through either MFC or the Win APIs it fairly directly wraps, so it has a familiarity advantage to those people.
Like the compiler itself, the version of Dinkumware's standard library that shipped with VC++ 6 is riddled with rather pathetic bugs. It also has some severe performance problems when compared with alternatives such as STLPort. In fairness to them, that version of Dinkumware's library was shipped before the C++ standard was finalised, and they released a much improved update shortly afterwards. The fact that MS chose not to supply it in a service pack for VC++ is fairly despicable, but hardly Dinkumware's fault. It should be in VC++.NET.
As far as developing for Windows goes, there is plenty of support there, but it's all a bit too tied in to MS' own technologies and doing about 75% of a good job. The built-in wizards are heavily MFC friendly, but the code they produce is pretty ugly at best, for example. We rarely find anything beyond the basic resource editors to be helpful at work, as far as Windows RAD work goes. The basic VC++ IDE is nice, though, with a good editor and all mod cons.
So, in summary, it produces decent enough code and has a nice IDE, but the number of bugs and gratuitous incompatibilities and the poor libraries make it far less appealing. Given a choice, I'd rather go for Borland's C++ Builder, which produces output of a comparable standard but is far superior on all other counts IMHO. The only thing that would make me choose VC++ is working on a team with lots of Windows API experience behind them and little or no prior exposure to Borland, in which case the familiarity would probably outweigh the disadvantages.
Keeping options open (Score:3, Insightful)
That's what all the Visual J++ developers thought, too, until MS canned it and they had nowhere to go. Smart guys stick to standards and minimise dependencies on specific products as much as possible. Anyone who's been dropped in it understands this. Anyone who hasn't is like a driver who thinks it's safe to be 5m behind the car in front at 70mph. Usually he's right, and then one day he's dead. The only reasons to use product-specific features are necessity and laziness, and only one of those is smart.
Sticking to a standard also has benefits in terms of training and team development. If everyone's coming from the same playbook, life is much easier. Some of the hardest people to work with are those who think that Visual C++ and C++ are the same thing, and want to know where all their MFC, ClassWizard and other toys are when they have to develop an application for the Mac or Linux using some other C++ compiler.