numerical_limits

I’m working on a C++ class that encapsulates changes to a “steerable” variable. It’s part of a system that allows trusted commands from a socket library to change the value of registered variables. For example, a client might:

int sInt(0);
float sFloat(0.3);
registerParam("someSteerableInteger", &sInt);
registerParam("someSteerableFloat", &sFloat);
...
// Library makes these calls after receiving remote commands:
setParam("someSteerableInteger", 5);
setParam("someSteerableFloat", 3.4);

There’s some intelligence in the class to ensure integrity of the data. For example, it will cast the value past into setParam(…) correctly, so that a call to setParam(“someSteerableInteger”, 5.3) results in the 5.3 cast as an integer and then used to set the integer’s value.

Some of the other intelligence needed is that the user might specify the minimum and maximum valid values the variable might take on. Or he or she might not. If not, it would be nice to have a convenient way of specifying a reasonable default minimum and maximum.

Enter numerical_limits. It’s a static templated class that can give you some insight into the built-in types. For example:

#include <iostream>
#include <limits>
using namespace std;
...
cout << "Min unsigned int: " << numerical_limits<unsigned int>::min() << endl;
cout << "Max float: " << numerical_limits<float>::max() << endl;

Tagged with:
 

Wrapping printf(1)

Working on an application that had become a little… verbose, I decided it was finally time to wrap my prints in a function that could easily be switched on or off depending on whether or not I wanted it to be verbose. One approach I had seen before (from my OS professor) that has a certain amount of merit is to wrap statements with a macro:

#ifdef DEBUG
printf(....);
#endif

The nice thing about this approach is that debugging can be turned on or off easily at compile time. However, my experience has been that it leads to a lot of typing, and seeing too many macros in the middle of code makes my brain explode in a fiery rage. So, I figured that if I wrapped my prints in another function (I called mine ‘log’ and ‘error’), I could avoid this whole mess and keep my sanity. I’ve done this with a number of other projects in other languages, but I had to learn some magic to do it in C.

Lesson Learned #1 : Variable arguments. It turns out you can define functions that take a variable number of arguments with va_list (from ). You define such a function:

void log(const char* fmt, ...) {
va_list args;
va_start(args, fmt);
...
va_end(args);
}

Lesson Learned #2 : However, from what I can gather, you can’t just inject printf directly into this. However, having anticipated this, there is a set of functions designed for cases like this: vfprintf, vprintf, vsnprintf, vsprintf. The ‘v’ stands for va_list (variable-argument list), and you can use them just like you’d expect:

void log(const char* fmt, ...) {
va_list args;
va_start(args, fmt);
fprintf(log_fd, "NOTE : ");
vfprintf(log_fd, fmt, args);
va_end(args);
}

The thing I like about this approach is that you have control over how log messages get printed in one place. So, for example, if I provided another function, setLogFD, then I could easily just set the file descriptor where all log messages get printed. So easy! Something I’ve used this for in other instances (especially servers) is to also inject additional information like a timestamp on every message. So, when I call:

log("Some event '%s' just happened.\n", event_name);

Then I automatically get “NOTE : ” and maybe a timestamp prefixed on that message. Which make code look clean, and adds a great deal of functionality. I actually added another function error(…) that prints to a different file descriptor in case I want to suppress debug messages, but no error messages. For additional layers of debugging, you might do something like this:

void log(int level, const char* fmt, ...) {
va_list args;
va_start(args, fmt);
FILE* fd = my_log_files[level];
fprintf(fd, "NOTE : ");
vfprintf(fd, fmt, args);
va_end(args);
}

This way, at startup, you could easily set some of the file descriptors in my_log_files to stderr and some to point to /dev/null or otherwise dissolve into the ether.

Tagged with:
 

Heart-throb

My latest little heart-throb has been the reason behind more than a couple sleepless nights as of late. It’s called Visual C#.

We met under the shade of iTunes’ beautiful SDK and it was love at first sight. It’s the comfort of an old friend, C++, combined with everything I love about scripting languages, and it’s really easy to make solid GUIs (graphical user interface) with it. Not that there aren’t problems in our relationship – it runs almost painfully slow, but what it lacks in speed it makes up in flexibility.

As I mentioned before, the only reason I’ve been messing around with it is because of iTunes’ API (application public interface for those playing at home; an API allows you to write your own program that interacts with the functions of another program in a publicly described fashion; for instance, Amazon.com publishes an API that allows other websites to grab information from their website using tools that Amazon.com has written). iTunes has this habit of keeping tabs on how many times you play any given song, and when you last played it, but if you play it on your iPod, it doesn’t keep track of that. Your iPod grabs the play counts from iTunes, but when you synchronize your iPod with your iTunes library, the times you’ve played your songs on your iPod seem to disappear. One way to solve this problem is to write a script using the API published by Apple.

There are a couple of other little tricks I’d like to teach iTunes, and so I’ve been putting together this little bundle of random tools with C#. It’s a lot of fun, and I figure it’s better than me playing Mario Cart.

Tagged with: