Microsoft Tells What's Next for C++

Microsoft Tells What's Next for C++

  • Comments 64

 By chance,  are you among those who think that Microsoft is leaving native development in general and the C++ programming language in particular behind? You better watch this interview to Ale Contenti, Principal Development Manager with the Windows C++ team at Microsoft.

Click here to play this video

[Can't see the video player in this page? Try Channel9]

 

The interview was made by Christian Binder, Platform Strategy Manager with Microsoft Germany and Development Practices track owner in the still recent TechEd Europe 2010. Ale talks about key differentiators C++ offers today to developers, before other programming alternatives, but he also clears up any suspicion about Microsoft commitment to the language created by Bjarne Stroustrup by listing the efforts Redmond is doing for its evolution.

Ale had also delivered a session on ALM for C++ in that same conference.

  • Have you ever tried creating a new class in VS2010 ? if you create a new class on a folder/filter inside the ide, the class header and implementation files are added to the root of the project!! you have to go and fix this *each* and every time! what a mess and waste of time!

  • I also long for features present in VC6, like being able to resize the main menu to a small sqaure in a corner, being able to display full paths (not just the filenames) as titles in code windows, erase by columns instead of lines in the editor without having to switch to Brief editor mode etc.

    But I digress, we all know what's needed: a "Visual Studio development reset" similar to the Vista development reset that occurred in 2004. Toss as much of the bloated code as possible and rewrite it in the new C++ 11.

  • For a good summary of the problems with C++ for VS2010, this is probably the best collection I have seen:  social.msdn.microsoft.com/.../a6d500a2-d4ea-43e2-8460-9283ea5c1d89.

    I really hope SP1 can fix the issues mentioned there (and soon).  The overall C++ experience in the IDE is not even close to VS2005 and is disappointing given the high cost of the tool.

  • Oh - and yes - the new Help system is downright awful.  A big step back from VS2005.

  • To our valued C++ community,

      We must say a HUGE ** THANK YOU FOR SPEAKING UP **

      Introducing myself, I'm Diego Dagum and I'm your C++ Community PM and I'll be your link with the Visual C++ team.

      I had been thinking days ago, while organizing my communication agenda in my first week in this position to enter a post introducing myself, but given the degree of attention this thread generated, my self-intro has better chances of being read.

      Regarding your feedback (and thanking again for taking the time and diligence to provide it) I'm compiling your comments and thoughts in order to elaborate the answer you guys deserve. The fact is that there are certain things I could answer directly. Some other things (as some of you guys guessed) are a bit out of the scope of my team, yet under the scope of some other teams at Microsoft but I need to involve them rather than answer on their behalf.

      For sure, the bottom line here is that your opinions matter to us, and you guys matter to us as well. I'm going to start a regular communication with you guys through this team blog http://blogs.msdn.com/vcblog, through our twitter http://twitter.com/visualc, through our C++ Dev Center in MSDN msdn.microsoft.com/visualc, through events and other channels we'll be enabling.

      Repeating here: I took your feedback guys and will address your concerns.

    Thank you!

    Diego Dagum

    MS C++ Community PM - Visual C++ Team

  • Diego, thanks for the intro.  Please don't neglect the many comments on the page of the Channel9 video itself.

  • I don't have a problem with slowly phasing out GUI development in C++. MFC is certainly not my best friend.

    I think it was a bad decision to "upgrade" MFC with the BCGSoft feature pack. It has lots of drawing quirks. The time should instead have been spent on improving C++ support in Visual Studio. It gave false hope, and maybe caused some to make wrong decisions.

    Also I don't mind that C++ is not a first class citizen in the Visual Studio ecosystem. I can understand that other languages are better suited for testing new approaches and technology.

    But I really think that C++ is loosing in the catching up game:

    - Large projects in C++ (1 MLOC) really suffers in new versions of Visual Studio. Many of the code navigation tools are simply not made for such projects.

    - Refactoring tools for C++ are simply not there.

    - Intellisense only works properly when using a third party plugin like Visual Assist.

    - Compiler errors when working with templates means looking through several hundrds lines of compiler error details. Why not just show where the template is used, and where in the template the problem occurs ?

    This has not changed since VC6.

    But your compiler is wonderful, and I really look forward to start using the "auto" keyword.

  • > Something like the QT framework would be awesome.

    Please don't make one more "C++ framework"!

    It's much more advantageous from a commercial point of view and is much more reasonable from the viewpoint of many programmers who use Qt for Windows to give official support for Qt out of the box (like better Qt plugin for VS) and to contribute in Qt (note Qt future with MeeGo): patches and custom solutions such as custom widgets would be much more appropriate.

    Also I'd be very happy if MS makes efforts to (continue) improve STL (shipped with VC++) and to optimize Boost C++ Libraries for Visual C++ compiler (as any other open source C++ based libraries).

    Project managers – do not afraid to support C++ open source projects (especially popular libraries). If MS won’t do it than others will and Visual C++ (and Visual Studio as C++ IDE) will slip to the margins of popular C++ toolchains.

    And please, make a better C++ support in VS – Qt Creator is watching for You 8)

  • Any insight on what libraries and frameworks are used by Microsoft developers for products like Windows, Office, SQL Server, etc.? These products are written (mostly) in native code and I don't think they work directly on top of the Windows API or use MFC, do they?

    I also heard several times that the Windows teams do not use Visual Studio, what about the other teams?

    I think C++ has a bright future as this is a general-purpose language designed to solve a broad-range of problems and that the language is still evolving. This is the kind of language once you know it that you can (but not must) use to do everything. I understand that Microsoft want to promote their own development stack but they are doing it against other more universal languages like C++ (which they are turning into a niche language) - This is a dangerous bet that I think may have some bad consequences for Microsoft.

  • "Have you ever tried creating a new class in VS2010 ? if you create a new class on a folder/filter inside the ide, the class header and implementation files are added to the root of the project!! you have to go and fix this *each* and every time! what a mess and waste of time!"

    Yes, that is very annoying.

    Honestly one of the huge things I don't get is why Visual Studio doesn't have better syntax highlighting or file navigation.  Look at Visual Assist.  Honestly Visual Studio is great, but it completely neglects some of the most simple and obvious visual enhancements.  If you can implement runtime squigglies I don't know why you can't offer better syntax coloring options.  Why should I be forced to purchase a third party tool to bring your text editing capabilities in line with pretty much any other IDE for any other language in terms of basic text manipulation and file finding?

    I ask this because in many much more fundamental and complicated ways Visual Studio is superior.  It seems odd that it fails on the simpler topics.

  • [Rolf Kristensen]

    > Compiler errors when working with templates means looking through several hundrds lines of compiler error details.

    That's a feature, not a bug. Template error messages are notoriously ugly and verbose for a good reason: all of those lines are explaining the "template instantiation context" which is often critically important to understanding the cause of the error.

    (I'm not saying that VC's error messages are optimal; there's tons of room for improvement. It's just that the template instantiation context is much more than annoying noise.)

    > Why not just show where the template is used, and where in the template the problem occurs ?

    That is, in fact, what's being shown. The template instantation context is "where the template is used". If the error occurs in template Foo, the template instantiation context consists of Foo's template arguments (which you need to know in order to figure out what types, etc. are involved in the error) and who instantiated Foo (which you need to know in order to figure out where Foo's template arguments came from). If the code that instantiated Foo is itself a template Bar, then information needs to be emitted for Bar, and so forth. The top of the error message is "where in the template the problem occurs", the bottom of the error message is where the chain of instantiations began, and the actual problem that you need to fix could be anywhere in between.

    [Marat Abrarov]

    > Also I'd be very happy if MS makes efforts to (continue) improve STL (shipped with VC++)

    Dinkumware and I are paid to do exactly that all day long.

    > and to optimize Boost C++ Libraries for Visual C++ compiler (as any other open source C++ based libraries).

    We've had Boost running in our compiler test suites for quite some time now. We also pay special attention to compiler/library bugs that affect Boost. (Boost developers tend to submit very high quality bug reports!) And I've begun monitoring the Boost mailing list for VC-specific issues.

  • [Stephan T. Lavavej MSFT]

    > That's a feature, not a bug

    Well the feature could be improved, just like the other features I mentioned :). For 9 out of 10 cases it is easier to look at the code, than looking at the compiler errors when dealing with templates errors. But the two very important locations (what line is the template used and at what line does it break insíde the template) is hidden away among these 100 other important lines.

  • Well, conceptually, the template instantiation error is little more than a "compile-time" call stack. Couldn't it be shown as such? Provide a similar UI to what you use in the debugger when showing the call stack, to show the "stack" of template instantiations?

    Just tossing that out there. As Rolf says, it could be improved. (Although I certainly agree with STL that there's a good reason for its verbosity, it could be presented better. Perhaps not by string formatting, but by presenting it differently visually.

  • Actually, I find the VC template error messages more intuitive than GCC's.

    In general, they ARE ugly, but that's how templates work. You won't find this uglyness in other languages, but neither will you find what you can do with the templates of C++. And I think VC doesn't do the worst job in points of uglyness.

    Having said that, I think VC needs more attention to detail. For example, the header completion feature is nice, but I always have to write the finishing " or > character, which is unnecessary. nullptr ist nice, but as I have seen at Connect, seems to not be completely conformant. Rvalue reference are not up-to-date either. It is those details who cause a lot of trouble and they are not fixed in SP1.

    And yes, the IDE is annoyingly slow. I have always been pointing out that it's not a performance problem in the sense that operations take too long. The problem is that the GUI IS NOT RESPONSIVE, for example when starting a build. Given that the build is done in a separate OS process, this is completely un-understandable.

  • The compiler, the libraries and the debugger are top notch, even if the IDE has issues. Better than MinGW and good enough when compared to Intel.

    I would also vote for MS official Qt support in VC++ or helping the Qt team with integrating CDB and the build chain in Qt Creator.

Page 3 of 5 (64 items) 12345