Slashdot stories can be listened to in audio form via an RSS feed, as read by our own robotic overlord.

 



Forgot your password?
typodupeerror
Microsoft

Interview with Stanley Lippman, Mr. Visual C++ 20

Posted by Hemos
from the what's-happening-with-visual-c++ dept.
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."
This discussion has been archived. No new comments can be posted.

Interview with Stanley Lippman, Mr. Visual C++

Comments Filter:
  • Favourite Quote: (Score:2, Insightful)

    by __past__ (542467)
    Posted 14 Nov 2001



    Hardly news, guys.

  • by leifw (98495) on Wednesday January 16, 2002 @10:04AM (#2848011)
    Microsoft's goal is to have a 'competitively compliant' compiler - meaning it won't be 100% compliant. There are a couple of features of the ANSI/ISO standard (for instance the 'export' keyword as applied to template classes) that won't be implemented because they are considered by Microsoft to be obscure and, at this stage, theoretical.

    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]

    • To me, the export keyword is a "nice to have", and not a "must have". Personally, I'll consider export a viable alternative to defining templates in the header when a broad range of compilers support it. Unfortunately, it seems that most implementations will be lacking it for a while longer. The compiler that is closest to supporting it, AFAIK, is Comeau [comeaucomputing.com].
  • Repeat post (Score:2, Interesting)

    by Utopia (149375)
    First, this was posted earlier Visual C++ and C++ Standard [slashdot.org].

    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.
    • 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.

      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.

    • 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.

      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.
  • From the text: "he's developed against many different platforms."
    Maybe that's how you feel when Windows is your OS :-)
  • Stanley is very clear on the future: "I believe Visual C++ has a prosperous future". He has met the Visual C++ team and says they have undeniable enthusiasm and energy. His goal is very simple: "I want Visual C++ to be the C++ implementation of choice". Stanley's personal goal is to have C++ developers choose Visual C++ not only because of the tools and platform, but because it's the premier implementation of the C++ standard.
    I have only dabbled a little bit in C/C++ (I primarily write Python scripts and modules and some PHP), so please excuse the ignorant tone of the question... Is Visual C++ that great of a C++ implementation? On the Windows side of things, how does it compare to other C++ compilers available (like from Borland or Intel)?
    • by Anonymous Brave Guy (457657) on Wednesday January 16, 2002 @05:02PM (#2850929)
      Is Visual C++ that great of a C++ implementation? On the Windows side of things, how does it compare to other C++ compilers available (like from Borland or Intel)?

      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.

      • Thank you for the informative answer, I'll keep your points in mind if I do venture a little further into Win32/C++ programming.

        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 :(

Real Programmers think better when playing Adventure or Rogue.

Working...