Enjoy

The news of the day is that I implemented the comment preview. So before leaving a comment you have a chance to read it again and make corrections if needed. I trust that this won’t reduce the number of comments just because you have more chances to change your mind in the process 🙂 Also let me know if anything’s wrong with the new version.
The link of the day is The Development of the C Language. This is a document written by Dennis M. Ritchie about the birth and evolution of the C language. Starting back in the days of the PDP-7 and Multics. The document explains the genesis of the C language and many of its idiosyncrasies. If you (like me before reading this) believe that the “++” operator was introduced because it mapped on a specific assembly instruction you should read it.
Ok, you have no time, so the answer is – the PDP-7 had no pre/post increment/decrement assembly instruction. Instead, it had just 8k of 18bits word of memory. So keeping things small was an urging need. And x++ saves a bunch of bits respect to x=x+1.

C++ To Gui or Not To Gui?

One of the most missing feature of the C and C++ standards is, at least for us everyday programmers, the standardisation of the GUI. What a bless could be a single approach to the GUI programming. Tools companies may focus their efforts to provide wonderful tools, programmers could stop wasting time in #ifdeffing around, and so on. Anyway looking at Java language maybe that ISO/ANSI committee were not so wrong in taking such a conservative approach. At only some 10 years after the language debut, Java, although strictly controlled by Sun, has 4 different (and incompatible) GUI toolkits (JWT, AWT, Swing, SWT) plus the J2ME GUI interface.

News from C++0x

Hello there, I’m back from holidays. Refreshing (actually a bit more colder than refreshing 🙂 holidays.I found this article from Stroustrup providing a quick glimpse on the next C++ standard. I know you’re holding your breath for my review of Design and Evolution of C++ and since I don’t want to loose any one of you two, you can start reading this. I found here the same guiding spirit and ideas that lined through all the book.
My favorite quotes:
– In my opinion, C++ has become too “expert friendly”
– Finally, C++ is so large, is used in so many application areas, and there are so many useful C++ design techniques, that we are all “novices” much of the time.
– I hope that after looking a bit at this example, your reaction will be “How simple!” rather than “How clever! How advanced!”
C++98 took several years, mainly because of a wealth of new things not existing before. This huge effort resulted in a large language and equally overwhelming library, capable of coping with most of daily uses of most of the C++ programmers. Unfortunately the effort hadn’t been equally spent on making things simple. The learning curve of the most advanced features of the language (e.g. the algorithm library, or the metaprogramming) is rather steep.
It seems that one of the main objective of the C++0x (where x is expected to be ‘9’) is teachability and simplification, so there are good chances that we’ll see definitive advances in these directions.

Humble programmer, this time for real

Sometimes even the most skilled programmer like me lose their humbleness and blame the compiler. Luckily for him (or her) reality is ready the put them back at their places. This is what happened to me today. It was afternoon and after some thick coding with containers and containers of containers I was rather tired, maybe in need of a break. I don’t believe in break so I went on and wrote the destructor.
Pretty simple stuff a for loop iterating through all the container elements and basically deleting them one by one.
So far so good, then I wrote the test case (I do believe in test cases) and I got a rather surprising behavior on the destruction of an empty container. My code was supposed to skip the destruction loop and get out of the destructor cleanly, instead what actually happened was that the loop code was executed once causing exception and exception dialog popping all around.
Puzzled I stared at the code without a clue. It was a for loop as thousands other I wrote.
So I composed a small source to test just that behavior (I do believe in small source test, too, they usually help you a lot understanding stuff). And I got it perfectly right. The code was doing what I expected. So I cut and pasted some types from the project into my test. Maybe after all it had something to do with the complex types I used.
But once more the small test code run perfectly.
I was quite astonished and tempted to blame the compiler. So I went for the assembly window just to have the confirmation that the code was actually different and that the project code compiled to execute the loop once.
My personal C++ GURU was away so I had to handle it all by myself. At this point I tried to do some more cut & paste to understand were the problem arise and… I got it… There was, right after the closing bracket of the for statement and before the opening curly bracket… there a SEMICOLON!
Feeling dumb would have been an giant leap upward respect to that I felt. I knew that very seldom the compiler is to blame, so despite of appearance I was the culprit. Also I should believe some more in breaks, just a few minutes to get from ‘fused’ back to ‘bright’. And … yes C++ (or C, in this case it is a common pitfall) is a loaded gun ready to shot into your feet by default… but, what the heck! A little warning from the compiler would have saved me quite a time.
In fact my personal programming style is to always use the curly brackets even when the block is empty. I found this to be more readable and less error prone. It would be nice to instruct the compiler to emit a warning when this rule is broken. If the programmer is so smart to do everything in the for parenthesis and doesn’t need to specify a loop body, then she could spend part of the saved time writing a pair of curly brackets.

Don’t fear, it’s only C++

One thing I’m sure about C++ is that it had a troubled history. It sprang to life in mid 80s as a C with classes, a language aimed to bring the then new object oriented paradigm to C programmers. The standardization was far ahead, but the language when arrived to the first programmers outside AT&T was quite stable: single and multiple inheritance, late binding, function and operator overload.
But quite stable isn’t as stable as stable, so the first addenda to the language arrived by the beginning of 90s: exceptions and templates.
The standardization arrived quite late (late 90s) in the history of C++ and rather than codifying the existing practice, as it had been the case for C, took the way of empowering the language. The committee added many features to the language, one for all the STL. The standardization of the C++ language had been an impressive result, if for anything else at least for being a result. With the heavy load of new features it would have been easy to get lost on the way killed by the committee overhead.
Today, by admission of the language creator himself, Bjarne Stroustrup, it is unlikely for a single programmer to have a perfect knowledge of the whole language (considered as both the core language and the library).
With this troubled history, compiler vendors had their hard time to keep up with improvement first and standard later. The standard presented for sure a hard challenge. Being compliant could be a too ambitious goal when you have actually to develop a product and put it on the shelves.
Incompatibilities, non-compliancies, misbehavior were only part of the problem that programmers had to deal with, the part was the increased level of complexity: whole new concepts in the template field, tons of components and functions in the library. Also from the development battlefields new concern arose. Exceptions which had considered an elegant way to deal with errors and anomalies turned out to be if not a false friend, at least a very difficult one. If not carefully planned and the code actually being written with exceptions in mind, the exception mechanism would yield no benefits and the problems caused by misuse are more or less the same you would have without using exceptions and ignoring anomalies.
Another pretty impressive result from the battlefield was the meta-programming. Templates were intended to describe a set of classes or functions that performed the same algorithm on different types. In order to do this some business have to be done at compile time. It was discovered, from a programmer, that this kind of business could be used to perform non-trivial computation at compile time. If generating a set of prime numbers at compile time could be not much interesting, the matter changes when the result of the generation is a parser or an optimal evaluation of complex expressions.
With this sort of history it is pretty natural that many programmers are scared by the new features of C++ (if not by the whole language itself). As any kind of fear, this too deserves to be analyzed and addressed. There no point in avoiding everything that hide some side effect, because this is the main mechanism behind abstraction – ignoring details of the lower levels. Instead the programmer should develop an approach that let her avoid pitfalls and undesired effects of the use and abuse of the language.
Also, nowadays most of the compilers are reasonably compliant with the standard. Even Microsoft Visual C++ is now a pretty good compiler by standard… standards. Therefore even from this point of view, programmers could stop worrying and start using the language to its full potential. And C++ has a huge potential being nearly the only language that allows the programmer to properly choose the right amount of abstraction to employ.
For sure C++ isn’t for the faint hearted, stealing someone words, C++ is like a gun loaded, ready to shot and aimed straight to your feet by default. I’m sure it’s what you want when there are grizzly around.

C++ Standard Library

(picture refers to the cover of a later version of the book) My approach to C++ was of unbound enthusiasm, until I started using it intensively. Then I got a more fair perspective on the language. Although it is still my language of choice (and it will likely be for a while) it is far from the elegance and simplicity that were the hallmark of the C language.After learning the ins and outs of the standardized C++, you’ll discover that the modern C++ language is a complex, heterogeneous, large pile of different bits and stuff patched together. The standardization process did no good to this and when you go in details of the standard C++ library all the mismatching comes to light.
Covering the whole standard C++ library is a daunting task, but this book does an excellent job. The aim of the book is to provide both a reference and a tutorial. Despite of these two, somewhat opposite, goals the result is very good. When you read it as a tutorial you can skim over the reference parts, glancing through tables and summaries since you just read the real stuff. When you use it as a tutorial you’ll find plenty of cross-reference both to descriptions and examples.
The only lacking in the book, by admission of the author himself, is about the io/stream section of the library which is not discussed in fine details. Anyway I found it very complete covering all the common and a good deal of the not-so-common usage of the everyday usage.
If you are going the C++ way and you’re already a programmer I strongly recommend this book along with “The C++ Language” by Stroustrup.