File size

File size

File size

File size

File size

500.5 MB

C++ has been around for what seems like forever. It might seem like it's taken a back seat to languages that provide better application isolation and better development throughput, but in truth it remains one of the most widely used languages in the world. In order to gain some better insights on how C++ measures up in a "managed" world, I've invited Herb Sutter, Program Manager for Visual Studio, to explain how C++ has evolved and how it remains a great choice for many modern day development tasks.

And here are a few additional links to more information about C++ that will help you learn how to use it in your projects:

GoingNative 2012This event was held back in February, and was streamed live throughout the world. It featured industry experts discussing the importance of C++ and its proper use in modern application development. All of the sessions are available for "on demand" viewing over on Channel 9.You can access all of the videos here: http://channel9.msdn.com/Events/GoingNative/GoingNative-2012

Welcome Back to C++ (Modern C++)For Visual Studio 11, MSDN has prepared details on the advancement and use of C++ which includes examples, reference material, and information on the currently supported features. It is definitely worth checking out to get up to speed.The MSDN C++ content starts here: http://msdn.microsoft.com/en-us/library/hh279654(v=vs.110).aspx

Great interview chaps. I find that one of the big problems C++ suffers from in the Windows programming community these days is that the folks writing it 10 years ago have moved to .NET, taken on team leadership roles and can't seem to separate in their minds C++ from 'COM', 'ATL' and 'MFC'. Whenever I hear negative stuff about C++ it's 'Oh, remember the grief we had with COM, manual reference counting and the registry', which of course has nothing to do with either the core language or its wonderful (if small) Standard library.

You just don't encounter this on other platforms. I think Microsoft has some way to go in order to undo some of the rather happy-go-lucky messaging that managed code was showered with over the past decade.

I find that one of the big problems C++ suffers from in the Windows programming community these days is that the folks writing it 10 years ago have moved to .NET, taken on team leadership roles and can't seem to separate in their minds C++ from 'COM', 'ATL' and 'MFC'. Whenever I hear negative stuff about C++ it's 'Oh, remember the grief we had with COM, manual reference counting and the registry', which of course has nothing to do with either the core language or its wonderful (if small) Standard library.

Note that ATL is an excellent tool to do COM programming in C++ in an efficient way, and it also offers convenient RAII wrappers to raw COM interfaces like CComPtr<T> smart pointer. There is no need to manual ref count if you use ATL.

And note also that COM is a robust native technology that is still at the basis of more modern stuff like WinRT, and modern Win7 APIs like Ribbon or Animation Framework are conveniently exposed in an "object-oriented" way using COM. COM in plain C can be complicated to program, but COM in C++ with ATL is OK.

Instead, I agree with you that MFC exposes some "anti patterns" (like throwing exceptions on the heap instead of on the stack, having an array class that grows arithmetically instead of geometrically like std::vector correctly does, having some container classes that "memcpy" their data instead of using proper copy constructor, etc.).

However, one of the advantages of MFC is that there is a rich 3rd party market, like Codejock components; ATL and WTL unfortunately don't have that.

In C++ you have make_shared, vector<shared_ptr<>>, const shared_ptr &, etc. C# code is simpler (no make_shared, no shared_ptr, no reference "&", etc.), there is no doubt about it. But, as Herb Sutter excellently pointed out in the interview, this has a cost in terms of efficiency.

I think the golden rule is: "Use the right tool for the job". And, if you want efficiency, speed, low memory consumption, etc. then: go native

BTW: Speaking of performance of native vs. managed code, I wish Microsoft came back to a fast native Visual Studio IDE (like we had in VS2008 and before).

C++ is simple & easy IF YOU MAKE IT SO. The language committee has gone WAY OUT OF THEIR WAY to needlessly over-complicate the language, but you don't need to go to their seminars, buy their books, or drink their koolaid.

Keep it simple and C++ is the simplest, most portable language on the planet. Today's colleges focus so much on Java they've created two generations of programmers who are actually AFRAID of C++ because "pointers are scary".

To quote World of Warcraft: "Don't stand in the stupid." If doing something in C++ causes problems, DON'T DO THAT. It makes your code simpler and easier to maintain as well.

*cough* bullcrap *cough* You can make managed languages efficient. You can make managed languages run on low end hardware. The issue is that the C++ folks never believed in anything but C++. When I look at the "new C++" I go screaming into the hills because of the complexity.

I write financial analysis code, and started with Fortran. About 20 years ago the Fortran people said the same thing about the C++ folks that the C++ are saying today. Look what happened with Fortran. Raw low level C++ that does not have boundary checking and smart pointers is faster than C#. No doubt about that. I tested it. HOWEVER, once you add the smart pointers, and all of the other "goodness" C++ dramatically slows down to the point that there is only a 10% difference between C++ and C#. Well sorry, I will stick to managed code...

IMO Microsoft buggered itself up doing this step backwards. Sure the old guard will be happy, but the old guard is not the crowd that will keep the Microsoft platform alive...

Well it is not like you would use smart pointers on every object you create. In C# you have no real control where a object is allocated. In C++ you have to make the choice all by yourself. This requires a careful choice, and you will first try to allocate your stuff on the stack. This is blazing fast AND safe.

Well it is not like you would use smart pointers on every object you create. In C# you have no real control where a object is allocated. In C++ you have to make the choice all by yourself. This requires a careful choice, and you will first try to allocate your stuff on the stack. This is blazing fast AND safe.

Yes, for simple allocation stack semantics is fine. But in non trivial code you have to create objects and put them in some container.

But a more interesting question would be: "Would it be possible to kind of extend C++ - without sacrificing its core values like efficiency - so that we can use a simpler syntax?"

For example, I'm thinking of having something like C++/CX "^" (but without WinRT), which is still pure native code (no garbage collector, no virtual machines; just ref count automatically performed by the compiler) but without a verbose shared_ptr<> syntax required. Maybe in this case the compiler could also do some optimizations that are not possible with shared_ptr.

ive been following c++ almost since the same time as robert hess did. and i must say i really like to watch the newfound excitement for c++ these days (not just in the industry in general but also at microsoft).

i remember that my last post i wrote here was a *huge* complaint / rant how C++ got quite a bit neglected in the times where .net kicked off. back in the time i also felt a bit negative towards microsoft because i thought - at the time - that marketing and "evangelism" really leaned towards managed. there have been times where the "hype" around c++ was almost down to zero. i do not think that a language such as c++ even needs hype or marketing. but on the other hand keeping it in people's minds, in students minds, in scholars minds is very important. and for that you do need hype and excitement.

i think this video really showed that we are back again at where c++ should be. if you just think about the expressiveness and power of this one slide of code Herb Sutter showed, its just amazing. this is all not news to me, since i do watch the course of the standard and all. but the point is that people can get excited again! students can! its a major point of a successfull language to be usable and *teachable* aswell. we are at that point with c++ now. i know that in production things are always more difficult, intricate, etc etc.

also, this video really sums of nicely that we have to rethink how we write c++ without getting into the dark corners ;) i think, fully embracing the possibilities of the new standard and also letting go of some of the old things we had to learn maybe a new style of apis / interfaces / libraries will arrive. its just a feeling i have so far: the new features as a whole will make us rethink how data flows through our apis, how we interact with it and how to specify behavior and *not* in an involved, complicated way but with code that feels natural. combine this with actually using allocators for what they are intended (and i think they are generally heavily underused)... in some sense, types are not fixed anymore. data can move more freely (see passing by const reference, etc). new library designs and paradigms (on the larger scale) need to follow (counting on a. alexandescu for that ;)). these are interesting times to rethink what we have written in the past.

i'm getting carried away here ;) this video just made me post. last time i posted a frustrated rant. that was about 6 years ago.. its time to draw new conclusions (even if its just for myself i wanted to write about that ;)).

sorry for this very untechnical post. but i do think that even something as programming languages, and for me especially c++, have a non-technical (almost emotional but thats the wrong word) side aswell which eventually will influence the technical side again, the way we design.

enough with the philosphy now ;) thanks for your efforts charles and channel9. ive been watching your work from day one even though i'm very silent here and it's been a great journey!

It's ironic that one of the things that could well hold you back working with C++ today is a deep and strong knowledge of C++ yesterday. You may have a lot of hard-won rules of thumb about never do this and always do that and careful about this other thing, it will hurt you. And those rules may now be wrong.

Don't return big objects by value because the copy is expensive? While you weren't looking, RVO became the norm. Don't pass temporaries by value? Move semantics FTW (as discussed in this video for the flip() function). Everything you new you must delete? Not if you hand it to a smart pointer. Try this rule: if you're typing delete, you're doing it wrong. Heck, if you're typing new you're doing it wrong. Most of the complex and hard to read code that people show me just isn't modern C++. I'm not going to defend it. But I'm also not cool with it being taken as some sort of indictment of C++. You can write hard-to-read things in many languages.

In other cases, I find that it helps to reword the emphasis in your rules. Take "Remember to declare destructor virtual when using inheritance (usually when there are already other virtual functions)" for example. In many languages, everything is virtual. You can't turn it off. In C++ we turn it on only when we're willing to pay for it. When you design something, you think at the beginning - do I want polymorphism? Am I inheriting from this? Will virtual functions make the code that uses this class so much simpler to write? And if in that thought process you decide yes, I want some virtual functions, then part of having them is remembering to write a virtual destructor. That extra thought at the beginning is a feature. I prefer that to a system that saves me from myself and makes everything virtual just in case.

This is really the point Herb is making. It is more productive in terms of developer time to remove that decision. Everything's always virtual. There, now you can't get it wrong and you don't need to take the time to think about it. And for a huge class of problems, the extra space and time consumed at runtime s a consequence of that choice won't hurt your app. But not all problems, not all apps. When you choose to work in C++, you're saying "give me the control, let me decide." When someone posts saying "C++ sucks, you have to decide stuff, you have to remember stuff" they aren't wrong (at least the last 2/3rds of the sentence isn't wrong) they are just prioritizing developer ease over anything else. And for many kinds of projects, that's the right decision. What I'm saying, what many folks are saying, is that there do exist projects for which the power and control of C++ are absolutely necessary and the 5 minutes of thinking, remembering, and choosing that the language asked from the programmer turn out to be 5 minutes very well spent.

@Jagannath:You're right: C++11 range-based for loops are a great tool to improve code quality, and are a very welcome addition.

But the general point about C++ having more details to pay attention to than C# still holds.

Even in your code, you have shared_ptr, and in general the C++ programmer has to think: "I need to put X in a container. Should I use X*? Or shared_ptr<X>? Or unique_ptr<X>? etc.". In C# you just use SomeContainer<T> and are done.

And there was another very good example made above about virtual. And others can be found along the same line.

Of course, all this is not "rocket science". It just requires more study and a steeper learning curve to climb.

@Chris:To kind of support Chris' point about managed code performance, there is a long thread on a MSDN Forum about the slowness of VS2010 IDE, an interview to a VMWare dev (former VC++ MVP and author of a great tutorial series on WTL) that confirms this opinion, and the experience of Evernote (emphasis mine in the following quote):

"Evernote 4 is a major departure from Evernote 3.5 in every way. While 3.5 added tons of great new features, there were some problems we simply couldn't fix: the blurry fonts, slow startup times, large memory footprint, and poor support for certain graphics cards were all issues that the technology behind 3.5 (Windows .net and WPF) was incapable of resolving. As a result, we ended up chasing down platform bugs rather than adding the great features our users wanted.

So we decided to start over from scratch, with fast, native C++ that we knew we could rely on. As you'll see, the results are amazing."

I love all of the discussion going on here, I think a key thing to keep in mind is that I doubt there could ever be a single programming language that solved everybodies problems. As Herb mentions a few times in this video "The Right Tool for the Right Job".

As somebody who has programmed in far more languages then I can even remember, I enjoy getting into the groove of each one and appreciating the features and capabilities they bring to the table.

FORTH may have never been a terribly practical programming language, but it was a lot of fun, at times almost seeming like playing a game of Tetris :->... Modula-2 was a well structured language with a great balance of polite power. C, when I was first coding in it, was sort of like a challenge to see how tightly you could wind your code, and in a sadistic sort of way trying to make it do something in a next-to-unreadable way (you've got to remember, I was just a fun-loving kid back in those days! :->)

I've been using C# for many years now, and find it both comfortable and familiar, but seeing some of the new capabilities working their way into C++ makes me realize that it's probably time to take a look at it again.

Well, I'm waiting to see when they'll come back to plain C. Still templates, multiple inheritance, overloading and Co. aren't friends of embedded. They (Ms) got bitten by that since experimenting with this realm of software art.

After working with C# (and loving it BTW) for four years I'm now back at C++ in my new job. I was really surprised at how much has happened in the field of C++ since, especially the very nice Boost-Library.

Herb's demo of C++ 11 is really interesting and looks great and clean. C++ finally seems to set some focus on simplicity and wrapping usual C++ idioms. And I love the lambdas !!!

If you like the language features of C# but want a native version I can recommend Delphi, Anders previous language. I use both for different problems, I prefer the language of C#, but sometimes it is very useful to just compile everything from source (you always compile the whole framework from source in delphi, and it's among the fastest compilers ever, so it's never a problem) and ship a fast .exe file with no framework, installation or dlls needed.

I am curious in the interview Herb say that if the lambda do would do a bit more the runtime would probably put them on different threads. How does the run time knows when to put task/async lambdas on a different thread or not?

I am a self taught programmer, the only education I had towards programming was in H.S. back in 97-99 and we used Visual Basic. "Eh!" Since then I've taught myself c++ and for a little while I tried c#. Most the stuff I am writing is native, sometimes managed depending on the need of the project. The main project I am working on is a 3D Game engine, with custom GUI, HUD, basic physics engine that used simplified Euler Integration, Interpolation, Sound Engine, with file parsers to load in 3d model objects, scenegraph, etc. This project started out as an empty win32 win app with no precomipled headers. I originally wanted to use DirectX and at the time I started this project DX 9.0c was mainstream and DirectX 10 was being announced for release, MSDN was very helpfull in learning it, so I went to OpenGL and yes it can be a pain using new and delete, and having to know when objects on the heap are going out of scope to remember to call delete. Remembering to use virtual on a base classe's destructor, and using explicit for a constructor with a single param. These are all pains to work with, however if I would of used c# or some other strictly oop managed language, I wouldn't of been able to do some of the things I was able to do in C++. Some of those features involve an few functions that dont belong to a class, no use of templates, for example a swap function or a func that returns min or max etc. and also macros can be usefull in c++. Im sure c# has its place in the programming world, but for some jobs managed just doesn't cut it.

My current project I am working on has a lot of overhead behind the scenes, but the library will be very simple to the user. I am in the process of creating a library that will create any Element off of the Periodic Chart, and it will automatically create all the necessary parts. Yeah one could create a class called Atom or Element and give it 3 int variables to make it simple; the number of protons, electons, and neutrons, but this wasn't my goal. The Atom class itself is inherited from a class called Nucleus, this class holds the amount of Neutrons and Protons, it also determines if it is an isotope, and holds the position/velocity vector in 3D space, If the constructor of the Nucleus class passes, then the Atom's constructor calls a function to create and ElectronCloud. This class contains many parts. It doesn't just have the amount of electons, it has all the shells and subshells and as well as another class which is called ElectronPair. Having this class enables the idea of +/- spin in that pair for electron infinity. So I have a base class named Shell which is just an empty class, but each of the primitive shells S,P,D,F and Theoritically G, are derived. The shell classes contain an Orbital class that inherits from an ElectronPair class and the ElectronPairs contain the Electrons. The oribital class controls which electrons are private and which are public. Inner electrons don't normally react, but the outer ones do. The ElectronPairs class is used to fill and associate 2 electrons to a pair, however in some elements the proccess is skipped. This is done inside the ElectronCloud Class. Now here is another rich feature; the Electron, Proton and Neutron classes are inherited from a Particle Class and the Particle class is inherited from a Charge class. There is an inner connection of objects going on. In some casses objects are crated on the stack but in other cases where life time of the object varies, it needs to be on the heap. This could of easily been done within c# or java, however in c++ when I run the program... "In its early stages as a win32 console program for testing purposes" I am only using about 500k in memory from the proccessor when I try to create the element 118. This element has 118 protrons, 176 neutrons, and 118 electrons all created on the heap and the electron cloud is on the heap and the nucleus that the 118 and 176 protrons are in are on the heap. And it computes this atom in a few seconds. Im running an Intel Quad Core Extreme 3.0GHz with 4GB DDR3 Ram running on Windows Vista Ultimate Service Pack 2 32bit.

I forgot to do this in the above 2 posts. So here it is, Everything that I just mentioned happens dynamically when the user chooses which Element they want, and weither or not it is an isotope based on the amount of protons, and if it is an anion-cation based on the amount of electrons. This is how my main looks and it is still simple, clean and readable. I haven't used smart pointers and lambda's etc since I started this on VS2008 and recently converted it to VS2010.

I'm with Kate.I always hear "Meh, I have to do this, I have to check that, I have to care about foo". But I say: "I GET to do this, and I GET to care about foo".It's better to have all the strings in your hand rather than not even knowing what strings there are. (BTW: "string" <- no pun intended)

STOP "Improving" C++ and leave it alone. If you want more, change languages. STL is fine - it is a library add-on. foreach? WTH? If you want to use foreach, it is time to use C# or Java. C++ is fine as it is and does not need any additions. LEAVE IT ALONE and stop fixing what is not broken.

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.