C++

Yesterday, one of friend called me as she needed some help in C++ for her TA assignment. She had to solve around 10 problems, all dealing with basics of C++ and in an increasing order of difficulty. And even after me explaining her the solutions, she seemed to be quite frustrated with solving them. She told me that the moment she thinks she has learnt quite a bit of C++, she realises that it is not enough.

I think, this feeling of hers is quite common for someone beginning to learn C++. My advise to someone would be to try learn the concepts of OOPS and think of C++ as a language that implements those concepts. Also, while learning they need to try to abstract any C++ program at different levels simultaneously. Most people concentrate on syntax while learning a new language, which does not serve the purpose. And as far as C++ is concerned, its syntax is very easy for anyone who is a little bit familiar with C. The idea is to understand different concepts such as encapsulation, inheritance, polymorphism which C++ offers and to understand how those find application in real life problems. Learning C is quite easy as it adopts a procedural approach. However learning C++ on the other hand needs persistance. OOPS concepts cannot be grasped in first read. But if one persists, it isn't long before one starts seeing through the capabilities of the language. It is usually that one moment, which changes everything. You then start appreciating the strengths and accepting the weaknesses of the language.

Well coming back to the topic, my friend's frustration reminded me about the interview given by Bjarne Stroustrup, the inventor of the C++ language. I would like you to first read the interview at http://www.oceanwave.com/technical-resources/humor/c++-hoax.html , before reading the rest of the article.



It is quite obvious that Bjarne never gave that interview, but a lot of people identify with the questions asked by the interviewer, especially those who are still in the learning curve for C++.

Now, you can go through the following link to read the real interviews given by Bjarne.

Part 1: http://www.techreview.com/Infotech/17831/
Part 2: http://www.techreview.com/Infotech/17868/

The interviews were conducted in two series. Apparently there were a lot of comments to the 1st interview and hence the tailor-made questions were addressed in the 2nd interview. Therefore, the 2nd interview makes a much more interesting read.

For those who do not have the time, below are the highlights of some important issues on which Bjarne talks about:

1) Examples of some great software developed in C++ :

Bjarne : "Google! Can you even remember the world before Google? (It was only five years ago, after all.) What I like about Google is its performance under severe resource constraints. It possesses some really neat parallel and distributed algorithms. Also, the first Web browsers. Can you imagine the world without the Web? (It was only about 10 years ago.) Other programs that I find cool are examples of embedded-systems code: the scene-analysis and autonomous driving systems of the Mars Rovers, a fuel-injection control for a huge marine engine. There is also some really cool code in Photoshop's image processing and user interfaces. What I like about these programs is how they are structured to be reliable and responsive under pretty harsh resource constraints. Some of Photoshop's ways of managing internal complexity (for instance, the graphical user interface [GUI] layout and access from image-processing algorithms to the pixel data) are just beautiful."

(2) Next big conceptual shift in the design of programming languages :

Bjarne : "All that said, I don't know what the next major conceptual shift will be, but I bet that it will somehow be related to the management of concurrency. As programmers, we have been notoriously bad at thinking about lots of things happening simultaneously, and soon our everyday computers will have 32 cores. Instead, each programming paradigm adds to what worked previously, and as a paradigm matures, it is increasingly integrated with previous paradigms.

Kristen Nygaard was fond of saying that multiplication didn't completely replace addition, and, by analogy, whatever would come after object-oriented programming would include object-oriented programming as a subset. I tend to agree. The evolution of C++ was guided by this view, and the evolution of Java and C# provides further examples."

(3) Computer languages remain generally difficult to learn :

Bjarne : "Obviously, we don't want our tools--including our programming languages--to be more complex than necessary. But one aim should be to make tools that will serve skilled professionals--not to lower the level of expressiveness to serve people who can hardly understand the problems, let alone express solutions. We can and do build tools that make simple tasks simple for more people, but let's not let most people loose on the infrastructure of our technical civilization or force the professionals to use only tools designed for amateurs. We need relatively complex language to deal with absolutely complex problems."

4) On maintaining backward compatibility with C, its pros and cons (evolutionary approach vs revolutionary approach) :

Bjarne : "Java shows that a (partial) break from the past--supported by massive corporate backing--can produce something new. C++ shows that a deliberately evolutionary approach can produce something new--even without significant corporate support. To give an idea of scale: I don't know what the marketing budget or Java has been so far, but I have seen individual newspaper advertisements that cost more than the total of AT&T's C++ marketing budget for all time.

Another reason-- probably even more important--is that organizations prefer interfaces that are in the C/C++ subset so that they can support both languages with a single effort. This leads to a constant pressure on users not to use the most powerful C++ features and to myths about why they should be used "carefully," "infrequently," or "by experts only." That, combined with backwards-looking teaching of C++, has led to many failures to reap the potential benefits of C++ as a high-level language with powerful abstraction mechanisms."

5) On .NET and C# :

Bjarne : ".Net is "the progeny" of a large organization, though Anders Hjelsberg has a large hand in it through C#, the language he designed, and its libraries. I suspect that C++ played a significant role, but primarily through MFC (which is not one of the more elegant C++ libraries) and as an example of something perceived as needing major improvement. C# as a language is in some ways closer to C++ than Java is, but the main inspiration for .Net and C# is Java (specifically, J2EE). Maybe C++ should be listed as a grandparent for .Net but as both a parent and a grandparent of C#."

(6) On portability :

Bjarne : "Personally, I'm a great fan of portability. True, you cannot write a complete application of any realistic size without introducing some system dependencies. But the question is how deeply integrated into the application those system dependencies are. I prefer the application to be designed conceptually in isolation from the underlying system, with an explicitly defined interface to "the outer world," and then integrated through a thin layer of interface code."


Personally I think there is one area that C++ loses out on as compared to its counterparts and that is the area of concurrency.

When the C++ Standards Committee was creating the initial C++ Standard, a concurrency mechanism was explicitly excluded because C didn’t have one and also because there were a number of competing approaches to implementing concurrency. It seemed too much of a constraint to force programmers to use only one of these.

The alternative turned out to be worse, however. To use concurrency, you had to find and learn a library and deal with its idiosyncrasies and the uncertainties of working with a particular vendor. In addition, there was no guarantee that such a library would work on different compilers or across different platforms. Also, since concurrency was not part of the standard language, it was more difficult to find C++ programmers who also understood concurrent programming. Another influence may have been the Java language, which included concurrency in the core language. Although multithreading is still complicated, Java programmers tend to start learning and using it from the beginning.

Lastly, I would like to echo what Bjarne had to say in the interview:

Bjarne:
"I'm sure that for every programmer that dislikes C++, there is one who likes it. However, a friend of mine went to a conference where the keynote speaker asked the audience to indicate by show of hands, one, how many people disliked C++, and two, how many people had written a C++ program. There were twice as many people in the first group than the second. Expressing dislike of something you don't know is usually known as prejudice. Also, complainers are always louder and more certain than proponents--reasonable people acknowledge flaws. I think I know more about the problems with C++ than just about anyone, but I also know how to avoid them and how to use C++'s strengths."