Jeeves with Classes

The time_t's Are a-Changin' (into system_clock Time Points)

2012-01-09T07:56:00.000-08:00

2011 came and went, but left us with a new ISO C++ standard, codenamed C++11. I've looked for an updated edition of "The C++ Programming Language", or at least some other full-sized book on the subject, but the best I've been able to find at the time of writing this is Scott Meyers' "Presentation Materials: Overview of the New C++", as recommended by Herb Sutter. It's not perfect (it doesn't cover everything, it does have a few bugs, and it's not completely up to date with C++11), but it's good and required reading for serious C++ developers.

Probably the single most important change in the language itself is the addition of rvalue references, with all that comes along with them, such as move semantics and perfect forwarding.

I'm happy to see auto_ptr, with it's freak copy-is-move semantics, go away to be replaced by unique_ptr. I'm also very happy to see added support for custom deleters in the new _ptr classes: that makes the problem of resource acquisition and release that I've written about here easier to handle.

Anything involving callbacks is now easier, thanks to function. And good riddance to exception specifications and the (template-related) export keyword that almost no C++ compiler implemented anyway!

There's now support for writing multithreaded applications, but semaphore classes are conspicuously missing. You can simulate a semaphore with condition_variables, but that misses out on native OS semaphore support. Why semaphores didn't make it into C++11, I can't imagine. And why no sockets in C++11? They're as ubiquitous and necessary today as mutexes.

I'm disappointed to see that a subtle feature that would have solved a lot of issues did not get into C++11: the compiler could (and in my humble opinion, should) make all destructors of classes with at least one virtual member function virtual as well. A class with a virtual member function is most likely meant to be inherited from, and in case the destructor releases some resource, destroying a derived object through a base class pointer is very dangerous, unless the base class' destructor is virtual. Making it virtual by default in such a case would thus greatly improve safety.

There are, of course, plenty of other new things in C++11: variadic templates, Java-like inherited (and delegating) constructors, the auto keyword (guess what that does), range for() statements, and so on.

You might like to read Bjarne Stroustrup's C++11 FAQ, where, in response to "what do you think of C++11?", he states that he's "still an optimist". C++ started as "C with classes", making it easier than stuffing pointers-to-function into structs. Then, it got templates, adding generic programming to its object-oriented and procedural capabilities. Then, Lisp-like functional programming got added on top of the generic programming support with the popularity of template meta-programming. While it's still true that, with C++ (11 or otherwise), you don't pay for what you don't use, it's also still true that you have to know about almost everything in order not to accidentally shoot yourself in the foot. And everything is getting bigger. C++ is one of the areas of software development where "junior" and "senior programmer" are heavily meaningful terms. If your company can't afford at least a senior mentor to 2-3 junior C++ programmers, you might be better off using plain C, Java or C#.

C++11 improves some things, leaves others out, and complicates yet others (e.g. container::cbegin()/container::cend() added for auto). If you're comfortable with C++98, there's still plenty of time to get acquainted with it's features (and quirks), since most compilers don't yet fully support it. It'll be some time until C++11 gets fully implemented by compiler vendors, and it is very likely that some of it's features will never be implemented by some of them (just like C++98's template export keyword). This is what GCC 4.5.3 had to say to me today (on my Gentoo Linux system):

$ g++ future.cpp
In file included from /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/include/g++-v4/thread:35:0,
from future.cpp:2:
/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/include/g++-v4/bits/c++0x_warning.h:31:2: error: #error This file requires compiler and library support for the upcoming ISO C++ standard, C++0x. This support is currently experimental, and must be enabled with the -std=c++0x or -std=gnu++0x compiler options.

Punk Rock Programming

2008-12-06T11:48:00.000-08:00

Having had the privilege to experience a couple of days' worth of temporary tinnitus due to attending Marky Ramone's Blitzkrieg show (picture courtesy of rockXpress.ro), I've been thinking about a conversation I've had a few years ago with an ex-colleague about C and C++. Why? I'll tell you in a minute, but first: if you don't know who the Ramones are, give them a listen right now.

Now, my then colleague expressed his reservations about the continued use of the C programming language. He argued that C is now mostly a subset of C++, therefore C should probably be better off put away somewhere and forgotten. No more separate committees for ANSI C and ISO C++, resources spent more efficiently, and so on. The argument has some justice to it, and I'm sure the hardcore geek readers' eyes are gleaming with anticipation of a rainy weekend with a hot technical debate over whether compiling with one compiler for both programming styles should generate exception handlers for the low-level code by default, but that's really not what I want to talk about.

What I want to talk about is the human component to using a tool such as a guitar, or a programming language. Programmers tend to believe the myth that efficiency has to be desired at all costs, and by organizing the code, and indeed the workplace in a certain "One True (TM)" manner all will be well with the world. Incidentally, so did the Nazis.

But there's a big difference in the overall philosophy of most of the people who prefer C vs. the axioms of the people who prefer C++.

C++ is more like classical music. If you want to be a classical music composer, or simply a competent classical music instrument player, you need to train a lot for dexterity, to master the music modes, to understand how intervals and modes relate to chords, to study the work of the great composers, to learn sight-reading music, and so on. So you have your Mozart, your Mahler, and your Yehudi Menuhin.

But, what if someone simply enjoys music, and wants to have fun with it? Make the best of what one can learn in a short time with limited resources? After all, my high school psychology manual used to define one's level of intelligence as being directly related to one's capacity of doing more with less. So then, you have your Ramones, your Nirvana, your Stooges, your Mudhoney. Two-note chords, at most five distinct chords in a song. Cheap one-pickup guitars. But you react to it. Things get done. You're moved by it, not in the same way as you would with classical music, but neither in a way that's better or worse.

C gets things done. It's almost assembly language, but then again it's not. It's direct access to your computer. And you can learn it from a less-than 100 pages book ("K&R"), as opposed to the ten times as thick "The C++ Programming Language".

Both languages have their place, and as long as they will be actively supported by their respective committees (and more importantly, their developer communities), this will continue to be the case.

The GPS Coordinates of Jung's Tower

2008-10-11T09:28:00.000-07:00

As technology workers, we're all too familiar with pro-technology arguments. However, Donald Knuth, author of "The Art of Computer Programming", and king of the geeks, states that "he has been a happy man ever since January 1, 1990, when he no longer had an email address".

C. G. Jung, not a big hacker himself, but still the father of analytical psychology (aptly, also known as "Jungian psychology"), has this to tell us in his autobiographical project "Memories, Dreams, Reflections", in a chapter called "The Tower":

"Our souls, as well as our bodies, are composed of individual elements which were all already present in the ranks of our ancestors. The 'newness' in the individual psyche is an endlessly varied recombination of age-old components. Body and soul therefore have an intensely historical character, and find no proper place in what is new, in things that have just come into being. That is to say, our ancestral components are only partly at home in such things. We are very far from having finished completely with the Middle Ages, classical antiquity, and primitivity, as our modern psyches pretend. Nevertheless, we have plunged down a cataract of progress which sweeps us on into the future with ever wilder violence the farther it takes us from our roots. Once the past has been breached, it is usually annihilated, and there is no stopping the forward motion. But it is precisely the loss of connection with the past, our uprootedness, which has given rise to the 'discontents' of civilization and to such a flurry and haste that we live more in the future and its chimerical promises of a golden age than in the present, with which our whole evolutionary background has not yet caught up. We rush impetuously into novelty, driven by a mounting sense of insufficiency, dissatisfaction, and restlessness. We no longer live on what we have, but on promises, no longer in the light of the present day, but in the darkness of the future, which, we expect, will at last bring the proper sunrise. We refuse to recognize that everything better is purchased at the price of something worse; that, for example, the hope of greater freedom is canceled out by increased enslavement to the state, not to speak of the terrible perils to which the most brilliant discoveries of science expose us. The less we understand of what our fathers and forefathers sought, the less we understand ourselves, and thus we help with all our might rob the individual of his roots and his guiding instincts, so that he becomes a particle in the mass, ruled only by what Nietzsche called the spirit of gravity.

Reforms by advances, that is, by new methods or gadgets, are of course impressive at first, but in the long run they are dubious and in any case dearly paid for. They by no means increase the contentment or happiness of people on the whole. Mostly, they are deceptive sweetenings of existence, like speedier communications which unpleasantly accelerate the tempo of life, and leave us with less time than ever before. Omnis festinatio ex parte diaboli est - all haste is of the devil, as the old masters used to say.

Reforms by retrogressions, on the other hand, are as a rule less expensive and in addition more lasting, for they return to the simpler, tried and tested ways of the past and make the sparsest use of newspapers, radio, television, and supposedly timesaving innovations."

Code Reuse: It Would Be a Very Good Idea

2008-07-19T22:00:00.000-07:00

As you must have noticed, the title of this article paraphrases a Ghandi quote: When asked what he though of Western civilization, he famously replied "I think it would be a very good idea".

Code reuse in the software industry is an elusive beast. Words such as "reinventing the wheel" are often being paraded around by people across departments even remotely connected to computer programming, and everyone seems to be thoroughly convinced about the perils of re-writing code that's already been written, of solving problems that have already been solved.
Unless, we need to reuse code for our project.

It comes as no surprise to most seasoned software developers that code reuse almost never happens. That is not to say they endorse the situation. But it's just a fact of life. Why? That's a tough question to answer.

In today's fast-paced computer software industry, developers are being hired right out of highschool, or in their junior college years. They come from all possible backgrounds, and most of them have not properly studied their field for the full time required to master their tools. They tend to do whatever learning they can on the job, and then float towards management positions as soon as they've mastered enough to finally be able to be of proper use.

A programming language such as C++ takes years to master. Add some time for learning how to use a control versioning system tool, some build tools, a couple of non-trivial source code editors, the quirks of a supporting OS, basic network administration, some APIs, and properly study a specific business domain, and you've got a good chunk of your life spent working to master your field. Garbage-collected, user-friendlier languages such as Java or C# take somewhat less time to learn, but still require considerable effort to master.

To be able to reuse code properly one needs to:

have enough experience to know where the project will be going, and anticipate usable solutions. For example, your application might only need to be Linux-compatible now, but why not be able to compile it for FreeBSD in the future? Making that decision upfront will save development time in the future, while incurring little or no overhead in present development.
know as many tools (programming languages, build tools, operating systems, UML tools, etc.) as possible, or at least know about them, and be willing to properly study them if need arises.
anticipate maintenance costs, and project risks. For example, it might pay off to use a stable open-source library maintained by other people if your team cannot afford to maintain it's own custom version. Your team can find bugs and send patches to the maintainers anyway, so debugging is still possible, but the bulk of the work is done by somebody else. That way, you will also have the benefit of others' experience - all users will find bugs and send patches, so by the next version there'll be more bugs fixed than there would have been if you were the only library users. This approach also pays off if your team has little or no resources available for testing this piece of software - you'll be testing it a bit by using it, and so will it's other users: all in all a lot more testing than you alone could have done.
have an open mind and realistic expectations about your team's competency level and schedule. This is usually very hard to do. The line of thinking is usually "we are very competent, we intimately know the project, and custom code is the best, and we don't need all that bloat that somebody else's library will bring into the project". Sometimes, that is indeed the case, but for a huge percent of projects that's a trap. We soon discover that "that bloat" was there for good reason, and now we either need to switch to that implementation, or write our own "bloat". Obviously, your team really is the best - you're in the former category. Just keep this guideline in mind for your next job, though...

The conclusion? It almost always pays off to reuse code. Not only from your company (not reusing company code is only excusable if it's very bad code, and then that's a lame excuse). Find a mature product, find out what types of support it offers (forums, mailing lists, live technical support, knowledge bases, etc.), and start using it. You'll roll out your software on budget and on schedule, you'll avoid grunt work, you'll make your users happy, you'll make the library authors happy, and you'll make yourself happy.

A Memetic View on Project Management

2008-07-03T03:43:00.000-07:00

Having recently discovered Jon Whitty, I've stumbled upon his critique of project management, with reference to the PMBoK:

"This paper makes no claim of uncovering a secret or hidden message, but it does profess to decipher the memetic code of project management (PM) to reveal the real reason why PM is so prevalent.

Why is PM so prevalent? Even though the discipline of PM is ubiquitous in Western society it exhibits many inexplicable and contradictory aspects. The prevalence of PM continues to increase across all business sectors and all geographical regions, with companies suggesting that projects are a vital contributor to future business success, and that projects are the key enabler of business change. PM is also consuming more of corporate training budgets than ever before. An increasing amount of Universities are also delivering PM courses at undergraduate and postgraduate level, and at least one corporation is supporting the teaching of PM at high-schools. The bulk of such training and teaching is modeled on the Project Management Institute (PMI®) Guide to the Project ManagementBody of Knowledge (PMBOK Guide).
However, despite the prevalence of PM, organizations report that project failure is commonplace and that the delivery of projects to cost, time and benefits is not improving. It is therefore valid to ask why PM is so widely and commonly occurring, accepted, and practiced, when it still fails to live up to expectations."

Whether the gentleman is right or not, I will not venture to say. What I will say, is this: his answer will certainly surprise you, and most likely completely change the way you've been thinking about the issue.

C++ System Programming Rule: Always Join() Threads Referencing External Objects

2008-06-25T06:45:00.000-07:00

Let's assume you want to instantiate an object of type C in function f(). Function f() then proceeds to create a new thread, and passes a reference to this object to the new thread. The new thread uses the object, and then exits, but f() does not join() the new thread (that is, it does not wait and make sure that the new thread has finished running before f() itself exits). A snippet of pseudocode is worth a thousand words:

void thread_fn(const C& c)
{
  c.perform();
}

void f()
{
  C c;
  system::create_thread(thread_fn, c);
}

Creating a thread and then not caring about when it stops seems to especially make sense with UNIX detached threads. But it almost never makes sense to use detached threads with C++. Because C++ programs tend to use objects. And C++ objects get destroyed.

Let's consider the following scenario:

1. F() creates the C instance c. F() then proceeds to create a new thread with the fictional system::create_thread() function. We will assume that this call also starts the new thread, and it runs the thread_fn() function in the new thread.

2. System::create_thread() has now exited. The new thread has been created, but thread_fn() is not yet running in this new thread. F() then exits, and in doing so destroys the C instance, c, the object that had been passed-by-reference to the new thread function.

3. Thread_fn() starts running, but it now has a reference to a destroyed object.

What's the consequence of this? The program will abort. If perform() is a virtual member function of C, your program will most likely abort with an error along the lines of "pure virtual function call". That is actually what happens most of the time, and I've seen many senior developers scratching their heads in disbelief at the possibility of having had been able to instantiate a C++ abstract base class, which is what the problem appears to be at first sight.

So remember, join() is your friend. Do not allow your main thread to exit until you've join()ed all of the threads it has created. It's actually a good rule of thumb, regardless of the programming language you're using, but it especially applies to C++, where stack objects get destroyed when they go out of scope.

Open Source vs. Closed Source Projects: A Career Choice

2008-06-13T06:11:00.000-07:00

Open source does not necessarily mean free software. My favourite CORBA ORB, Orbacus, is not free, but it's open source - that is, you also get the source code with the precompiled stuff. Conversely, CREdit, a lightweight, highly customizable text editor, is free software, but you can't get the source code for it.

Also, free or open source software doesn't mean that the people working on the project don't get paid. There are many complex ways of generating revenue.

Here's the case for working on open source software:

it will improve your skills as a software craftsperson. It's widely known that we perform better when we know that our peers are watching our work. Therefore, we write better code knowing that your peers will actually see and critique it. With more people watching, you also get more bug reports and patches.
there's personal visibility. With most closed source companies, your contribution will be the work of "<insert your company name here> <insert your project name here> team". An open source project more often than not provides some way of name-recognition for its contributors.
you will make contacts within the community, thus creating opportunities for meaningful future work, hopefully even skipping repetitive, boring steps such as job interviews (since your competency has already been proven - everyone has access to the details of your work).
companies are sold, become bankrupt, or simply decide to shut down whole departments. License permitting, an open source project can continue it's life even after the original maintainers move on, so you'll be more likely to be able to continue your work if you're so inclined.

C/C++ System Programming Rule: If You Must Write Single-Threaded Network Servers, Always Prefer Poll() to Select()

2008-05-29T00:20:00.000-07:00

Let's assume you're going to write a C/C++ network server application, and you need to decide how to implement the code responsible for accepting connections from clients, and serving the clients simultaneously after accepting the request. Typically, you'd do this in one of two ways:

Write a multithreaded application, with one dedicated thread blocking in accept(). Once a connection has been established, take the new client socket handle, pass it to a worker thread and resume waiting for a new connection in accept().
Use a single thread for accept()ing and processing client requests. If you'll look this method up, you'll find that most examples illustrate using select().

While conceptually there's nothing wrong with using select(), there's a serious problem with it's implementation that makes it unsuitable for real-world server applications that need to scale well. The problem is this:

"Macro: int FD_SETSIZE

The value of this macro is the maximum number of file descriptors that a fd_set object can hold information about. On systems with a fixed maximum number, FD_SETSIZE is at least that number. On some systems, including GNU, there is no absolute limit on the number of descriptors open, but this macro still has a constant value which controls the number of bits in an fd_set; if you get a file descriptor with a value as high as FD_SETSIZE, you cannot put that descriptor into an fd_set."

On my Slackware Linux system, FD_SETSIZE is #defined as 1024 in /usr/include/bits/typesizes.h. BUT, it's plausible that your application might want to be able to handle more than 1024 socket descriptors at one time. And once you get socket descriptor number 1025, put it in your fd_set and give that to select(), all bets are off.

Some systems will do the right thing if you #define your own FD_SETSIZE, but that's not crossplatform, and even worse, it's very error-prone. What about libraries you might be linking against, that have already been compiled using the default FD_SETSIZE value?

You might think that an application with more than 1024 sockets opened at the same time is probably not a good idea, and you'd probably be right. However, you don't even need to have more than 1024 socket handles active simultaneously. All you need to do to get to "there be dragons" territory is to have one socket handle with the value 1025 and try to use that in a select() fd_set.

The alternative? Meet your new friend poll().

Efficient Thread Pool Design

2008-05-18T03:57:00.000-07:00

If you've ever needed to design a non-trivial network server, you've probably needed your application to be able to handle requests as quickly as they come. Leaving aside the old "threads versus processes" UNIX debate (threads are better if you need efficiency and portability outside the fork() realm, processes are better for high risk workers where one crashed worker won't bring the whole application down), and assuming we've chosen threads, we now have two choices:

Create new threads on demand. That is, once a new connection to our server is initiated, start a new thread and assign it the required task. This approach works best where either the server will have considerable idle time (in which case it won't need to waste unused thread handles), or where the instructions needed to create the new thread take much less CPU time than the actual "business" code.
Create a thread pool. At application initialization time, create all the threads you think you will need. Thus, the thread creation/start code will only run once. After that, all the threads will wait for requests to handle. That way, once a request comes, it will be handled in the fastest manner possible. Another advantage of this approach is that we'll know upfront if the system can handle all the threads we think might be running simultaneously at any given time (something similar to Herb Sutter's suggested strategy for dealing with std::operator new's std::bad_alloc exception handling - just allocate and touch all the memory you think you're going to need upfront and use that pool for your application).

Now, assuming we've decided to use a thread pool, the first solution that we usually think of is "the queue solution". The queue solution goes something like this (pseudocode):

// Main thread:

while(keepAcceptingConnections) {
 socket request = server_.accept();

 requestQueueMutex_.lock();
 requestQueue_.push(request);
 requestQueueMutex_.unlock();

 requestQueueSemaphore_.post();

 // if error, set keepAcceptingConnections, etc.
}

You'll notice that what we need to use is:

A mutex, needed to synchronize read/write access to the request queue.
A request queue. This is where you usually put the sockets returned from accept().
A semaphore, needed to signal to the worker threads that there's one more request for them waiting in the queue.

Here's how you might write a worker thread:

// Worker thread:

while(keepRunning) {
 requestQueueSemaphore_.wait();

 requestQueueMutex_.lock();
 socket request = requestQueue_.pop();
 requestQueueMutex_.unlock();

 // Do actual work with the request socket,
 // set keepRunning, etc.
}

That's the time-honoured, and the simplest, design for a thread pool. BUT, there's something better. It's called the leader/follower pattern, and it eliminates the need for the requests queue, the semaphore, and separate implementation for a main and worker threads.

What the pattern proposes, is that there be only one thread type (no longer a main thread and a worker thread design), but that this thread go through several states. That is, a thread in the thread pool can be in the "leader state" at one time, and the "follower state" at another. Only one thread can be a leader at one given moment, but we can have more follower (or worker) threads running simultaneously. If I've managed to confuse you, the following pseudocode snippet will make it all clearer:

// Leader/follower thread:

while(keepAcceptingConnections && keepRunning) {
 // Follower state:
 serverSocketMutex_.lock();

 // Leader state:
 socket request = server_.accept();
 serverSocketMutex_.unlock();

 // Follower state:
 // ... do actual work with request here
}

So, no more queue, no more semaphore. As soon as a request comes, the thread simply starts handling it, and unlocks the mutex controlling the accept() for the next thread available for entry into the "leader" block of code. If all threads are busy, there's no accept() in progress, so the number of acceptable requests is always equal to the number of available idle threads.

It can, and often does, get more complex than that, but that's the gist of it. For a more in-depth analysis of the subject, refer to the full paper by Douglas Schmidt and Carlos O'Ryan.

Debugging When the Debugger Can't Help

2008-05-13T23:35:00.000-07:00

I've recently had a discussion with a couple of friends about exceptional cases where an application crashes, but the debugger is completely off-mark about the place that causes the problem.

As an example (and in keeping with UNIX-style examples), consider an application that produces a core file, and it's compiled in debug mode (-O0 -g). But, when we load the application file and the core file in gdb, and try to obtain a backtrace, we end up in some perfectly innocent std::string member function call.
That can't possibly be it, so after a few hours of debugging something dawns on us: could it be that gdb is wrong? Well, technically speaking, no, it can't. But the core file is irrelevant.

Why? Well, most of the time that happens because of what's generally referred to as "a double-free" issue. In C++ terms, that tends to happen when a smart pointer class doesn't have well-thought-out copy semantics, and two smart pointer instances end up pointing at the same memory address via their identical underlying dumb pointers. When the first smart pointer gets destroyed, it calls "delete p_;", then the second smart pointer gets destroyed and does the same thing, for the same value of "p_".

But it doesn't need to be a pointer. Closing the same file handle, or socket handle, or mutex handle twice can have the same effect. Basically, anything you can think of as a resource that you acquire, and then need to release, can get you in this fix.

At other times, invalid debugging information is caused by invalid memory access: buffer overflows, interpreting garbage data as valid objects, and so on.

There's no easy way out. You can of course set breakpoints and watchpoints, but you'll soon discover they won't be very helpful. You need to be able to pinpoint the exact moment when something went wrong - if you're one tiny step after it happens you're too late. The call stack breaks and you stop getting useful information.

Here are a few suggestions that might help you cope with the problem:

Have you recently added a new library to your project? Does it seem likely that the crash is caused by a call to a function in that library?
Have you (or someone in your team) modified any particular code recently? Can you revert your build to the previous version (in case the previous version was working)? Can you see the differences between the two versions (with CVS, for example, you can use the Cervisia tool for this task)?
Have a TRACE(x) macro in your C/C++ project. It should expand to nothing at all in release-mode, but print it's argument to a file in debug mode. Feel free to sprinkle as many TRACE() calls as you wish throughout your code. Read the output after the crash. What was the last thing that in the trace file before the crash? Start commenting out blocks of code while the crash still happens, until you find the line of code that has caused it. (For C++ users, a special case of TRACE() is, for lack of a better name, SCOPE_TRACE(): output the name of the current function and line, in a special stack object's constructor and destructor - this is an exception-safe way to know when you've both entered and left a function.)

Automatic Coding Style Enforcement

2008-05-08T23:28:00.000-07:00

How often did it happen to you that your team has decided on a coding style, somebody wrote a document about it, and it all seemed great until you've checked out a source code file that a new colleague wrote, only to find out that he/she had used tabs instead of spaces for indentation, and that his/her 8-characters tab indents don't look that hot with your 4-spaces indents?

Having a coding style document is important, and enforcing it will prove very valuable in time. And indeed, some coding style constraints cannot be enforced any other way, except having someone periodically reading the others' code and requesting changes. This is, in part, due to the somewhat flexible definition of what a coding style document is (for example, some stop after defining "the look" of source code: indentation rules, naming conventions, etc.; while others include best-practices rules such as "never use naked pointers" - for a good (and free) book of the latter type, see "Industrial Strength C++").

But, some things can be transparently enforced. That is, if your favourite editor supports that. The top editors on my list, (X)Emacs and Vim, both do. You can set the number of spaces you'll see for a tab indent, you can specify whether or not pressing the tab key will translate to any number of spaces, and you can tell the editor to interpret the file as source code written in a specific programming language (for syntax highlighting purposes, when it can't be deduced based on file extension).

This (or variations of it) is what you'll find at the bottom of all the source code files of most of my projects:

/*
  Local Variables:
  mode: c++
  c-basic-offset: 8
  tab-width: 8
  c-indent-comments-syntactically-p: t
  c-tab-always-indent: t
  indent-tabs-mode: t
  End:
*/

// vim:shiftwidth=8:autoindent:tabstop=8:noexpandtab:softtabstop=8

Now any team member who edits the file with (X)Emacs or Vim will have the editor enforce coding style conventions, whether (s)he forgot them or not.
Find out if your favourite editor can help out like that.

The Most Helpful Kind of Knowledge in Software Architecture

2008-05-07T21:52:00.000-07:00

Many people argue that computer programming depends heavily on mathematics. To some degree, that's true - it is a fair assumption that the computer model is a mathematical abstraction

But programming involves using a programming language. Unless that programming language contains the particle "math" somewhere in it's name (and perhaps even then), the emphasis, for the purposes of this article, should be on the word "language".

What language has been used for for thousands of years is to express our understanding of the world. You can use language to write poetry, you can swear, and you can write technical manuals. Some early languages were nounless - what you can express today is different than what you could express back then.

Languages are evolving entities. We add new words as the need presents itself. The ancients did not have LCD monitors. They did not have to implement quick sort. Part of mankind's development has been to add new objects to its conceptual toolbox, and remove obsolete ones.

Adding new concepts is a difficult business, and we need to take into account a couple of things:

Our building blocks. The context. The existing concepts, that are the basis of the new ones. With the addition of a new concept, the context changes and the loop continues.
The need for the birth of new concept (quantifiable perhaps by the intuitiveness of the use of the new concept). We don't go around thinking that something's missing in the world because nobody invented sunglasses that produce bread.

Does anything sound familiar so far? If you're designing code, it should. It's basically software architecture: the context is your programming language (classes, overridables, data encapsulation, functions, operator overloading, data manipulation primitives, etc.) and your dependencies (libraries you need to use, and their design and implementation). The new concepts collaborate to make your code work (in object-oriented terms, these will be classes and class hierarchies). The quality of these concepts, all other things being equal, will always depend on the quality of your training in ontology.

In conclusion, good to have attributes for a software designer would be:

Time in the trenches with the category of programming language that the project will use (for example, C++ or Java for object-oriented software development, C for procedural software development, and so on). You will simply not understand the full power of the tools you're supposed to map your high-level concepts on, unless you're experienced with them.
Experience with as many other frameworks as possible. They're brainchildren of other designers. Some of them are very valuable. Especially at the beginning, emulation is nothing to be ashamed of ("imitate good writing").
To be well read. While books on the Rational Unified Process, Agile methodology, and so on, do have their value, the recommendation here is to go deeper into language semantics, ontology, phenomenology and deconstruction, as written about by Wittgenstein or Heidegger. To the extent that designing a new system is an exercise in ontology and semantics, there's nothing better than turning to the real professionals of that field.

C/C++ Rule: Never Locally Release a Resource Allocated in a Dynamically Loaded Plugin

2008-05-06T08:31:00.000-07:00

This rule especially applies to acquired memory, but it extends to file or mutex handles, and pretty much anything that can be considered a transient resource.

After you load a module (an .so for UNIX - with dlopen(), or a .dll for MS Windows - with LoadLibrary()), you might call a function that returns a pointer to freshly allocated memory.

Example pseudocode:

typedef char* (*p_aq_fn)();

int main()
{
    void *module_handle = 
        dlopen("mymodule.so", ...);

    if(module_handle) {
        p_aq_fn heap_allocated_string = 
                 (p_aq_fn)dlsym(module_handle,
                             "heap_allocated_string");
        if(heap_allocated_string) {
            char *my_string = 
                heap_allocated_string();
            // Use my_string
            free(my_string);
        }
    }

    if(module_handle)
       dlclose(module_handle);     

    return 0;
}

Yes, the code is not exception safe, or very of C++, for that matter, but please ignore that for the bigger picture I'm trying to paint: the free(my_string) call is asking for trouble.

The reason why that won't work is this: dynamically loaded plugins have their own memory and exception handlers. It is therefore a very bad idea to allocate memory using one allocator, and ask another allocator to release it. I repeat: the allocator used by the loaded module is not the same as the allocator used by the module's loader.

Don't despair though, there is a solution to this problem: for each type of resource that you plan to acquire from the module, provide a module function responsible for releasing it. Then get a handle to that function, and use it to release your resource once you're done with it. Such as:

typedef void (*p_release_fn)(char *);

// ...

p_release_fn release_string = 
    (p_release_fn)dlsym(module_handle,
                        "release_string");
if(!release_string)
    ERROR("No release_string symbol!");

// Use heap allocated my_string here

release_string(my_string);

NOTE: You should, of course, use RAII (resource acquisition is initialization) to make your code exception-safe if you're planning on using C++. In spite of it's fancy name, meant to scare away nice people from potentially lucrative software development careers, all that it means is that you should implement special classes whose instances will acquire resources in their constructors and release them in their destructors (be very careful about copy semantics!), and use them as stack objects in the scope that uses the resources.

CORBA Myths and Facts

2008-05-06T02:13:00.000-07:00

I'm sometimes asked to diagnose problems in complex distributed projects that have become hard to continue or maintain. In a significant percent of cases, CORBA would have saved the day had it been used from the start.

When asked about their decision not to use CORBA, the decision makers usually invoke these arguments:

CORBA is too complex. The irony is that often the project developers implement (at the very least) their own skeleton/stub functionality, something that could have been avoided by simply defining a 10-line CORBA IDL interface, running the idl-to-source-code compiler, and simply derive a class that implements the business-logic. At it's simplest, CORBA is a quick (and fun) way to implement distributed binary objects across potentially heterogeneous networks, with no more overhead than linking with the ORB library.
CORBA's IIOP protocol is sub-optimal. In fact, it is not. It's safe (and if you roll your own communication protocol you need to implement it with safety in mind, and test it for little things - such as potential DOS attacks, buffer overflows when serializing strings, etc.), and it's a binary protocol, which makes it "faster" and more compact than, say, SOAP's XML-based protocol. Furthermore, most ORBs will let you roll your own communication protocol, if IIOP is not to your liking.
We've considered using CORBA, but the ORB software we've selected costs a lot of money. Some do. There are many free ORBs out there (MICO, TAO+ACE, etc.), but it's possible that they did not meet your needs. However, you need to ask yourself this: are you willing to pay a team of developers and a team of testers to re-implement basic CORBA functionality, for at least a couple of months (probably more, if you're not one of those companies that not only claims, but also does work with the top 5% people in the business)? If so, would that cost more than one ORB license right now? Because, in the end, if you do implement most of what an ORB offers even at it's simplest, I can guarantee that your solution will be inferior. A bold statement, perhaps, I stand by it. CORBA is a standard developed by a committee that includes top software companies and talented individuals; ORB software that's been around for many years and used by many software projects is bound to have benefited from more testing and improvements, and is bound to be more robust than your ad-hoc, in-house marshalling solution.
We've compared CORBA to RMI/RPC/SOAP and the alternatives seem better. If you don't actually need CORBA at all, then by all means do not use it. There really are cases where all you need is a socket and a bunch of bytes to push along. But do not compare CORBA with RPC. You might compare a subset of CORBA to RPC: the part that allows you to specify interfaces and marshall inter-process data. Even so, CORBA is an object-oriented technology that maps better on programming languages such as C++ or Java, and RPC is not that portable. But, CORBA is much more than language-independent interface specification and cross-platform data-marshalling. It also comes with it's own "standard library" of goodies. Things like the Naming Service, that maps a human-readable name to an interoperable object reference (IOR), or the Event Service, that allows you to request and use an event-channel, for real-time notifications from event providers to subscribers.
But I don't need all that CORBA has to offer for my project. My own simple protocol is enough. Fair enough. But that may be right for today. You need to plan for tomorrow, so that when it comes you don't need to hire ten more developers and a consultant to sort out the mess. Ask yourself, "what will I do if my product is successful?". That would mean more and more users for your product - some of them will require new features. You will probably want to add more features and charge accordingly, to increase profit. Is it worth it to risk that trouble, when it doesn't even cost much extra to use something now that will make development and maintenance easier in the future? At most, it will cost you the price of the ORB (unless you use a free one), and the training time for your developers.

If I've managed to convince you to take a closer look before making that decision, I warmly recommend for further reading "CORBA Explained Simply".

C++ Rule: You Can't Catch an Exception from Another Thread

2008-05-06T00:00:00.000-07:00

C++ is an old language. It's got thousands of features and special cases, and by the time the ISO C++ standard was approved, there hadn't been enough time to include frequently used, but not core-important (at least not in the same way as, say, containers and iterators are core-important) concepts, such as sockets, and threads. Consequently, ISO C++ has no knowledge of threads (although Bjarne Stroustrup has said at the PACT 2007 conference that they're acknowledging threads in the upcoming C++0x standard).

What this means, is that when you're working with threads (perhaps implementing a threadpool with C++), you can't know what will happen if you mix exceptions-style context-switching with threads. It's undefined behaviour, which means that it may, or it may not crash your computer, erase all of the files on your hard disk, or play the theme song from "Flight of the Conchords". Most likely, it will just crash your application.

More to the point, you can't do this:

void thread_function(int *return_code)
{
   *return_code = NO_ERROR;

   if(something_wrong)
       throw MyException;
}

int main()
{
   try {
       start_thread(thread_function);

   } catch(const MyException&) {
       log("Exception caught!");
   }
}

Or rather, you can do it, but you'll most likely never get to the log() call. The exception thrown from the new thread will never be caught anywhere, and your program will misteriously abort. The proper way of doing it, would be something along the lines of:

void thread_function(int *return_code)
{
   *return_code = NO_ERROR;

   try {
       if(something_wrong) {
           *return_code = ERROR_MYERROR;
           return;
       }
   } catch(...) {
       *return_code = ERROR_GENERIC;
   }
}

This has serious software design implications:

Not only do you have to be careful not to throw exceptions from a new thread, you have to be careful that no function you might call there will throw an exception. That's almost impossible to do, unless you're planning to use only code you've written (which is a completely unrealistic expectation in a real-world application), or if you only call C functions. Even so, bare in mind that even C++'s operator new throws a bad_alloc exception when it runs out of memory, so you can't really promise that nothing you call in your new thread will ever throw an exception.
You need to think of new threads as processes in their own right (which on some UNIX systems is indeed exactly what they are underneath that POSIX threads API gloss). That means, whatever code you're using in your thread, make sure you're always catching all the exceptions that could get thrown before you exit the thread, and if you need to report problems, do it with a plain-old C-like return code. This is one of the places where the catch(...), or "catch-all" clause, doesn't seem so primitive.

Why "Jeeves with Classes"?

2008-05-05T12:04:00.000-07:00

Because, C++, my favourite programming language (but not the best for everything), was initially called "C with Classes", by it's author, Bjarne Stroustrup. Jeeves, of course, is the name of P.G. Wodehouse's most well-known character, the always helpful guide for whatever characters had managed to get themselves in a fix.

Though I do not intend to limit our discussion here to C++, C++ is a good conceptual tool to work with, because it is a multi-paradigm programming language. We'll sometimes be discussing high-level software design patterns, and sometimes implementation gotchas, and just for the fun of it, sometimes completely unrelated things just to take a break from the mundane. But mostly, I'm planning to share some of my humble experience working as a professional software designer and developer for the better part of the last decade of my life.

In the hope that this will turn into an experience both entertaining and educational for both the reader and myself, I declare this blog open. Enjoy!