Super! Delegates

I have added support for D programming language delegates to the ZeroBUGS debugger!

And I am in the process of rolling out beta binaries, and a new release for Ubuntu 8.04 (Hardy Heron).

Happy (Eastern Orthodox) Easter!

Is it the Blogosphere, Stupid?

Oh Lord, it is so hard and stressful being a blogger; and poor bloggers may die of stress. This is what some recent "breaking news" wants you to believe.

First of all, stress is bad for one's health in any activity (I almost wrote "line of work"), what's the big news?

Secondly, blogging may beat doing real work but it is not work. Who the fudge are we kidding? It's like saying that keeping a journal is work. No, you just jot down ideas or things that you find interesting or worth capturing (perhaps when you wind down at the end of the day). You write about a project you are working on, a hobby, or something that bothers you; or something meaningful in your life.

How many people do you know that are enjoying some level of success (politicians, writers, software engineers, doctors, lawyers, you pick) who blog several times a day, every day? Ok, politicians may be a bad example since they have minions blogging for them.

Web 2.0 turned blogging into a full time "job"; self-proclaimed experts "cover" the markets, the political scene, celebrity gossip, and technology. When have these people had any time to build any expertise when every single day they blog till they drop? Do they ever stop and think about what they are writing or merely smell each other's farts?


Instead of building things (and, why not, selling for a profit), modern society "generates content", begging for somebody's mouse click; and then everybody and their grandma complains (in a blog) about the economy being in decline.

And I bet that whatever few mouse clicks this blog entry has trapped, they are coming from hungry blogger dudes, avidly searching the internet for ideas to expertly comment on. Dude, put your flip-flops on and go get a job. A real one.

An Exceptional Chain of Events

It was said of yore that throwing an exception from a C++ destructor is a verie wycked and wofull thyng.

Remember goto? Some distinguished gentlemen of the C++ programming trade look down on throwing from destructors as being eviler than using a goto. Standing base for such moral a judgment is that "a throwing destructor makes it impossible to write correct code and can shut down your application without any warning" .

Destructors in C++ are one essential ingredient to the Resource Acquisition Is Initialization (RAII) idiom, which can be resumed as follows: Resources (i.e. memory, sockets, file handles, etc) are acquired during the construction of an object. If an exception is thrown from anywhere in the code during the lifetime and after the object has been fully constructed, the C++ language rules guarantee that the object's destructor will be summoned.

Thus resources can be released gracefully and graciously by said destructor, even in the distasteful and exceptional eventuality of... an exception. The Programmer is relieved from the burdensome duty of having to release resources on every single possible code path.

RAII relieves the programmer from manually preventing leaks.
(Notice how nicely relieves and leaks go together).

If a destructor, invoked as part of the automatic cleanup that entails the throwing of an exception, decides to throw its own exception, then the system has but two choices: to go into an ambiguous state (now there are two outstanding exceptions, the original one, plus the destructor-thrown one) or... throw the towel.

It is C++ Standard behavior to follow the latter course: the towel is thrown from around the waist, the user is mooned and the program calls terminate(). Hasta la Vista, Baby. And for this reason, they say your destructors should never throw.

But what if there's not way to recover?

Let's consider a generic Lock object which may look something like this:

template<typename>
class Lock : boost::noncopyable
{
 T& mx_;

public:
 ~Lock() throw()
 {
      mx_.leave();
 }
 explicit Lock(T& mx) : mx_(mx)
 {
      mx_.enter();
 }
};

The problem with the code above is that T::leave() may throw an exception (it may as well not throw, but one really cannot tell, since T is a template parameter).

An so I come to the conclusion of this post. I assert that the code above is just as good as it gets. Of course, T may be bound at compile time to a class that implements the leave method somewhat like this:

void Mutex::leave()
{
 if (int resultCode = pthread_mutex_unlock(&mutex_))
 {
     throw pthread_runtime_error(resultCode);
 }
}

If unlocking the resource fails, then a) something really bad must've happened (possibly a memory corruption?) and b) there is little, if anything, to do about restoring the system to a stable state.

I say let ye programme crash and burne.

What do You reckon?

Test Drive: GCC 4.4.0

I have finally gotten around to test ZeroBUGS with a C++0x supporting compiler.

Even though said support is labeled as experimental and is not activated by default (-std=c++0x in the command line does the trick), GCC 4.4.0 seems to be working just fine. Or I should rather say that Zero seems to be debugging GCC 4.4.0-generated code just fine.

I have installed the latest compiler snapshot on a Ubuntu 8.04 beta system, by simply typing apt-get install gcc-snapshot (apt is the awesomest).

Then I set the compiler to /usr/lib/gcc-snapshot/bin/g++ in my environment and fired up a battery of automated tests.

I also did a bit of manual testing for variadic templates, using code samples straight out of Wikipedia, and one quick test for rvalue references. Things look good so far.

Surprisingly, all unit tests having to do with floating point variables passed.

I may have to look deeper into these tests, since as stated here,

"Starting from GCC 4.3.1, decimal floating point variables are aligned to their natural boundaries when they are passed on stack for i386."

I will keep you posted.

Random Log Entries

Ten years ago I used to carry a bulky day planner, and like in a Seinfeld episode almost bought a man-purse for it.

My handwriting sucks. I hear some schools are dropping cursive from their curricula.

Keyboards.

Instant messaging (thumbs up for opposable thumbs!)

Digital scrapbooks. Cloud(ed) computing memories.

Virtual social networking.

What will future historians and archaeologists think of us if the decoder ring for the Internet is lost?

Songs about programming that I would like to hear:

• In a software continuum (you are my Heisenbug)
• Perpetuum beta mobile
• The universal constant is volatile (in C flat)
• Debuggers don't step in the same river twice
  
• Flossing bugs at dawn
• Recombobulate (your shattered assertions)