Anyone out there ever come across a preprocessor macro that compares an
argument value against the predefined __DATE__ macro in order to
control conditional compilation based on date.
Something along the lines of...
# define DateLaterThan(x) ...
that could be used for things like
#if DateLaterThan("Jun 15 2006")
#error The following debug code can be deleted now
#end
Would be pretty handy to be able to leave a forceful reminder in souce
code to prompt cleanup of ugly quick fixes, tempory diagnostics etc.
etc. rather than passive TODO/FIXME type comment tags.
The unaided preprocessor can't do it, because even though
it generates the literal corresponding to __DATE__ it's unable
to look at the contents of the literal (the literal doesn't
become a string until long after the preprocessor finishes,
and besides the preprocessor has no access to the memory that
holds the string).
Although the preprocessor won't do what you want, the
compiler itself can give some help. You could use Martin
Dickopp's trick
http://groups.google.com/group/comp.lang.c/msg/22b053811e98f490
to derive values from the __DATE__ string and a similar
string you supply, and then you could use the two values
in a relational expression in a context that causes a
compile-time error if they're not in the correct relation,
such as declaring an array whose dimension is invalid if
__DATE__ is too late.
However, I'd suggest you seek other avenues. A long time
ago I, too, longed for such a construct -- I had just tracked
down and fixed a performance problem caused by a "temporary"
hack that had remained in the code through two major product
versions and into the development phase of a third. I thought
that if the compiler could have alerted us that the code needed
attention, much grief would have been avoided. After pondering
for a considerable time, though, I came to the conclusion that
the compiler's job is to translate the code it's given, not to
act as a software engineering methodology enforcer. There are
other tools to handle the latter function, and they're capable
of things that are completely outside the compiler's purview.
Also, __DATE__ is rather inflexible. You'll put in some
sort of hack and then estimate how long it'll be before you
simply must come back and do a better job, but schedules for
software development are notoriously elastic: your estimate of
the deadline is not going to be reliable. Yes, you can always
respond to the compiler's complaint by postponing the drop-dead
date, but that's just make-work -- and since Murphy never sleeps,
you can be sure the drop-dead will happen on the very night of
the Giant Rebuild before the Big Demonstration ...
If you must insert time bombs in the compilation, I'd suggest
you base them on things like product version numbers, "build for
release" flags, and the like: they are sensitive to the status
of the development rather than to the passage of time. I once
needed to hack around an error in the vendor-supplied printf()
by substituting my own version, so I had something like
#include <stdio.h>
#ifdef PLATFORM_X
#ifdef DEBUG_BUILD
/* Beta versions of printf() et al. print
* floating-point values at one-quarter
* actual magnitude. Use our own substitutes
* until Vendor X fixes this.
*/
#undef printf
#undef fprintf
#undef sprintf
#define printf fake_printf
#define fprintf fake_fprintf
#define sprintf fake_sprintf
#else
#error "Do we still need this hack?"
#endif
#endif
(The reality, of course, was more elaborate.) IMHO this sort of
thing makes more sense than date comparisons -- but it's still no
substitute for self-discipline.
