DMP Photo Booth: To #define Or Not To #define
While working on DMP Photo Booth, I have had a basic philosophy on functions: nothing should return void. Any function that would return void will instead return gint. (instead of int because I’ve gone all in with GLib primitives) By returning gint, I can check for success or failure. I’m now about 7 .h/.c pairs into my program, and I’ve been merrily
#defineing my return values when it occurred to me: maybe I should be using an enum.
After it occured to me, I took a minute to think about it. There really isn’t that much to weigh; enums in C are basically just integers. Enums are “safer” because they avoid the preprocessor, but they add a slight amount of overhead because you need to know just what a
dmp_pb_return_status is. Specifically, you need to
#inclue the file that typedefs it. Additionally, this would make the module API slightly more complicated as it would be another requirement placed upon the modules to match the Core’s return value enum.
However, if you just use
#define, you still need to
#include the file that defines the symbol if you want to use it by name. However, you don’t have to. If you don’t include the file, you won’t get some magical unresolved type, you just need to know what the magic numbers are.
Maybe it’s just youthful overconfidence, but after working with C for a while, I’m not quite as terrified of the pre-processor as they would like me to be. While I prefer functions to fancy macros for the most part, I’m not above the occasional
#define. If you’re careful, they can save you time and boilerplate.
With all of that in mind, I’ve decided that I will stay the course with my
#defineed return values.