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.
Re:MS puff piece (Score:2, Informative)
to bless VC++ with the C++ logo by
waving Lippmann's name over it, but it's quite
clear in the text of the article that MS has no
intention of implementing C++ or of being
interoperable with conformant implementations of
C++. VC++ is in fact being crushed in the vice
of embrace-and-extend. They don't WANT you to be
able to write portable code, and it's getting
harder every day, not easier.
I'm repeating myself on purpose because
it's true and important, and i don't care
about my karma if the truth is at stake.
Re:MS puff piece (Score:1)
> it's true and important, and i don't care
> about my karma if the truth is at stake.
OMFG
Two identical posts, the first is a troll, and the
second is insightful.
and the guy is such a genius
finish.
Dude, were did you get this 2x trick? it is really
working
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]
I'm not holding my breath (Score:1)
Repeat post (Score:2, Interesting)
Second, I develop in VC++ but I don't care if it is standard compliant or not. It is a windows only development solution and will probably remain so. There several others compilers which would let me write STL or Loki compliant code if need be. The only part I hate is some of the junk code generated by the wizards.
Third, I disagree with Microsoft that when they export on template classes is obscure - not that I need/use it. Its a hard to implement feature considering the number of compilers which have added this feature.
Re:Repeat post (Score:2)
Although Comeau Computing's [comeaucomputing.com] C++ compiler is due to include support imminently, according to their web site. Their compiler is far ahead of most others in standards compliance, however.
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.
Re:Keeping options open (Score:1)
But I don't think VJ++ developers will be left hanging for long. Part of Microsoft's success with Windows has been wooing developers to create applications for the operating system, thereby increasing Windows' appeal. With the Microsoft
Re:Repeat post (Score:1)
Why do you separate standards compliance and windows programming? Standards compliance affects all of us. It is unfortunate that MSVC++ is both popular and non-conforming, because programmers are both limited and frustrated by it.
What I want to happen to others and myself:
They try to write good, re-usable code and, more importantly, use the C++ language to its fullest extent. It works because the programmer knows how to write C++ code (which isn't asking too much).
What I don't want to happen:
After a few hours spent arguing with the compiler, the programmer says "screw it" and uses some sort of half-assed, possibly VC++-specific approach.
I don't know about you, but I like being able to use the standard library to its fullest extent, and I don't like being held back by a poor implementation. It simply wastes your time. You end up saying "well, it should have worked, but now I have to spend some time figuring out why it didn't work and what I have to do to make it work on this implementation."
Compliance to the standard isn't a cross-platform code issue with me. It is about frustration. I don't want excuses, I want it to work. Granted, I can accept some deficiencies, but it's clear to me that MSVC++ needs to get its act together to make it less of a pain to use.
Developed "against" many platforms? (Score:1, Funny)
Maybe that's how you feel when Windows is your OS
Visual C++ a premier C++ implementation? (Score:1)
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.
Re:On Visual C++ as a Windows development platform (Score:1)
I have not used Visual Studio suite nor the included languages in a while, since my of my current development and scripting is for the Solaris and FreeBSD servers at work. I agree that the IDE is pretty nice... but I ran into irritating bugs or nuances with the VB and the general Visual Studio IDE. Having worked a little in the VS.NET IDE, I think is a little bit better, but way to sluggish on my machines :(