File size

File size

File size

File size

File size

239.8 MB

The last time we got the chance to talk to Mohsen Agsen, a Microsoft Technical Fellow who runs the Visual C++ engineering team, he put forward the notion of a renaissance taking place in the native world. Shortly thereafter, we created the catchy C++ Renaissance mantra. (Mohsen is great at building metaphors in real time. See if you can identify a few new ones in this conversation!) The reception to C++ Renaissance message has been great (and, in some sense, unexpected). Now that some time has passed, let's revisit this meme and get a sense of what Mohsen really meant by a renaissance taking place in the native world, and C++ specifically. Is this renaissance taking place in the industry at large, or was Mohsen focusing on what's going on inside of Microsoft? Maybe it's both (at least from the native perspective, given Obj-C, C, and C++ usage outside of Microsoft).

Mohsen works in the Microsoft Hawaii office, located in Honolulu on the great island of Oahu. I was recently in Hawaii for the ICSE 2011 conference in Waikiki, so I was able to visit Mohsen to continue our conversation from a few months back.

It's really easy to talk to Mohsen—he's passionate, engaging, curious, and, most importantly, honest and open. There's no marketing in Mohsen. He's all engineer. When I asked him about what he thinks is needed in C++ and VC++, specifically, he answers, but he also asks YOU for your opinions on the matter -> How do you use C++ today? Are you interested in using C++ for building high-level UI-centric and data snacking apps? What do you want the VC team to focus on? Please answer these questions in this post. Mohsen and the VC product team will be looking for your answers here, so speak up! And thanks for asking, Mohsen. Very cool.

Tune in. Enjoy. (And remember to tell Mohsen what's on your mind regarding what he asks you in this conversation.)

any news about the Data Parallel Extensions for C++ ? I remember Stephen Toub or somebody in TC group has talked about it for several times.

a seperate release for C++ ? if its still VS and can be integrated into the full VS then OK, if its something like WebMatrix then not so good. I am a mixed-mode developer and coding many different things, my sln always has csproj and vcproj in it. the 'Windows C++' (by MJF) should always be the "Windows SDK" right ?

p.s. its a good chat but not really that 'deep' huh, should be a post instead of this show IMHO.

@felix9: Going Deep does not require a whiteboard - the focus of the "show" must always be below the surface, which could mean breaking apart the Windows kernel or breaking apart the history that's led us to where we are today with technology x and how today's decisions will lead us into the future. In my opinion, this conversation effectively accomplishes the latter with respect to native code (not just C++). That said, if you want a deeper technical foray into specific C++ subject matter, then watch Herb's latest Q&A.

We're going to continue to go very deep into the native world on C9, to be clear (whiteboards, code, etc - like STL's great lectures, but beyond the STL).

Conversations like this one with Mohsen are important to a) showcase the thought leaders who drive technical direction and b) provide you with high quality conversational content that focuses on technical subject matter. In this case, it's great to hear Mohsen's perspectives on C, JavaScript and even Go. Most of the time is spent talking about C++, of course, and there are some excellent nuggets of deep wisdom and information here.

C

PS: Please remember to answers Mohsen's questions! He wants to hear from you.

Getting a separate product (e.g. not integrated in VS) for C++ would be an interesting idea as a lot of developers (including myself) seem to miss the VC6 days in terms of performance and reactivity of the environment. The IDE used to be blazing fast, would love to get that feeling back!

I'm using C and C++ for system and application developement (both client and server) and here is what I would really like to get in the future:

- a modern UI library based on DirectX/Direct2D with some tooling support inside VS and the ability to run applications based on this library out-of-the-box on every version of Windows (just like with MFC).

- a C++ layer on top of the Windows Web Services API to get more functionnalities and improve productivity, the ability to run applications based on these APIs out-of-the-box on every version of Windows. On the server side, IIS support would be great (easy deployment of services) as well as a mini-framework with some core features like caching, session management, database access and so forth (no need for something as rich as asp.net).

- some improvements in terms of application architecture and deployment (COM is huge but it has not been evolving recently) with appropriate support inside VS. The ability to build and deploy seamlessly the components of a stand-alone application.

Besides, I have a tremendous amount of C/C++ code that I would love to run on the phone and on the Xbox, but that's another story

Using it for a large Windows Application that is mixed mode. Our UI is all native and MFC based, but would like to slowly evolve into using WPF so our application could be "prettier". There was a lot of discussion about that years ago, but all I have seen is very simple examples. I know you have learned a lot when transitioning Visual Studio itself to use WPF, is there any additional wrappers to help MFC people make that transition?

Also looking to add more async in my application and would like to see more async built into the language, like in the future version of C#.

Misc: Spatial Libraries and operations in native C++. Would like to create better reports for my users and would like a framework for this. Direct2d wrappers like mentioned by previous poster.

So for me Visual C++ needs to be with Visual Studio as a whole, because my application is mixed mode and I also have other managed applications too.

I have used C++ for a business application on the server end, that just needed to handle lots of requests for lots of different clients. This talked to a database and did some mathematical calculations, plus it parsed various scripts (Python etc) from clients.

So this really wasn't a special C++ requirement type project, however I do think it had benifits from the extra control factor you have in C++ over managed languages.

I enjoy writing C++ a lot, more then .NET coding, which is where I started. :) Love to see loads more content on the C++ front. :)

1. I use C++ in the MFC context. We have many MFC based apps that are being maintained, and at times added to. We do have .NET apps, but most times they are segregated. If there were a separated VC++ we could live with that. 2. as for data access, it would be great if there were a standard XML library. Since there isn't, it would be nice if MFC would have XML functionality similar to .NET. While there is XMLlite functions via WinAPI, a C++ based portable solution would be better. We have to target Win2000 which isn't supported with XmlLite. A MFC based XML serialization would be nice instead of using CArchive and its 'magic' to output a proprietary binary file. 3. +1 for a modern UI library. While MFC is doing some advancement on that front, will there be a native replacement or supplement to MFC? Or as previous poster mentioned, a path to use WPF from MFC? Thanks, and appreciate the video.

From my side, I use C++ more for (self included) learning and teaching core language/STL, parallelism and graphics (GL, DX, CL), so I still on my old post on the Goodhew interview: a minimum Visual C++ IDE with Extensions enabled (one step further Express), plus a better modularized/decoupled Windows SDK, so we don't have more (or mitigate) the crashes with handling many versions of WSDK (like the headache we had with the latest SP1 for VS+WSDK).

A simple UI with direct2D would be awesome, but if you guys improve the interoperability already existent in Ribbon would already begood.

Am I interested in using C++ for UI or data-driven apps? Why yes, I am. Am I going to start using MFC for it? No. If there was a UI library of the quality of the new PPL, then I would be one very happy bunny. Double points if it can take my Direct3D9/10/11 Device for hardware rendering.

The thing about WPF interop is that it brings what you want to interop it with into managed code. That's great- if you want to write a managed app, extended by <insert technology here>. But I'd really rather just write a native app extended by WPF, because the only UI library provided is MFC, and it's really past it's expiry date. When you go into WPF then you lose control- you don't write your own main loop, WPF tells you when to render, etc etc, which is definitely not what I'm looking for as a native developer to structure my whole application that way, because I need a UI library.

What I'd like from a UI library is, not just a new naming scheme and new interfaces (like no HRESULTs), but also control. Here, process Window messages. Now render the controls, because I rendered my 3D content and I'd like you to render on top.

In my opinion, definitely the biggest problem with the Standard is that it tries to be compatible with too many people and too many platforms, and consequently, it just doesn't have the breadth of platform-specific features that I'd like. For example, if I want an unordered_map, it's great that it's in the Standard, but really, I could have just grabbed it from Boost. I'd much rather that the Standard focused on providing facilities that aren't already generic- like directory and other filesystem support, or UI, or networking - where you'd have to re-write for every target platform. The new Standard thread support is a good example.

As for language, definitely the biggest thing I'd like to see from the language is the removal of header files. I used to write a lot of template-heavy code, and it was sweet, but eventually I just stopped because making the declaration and definition orders work was just too much hassle. Not to mention the duplication of having to write the class prototype twice, and having to keep them in-sync, and the nasty readability penalties of having the code out-of-line. I'd rather see something done to eliminate the compilation model than have Concepts, or even variadic templates and rvalue references.

The current error message system, I think, could be improved upon by judicious use of static assertion and type traits. For example, attempting to use a std::map with a non-comparable key type will give a nasty and only very vaguely readable error right now. However, it's trivial to write a static assertion that will cleanly error- actually in VC10, not just in a theoretical up-to-date perfectly compliant implementation.

Firstly thanks for reaching out to the community. I hope the reach can extend out to the trenches. Do appreciate the C++ weekly.

I wouldn't view response or lack of here as any indication as to the size/strength of the C++ community. I'm not sure how many really know about this area and still the magazines are all about managed. I too miss the glory days of VC6. I hope some effort is spent to exceed the UI performance that was back then. Can't really use the IDE on a laptop on battery power due to high power consumption. I'm hopeful vNext can have C++ tooling that actually works. Have been unable to use (on x64 OS) Sampling Performance analysis on 32-bit (doesn't work). Instrumentation flat out fails (both 32/64).

To answer some questions. I use C++ is used for application development. Not simple apps, but real down to the metal powerful applications that are highly responsive and mature. CPU power is available where it's needed, namely for audio processing/synthesis and the like and not on higher level language interpretation.

Having recently coded a fun application in C++, I had ported it to Javascript to run in the browser and essentially consumed a lot more power in the process. For efficiency and performance it still needs to be C++.

Yes there are cases for web applications, etc. where using javascript/html5/etc. are efficient and quick. Yes we're seeing the trend for simple/basic things that are good on phones/tablets, It makes sense to use the appropriate language for those cases. Still someone has to code the managers in managed code or interpreted languages

Every modern C++ library should use exceptions. I wrote an ODBC wrapper library for the company I work for now and by switching to that from various C style wrappers, we found old SQL that had never even run before due to syntax errors... It's well known that most people just don't check return values and that just confirmed it for me.

The C++ standard needs some serious library work. It's great that threads etc. got attention for C++0x, but boost::asio really needs to become a standard library as soon as possible. It's just plain embarassing that C++ doesn't have a built in networking library yet.

I strongly agree with DeadMG above regarding static_assert usage. All these kind of tricks should be used now, to make error detection easier and faster.

First of all, this is what we do: we are developing applications that control sophisticated, laser based, optical measurement systems that acquire 100 MBytes/s and more of data, processing it real time, storing, analyzing and visualizing it. We currently use DirectShow (for dataflow parallelism of the data acquisition), DirectX (for live video and overlay), ATL (for component based architecture), MFC, boost, OpenGL (for 3D visualization) and .NET (interop via COM).

I appreciate the work that was already done for VS 2010 like lambdas, rvalue references, the update of the STL to use move semantics, ConCRT, PPL and the agents library, debugging (parallel threads, tasks, profiler). This is great stuff! We are currently looking into using ConCRT and PPL of off-load work from the UI thread and maybe agents to replace DirectShow for the acquisition part. And we are looking into replacing the UI part written in MFC by C# WindowsFormsor WPF.

Comparing development in C# / .NET with native C++, our experience is, that productivity in C# / .NET is much higher (1.5 x to 2 x) because of tools and libraries.

What we miss most in VC++ 2010 is: code coverage, unit tests, refactoring, support for XML comments, code metrics. I know that for most of these there are third party solutions but having it all at your fingertips and fully integrated like in C# is a great benefit. I hope the rumors are right, that VS next is addressing some of these and I hope it will be available in VS professional and not only in ultimate, which is unaffordable.

The other topic, which is at least as import, is libraries. Mohsen's statement (joke?) about BCL == STL touches the core issue: STL provides great containers and algorithms that are comparable to or even better than the BCL versions. But what we need is much more. Look at code created by the MFC app or ATL simple COM object wizards and compare it to C# code (Windows Forms, COM visible objects). The C++ version is not C++ (at least not modern C++). It is cluttered by macros (MESSAGE_MAP etc.), unsafe types (WPARAM, LPARAM, BSTR, SAFEARRAY), needs a separate language (IDL) and lots of boilerplate code. In contrast the C# version is succinct, seamless and uses the CLI types (string, arrays) decorated with few attributes. Writing COM objects in C# is much more productive than doing the same with ATL / C++, set the non deterministic destruction and deployment (where to put the type library, reg-free COM) aside. The same is true when comparing Windows Forms and MFC.

What is desperately needed are STL / PPL / boost like libraries that use RAII for resource management, exceptions for error handling, containers that are STL compatible and that are named consistently.

You have invested lots of resources for designing the .NET framework. Why not take this investment and port parts of the framework to native C++? I am not talking about interop or wrapping it, I am talking about native C++ libraries with modern interfaces that do the same thing and use similar names for classes and types.

Top priority list would be:

File system

network (UDP, TCP/IP, HTTP)

registry access

XML parsing and writing

serialization (binary and XML)

UI (Windows Forms or WPF like)

Instead of the .NET reference types use C++ pImpl pattern with std::shared_ptr to the mplementing class (like task<T> of the ConCRT extras sample pack). Then we get performance, safeness and deterministic destruction for free.

Speaking of task<T>: throughout the framework use a consistent model for asynchronous method calls, like TAP for .NET. Implement a full blown task<T> type like .NET's Task<T> (the version of the ConCRT extras pack 0.4 is a step in the right direction but error handling, proper cancellation support and support for scheduling continuations on the UI thread are missing). Implement all asynchronous methods by returning task<T>.

That would be a huge productivity boost! And having that library on Windows Phone, andWindows XP - Windows 8 would allow developers learning it once and apply it everywhere.

C + + needs a decent graphics library, which is really object oriented, unlike that monster now called MFC. To take advantage of the knowledge that many developers have Visual C + + using MFC, could be created a new version of MFC, MFC a really OO.

We use c++ for our very large desktop MFC app. Whilst I love the new C++ features in vs2010, the biggest issue for me is the performance of the app. It just feels really, really sluggish and is a productivity killer. Not sure if farming off VC++ would help, but I'd love to see VC++ get back to the VS6 performance.

In terms of the breadth of the language, database access still isn't as easy in C++ as it is in C#. it would be absolutely fantastic to have something like LINQ available natively (as long as it was quick).

Yes, I was disappointed that concepts didn't make it into the Standard. They would have made templates so much easier to use. I'm happy though that C++11 supports concurrency and has a memory model. I'm glad that Visual Studio incorporated some of the C++11 features, although its support for lambdas is a bit buggy. However I'm very disappointed that Visual Studio doesn't support C++11 concurrency constructs. Wouldn't TPL be easier to implement on top of C++11?

I like working in Visual Studio, but sometimes I have to switch to GCC to do some advanced programming. If there were a version of the MS C++ compiler independent of VS but supporting more C++11 features, I'd definitely use it.

@Charles:Well, I give a test drive to WWS, it's nice and all but with the trouble with SP1 I rolled back the WSDK and not installed it again Would be nice some more text about it, the examples that come along are good, but need a bit more insight on the documentation. More propaganda would help WWS widespread (like examples involving WWS and Windows Phone, sure it will be like honey for bring peoples attention )

But for teaching, I end up using direct sockets plus simple messages, lightweight html/cgi handlers. I'm looking forward for use WWS and OData on server side and HTML5+Javascript on client side for newly courses. The boost have some nice tools to, if VS.next include some tool or help establish a mapping for C++ data serializing and xml binding well be greatly welcome.

(Of course, all implemented in modular way, for the sake of clean VS.next Standard edition, augumented only with the modules you buy/download from VS Module Market (yeah!, like app market))

@Charles: Up until I learned about the new C++0x features, I would never consider using C++ for things like web services or data access layers (the legacy code I have had to work on, which does perform data access is horrible next to ADO.NET, for example), however, I've certainly been considering it lately. I'm not sure if it's necessary, but should you be able to? Yes.

As much as I like C++, the only situation I seem to be using it lately is where we're either on a non-Microsoft platform, or we're doing stuff that involves too much interop (and we switch to C++/CLI), or is downright impossible in .NET (debugger extensions, device drivers).

I would love to see a boost-like (read: mostly header-only) library on top of win32. Also, I wouldn't say no to a mechanism that gives me the same sort of alloc/dealloc performance as .NET (where allocation is superfast and deallocation depends on principle of locallity -- and a bunch of heuristics). IOW: I do not want to be drilling into a 7x24 service to find that it's spending near 100% on its heap due to fragmentation.

Testability (easy to use unit testing/mocking framework) would make for a good 3rd on my list, I guess.

@BartoszMilewski: Remember that VC10 can only be implemented to the draft Standard- as it was at least two years ago. What's likely is that that part of the Standard wasn't ready.

You know, the other thing I wanted to talk about is C. The Visual C compiler doesn't even implement C99- so why are all the new things like WWS ugly C interfaces? I mean, I get that you might want to have one because C++ interfaces like to break, or for language compatibility, but a couple of C++-only headers making it more palatable would make a big difference to me. After all, it's probably not a lot of time to wrap a single library, but when it's every native library, then it gets old fast.

I'm a university student whose major is computer science.So it is a must that we all have to learn C++.Until now,we still code with it.In my opinion,it's quite great and I some kind of like coding with it.(Freaking out!)But I didn't learn it so well so I decided to study it more in my coming summer vacation.In order to find an ideal job,I think C++ is a must.

Maybe this question is a little deep.I think computer language is just the same as foreign languages.As long as we know the grammer we can use it.All we need to do is practice again and again.And after that we can grab its soul and make full use of it.

We have two major engineering/science-oriented applications that we deliver to our clients. Complicated custom ui-elements, 2D graphics (printing etc), 3D graphics. We use(d) win32 - Api and MFC. And let me tell you it has not been a childs play. Lot of pain because of insufficient documentation and trying to hack away the anomalies. We've been satisfied with MS ides though, for example Fortran-compilers and other 3'rd party tools integrate smoothly.

So C++ ui - creation has been a pain....untill we found Qt. I'll have to say that since that, we,ve truly enjoyed the ui-creation. Qt gives us more than we ever could have imagined, nice set of ui-elements that are easy to extend and customize, a sophisticated 2D and 3D graphics programming capabilities, database support, support for xml-stuff and lots more. It is truly object oriented. Nice programming paradigma of signals and slots to allow ui-monsters to communicate. Nice set of tools to produce different language versions of programs. Etc. etc...

So Qt is a new "MFC" for us, we've been porting our programs to Qt and will be ready to start shipping soon. Just keep the visual studio language and standards compliant and you'll give us programmers a chance to use tried and tested libraries to keep our productivity high :).

I'm an OS-level developer, who uses C and some C++ for driver development on Windows. I've also written applications using MFC.

The problems inherent in a language like C or C++ are legion. Bad string handling, lack of pointer validation... THIS is why we have security issues and crashes in Windows. Things like SAL notations are, at BEST, a big fat hack to try to make C++ "safer."

We need to move beyond C++ to languages that enforce safe data environments. That's what C# does... and in my opinion (ignoring the whole .Net part of the language) the C# is a *much* improved version of C++ (more consistent, cleaner, clearer).

WHY prolong the life of C++? It's time to move beyond 1970's computing ideas to the future. Spec# is an even better C#. C++? Wow, dude, that's sooooo yesterday.

I think rab36 nailed it. XML serialization and WCF are tops on my list.A little off topic... has anyone worked with Objective C (iPhone dev)? Is it even possbile to think that something can be done to kill object C?

It's not about the language itself, it's more about ready to use libraries. There are no silver bullets, instead tools that are more or less suitable for the task you are facing. Think about it...it would be total madness to rewrite all those tried and tested C++ libraries in C#, not to mention LAPACK etc. C++ also co-operates almost transparently w libraries, written in FORTRAN etc. And considering evolving nature of C++, new features are being added, language improved I'd say that C++ is a strong keeper for years to come.

Ever given a try for the Qt? I'd say that you will fall in love. You'll also get that unicode string handling goodness. Just brilliant, the best of the best, documentation. And as a bonus...your programs will run on multiple platforms.

So would I use C++ for data snacking applications? No, C# works nicely for that.

C++ for WebService as a Client - Yes, my C++ client hooks to Webservices and I think it was in VS 2003 you could import a WSDL and a C++ wrapper would be generated. Now we are forced to use C# in our C++ app in order to take advantage of the import.

C++ for WebService as a Server - Like someone mentioned C++ - WCF sounds like a great idea.

C++ Data Access - YES!! - Most applications at some point have to access a database on the client or elsewhere even if the application is doing a lot of operations, and .NET type data access is quite nice.

I also think that rab36 is right on the money. I use C++ for a lot of performance based projects that are consumed by .NET projects, many dealing with video, graphics, multimedia, etc. A large majority of these projects would have been better suited being all C++, but with a need for a large amount of (consistant) tooling and libraries, these projects have been .NET centric. It always comes to a line in the sand that a team must choose between productivity (libs and tooling) and performance. I want to believe we can have both.

If I'm reading some of the hints on the VC++ blog correctly about "bringing native to parity with managed", maybe this is where you guys are going. I cry a little each time a customer has a large C++ codebase and they have to pull in a CLR dependency just to create a rich UI. I think there is a huge desire for a modern "high level [rich] UI" for native developers. Not having one, IMO, has seriously stunted the growth of high performance, rich consumer applications on the Windows desktop. If there is a high level rich UI in the works, one should only worry with, "How high level?" Nothing limits the ability of UI platform more than being "too retained" (see: WPF/SL) and/or "too slow at rendering" (see: WPF/SL). In other words, let the developer choose if they wish to participate in how (immediate mode hooks) the UI is rendered.

I am truely excited to see what you guys have in store. I think you guys got a tough job ahead after a decade of downplaying C++ by upselling .NET...but I have a blog ready to sing praises if my current excitment ends up matching reality

Moré focus on the parallel programming aspect of the language. Code templates inside the IDE (both C# an VB have it, C++ does not). Make the IDE faster. 2010 ide is at least twice as slow as the 2008 one. Allow easy integration with Internet explorer. Emphasis on easy, this allows developer to focus on the application while letting a designer to work in parallel on the interface. Of course require applications to be signed.

A bigger focus on modern C++ design. Look at the PPL -- it knows that it's in C++ and takes full advantage of it. It fits perfectly, working exactly as expected. Contrast this with so many of the other C++ offerings at MS which rely on or try to mimic COM. COM is not a good or friendly way to write C++!

A better way to use SIMD intrinsics. They're kind of a pain right now and I think it could be made much much better, to express it as native C++. PPL is hyped as a way to better utilize your CPU, while a lot of people are still missing out on 2x-20x increases SIMD can provide to certain problems!

A new, pure-native UI framework with a focus on databinding. Direct2D and pure vector like WPF would be a plus. Built-in async databinding would be even better! Like WPF, design as if there was a clean slate -- don't just upgrade Win32 or MFC.

A kitchen-sink library similar to the .NET Framework. Windows already has APIs scattered around for much of this, but a collection of supported, modern C++ wrappers would be fantastic.

. I think what you want is support for vectorization/vectorization library. Yea, vectorization support are nice but the ones I see around (gcc, Intel) still very close to C + compiler extensions. I hope things begin to get better after the C++ and GPU talk in the C&B and in the AMD Fusion Developer's Conference.

Actually I love the intrinsic header files (and it is the only way mix assembler code from 64bit), but I'm suspect to talk about it (I'm that type of crazy dev who like to "brush bits" sometimes )

*snip*. I think what you want is support for vectorization/vectorization library. Yea, vectorization support are nice but the ones I see around (gcc, Intel) still very close to C + compiler extensions. I hope things begin to get better after the C++ and GPU talk in the C&B and in the AMD Fusion Developer's Conference.

Actually I love the intrinsic header files (and it is the only way mix assembler code from 64bit), but I'm suspect to talk about it (I'm that type of crazy dev who like to "brush bits" sometimes )

Sadly most existing libraries are too inflexible or require you to jump out of C++ and use some other language to define the vector bits.

I'm not convinced GPU stuff like AMP will help at all for SIMD on the CPU -- GPU and CPU design are just too different. CPU requires a much more careful design, where an algorithm might look completely different between SSE2, SSE4, and AVX instruction sets. GPU still requires a careful design, but in wildly different areas.

@PhrostByte: I don't see much difference between CPU and GPU with respect to SIMD, at least in the view of the bare metal (1 execution/shader unit :: 1 CPU; VLIW4/5 :: AVX register/instruction; GPGPU thread grid dispatcher :: Multicores and NUMA nodes). But the programming paradigm yes, this is quite different as it give you direct control over what is put in the cache levels (but that is something they want turn optional).

The Intel OpenCL SDK are a cool as they are providing an off-line visual LLVM compiler, where you can inspect how the code are generated in x86 SIMD (SSE4 and AVX).

My faith on those GPU talks is cause the Khronos, and others, are very interested in migrate from C for GPU do C++, but a C++ suitable for GPUs and CPUs at same time, CUDA already providing Unified Memory Address (pass pointer direct, no more host_ptr and device_ptr), lets see next version of OpenCL

@BartoszMilewski: Remember that VC10 can only be implemented to the draft Standard- as it was at least two years ago. What's likely is that that part of the Standard wasn't ready.

I do understand, but then I look at GCC and they have it. Plus, atomics libraries have been available for some time now. Maybe for this period of the adoption of the new standard Microsoft could change its tactics and be more aggressive with releasing new features. And if VS is the blocking factor, releasing a command-line version separately would make sense.

@fredBed: I don't think you have the option of using C# in OS or driver development. These are exactly the areas where you can't use an interpreted language with garbage collection. Plus there is the performance issue. This is why C++ is called a "systems" language. In the areas where C# (or Java) is a better fit, there is no need to "kill" C++. The programmers have already moved away from it.

@BartoszMilewski: GCC focused on different areas first- they didn't have lambdas or rvalue references for quite some time. In addition, they both release faster, *and*, sure- atomics libraries have been around for some time. That doesn't mean that they were Standard for some time.

MSVC could only have implemented them if and only if they were guaranteed to be in the final Standard in a form very close to the form they were in now. If they weren't up to that scratch, then it couldn't be done- period. What GCC can do is irrelevant.

@fredBed: If you're being bitten by bad string handling in C++, then, well, you just don't know how to use it. There's no two ways about it. The Standard provides a value-typed, perfectly safe string type. Use it. Along with all of the other type-safe, bounds-checking, programmer-friendly high-performance classes that manage resources completely safely. I'm not completely sure why you're talking about coding ideas from the 1970's- C++ was only Standardised in 1998, with another Standard in 2003, and a major new Standard this year. Guess what it includes? Why, it just might be - pointers that manage their own memory. That one that's been around in Boost for a long time.

Your post just makes me think that you haven't updated your coding practices or checked around for how to use C++ for, well, since pre-Standardisation.

About me: been programng since 1980's. laguages used over the years: basic, qcasic, pascal, fortran, cobol, perl, c, c++, c#, F#, plus scripting laguages galor. I have come to think of programing languages like tools, with that said C++ is like any other language is a toolbox. There are things C++ is good at and are easy to do and there are others i would rather have my balls in vise than write them c++. There is a paradox that goes with that being the nicest part of a language is the hardest part to truly understand.

For example regular expresions = perl, yet they can be the hardest prt to fully understand their use.

Likewise example: c++ string types. it can really be a pain and once your make mistake it takes al kinds time and or code the figur it out.

Another example: There are math programs in fortran i woud never attempt to write in C++, the balls in a vise come to mind.

With that said the web serivices and financial componenets have been talked about in the c++ world for quit somtime. When does it start to become too late, about 8-10 years ago. Yes there are libraries like Qt, but CORBA comes to mind.

I still write somethings in c++ because of libraries, upon libaraies, upon libraries etc. and I like it and i am lazy. Is it c# no. Is it f# (camle), hell no. Is it slow in evolving yes because of a global committee. Whenever you want to slow something down put it in committee. The lack of change in base can be seen in two ways. A strong base or stubberness to the ideal of write your own object and leave core allown.

I would like the MS c, c++ to the work seamlessly with .net simular to PhrostByte statement. I have written programs in c# just because the .net in c++ had to be marshelled or some other wierdness. The whole thoery of c++ is that if it is not there you write your own object. Then it can be resused, which is what .net is all about.

Thus, having to be play with or workaround to make those objects work in c++ is am upsetting thought. I do not want to hear about what should be in the standard, I want to hear about the linq working seamlessly with the ms c++. I do not wish to be asked if db and data manipulation should be in the stanadard i want to read about how it works in the ms version of the libararies. I also wish to be able to make 2d objects act like 3d objects like silverlight with simple chagne 45% which I can do in c#, but not c++.

Maybe I am rambling. I think i am and will now stop. sorry if i offended.

I've been working for different ISVs for several years on large C++ projects (tax paying software, Image editing, Financial, programming tools...)

One problem with existing C++ apps now is the UI, which is outdated. They share that problem with Delphi apps . You know that battleship gray. I've spent lots of time trying to move (parts of) projects to Winform or WPF. This generally ends up with an awfull mix of C++, C++/CLI and C#. You know what I mean since you guys have ported Visual Studio UI to WPF ! This surely has been a huge amount of work.

If there would have been a modern UI C++ library, thing would have been far simpler. I've heard about DirectUI, and I can't wait to know more about what seems to be a native UI library.

Also I have participated to brand new WPF projects, in C#. For example an image editing app. One year after it started, the project is thrown away (10 men-year). WPF is too heavy, .Net has poor memory management, and the software was not compatible enough with previous versions of this project. Customers don't want a new app, they just want a better app which is able to reuse their old files/data.

What are all the C++ app developpers doing ? They have built their own UI framework and libraries years ago, sometimes based on MFC, or other libraries. (AFAIK MFC is not that bad, it is still used in many C++ apps, it is just old) They try to update the framework over the years. That's not easy, and requires a lot of resources. In the same time they have to update the applications. I bet the Office team at Microsoft has its own C++ framework. You can ask them what to do.

Since I've discovered .Net framework, I wonder why it is not also written in C++ native code. Maybe not the whole framework, but at least some core libraries, a powerfull UI layer, a fast database engine (I sometimes use SQLite in C++ client app)

Well, you know, just ask the guys who have ported Visual Studio to WPF, they will tell you what you need to do

Oh, and an important point: all developers have coding guidelines (or at least they should!). Many C++ ISVs ask their developers to write SIMPLE code. That means, avoid functors, use templates sparingly, etc. Don't use advanced C++ features if you can write simple code. Because simple code contains less bugs, and can easily been maintained. C++ is a powerfull language, and not all C++ developers can handle that power correctly.

I don't expect C++ language improvements, C++ is fine. But please, give us the equivalent of a light .Net framework, written in native code. That would be heaven.

- A sane, modern, well-designed UI library designed for C++. MFC is painful, first because it's basically C with classes, second because it's a framework that pretty much tries to take ownership of the entire application, rather than being a library I can call into at my leisure. And plain Win32/GDI? Ick. Perhaps a higher level abstraction layer on top of Direct2D would be an option. Perhaps something like a C++ equivalent to WPF (although I'd prefer something with less internal complexity, and less black-box magic, and less XML/configuration which cannot be debugged. Maybe it's just me, but it could also be a general C++ thing: I want some level of transparency: I want to know what my UI library is doing, even if that means having to write 30% more code. - Perhaps as a generalization of the above: clean up your APIs. How about a Windows.hpp header? One which gets rid of the macro hell of windows.h? One which compiles as ISO C++, without relying on proprietary extensions? One which utilizes namespaces? How about offering modernized C++ wrappers for your most commonly used APIs? WinSock, UI widgets, text encoding/processing and so on. Feel free to reuse the "traditional" win32 APIs under the hood, just wrap them so we don't have to suffer that amalgamation of 25 years of bad API design. And then, perhaps as a part of Windows, perhaps as separately maintained and released libraries, provide higher-level abstractions on top of these. But in terms of libraries, I really would love to see better ones for interfacing with your own components: the Windows API, extensibility for your various products and so on.

- As Charles mentioned in the interview, Faster/more agile releases of Visual Studio. When STL mentions that the <thread> header has been implemented internally, why do we have to wait 18 months before we can use it? When bugs are fixed, why don't we get to see them before the next major release? When we are asked for feedback, ostensibly to improve the product, why do we not get to see the improved product? I don't need a new release of Visual Studio every 3 months. But I absolutely want new features added, bug fixes released, components updated. The current schedule is inexcusable. Clang, GCC and all the other major compilers release new versions all the time; Visual C++? Once every 24-30 months. Because it has to tie in with a major Visual Studio release. Better debugger features? Again, only as part of a major release.

- And since Microsoft has a long history of applying insane amounts of effort, time and skill at solving complex problems in absurdly complicated ways, I want to see you doing some of that with the really tough problems of C++ and your IDE: You have no support for debugging templates. Give me a "compile-time" debugger where I can step through template instantiations. How about a kind of REPL loop for C++, so that I can, both "offline" and while my code is running, inspect types as well as values, instantiate templates, do all those complex tasks that C++ can do, but your actually-designed-for-C IDE and debugger currently cannot? This could even, to a large extent, replace Intellisense which you're perpetually struggling with. If I could just ask the compiler "ok, so of I instantiate a vector of ints, what does its iterator look like?", or "can I legally instantiate this template with that type?", without compiling my entire application, *that* would really boost productivity. Or how about allowing me to compile just part of an application? Say I'm in the middle of refactoring some code, and a bunch of my unit tests currently won't compile. But I still want to be able to run the remaining ones. Give me a simple way to compile the *rest* of them then. Perhaps I could just select a snippet of code, right click and select "build". Perhaps a more flexible project model in which I can easily build using just some of the .cpp files, or perhaps some entirely different option. Think outside the box to solve some of the pain points associated with C++ being such a static language, and one where build times can be, well, non-trivial.

- and in the same "absurdly complicated" (and probably even more so) category, how about solving the problem of compile times. Yes, when we follow the same 30-year-old compilation model, there's very little we can do to speed things up (although your linker performance is miserable compared to your competitors). So think outside the box. Precompile *all* headers, implicitly and separately, without making it a project setting, just as invisible caching done by the compiler. Yes, it'll require a lot of complex hacking and some very flexible data structures in the compiler, and yes, it'll rely on heuristics that might break occasionally, but then let the compiler fall back to "naive" per-translation-unit compilation for those cases. But 99% of the time, we can make a lot of of assumptions about the context in which headers are included, and the compiler could conceivably use these assumptions to compile those headers once, in isolation, and then reuse the result anywhere it is included. Again, Microsoft has come up with some absurdly complex solutions to problems before. Let's see you apply those skills to this extremely complex problem!

Finally, echoing what others have said, a separate "not-part-of-the-big-monolithic-VS" release of C++ tools would be interesting. VS is huge, it's bloated, and it's overflowing with very nice features for managed code, which are just useless in a C++ context. To be honest, most of the VC++ IDE has very little value to me. I need a build system (and I wish more of the flexibility of the underlying MSBuild was exposed, rather than the rigid project model used by VS), and I love the debugger, and the compiler is pretty decent too. But most of the IDE just gets in my way, not because I'm an anti-IDE fanatic, but because it's so slow, and so clumsy, and so obviously tailored at a whole different world: managed code.

I echo those who are calling for a return to the VC6 days when VC++ was the most productive programming environment for developing practical programs. People love VC6. Less so VC2010. Hint: the standard of vNext should be "how much faster than VC2010 is it?" Not, "how much slower is it than VC2010" which was the release criteria of VC2005, VC2008, and VC2010. (In all cases, if the performance only degraded a few percentage points, it was fast enough.) That doesn't work for VC, any better than it worked for Vista.

Kudos to those calling out Qt to be the reference of a modern C++ UI framework that you instantly fall in love with.

OTOH, the MS-recommended libraries suck. STL is a very poor library that was designed by a mathematician and not a programmer, and it shows. I can't believe Moshen says "just use that for modern C++" with a straight face. For one thing, the string class is horrible.

Same for XmlLite and all the other COM-based libraries that force the horrendous number of string and variant types as rab36 says. We don't need "no more of those!" QueryInterface() is even more quaint than MESSAGE_MAP. Why do C++ programmers get stuck with glue code of COM when it is hidden to every other language MS supports? Is C++ not a first class language that we can get C++ types unaltered? Moshen says assembly language is officially obsolete, but dealing with COM crap like .idl, etc. is worse than assembly language.

Make tools, languages, and libraries that people love! (Hint: Qt would never think to make you do any of the above.)

So the answer for vNext is simple: bring back the love into C++. Unfortunately, with the focus on the niche reasons mentioned for using C++ in the video, such as to save battery power, it seems love has nothing to do with what motivates the VC++ team these days.

Moshen was interesting to listen to, but he gave no more reasons to believe in any "C++ Renaissance" in this video than he did in the previous one. I don't want to use the words "put up or shut up" but really, the time to blow us away with goodness is really past by some years! :-(

A bigger focus on modern C++ design. Look at the PPL -- it knows that it's in C++ and takes full advantage of it. It fits perfectly, working exactly as expected. Contrast this with so many of the other C++ offerings at MS which rely on or try to mimic COM. COM is not a good or friendly way to write C++!

A new, pure-native UI framework with a focus on databinding. Direct2D and pure vector like WPF would be a plus. Built-in async databinding would be even better! Like WPF, design as if there was a clean slate -- don't just upgrade Win32 or MFC.

A kitchen-sink library similar to the .NET Framework. Windows already has APIs scattered around for much of this, but a collection of supported, modern C++ wrappers would be fantastic.

Funny, a week after I write this I read an article on Ars that makes it sounds like much of this is coming in Windows 8. Perhaps it's time I get a job at MS (or at least, start working for some tech predictions website), if I'm so randomly in tune with their thoughts on the native future.

In addition to the topics already mentioned, C++ is the only platform-independent tool existing to date. Recently, we created a new service for smart phones. For obvious reasons you want to support the iPhone and iPad, right? So this is where we started and it was fun. We used our existing classes for AES encryption, template classes for elliptic curve cryptography (ECC), network packet framing, etc. There was just a thin layer of Objective-C++ necessary to handle the UI, and it integrated seamlessly. We reused the same classes on our mating core service running on Windows Server. And when we decided to support Android, we used the same protocol processor classes, crypto system, etc. we had already up and running and carefully tested on iOS and Windows platforms. We just needed to add JNI wrappers and only the UI portion needed to be done in Java. So we ended up with a frame work of classes with some platform-specific parts (networking on BSD and Windows, timers) implemented via virtual functions. No duplicate code to maintain, very appealing design. Would have been a snap to add Windows Mobile support, if it had not disappeared from the market. Adding Windows Phone 7 support? Not with the curent and expected market shares. Nothing against the WP7 UI, but why the heck are you keeping native developers off the platform? Google tried the same with Android and was smart enough to add the NDK. Microsoft should do the same.

It's not that I am against managed code. I have to admit that I personally prefer C++, but we used C# and ASP.NET MVC 2 in the same project to implement our customer's web portal. Thank you for that framework, 1000 times better, cleaner, more productive, more readable and more maintainable than PHP, Python, Ruby... you name it. We also created the billing system as a Windows Service written in C# using LINQ.

But: Never would we have implemented the core networking service that way. Here is where performance counts. In terms of memory requirements per connection and CPU cycles per request. And in terms of deterministic behavior. I want full control over the lifetime of dynamic objects in such a volatile environment. shared_ptr gives me that in a safe, reliable and predictable way. I do not want a garbage collector to take decisions for me.

We used SQL server native client to access the data base shared by web portal, core networking service and the billing service. Besides the pain we experienced with supporting BLOBs (via IStream interfaces), we had to add spatial support, since we used geo-position on mobile devices and SQL server's powerful spatial queries. We also fixed a few bugs in ATL Server - yes it still exists :) - to be able to send e-mails properly. All in all, the effort was worth it. We created a very stable, responsive and deterministic solution.

And we even did the Client application running on Windows desktop (XP to Windows 7) using MFC 10 and the new classes introduced with the feature pack. I was struggling a while if we should use C#/WPF instead. Again, using SQL server native client we were able to make use of the service broker to establish a connection between multiple instances of the core service and multiple client instances. Was not sure if that was possible with C#/LINQ at all.

We could have used WPF, but we did not want to. I must admit that this might be due to the fact that I am using MFC since version 1.0 and this experience can compensate the benefits you gain with C# and WPF :) But honestly, with this approach we are able to move the client application to other platforms - if necessary.

I would also like to mention that we have developed an in-home display for "smart home" applications. When we first started, I was keen on using Windows CE (at that time 6.0 R3 with 7 preview). But having Microsoft drop native support on Windows Phone 7 made me fear that Windows CE was also going to be abandoned, or at least was going to suffer from the managed code hype. So we decided to use Linux and Android instead. And we are paying in terms of poor performance of Android (compared to native code on Windows CE), but again, that is worth it and will be compensated with a more powerful ARM processor (1GHz Cortex-A8 instead of 400 MHz ARM 9).

So guys, please keep your excellent work on native development up. Visual Studio is better than Xcode, Eclipse and all the other competitors that I have worked with - and always has been. Though VS2010 IDE performance and UI stability are really embarassing. And this affects very basic features. When I hit Ctrl+F to search for text why do I have to adjust the window size of the appearing docking toolbar window each time? Double clicking a source file in Explorer sometimes makes the OS think that the application has crashed. It won't always open the first time because VS2010 is taking so long to start-up.

Language: order-independent compilation, so that header files go away. Yes, it would break code and you could not redefine macros anymore, but it would remove one of the biggest headaches in big projects.IDE: more stable, faster, in particular faster and more stable Intellisense, really just the basics.Other languages: Scala looks great, but is tied to the Java runtime and all-objects-on-heap with garbage collection.

I use C++ when performance is very important and that usually means realtime, e.g. gaming related stuff. Whenever it is possible to wait for the results for a bit longer, C# is a much better choice due to .NET framework. Like others have said, having a light version of .NET Framework for C++ would be awesome. The higher level abstraction of common tasks makes quickly getting a prototype ready so much easier.

I also use C++ for debugging related tasks, because it's easy to communicate with the winapi.

Regarding the IDE performance degradation, it is definetly easily noticeable. In fact from 2003 to 2008 the performance got so bad that the IDE froze everytime I typed ".", i.e. intellisense stuff. When I bought a brand new computer with a SSD, these problems went away. For the record, eclipse is still abnormally slow with a top tier SSD & quadcore CPU.

Remove this comment

Remove this thread

Comments Closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation,
please create a new thread in our Forums, or
Contact Us and let us know.