Programming is hard. Programming correct C and C++ is particularly hard. Indeed, both in C and certainly in C++, it is uncommon to see a screenful containing only well defined and conforming code. Why do professional programmers write code like this? Because most programmers do not have a deep understanding of the language they are using. While they sometimes know that certain things are undefined or unspecified, they often do not know why it is so. In these slides we will study small code snippets in C and C++, and use them to discuss the fundamental building blocks, limitations and underlying design philosophies of these wonderful but dangerous programming languages.
Sometimes I see code that is perfectly OK according to the definition of the language but which is flawed because it breaks too many established idioms and conventions of the language. I just gave a 90 minute workshop about Solid C++ Code at the ACCU 2010 conference in Oxford.
When discussing solid code it is important to work on “real” problems, not just toy examples and coding katas because they lack the required complexity to make discussions interesting. So, as a preparation I had developed, from scratch, an NTLM Authentication Library (pal) that can be used by a client to do NTLM authentication when retrieving a protected webpage on an IIS server. Then I picked out a few files, the encoding and decoding of NTLM messages, and tried to write it as solid as possible after useful discussions with ACCU friends and some top coders within my company. Then I “doped” the code, I injected impurities and bad stuff into the code, to produce these handouts. At the ACCU talk/workshop the audience read through the “doped” code and came up with things that could be improved while I did online coding (in Emacs of course) fixing the issues as they popped up. With loads of solid C++ coders in the room, I think we found most of the issues worth caring about, and we ended up with something that can be considered to be solid C++, something that appears to have been developed by somebody who cares about high quality code. Here are the slides that I used to summarize our findings. Feel free to use these slides for whatever you want. Perhaps you would like to run a similar talk in your development team? Contact me if you want the complete source code for the authentication library, or if you want to discuss ideas for running a similar talk yourself. I plan to publish the code on githup soon – so stay tuned.
I read a lot of code. Often I like what I see, but sometimes I see code that is perfectly OK according to the definition of the language but which is flawed because it breaks too many established idioms and conventions of the language. There are plenty of really good books about this topic, but most of them start at a slightly too advanced level – they assume that the reader already know about the basic stuff.
I have tried to make a little contribution by illustrating some of the really basic C++ idioms and conventions using a contrived but still complete example. Please take a look at this presentation.
When presenting this stuff, I usually hand out the first code snippet to a group of people, then I do online coding while the group suggests improvements and we discuss why it is so. Interesting enough, it seems like we always end up roughly at the same place. This presentation is just one of several paths that might happen when a group decides what to improve or not.
Oslo C++ User Group (ocppug) had their first meeting this week at The Scotsman. Twelve very knowledgeable men showed up for this meeting (Fredrik, Christian, Igor, Terje, Alf, Johan, Sergey, Samuel, Syver, Frans, Einar Otto and myself). The topic was C++0x, the up-coming C++ standard, hopefully to be finished by 2009.
I opened the meeting by giving a “Quick and dirty introduction to C++0x” (pdf, html). Einar Otto Stangvik provided a solid discussion about why multi-threading in a language not designed for concurrency is difficult. He gave a talk about “Threading in C++0x” (pdf). Terje Slettebø gave a talk about “Concepts in C++0x” (pdf) and he showed the reasons for introducing it into the language.
The meeting started at 1900, we finished the formal part of the meeting around 2130. Then we went downstairs to have some pizza, more beer and lots of good discussions. I really enjoyed this meeting, and I am already looking forward to the next meeting.
I am really excited about the upcoming C++ standard, nicknamed C++0x. It would be great to have a compiler that supports some of the proposed features, instead of just reading about them. So I set out to build the C++0x version of gcc.
Here is a quick description that worked for me (OS X 10.4):
$ svn -q checkout svn://gcc.gnu.org/svn/gcc/branches/cxx0x-branch gcc0x
$ cd gcc0x
This gave me the following error message:
configure: error: Building GCC requires GMP 4.1+ and MPFR 2.2.1+.
which I fixed by porting mpfr and gmp.
$ sudo port install mpfr gmp gmp-cxx-wrappers
and then I could configure, make and install like this (compilation takes about an hour):
$ ./configure --enable-languages=c++ --with-gmp=/opt/local --with-mpfr=/opt/local
$ sudo make install
$ /usr/local/bin/g++ --version
g++ (GCC) 4.3.0 20070628 (experimental)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Now I can write C++ programs and play around with new language features, such as static assertions, variadic templates, delegating constructors and decltype. I can also use some of the new library stuff, such as <regex>, <tuple>, <type_traits> and more… Cool!
Note, for some reason I get a warning during linking. It says:
/usr/bin/ld: warning can't open dynamic library: /libgcc_s.1.dylib ...
The code links and run so you can perhaps just ignore the warning, but here is a workaround that silence the linker:
g++ -Wl,-dylib_file,/libgcc_s.1.dylib:/usr/local/lib/libgcc_s.1.dylib foo.cpp
I am a big fan of unit testing, mainly because I see that it has a very positive effect on the analysis and design process. You program by intention, telling the computer what it should do rather than how to do it. I really enjoy working with JUnit when doing Java, but I have not found any good frameworks for unit testing in C or C++. I tend to implement my own mini-framework over and over again. It is now a kind of idiom that I keep in my C/C++ toolbox, just like I used to have an Enum idiom for Java.
So what is the problem with the current JUnit wanna-be frameworks out there? All the C and C++ frameworks that I have seen so far are bloated. Someone recently pointed me in the direction of a paper called “The Simples Automated Unit Test Framework That Could Possibly Work” by Chuck Allison. I skimmed through the article (not really bothering to read the text) to look for the actual code and realized immediately that it was just another bloated unit test framework for C++. The title kind of provoked me, but also inspired me to publish my small unit test idiom.
I have chosen to call it QUnit. It is under 100 lines of code. It integrates nicely into your development environment, and there are no bells and whistles. The framework is at sourceforge.
To see more about how to use it you should take a look at some slides from a presentation that I gave for some of my colleagues two weeks ago. The talk was about how test-driven development drives the design process. It presents my simple unit test framework/idiom and show how Uncle Bob’s Bowling Game Kata can be implemented in C++ using QUnit.