Recompiling can make me uncomfortable
Computer programs often involve encoding some assumptions especially at the top of the program and then go on to exploit those assumptions, either at compile-time or at run time.
Compile-time assumptions often use macros.
Computations in macros
In one of my image
processing programs I had the following macros:
#define IMAGE_WIDTH
320
#define IMAGE_HEIGHT
480
#define
IMAGE_NB_PIXELS IMAGE_WIDTH*NB_HEIGHT
The program was
meant to be used on pictures coming from a specific fingerprint
scanner. The idea of hard-wiring the size was useful in that there
could be a hard-wiring of a lot of constants in the program that
would result in a very fast program. Few people would complain that
the calculation IMAGE_WIDTH*IMAGE_HEIGHT would be recomputed every
time the program was modified, since recomputing the same constant
over and over again is such a small part of the overall time.
Include files
Let’s now consider
a slightly less innocuous practice in C++: the use of include files.
It’s quite common
to have an occurrence of a call to an include preprocessor directive
such as
#include <stdio.h>
#include “header1.h”
#include “hearer2.h”
(for example) inside
a program when in fact we do not know whether this leads to an
implicit include of the same include file twice. It’s generally
considered harmless because of a directive like for example
#pragma once
inside each of one’s
headers. There is alternate trick to avoid “double inclusion”
which uses something like
#ifndef HEADER_H
#define HEADER_H
<body of header
here>
#endif
In this case however
there is a slightly greater compile-time cost for not paying
attention to the dependencies.
An example involving music notation
This one is
something that came to mind, and I have not implemented. It is far
more sophisticated.
It is not really
about C++ programming but about maintaining assumptions in a program.
The above programs
have an implicit primitive handling of assumptions.
Suppose we are
writing a music notation program.
One might want to be
“declarative” and this means that one might want to describe the
different note
values that are involved in music. One way of going about it is
to state that there is unit note value (a duration of one note) and
that for each power of two P up to a certain power there is a note
value of duration 1/P, and that for each such note value there is a
distinct symbol (they are the conventional symbols for minim,
crotchet, quaver, semiquaver and so on).
This is a typical
statement one might make during an explanation. If I were listening I
might ask “what is the highest power for which there is a symbol?”.
So we would have an illustration of teacher-disciple interaction I
want to repeatedly allude to.
Then I as the
disciple might request that the teacher give me a graphical
description of the symbols that correspond to each note duration.
This request might
be followed by a later request to provide a better graphical
description (for example SVG replacing raster images).
The symbols need to
be ready for use in a running musical notation program. It is
hopefully clear that rerunning the initial description about the
different notes and the supply of various graphical descriptions is
somewhat unnatural, not to say ludicrous!
In fact in this case
it comes to mind for my AI background that a reason
maintenance system could be of help.
No comments:
Post a Comment