The Annoyance Filter.pdf - Fourmilab

222 DEVELOPMENT LOG ANNOYANCE-FILTER §256
installed them as mystrstream−GCC3.h, which is included if GCC3 is defined. I have yet to add the
autoconf logic to detect this; at the moment I’m specifying this when I invoke the Makefile.
An include of the now verboten iostream.h remained in statlib.w; I pulled the “.h”.
In addition, statlib.w ran afoul of the dreaded “implicit typename is deprecated” warning in GCC
3.2. I added the required typename qualifier before constructs such as dataTable < T > ::iterator p
in the methods of dataTable . See section C.13.5 in Stroustrup for details.
Previously, gcc treated the buffer argument of ostream ::write like a C void ∗ pointer. Now one must
explicitly coerce it with a reinterpret cast〈const char ∗〉. The same goes for istream ::read , where
the argument must be coerced with reinterpret cast〈const char ∗〉. This played havoc with our
binary I/O code in dictionaryWord and fastDictionary, requiring ugly casts all around. I may go
back and prettify these with a macro, but not before I get the sucker past all the other compile problems.
In days of yore, when everybody knew that an STL vector was just a dynamically sized array, you
were allowed to treat an iterator of the vector as a C pointer to access the contents of the object, as
long as you made sure all references were within bounds: no more. No longer can you, for example,
write the entire contents of a vector〈char〉 to a stream with a single write . Instead, you must painfully
iterate over every element in the vector, doing I/O on each one individually. This is potentially a huge
performance hit which may motivate abandonment of the STL vector in favour of a C array which can
be written in one swell foop. Fortunately, all the cases where this occurs in annoyance−filter are in
exporting fastDictionary objects, which happens so infrequently we don’t care how fast it runs.
Gcc 3.2 also complains if you declare the values of default arguments in a method within a class,
then repeat them in the implementation declared subsequently. I’ve always written code this way,
considering it to better document what’s going on, particularly since the poor sucker who has to fix
the code later on is probably going to be looking at the implementation and may be unaware of the
default argument values declared back in the class definition. Well, it turns out that one can read
section 7.5 of Stroustrup as prohibiting this pursuant to the “default argument cannot be repeated or
changed in a subsequent declaration in the same scope” prescription and, indeed, the example of default
arguments in class methods in section 10.2.3 is coded this way. Okay, what can I do but “fix” it, but to
my mind this reduces the maintainability of the code. I think you should be able to use precisely the
same declaration of the function in its definition and implementation, including default arguments and
attributes such as const. The compiler should verify that they’re identical, but then both the definition
and implementation serve as stand-alone descriptions of the calling sequence and method properties.
Oh, come on, guys! Now you’re telling me I have to do a reinterpret cast〈char ∗〉 to istream ::read
into a bloody unsigned char! You can imagine what this did to dictionaryWord ::importFromBinaryFile .
Unfortunately, I not only had to imagine it, I had to do it.
2003 February 16
With gcc 2.96, when you include math.h, it doesn’t define abs for double, as it’s supposed to do
according to section 22.3 of Stroustrup. Consequently, I defined my own abs (double) in the global
context to get the job done. Well, on 3.2.2, the existence of this function creates an overloading ambiguity
against the built-in one, which has now been added to math.h. It turns out that if you include cmath
in 2.96, you do get abs (double), although that file and math.h are documented as being identical. So,
I replaced the include of math.h with cmath and eliminated my private copy of abs . Now it compiles
on both of ’em.
They’ve gone and eliminated fstream ::attach (int fd ) from the standard—just try and plumb a pipe
into your input or output stream the way you effortlessly used to! As a first cut attempt to detour past
this off-ramp to oblivion, I tried building with HAVE_POPEN undefined, and promptly fell into a self-dug
abyss: bad conditional declaration of the file handle used to read compressed mail folders and messages
in mailFolder. I fixed that, and for the first time, we actually built and passed “make check” under
3.2.2! Just don’t try it with compressed mail folders quite yet. . . .