Friday, July 16, 2010

Of false dilemma's and C++

Periodically some e-famous programmer will rant about the evils of C++. This time it was Zed Shaw, though in the past Linus Torvalds has had a tilt at this windmill. These posts are always an entertaining read but what I find interesting in these discussions are the follow up discussions on sites like Reddit.

C++ is a complex language, no doubt about it, but it is entirely possible to manage the complexity. This has been a stated design goal of the language, any new feature introduced should be at no cost to the user should they not want to use it.

Several of these posters offer up exceptions as a case where C++ needlessly burdens the user, compared to its progenitor C. How do you manage memory in an environment that uses exceptions? I'm not going to lie, handling exceptions properly is a hard problem, so much so that it seems that half of Herb Sutter's Guru of the Week articles are on the subject of writing exception safe code. I'm going to go out on a limb here and say that it really doesn't matter how your application deals with exceptions because when one is thrown your system is in all likelihood hosed.

Imagine that you are in the land of C, free from classes and templates, how would you handle a scenario which could be a candidate for a thrown exception? Say malloc returns a null pointer (if that is a valid option, and your process isn't just killed by the operating system), what do you do? Realistically your program would bomb out.

So, now that C++ allows you to handle such a scenario, do you need to do anything about it?

No.

Let it fail, maybe print out a stack trace if you're feeling generous. Sleep well in the comfort that you will likely not have to roll your own data types and that your program is no less robust than if it were written in C.

No comments:

Post a Comment