Being Cellfish : C++

Exceptions or not?

cellfish — Fri, 02 Oct 2009 08:01:00 GMT

I've always had mixed feelings for exceptions. First of all exceptions should only be used for exceptional things, not things that are expected. For example if you open a file it may fail for several reasons; it does not exists, you do not have rights to open it or it may be locked. These are all perfectly reasonable errors and throwing an exception for these failures is in my opinion not a great API design. If there are other methods to check for all these circumstances it might be OK but not optimal. A reasonable compromise is to have a TryOpen method which never throws an exception. This gives the user of the API the option of letting file open errors being expected or fatal.

Because exceptions should only be thrown for exceptional circumstances there should be no reason to catch them other in the application's main loop unless you can add information to the error in which case you want to wrap and throw a better exception. The exception to this rule is when you use an API (such as file open mentioned before) that throws for pretty common error cases you want to ignore.

Another thing I don't like with exceptions is the fact that you (in C++ and C#, Java is better here) get no help from the compiler to know what types of exceptions a function may call. So in C++ and C# you may think you catch everything you need but you really don't which leads to unwanted behavior in your application. It is just too easy to get into a situation where you think a number of lines are going to be executed but they're not for some exception.

However if you use return codes (as you would in a C program) you get your code cluttered with "if (previous called failed) handle error" which hides what the code really does. This can be hidden using macros to handle errors (ex: result = DoSomething ON_FAIL_RETURN(result); ). And if there is no error handling it is hard to know what happens when the next line is executed even though there was an error.

Using exceptions is also a kind of "I failed and I hope somebody else somewhere can handle it" while the use of return codes defines a clear contract "I failed and you who called me must handle it". So even though exceptions are convenient, return codes feel more defensive, i.e. are easier to get right resulting in less bugs but sometimes at the cost of less clear code. As usual the mix of both approaches is probably the best. But there are more alternatives. If you use adverse as described by Feathers I'm prepared to accept exceptions to a much larger degree because they're being handled immediately so it reminds of the return code approach.

Remember to allocate memory just in case you run out of memory

cellfish — Tue, 11 Aug 2009 07:04:00 GMT

Today I read this blog post about how all .Net applications create three exceptions upon start; System.ExecutionEngineException, System.StackOverflowException and System.OutOfMemoryException. The reason is that if these are not allocated from the start, they cannot be created when they occur. This reminded me of when I was writing high performance daemons in C a few years ago.

In those daemons I did a number of things to prepare for the event of memory starvation. First of all I allocated some memory (a few Kb if I remember correctly). If the daemon ran out of memory it was suspended for up to a second and the memory allocation was tried again. Typically I did a handful of retries and if they all failed I released the preallocated memory, logged the error and terminated the process.

The reasoning behind this strategy was based on three assumptions. First of all, if a process cannot allocate memory it is because some other process is leaking memory (or is just using a lot of memory). Second assumption is that the offending process will terminate fairly quickly because of this. Last assumption is that if the offending process does not release memory quick enough it might be the current process that is the problem so it must terminate to let other processes proceed normally. But before termination we release some preallocated memory so that we have enough memory to log the problem.

So what about multi-threaded daemons? If one thread releases some memory another might take it all before we get the chance to log the problem. Well, in my case all daemons were single threaded. If I needed "threads" (which was rare) I forked. So that was not a problem I had to consider.

A reminder if you want to read/write your file in non blocking mode (in C(++))

cellfish — Thu, 16 Apr 2009 14:16:00 GMT

Sometimes you might want to read a file non-blocking. It could be /dev/random because waiting for entropy might take very long. Also when you have to read device files on unix you sometimes have to read them non-blocking. A common pattern is to open the file non-blocking using the open method: open(..., O_NONBLOCK, ...)

This however may be a problem. This type of open will typically succeed (because the system is opening the file non-blocking) and when you then start reading (or writing) you get a failure. The failure can be anything from permission problems to unavailable devices. This is how non-blocking I/O works and something you're well aware of if you're using sockets for communication but since "this is files" you might forget to take non-blocking into account.

So there is a really easy way to work around this. Files, unlike network sockets completes the open operation very fast. So making the open call non-blocking generally does not make so much sense. Instead I suggest you open the file in blocking mode and then change it to non-blocking one opened. And this is how you do that:


   1:  int fd = open(..., 0, ...); // Filed open in blocking
   2:  int fd_flags = fcntl(fd, F_GETFL);
   3:  if (fd_flags < 0) { // Get any flags set on the fd.
   4:      close(fd);
   5:      return error;
   6:  }
   7:  if (-1 == fcntl(fd, F_SETFL, fd_flags | O_NONBLOCK)) { // Add non blocking to the fd flags
   8:      close(fd);
   9:      return error;
  10:  }

But there is (at least) one situation where a non-blocking open might make some sense. That is when you open a file on a remote server and you cannot afford the waiting of an open call. And in this case you must treat the file descriptor like any other file descriptor used for network communication and use select to make sure the file descriptor is ready before you start using it.

Dangers of using Visual Studio 2008 Team System Code Coverage Tool for Native C++

cellfish — Tue, 18 Nov 2008 16:18:00 GMT

So now you know how to get coverage reports for native C++ using Visual Studio 2008 Team System (if not - read this). There are a few things you need to know before you get excited. First of all the only metrics you get are line and block coverage. A block is basically a statement and each line typically consists of one or more blocks. Unless you have 100% coverage I think these metrics both are pretty useless when measuring quality. For example consider a function consisting of ten lines of code. There is an IF-statement checking for an error and it throws an exception if the error occurs. If the error never occurs during the test-run you still get 90% line coverage since the other nine lines are executed. I think this is pretty common in production code. Most of the code is for the common state and fewer lines are used to handle errors. So you get pretty high line coverage even if you do not test any of error cases.

Block coverage is even worse. For example consider the following line:

SimpleClass* o = new SimpleClass();

That line produces two blocks of which only one is covered. And there is no reasonable way test the uncovered block since it probably has to do with when the process runs out of memory.

Identifying functions that are not called at all is often considered an important part of the code coverage report. Here we have another problem with the visual studio tool. Functions never referenced by the code will be excluded from the report completely (I suspect this is the case since the linker will remove all unreferenced symbols as part of the optimization at link time). This means the following class will report 100% coverage it it is instantiated and only GetA is called.

class SimpleClass
{
public:
    SimpleClass(int a, int b)
        : m_a(0) , m_b(b)
    { }

    int GetA() { return m_a; }
    int GetB() { return m_b; }

private:
    int m_a;
    int m_b;
};

So with all these potential problems there is another tool I'd recommend you consider. It's called BullsEye. It is a more "puristic" tool so there is no way to get block or line coverage, basically since those metrics are bad. In stead you can get Decision and Condition/Decision coverage. Basically Decision coverage checks that each conditional evaluates to both true and false and Condition/Decision coverage is when each part of a boolean expression is evaluated to both true and false. Consider the following line:

if(a || b)

There are two different decisions (either "a || b" is true or false) but four different conditions (both "a" and "b" must evaluate to true and false). BullsEye also adds instrumentation at compile time so the GetB method in the example above will not be lost but be part of the report as an uncovered function even if not referenced anywhere in the code. In the initial example (ten lines with 90% line coverage) we would get 50% decision coverage which is a much better indicator of quality.

And on using code coverage as a quality metric...I must insist you read one of my previous posts if you haven't done that already...

Native C++ Code Coverage reports using Visual Studio 2008 Team System

cellfish — Sun, 16 Nov 2008 13:16:00 GMT

The code coverage tool in Visual Studio 2008 Team System is quite easy to use from within the IDE unless you want code coverage for your native C++ code. In order to generate a code coverage report for native C++ you have to use the command line tools. This is how you do it:

First of all your project must be compiled using the /PROFILE link option. If you bring up your project properties it can be found here:
Configuration Properties -> Linker -> Advanced -> Profile
The profiler tools can then be found in the following directory:
C:\Program Files\Microsoft Visual Studio 9.0\Team Tools\Performance Tools
You need to add some instrumentation code to your EXE or DLL file and that is done with this command:
vsinstr.exe <YOUR_EXE_OR_DLL> /COVERAGE
This will copy the original file to an ".orig"-file and create a new file with the original name that contains instrumentation code needed to gather coverage data.
Now start the listener with this command:
VSPerfMon.exe /COVERAGE /OUTPUT:<REPORT_FILE_NAME>
Now run your EXE or some test suite that uses the file you want to calculate coverage for.
The listener started in step four (4) will not stop by it self once your test suite is finished so you have to stop in manually using this command (from a second command prompt):
VSPerfCmd.exe /SHUTDOWN
When the listener has stopped you just drag-n-drop the created ".coverage"-file into Visual Studio and you can view the results.

C++ pointer basics for kids

cellfish — Fri, 31 Oct 2008 10:18:00 GMT

A little video to explain pointer basics in C++ to your kids... If you for some weird reason want to do that...

Sleep does not sleep for a specified period

cellfish — Mon, 22 Sep 2008 08:38:00 GMT

I recently described how you can create your own usleep method when there isn't one to use. one thing that people however tend to forget is that the sleep methods (sleep, usleep, nanosleep) only guarantees that the calling thread will be suspended for at least the given time. There is absolutely no guarantee that the thread will resume its execution immediately after that time. On most platforms you don't really see the difference but there are exceptions. HPUX for example, even on an otherwise almost idle system I typically experience a delay of a few milliseconds even though I sleep for only a single microsecond.

So if you want your thread to sleep for an exact amount of time you have use a different approach than sleep. Even if you use some sort of synchronize mechanism (an event) and a timer (to trigger the event) there is no guarantee that the blocked thread will execute immediately when the event is triggered. This approach is more likely to work as expected than the use of sleep, but it is not fool proof since you never know what other processes execute on the system affecting your process' execution.

The closest thing you can come to exact sleep times is also the ugliest solution. You can always have a busy loop checking if enough time has passed over and over again. This will however change the behavior of the sleep into a busy loop which is rarely a good solution to a problem.

Since only a minimum time can ever be guaranteed with a sleep method, regardless of implementation you should not write your code so that it depends on an exact sleep method. I think you're actually addressing the wrong problem if you try getting an exact sleep. Instead try figuring out why you need an exact sleep and remove that reason because you'll never be able to get it to work exactly right. Maybe good enough for now but you never know what will happen in the future so it's just a bad design choice.

Sleep less than one millisecond

cellfish — Wed, 17 Sep 2008 18:09:00 GMT

On windows you have a problem you typically never encounter on Unix. That is how to get a thread to sleep for less than one millisecond. On Unix you typically have a number of choices (sleep, usleep and nanosleep) to fit your needs. On windows however there is only Sleep with millisecond granularity. You can however use the select system call to create a microsecond sleep. On Unix this is pretty straight forward:

int usleep(long usec)
{
    struct timeval tv;
    tv.tv_sec = usec/1000000L;
    tv.tv_usec = usec%1000000L;
    return select(0, 0, 0, 0, &tv);
}

On windows however, the use of select forces you to include the winsock library which has to be initialized like this in your application:

    WORD wVersionRequested = MAKEWORD(1,0);
    WSADATA wsaData;
    WSAStartup(wVersionRequested, &wsaData);

And then the select won't allow you to be called without any socket so you have to do a little more to create a microsleep method:

int usleep(long usec)
{
    struct timeval tv;
    fd_set dummy;
    SOCKET s = socket(PF_INET, SOCK_STREAM, IPPROTO_TCP);
    FD_ZERO(&dummy);
    FD_SET(s, &dummy);
    tv.tv_sec = usec/1000000L;
    tv.tv_usec = usec%1000000L;
    return select(0, 0, 0, &dummy, &tv);
}

All these created usleep methods return zero when successful and non-zero for errors.

Mocks are not Stubs

cellfish — Tue, 22 Apr 2008 09:24:00 GMT

As many before me I was recently looking at different mocking frameworks in order to find one that suited my needs, and was written in C++. And there are not many alternatives out there if you're using C++. I've found one open source and two internal (Microsoft staff can access what can be described as an internal codeplex) ones. Pretty soon it turned out that none of these frameworks did what I wanted. Actually they suggested using no framework at all for the situations I was looking to "solve" with a framework.

At this point I rediscovered an old article by Martin Fowler and it became crystal clear that the reason I didn't find what I wanted in the mocking frameworks was because I really wanted a stub framework (or rather a stub helper). Because what I wanted was a simple way to reuse the algorithm "return 17 the first 7 times called and then throw an exception after that, unless called with argument 4711 in which case you should always return 42". A pretty simple method to write in your stub if you just subclass and override the object you want to mock/stub but a little bit cumbersome in the long run if you do this a lot.

During a discussion on a company internal mailing list for TDD it became clear that people generally use the term mock object for almost every kind of non-production object used during testing. And when another large group do make the distinction between mocks, stubs, fakes and dummies you quickly run into trouble since you are no longer discussing the same thing. So here is yet another recap on what the different kinds of objects are so I can contribute to the cause, making world a better place to be. At least when talking about mocks & friends.

Object	Description	Comment
Dummy	Passed around and should never be used.	Should fail the tests if ever used.
Fake	Working implementation but takes short-cuts making them unsuitable for production.	For example an in memory database.
Stub	Quickly responds with a small number of known values.	Used during testing to mimic a certain behavior.
Mock	I like to think of mocks as stubs with the knowledge of usage added.	Used to verify that the user of the (mock)object makes the correct number of calls in the correct order. Many mock frameworks are designed to make verification of number of calls and/or order optional. But if you do not verify order or number of calls you're basically using a stub (but it is generated from a mock framework).

MFC is not dead

cellfish — Sat, 12 Apr 2008 10:24:00 GMT

When I wrote my master's thesis was the first time I came in to contact with VC++ and MFC. I worked with MFC and VC++ quite a lot for a number of years but the last four or five years have not had much MFC work in it. When the .Net framework came along with the possibility to write managed C++ applications I thought MFC was dead and didn't give it much more thought.

Then I read about the new VC++2008 feature pack here and watched the channel 9 video referenced. I noticed how the reporter also questions the MFC developer about the presumed death of MFC. Apparently MFC is not dead as many, including me, thought. The reason I thought so was that I just assumed that with managed C++ no one would bother writing them unmanaged in MFC any more. But when I think a little more about it I guess there are lots of people still out there who are familiar with the MFC framework and who do not have the time and/or interest to learn the new managed equivalents.

Some might say that you want to write MFC applications in stead of managed ones because the users do not have the .Net framework installed. A fair point but frankly I do not think that the user that will benefit from this MFC update (which for example includes office ribbon support for office 2007) also already have the .Net framework installed.

Update: I noticed that this post was referenced by this one: http://blog.stevienova.com/2008/04/12/why-is-mfc-not-dead/. I realized I was not 100% clear in my post. I must say that I agree with the author of that post - MFC will be used for many years for the reasons mentioned: People want to make applications that work across many different versions of Windows without installing the .Net framework. There was never a doubt in my mind that was the case. However I was surprised there was so much new development put into new versions of MFC since I guess all the new stuff will not work very well anyway. And much of the new stuff in MFC is there to mimic stuff seen in the managed framework and/or in latest versions of office/windows. And if you run Vista or Server 2008 I guess you will have the .net framework already installed and hence do not need to use MFC.