Scott Hanselman

C++ killed my grandpappy - Is C++ hard and where are the C++ coders hiding?

June 29, '10 Comments [52] Posted in Source Code
Sponsored By

After learning BASIC and ASM, for a job I started coding in C, when Hello World on Windows was 92 lines of code. (Apparently Hello World is easier now, says Pete Brown)

One of my first big projects was an app called Foolproof that kept kids in high school from breaking into their school's lab computers. It had a C core engine, a TurboVision DOS component and a 16-bit Windows C++ App. I did the DOS, Win16 and later the Win32 API all in C++. Later I did some VB3, then Delphi, then worked at Nike doing Java (right when RMI was starting, and HotJava when we wrote once and debugged everywhere) until I finally ended up in managed code, mostly doing C#.

Some folks don't know Microsoft has a free C++ Express Edition of Visual Studio 2010 and that it's one of the most used free versions out there. Someone is coding C++, and they are doing a lot of it.

Are you coding in C++, Dear Reader? What are you doing?

Most "managed people" cringe at the idea of using C++, thinking it's perhaps a language of the past and that it's not even possible to write Windows Apps in C++ without a Master's Degree. ;)

However, I just noticed there's a new project called Hilo with source to show people how to use the shiny new things in Windows 7 from C++ and how to make modern Windows applications that have animations and magical stuff that managed people assume belongs only to them.

The first drop of "Hilo" is apparently the first of many, all moving towards building a larger application. This first sample is a content browser (touch enabled!) for looking at videos and photos (yeah, yeah, I know) but you could totally use it to browse other stuff or use it as underlayment for your own app. This from the Windows Team Blog:

The main technologies used in Hilo: Direct2D, Windows Animation Manager, Windows Touch, Libraries and the Shell API.

  • Direct2D: For high performance and high-quality rendering of graphics.
  • Windows Animation Manager: To give the application a unique personality and to improve the user experience.
  • Windows Touch: To provide a more natural user interface through which the user can just “point” and “do”.
  • Libraries: To enable the application to provide users with a single, coherent view of their files.
  • Shell API: To navigate the images, to optimize by using the pre-built thumbnail cache and also to provide icons from actual content.

Even if you're not going to start coding C++, it's always a good idea to "see how the other half lives." For me, it's a return to what I thought I knew, and a way to look at C++ with fresh eyes.

What surprised me was that this app was written against Windows itself, with no frameworks. I always assumed you kind of needed MFC or some other library to be productive.

I'm not sure why I remember it this way, but C++ always made me think of regular expressions, and I assumed my code would **be &all like->this.you~know? You do need to know more about Windows, to be sure, as there is likely a decade of managed programmers who have forgotten what a message pump is, but it wasn't as scary as I had remembered.

Hilo Browser

Just download C++ Express, then the Hilo source, and build it. It has some cool effects with the carousel, like inertia when it spins, scaling, Z-ordering, hardware graphics acceleration. Now all they need is a designer! ;)

As an interesting example, it uses Direct 2D and has an animation for the orbit of the carousel. I removed all the if (SUCCEEDED(hr)) code from this snippet below because that's still the one thing about C++ on Windows that irks me. Don't judge then, judge me for yanking it for brevity.

This source is extremely defensive, dutifully checking HResults at every step. I mean, seriously, if it doesn't Succeed, what are you going to do about it? If (NOTSCREWED(hr)), you know.

For this source, the salient point is that there's some nice high-level Animation constructs like timers, transitions and storyboards.  For some wrongheaded reason I thought it'd be a pile of math so I was pleasantly surprised.

HRESULT OrbitAnimation::Setup(D2D1_ELLIPSE targetEllipse, double targetOpacity, double duration)
{
HRESULT hr = S_OK;

// Animation objects
ComPtr<IUIAnimationManager> animationManager;
ComPtr<IUIAnimationTimer> animationTimer;
ComPtr<IUIAnimationTransitionLibrary> transitionLibrary;
ComPtr<IUIAnimationStoryboard> storyboard;

// Transition objects
ComPtr<IUIAnimationTransition> centerXTransition;
ComPtr<IUIAnimationTransition> centerYTransition;
ComPtr<IUIAnimationTransition> radiusXTransition;
ComPtr<IUIAnimationTransition> radiusYTransition;
ComPtr<IUIAnimationTransition> opacityTransition;

// Initialize animation variables if necessary
if (nullptr == m_centerX)
{
hr = Initialize(targetEllipse, targetOpacity);
}

// Retrieve animation objects
hr = AnimationUtility::GetAnimationManager(&animationManager);
hr = AnimationUtility::GetTransitionLibrary(&transitionLibrary);

hr = AnimationUtility::GetAnimationTimer(&animationTimer);

// Initialize storyboard
hr = animationManager->CreateStoryboard(&storyboard);

// Create one transition for each orbit variable
hr = transitionLibrary->CreateLinearTransition(duration, targetEllipse.point.x, &centerXTransition);
hr = storyboard->AddTransition(m_centerX, centerXTransition);

hr = transitionLibrary->CreateLinearTransition(duration, targetEllipse.point.y, &centerYTransition);
hr = storyboard->AddTransition(m_centerY, centerYTransition);

hr = transitionLibrary->CreateLinearTransition(duration, targetEllipse.radiusX, &radiusXTransition);
hr = storyboard->AddTransition(m_radiusX, radiusXTransition);

hr = transitionLibrary->CreateLinearTransition(duration, targetEllipse.radiusY, &radiusYTransition);
hr = storyboard->AddTransition(m_radiusY, radiusYTransition);

hr = transitionLibrary->CreateLinearTransition(duration, targetOpacity, &opacityTransition);
hr = storyboard->AddTransition(m_opacity, opacityTransition);

hr = AnimationUtility::ScheduleStoryboard(storyboard);

return hr;
}

I was also pleased to see that intellisense worked nicely for everything typed as well as -> deferenced pointers, as seen in the screenshot below. Call me an intellicrack addict or weak-minded but it does speed things up once you know what you're looking for. The C++ Express SKU was a small download as well.

C++ Express Screenshot of Code

I'm not saying it's all puppies and cotton candy, but it's not the post-apocalyptic-Where-is-John-Connor-wasteland I thought it would be. I'll be giving C++ another look as I aim to learn (or relearn) another programming language this year (along with Scala). I'll report back as this application gets bigger and more interesting.

Related Links

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

facebook twitter subscribe
About   Newsletter
Sponsored By
Hosting By
Dedicated Windows Server Hosting by SherWeb
Tuesday, 29 June 2010 00:58:50 UTC
I work on the Google Chromium project in C++, it's a great example of a well written C++ app!
Pierre
Tuesday, 29 June 2010 01:15:25 UTC
Scott, C++ isn't as scary as many people think. It's just a different tool. It has some language semantics that scare people, like *'s for pointers and & for passing a variable by reference (in C# we use the ref keyword to achieve more or less the same result). And all those libraries written for .NET (not to mention some of .NET itself), really just wraps the Win32 API. There is some stuff which is totally managed code with no native code in sight, but eventually something must communicate with the operating system. I love seeing people's faces when I tell them that Windows Forms just wraps Win32 and it hasn't been updated since .NET 2.0 where as WPF doesn't.
Chris
Tuesday, 29 June 2010 01:29:16 UTC
I remember what a message pump is. Great blog post. It's been probably 12 years since I did any serious C++. You've inspired me. I'm going to go check out that Hilo project and start making null reference pointers all over again :)
Tuesday, 29 June 2010 01:30:25 UTC
Scott, the problem that novice native code Windows developers have is that the free version of C++ (Express) lets you use the Win32 API (of course!), but it doesn't support MFC programming. I suspect most C++ developers who have "real" work to do (and who therefore don't want to write several times more lines of code, as if they were working in C) would rather use MFC than Win32. They thus have to buy the Professional version of Visual Studio, and although developers who work in native code for a living will consider that expenditure worthwhile, someone who is just interested in learning about how to do Windows programming won't. Those folks will probably become X Windows programmers on Linux instead.
wil
Tuesday, 29 June 2010 02:15:00 UTC
Hi Scott,

Great blog post ! My C++ experience was with C++ Builder in a long time ago in college working with several types of devices (Computer Engineering). After this I develop a lot of applications with VB6, then Java and later C#, that I love most.

In the company I work in Brazil there is an outsourcing company that uses Visual C++ to create photogrammetry and transportation applications. They use primarily MFC along with different self-develop libraries to work with large TIFF files. In some applications DirectX is used.

I think there are some points where C++ is necessary. Can you open a 1GB TIFF file using .NET Image class? No way (OutOfMemoryException). :-)
Tuesday, 29 June 2010 02:15:43 UTC
Actually, C++ is far from a dead language. A lot of people have invested decades into C++, and there are still several areas where .NET simply hasn't caught up yet. For this reason, most of the better C++ programmers have not yet transitioned.

One example is the limited number of .NET collections that are available. .NET 4.0 helps somewhat, but is still blown away by the C++ stdlib/stlport. A couple of libraries have attempted to fill the gap (PowerCollections and C5), but neither of them are universally accepted.

Another example is the extremely powerful (Turing-complete) metaprogramming available through templates. Most C++-turned-C# users never understood or used the true power of C++. (Note that Microsoft's C++ compiler was a running joke among C++ programmers until Herb Sutter turned them around... well after .NET was released). T4 templates are a step in the right direction, but still do not achieve the power of C++ templates (in particular, automatic template instantiation based on usage).

A final example is RAII. Most of the "pitfalls" of C++ from a managed developer's perspective (i.e., deleting pointers) were replaced wholesale by RAII in the mid-90's. Really, any C++ developer after 2000 who wrote "delete" had no idea what they were doing. Sorry, but all those folks who "heaved a big sigh of relief that they wouldn't have to do explicit memory management any more" didn't know that they already didn't have to do explicit memory management! RAII is one of the most powerful idioms ever created; it enables truly rock-solid programs with a minimum of effort. The managed garbage collector actually makes RAII much more of a pain in the neck, making writing rock-solid programs much more difficult.
Tuesday, 29 June 2010 02:49:06 UTC
@wil: If you don't have legacy MFC code already, there is really no reason to use it. You can grab WTL or wxWidgets if you want a library, but I never found writing a window proc any more complicated, and simply banging controls on a window can just use dialogs (I'm pretty sure Express has the dialog designer, right?)

Re: "if (SUCCEEDED(hr)) ...", half agree here, I use (for example) "ASSERT_HR(animationManager->CreateStoryboard(&storyboard));" which will give me an assert failed dialog with the expression and HRESULT value, or "RETURN_FAILURE(expr)" which just returns the failing HRESULT. I've thought about throwing a HResultException, but it never seems any better than just C-style checking the value.
Tuesday, 29 June 2010 02:59:56 UTC
Modern C++ programming will have changed dramatically from what you're familiar with. Qt provides a set of cross-platform C++ libraries which rival .NET's in scope, quality and ease of use. The Boost libraries provide a truly staggering amount of functionality (several libraries have been absorbed into the STL as part of C++ Technical Report 1 and C++0x). For nearly all application domains, dynamic memory management is done exclusively using RAII principles and reference-counted smart pointers, which require near-zero mental overhead. For a garbage collector to achieve the same performance as RAII-based memory management, your program needs to use about 400% more heap memory. C++ currently sits unchallenged in a number of domains, since it's much easier to quickly produce error-free software in C++ than in C, and it's impossible to achieve the same performance using most higher-level languages. It's also nearly impossible to find a platform which C++ doesn't support. My day job is coding in C++, it's without question my favourite language.
Tuesday, 29 June 2010 03:53:56 UTC
I would argue that C++ turned into a niche language, overnight. In the 90's, there was VB (which was great for UI's and simple logic, but fell short with complicated stuff) - and C++ (which was great for complicated stuff, but fell short with the simple stuff). But C++ was the "catch-all" to fill a big void of functionality. When C# came out, and also offered "unsafe" chunks of code, that is the day that C++ started to rot instead of ripen. You could have the brevity of the "curly brace languages", the managed code which meant far less code, PLUS you could also temporarily dip down and write unsafe/unmanaged blocks of code - that fills the void.

What I mean is, what, 60%+ of your C++ code is memory management (as a rule)? That is overhead. That is wasted keystrokes (as you, Scott talked about a while back - where do you want to invest your keystrokes?). So the point is, C# can do absolutely everything that C++ can do, but still be easy to use (by leveraging managed code, when you can) - plus you have the whole .NET Framework.

So although some people may prefer C++, I think it will have it's semi-permanent niche going forward - that is low-level/device driver programming. It filled a void before when there weren't options. Not that there are, I can't ever see if coming back. It's far too wordy, requires a developer to type WAY too much overhead, and it's overly-complicated, for very little/no additional benefit. That's my $.02
Tuesday, 29 June 2010 04:13:37 UTC
As a college student, I think its a great language to start with. Even if there a lot supposedly *bad* things about it, its better to know what those are before joining the club. Now I've seen enough C++ and C# to know they can co-exist, simply because they cater different needs. There are some areas where C++ is THE way to go, the same goes for C#.
Tuesday, 29 June 2010 05:29:12 UTC
We used to have something like:
#define _HR(x) if (SUCCEEDED(hr)) {hr = (x);}


To write very lean, hr-safe code like:

HRESULT hr = S_OK;
_HR(AnimationUtility::GetAnimationManager(&animationManager));
_HR(AnimationUtility::GetTransitionLibrary(&transitionLibrary));
_HR(animationManager->CreateStoryboard(&storyboard));
// ... etc ...
return hr;

Also nice to have a debug version, like:
#define _HR(x) if (SUCCEEDED(hr)) {hr = (x); \
if (FAILED(hr)) { yarg(hr, #x); } }


I may have forgotten how to use cpp defines, but the idea is to be able to set a breakpoint in yarg... Or yarg can trace a log message with the hr and the stringized text of the expression x on the first failure in the method.
Tuesday, 29 June 2010 05:48:11 UTC
To learn .net, C#, Java, Silverlight, Visual Basic, Asp .net with advanced concepts, you can visit http://advanceddotnettutorial.blogspot.com
LearnDotnet
Tuesday, 29 June 2010 06:58:22 UTC
Scott,

Nice post. This last weekend I purchased Ivor Horton's Beginning Visual C++ 2010.

Having never done C++, I wanted to learn the language. I've got a few programs running; the speed is insane compared to managed code.

I'm looking to port a few of my WPF apps to C++ and see where this leads.

Thanks for post,

Cheers,

Karl
Tuesday, 29 June 2010 06:59:03 UTC
I am a games programmer in the UK and C/C++ is still very much the language of choice for all major platforms - Xbox 360, PS3 and Wii - and I can't see this changing any time soon. It would be impossible to optimize device-level code without binary operations and really being able to manage memory at the lowest levels. And templates and pre-processor commands mean we can construct some very robust systems efficiently.

I know its a steep learning curve but I always recommend new programmers to start with C++ because (unless you're really brave and want to get into ASM) its the lowest you're going to need to go these days.
acron^
Tuesday, 29 June 2010 07:04:55 UTC
Nice article.
Here is a question: chapter 3 for the hilo project on MSDN (http://msdn.microsoft.com/en-us/library/ff795785.aspx) says that hi-perf graphics programming on Windows 7 should be done in DirectX, which is made up of a set of COM-like APIs. Does this mean that COM is back in vogue? I thought when .NET was released 8 years ago the official line from MS was that COM would gradually go away; which i seriously doubted, since the entire .NET platform was built on top of COM.
bobby
Tuesday, 29 June 2010 07:08:21 UTC
I use C++ on an everyday basis on both Unix and Win32 professionally :)

VC Express is indeed quite limited (although the Win SDK will get you a lot and MFC is _not_ a silver bullet).
Managed C++ is completely up to date with modern times. Nothing like taking the bus back to the past. It's just the same as C# (unsafe?) but closer to the metal, as you like it.

> This source is extremely defensive, dutifully checking HResults at every step
It is the only way to survive in C++ professionally.

> I mean, seriously, if it doesn't Succeed, what are you going to do about it? If (NOTSCREWED(hr)), you know
If that is your stance, you might not be surprised some of the time. However you _will_ be screwed. Not all code handles 'bad input' the way you'd like it to. Really, the ultimate consequence of your thinking should be

if (S_OK!=hr)
abort();

instead of just forgetting it.
Seth
Tuesday, 29 June 2010 07:16:32 UTC
@Rob, what would you base your argument on that C/C++ is a niche language? This is far from the truth when you consider that most of what Windows kernel, MS Office, iPhone / iOS (specifically games), Linux / kernel, SDKs for PlayStation and Nintendo and more are built in these very languages... Take a look the TIOBE index for June, which shows C/C++ have increased, and combined are the most popular languages, by a significant portion.

My day job involves C# and C++ development. I develop in C/C++/Obj-C for iOS.

Cheers
Tuesday, 29 June 2010 08:16:01 UTC
I think the perceptions that C++ is hard and bogged down in manual memory management are both exaggerated, and down to bad experiences working on bad code bases. As others have said, good modern C++ will generally use forms of "auto pointers" (such as those in the Boost library) along with RAII techniques for memory managements. I developed C++ for 3.5 years in my previous job and I cant think of a single time I had to explicitly call "delete". I think people confuse the fact that C++ _can_ handle low level bit herding for the idea that its _all_ it can do, but C++ is as much an OO language as C# and has a far more advanced generic/templating system so is perfectly capable of as much abstraction as other languages.

I think there are two legitimate reasons people prefer other languages however.
1) The library : C++ is not a "batteries included" language and thus requires finding, studying, and using 3rd party libraries to achieve many common tasks for an application. Libraries for many tasks are very high quality and easy to use, but the extra step of having to find them is a deterrent.
2) Tooling : The meta data available in managed applications makes for more powerful and easier to use development / debugging tools.
Tuesday, 29 June 2010 08:49:01 UTC
Scott,
C++ is very much a core language and I doubt its going anywhere. If fact, I doubt i'd be as good at C# if i had not first cut my teeth on C++ (which is one reason I'm against using Python for introduction to programming courses).

I don't hate C++, I just hate pointers.
Tuesday, 29 June 2010 08:51:10 UTC
+1 for all the mentions of RAII in the comments. If you're doing C++ and not using RAII everywhere you're not doing it right :-)

C# is one of the few managed languages that supports any form of RAII (with the using statement), but it falls short of doing it properly - adding more burden at the call site, and leaving more scope (pun intended) for errors. It also makes the code less readable - see this blog post.

For some examples of where memory management is more of a pain in the managed world, see this blog post

And to clean up all that error handling, read this excellent article on Enforcements from Andrei Alexandrescu.

C++ is very much alive and in productive use (we've just rewritten a major system in C++ - it was originally in .Net). It's not perfect, and suffers from some legacy from the past. I'd like to see more mainstream interest in the D Programming Language, which is spiritually what C++ would be if it had dropped source compatibility with C, and included more "modern" idioms (including many not in C#).

Oh, and personally I'd avoid MFC like the plague :-) Use WTL if you must use a MS framework - although I've not done GUI work in C++ for years.
Tuesday, 29 June 2010 08:55:39 UTC
Semi-crazy idea, but what if Microsoft offered official support for Qt? C++ is very well supported at the tool level on Windows, but MFC can't compete with .NET.

Qt can, it's the equivalent of the .NET libraries for C++. Without Qt, I probably would have moved at least part of my coding to C# for the high-level libraries.
razvanpetru
Tuesday, 29 June 2010 09:20:23 UTC
IIRC (which I probably don't) I thought you could use the _com_ptr_t class to wrap up your interface and have it throw exceptions for you instead of having to check the hrs all the time. But I may well be misremembering.
Tuesday, 29 June 2010 09:24:08 UTC
Wow, C++ patterns have really matured since I coded in it so long ago, before the STL gained its S. Love all the talk about RAII. I know as I get back to exploring C++ more over the coming year, I'll need to take that into account. Any other big important global or architectural patterns you guys recommend?
Tuesday, 29 June 2010 10:40:01 UTC
@Pete I'd work through the Scott Meyer's "Effective C++" series (including the STL one), then Sutter's continuation in his "Exception C++" books, including "C++ Coding Standards", which he co-wrote with Alexandrescu. In terms of modern, idiomatic C++, and all the gotchas you need to avoid, that should sort you out.
There's a lot there to work through. If you don't think you can do everything just start with the Coding Standards book, which rolls up a lot of the other stuff anyway.
Tuesday, 29 June 2010 11:39:40 UTC
I don't think programming in C++ is as easy as some of the commenters make it look. For example, you don't have RAII for WinAPI or other C libraries by default. There are still many places which can go wrong with a subtle error. And when you talk about template metaprogramming, you should mention compile times as well. In short, my opinion is that you need to be an expert to work in C++ as painlessly as in C#.
Tuesday, 29 June 2010 12:28:48 UTC
@Quiark I agree that you need to have more than basic competency to use C++ safely (hence my long list of books to Pete).

However, as regards RAII and WinAPI - there are three options (and I wouldn't usually recommend working without once of these):

1. Use an existing wrapper/ helper framework/ library (such as WTL). Just not MFC unless you are forced to.
2. Write your own wrappers as you go. Just for the RAII bits, don't bother trying to encapsulate all the methods - you'll end up writing your own MFC otherwise. If you stick to the resource management it's not that much work - pays for itself after 2-3 calls.
3. Use generic RAII classes, such as ScopeGuard, or even Boost's shared and scoped pointers (which can manage non-memory resources too).
Tuesday, 29 June 2010 12:51:38 UTC
Great article Scott.
Sia
Tuesday, 29 June 2010 13:45:48 UTC
While a lot of people have abandoned C++ over the years there are places where it still has strong support. Although it isn't exactly the same, Objective C has some of the same pain points that C++ does and is still very much alive thanks to Apple. You will also see C++ where developers want highly optimized code like video encoders. Where you see an absence of C++ now is in the general enterprise application and I don't think anyone really wants to go back to C++ in that area. The lack of C++ coders is just a matter of where you look.
Tuesday, 29 June 2010 13:47:25 UTC
My question is "where is Microsoft going with C++?". We've been using VS 2008 to write C++ for an ObjectARX application. It involves a good deal of mixed/managed code and were suprised to find how lacking VS 2010 is to the mixed/managed C++ developer. Was none of the VS 2010 project accomplished withouth the /clr switch in a project or two?

What is Microsoft's vision for the future of C++ and managed code?

Jeff
Jeff Geer
Tuesday, 29 June 2010 13:48:37 UTC
I'd say that C++ is a more complex language than others, and has a lot more quirks that can bite you. The big problem is that there isn't a good GUI designer available from MS. MFC's just doesn't cut it. (There have been good tools out there, such as Optima++ from Sybase a decade ago and CodeGear's VCL, but they're not MS, so they don't get much love.)
Mike S.
Tuesday, 29 June 2010 13:53:53 UTC
Actually .net is not as easy as Microsoft wants people to believe. It is great for smaller applications, but if you need something more complex done, you will have a hard time. (I've been there.) With Windows forms intertwined with unmanaged Win32 code one needs to know all the quirks of both worlds to write an application that does not leak resources.

I'll personally switch to managed code when and only when Windows itself become managed (there is NO trace of notable managed code in Win7). And I do not see that coming any time soon - Microsoft is not that stupid, they know how problematic .net really is.
Tuesday, 29 June 2010 14:39:12 UTC
I programmed in C++ in college, and still do for some graphics work today, but mostly it's C#.

One thing I do rather miss about C++ is pointers. Yes most things in C# are technically already a reference, but I somehow found it easier to remember that when I had to manually de-reference things and pass addresses around myself. It's a good language for forcing yourself to practice good memory management, and to really think about how your classes are constructed.
Ben
Tuesday, 29 June 2010 15:23:28 UTC
"This source is extremely defensive, dutifully checking HResults at every step. I mean, seriously, if it doesn't Succeed, what are you going to do about it? If (NOTSCREWED(hr)), you know."

You could notify the user that something went wrong, restart the program, log the error. Isn't this basic stuff that you blogged about before? Doesn't it make the code more reusable to handle errors correctly? Did I miss you meaning here?
russellh
Tuesday, 29 June 2010 16:10:32 UTC
C/C++ may be mainstream for many, but it is niche for me. I help extend a mapping program that was originally written in assembly. For extensiblity it only supports old-style windows dll's. So, if I want to add a command to this program, I need to do it in C/C++ or at least connect up my C# with a C++/cli dll stub.

What amazes me is that most of the coders at work think that I'm some sort of wizard because I can to something/anything productive in C/C++.

BTW, I am be coding in C++, but I try to keep my syntax simple and in the pure C range. I may have to code a few more lines but ... for me it makes my code more readable and more maintainable.

Lee
Tuesday, 29 June 2010 16:19:50 UTC
The three languages most commonly used for scientific, engineering, and other numerically intensive applications are C, Fortran, and C++. (The scripting platform MATLAB is also heavily used, but it is more nearly a prototyping tool than a run-time environment, on account of performance issues.) It seems unlikely that this situation will change any time soon, since large volumes of new mathematical code are continually being written in those languages to add to the already huge legacy of decades' worth of existing code, much of which can still be handled by current compilers even though the languages themselves have changed significantly in their subsequent revisions. MS would do well to make sure that these close-to-the-CPU languages are well supported in Windows, through suitable native/managed interfaces. Otherwise, numerically intensive programming will become exclusively *NIX-based, and (as more and more programming moves to the same multi-core/clustered environments that now host most numerical computing) that could lead the way for the migration of mainstream commercial programming to that same environment.
wil
Tuesday, 29 June 2010 17:38:00 UTC
Yes !! Finally a post about my favorite language - bar none.

I'm a hobby programmer and I use Visual C++ Express Edition for some projects in pure win32. I don't use any MFC.

For smaller projects, I always find that frameworks just get in the way. Far simpler to overcome the learning curve once, write some reusable objects fitted to your purpose and move on. The good thing about the core API is that while frameworks come and go, the core API rarely changes - learn once, code forever :)

Here's a Sudoku program I wrote in visual C++ express edition in pure win32 (yes that's why the exe is so small, and a large part of it is the graphics)

jsiSudoku from Download.com - Visual C++ Express and pure win32


Tuesday, 29 June 2010 18:05:38 UTC
The majority of my programming is for embedded devices - and C/C++ is the rule for these applications. A lot of these targets may only have 4K/16K/64K of codespace total with maybe 256 or 4K of RAM. Most of them are not x86 instruction set based. Forget using .NET with its requisite overhead for these applications. That said, there has been a general downward trend of 32-bit micros into smaller embedded applications - but most of these are still bare metal or using some small OS that wouldn't support a managed .NET language with the available resources. And the .NET Micro Framework hasn't seemed to be able to gather much traction - unless you want a PC as your target device along with the associated costs. Maybe OK for a car or network appliance but not feasible for many whitegoods, cameras, photoframes or other devices...
Tuesday, 29 June 2010 18:53:49 UTC
C# is C++ without the compile times, and with vastly better refactoring tools. Even if C# were stuck at v2.0 I'd prefer it over C++. Eclipse is pretty good at refactoring C++, but Resharper blows it away (and IntelliJ for Java too).

I would like to use Java simply because it has tools that run on my Mac, but Java doesn't have pointer access or a way to map a struct to memory.
Tuesday, 29 June 2010 19:42:52 UTC
One of my most favorite advancements in Microsoft C++ development has been the C++\CLI language. Being able to mix .NET and native code is very much like having your cake and eating it too. I recommend it to anyone who is either hitting performance limits within C#/managed code or anyone doing any kind of P/Invoke or "unsafe" development in C# -- you don't know what you're missing out on.
Tuesday, 29 June 2010 20:34:52 UTC
I think that a lot of C# developers who have never seen a C++ compiler should really take a hard look at learning the language, and *without* any spiffy libraries that help to take care of the details of managing resources manually. There is a discipline that comes from working in a language that's perfectly willing to allow you to blow your own foot off that carries over its utility into any other language, managed or not.

I've seen enough fresh-faced youngsters who've never seen anything but C# with that perplexed look on their face that tells me they're thinking, "But I wasn't even *AIMING* at my foot!" to know that C# isn't protecting them as much as they believe it is. Just as I recommend that anybody who plans to delve into C take a look at Assembler, I recommend that anybody planning to work in C# take a look at C++. It never hurts to know what's really happening, and that knowledge will save you more often than not.
David
Tuesday, 29 June 2010 20:38:02 UTC
I'd rather program in Delphi or Java before I ever code one line in C++ any more. Five years of college were enough C++ for me. I mean if you REALLY like to be close to the metal, go all the way and write in assembler.
Wednesday, 30 June 2010 05:45:10 UTC
I base this on nine years experience in the .NET Framework languages, and 15 years in C++:

C# coding happens in time x, including debugging. No memory management bugs, decent Intellisense.

VB.NET coding happens in time 0.5x, including debugging. No case insensitivity bugs, undeniably superior Intellisense. Option Explicit On and Option Strict On wipe out whole classes of runtime and compile time programmer error bugs.

C++ coding happens in time 5x, including debugging. Oh, the mess you can make with a multi-inheritance template model... or COM. Or maybe it's just COM programming using C++; I'd much rather author COM servers in VB6 or a .NET language. I don't cringe; I've got a portfolio full of C++ COM servers, in- and out-of-process, and I came to hate it all compared to a direct-DLL/EXE or Managed approach to IPC.

(XAML coding? Time 10x, of course. Maybe Blend hides this, I dunno. Reverting to a late-bound declarative model and then gushing for four years about how much better it is without properly tooling it for developers, or documenting it at all well, made it difficult for me to take seriously. I hate getting HRESULT crashes at runtime, but only on test machines, and that ".toolbox" thing makes me wonder if I'm about to play a video game.)

Objective-C? Maybe 2x. The lack of a memory manager in Apple's stuff is aggravating, but at least its framework has been documented effectively, its models and patterns have been around for 25 years, and it doesn't suffer from absurd half-endorsed "open source" framework extension bloat and rug-ripping new-language inventions every other year. And to be equally as frank, XCode 4 looks really, really good.

Oh, and Scott? That body of source code for Direct2D *is* programming against an abstraction framework. Those are marshalled in-process COM calls, there. At that point you might as well just code it up in VB or C#.
Rob Perkins
Wednesday, 30 June 2010 06:32:22 UTC
Coding in C++ with the WIN32 API is a pain in the ass.
When I started to learn C++, I thought the WIN32 API was the only way to code GUIs under Windows. Because of that, I quickly hated this language.
Fortunately, I was completely wrong. There are numerous C++ GUI libraries.
WIN32 and the MFC have by far the worst APIs of those. They're not even cross-platform…

Then I discovered Boost, GTKmm, Qt, …
Finally, since several years, C++ is now my favorite programming language.
Florian
Wednesday, 30 June 2010 16:21:50 UTC
http://feeds.feedburner.com/ is blocked by the goverment of China, like twitter, facebook etc. You cannot believe that.
Scott, whether you can provide another rss source for users like me to subscribe.
Wednesday, 30 June 2010 18:08:57 UTC
The thing I loved about C++ is that because you had to handle all the memory or hook into the OS yourself you really learned how the computer and the OS worked. It is something of a trend in the younger programmers that I manage, that there is a lack of understanding with what is happening in the background (memory allocation, references/pointers, OS hooks), because the Framework and Language abstract that all away from the programmer. I feel it unfortunately makes worse programmers for it.
Scott Lance
Thursday, 01 July 2010 07:10:24 UTC
I started programming in C in the mid '80s on various platforms and loved it. Eventually I worked my way into DOS/Windows with Turbo C, Turbo C++, and Borland C++. Great compilers and a great language that made it a lot easier to move between operating systems. Then all of a sudden we're moving to Microsoft C++ and the language isn't so great any more. I know this has been years ago, but that implementation really soured me on the language.

For one, Microsoft's implementation feels overly cluttered with __DECLSPEC __WIN32 __WINNT, and whatnot. The implementation at the time was not even close to ANSI compliant (e.g. exception handlers were implemented as macros that leaked excessively) and didn't support much of the POSIX or ANSI class libraries so it was a real pain to move or reuse code across platforms. And I hate to say it, but MFC was never a real object-oriented class library--it was just a thin and clumsy wrapper around the Win32 API disguised as a class library. Maybe things have changed today, but that's the way it was back then.

I'm not really trying to bash Microsoft here since I love what they've done with C# and the .NET Framework, but the implementation of Microsoft C++ was the primary reason I decided to give up the language years ago. I tried picking up the language again last year with Visual Studio 2005/2008 and decided it wasn't worth the effort. I mean I am significantly more productive in C#, C# seems to be a much cleaner language, and I don't have to be overly concerned with ANSI/UTF-x/Unicode encoding issues or Pascal/C calling conventions.
Lothan
Thursday, 01 July 2010 08:42:53 UTC
Good post. Would be interested in more of the same.
Thursday, 01 July 2010 15:18:53 UTC
I know many people that programming in C#, but they do not understand what is happening under the hood. They can call the sort function on a ArrayList but they can not code their own sort function, and so on.

But most C++ programmers can code their own sort functions, and more. Most C++ developer have a better understanding of basic computer science, then C# developers do.
BobL
Thursday, 01 July 2010 15:53:31 UTC
I don't think C++ is so terribly different or more difficult to understand than C#. Often it's the libraries that are used along with it that make it complicated. Many C++ programmers have been paralyzed with options over the years. But personally, I wrote dozens of OpenGL programs in C++ without ever learning MFC. The OpenGL library was fairly simple and easy to follow back in the day, which made my overall experience with C++ rather pleasant actually.
Thursday, 08 July 2010 11:50:48 UTC
Hi Scott ,
The educational value of C++ is great. The other day , i took a presentation on how one can convert

int Add( int a , int b ) { return a + b ; } into

extern "C" int __declspec(dllexport) int __stdcall Add(int a , int b ) { return a+b; } to be exported from a DLL. I got a great standing ovation. With this simple program , i could explain extern "C" , exporting of functions , calling convention , Microsoft name mangling , Module definition file , Static linking of DLL , Dynamic Linking of DLL as well.

I found out that we can use WineLib to write Linux applications using Win API . Pls. check
my blog entry @http://praseedp.blogspot.com/search/label/WineLib

I purchased Windows via C++ by jeffrey ritcher yesterday and it was amusing to read it as well.


regards
Praseed Pai
Thursday, 08 July 2010 15:17:36 UTC
It would be interesting if someone at Microsoft (e.g. C# Team, or WPF team...) could develop a C# version of this C++ Hilo Image Browser, so we could compare the responsiveness, start-up time, and general user experience (and code complexity as well) of the C# version vs. C++ version.
Thanks.
A C++ Guy
Saturday, 10 July 2010 03:28:37 UTC
I mainly use managed languages now days. But I dip into C sometimes for stuff that requires a lot of windows api calls. And BTW, if you don't need to create a window, you can create a very short windows program:


#include <Windows.h>

int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow)
{
MessageBox(NULL, L"Hello, World", L"Hello, World", MB_OK);
}
Comments are closed.

Disclaimer: The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.