Re: Cpp Considered Harmful

From: Steven T. Hatton (susudata_at_setidava.kushan.aa)
Date: 08/31/04 

Date: Tue, 31 Aug 2004 17:25:26 -0400

Chris F Clark wrote:

> Steven T. Hatton talking about assertions (via cpp) wrote:
>
>> There has to be some need I have before I look for something to fill
>> it. The idea of aborting a program on failure is simply not
>> something I believe to be a good practice.
>
> Who says assertions have to abort your program?

IIRC, that was the context not the necessary behavior. And I was really
intending the official <cassert> which is said to be documented in the C
standard documentation. I don't have that, but K&R tell me it aborts the
program. They don't tell me I can change that behavior.

> Note, that nowhere did I say that our assertions abort the execution
> of the program--assertions tell you where something went wrong, a good
> assertion package helps you debug that point--a poor assertion
> paqckage simply "gives up" (with a message) at the point where the
> code failed--however, even that is better than the code randomly doing
> something further wrong and possibly silently producing incorrect
> results or mysteriously crashing in some unrelated part of the
> program.
>
> However, in either case, assertions are invaluable in making certain
> that the code does exactly what we say it does and that flaws are
> caught as near to the source of the error as possible. As a result,
> the team has been amazingly productive. It has really paid off in the
> maintenance/enhacement phase, where we can quickly upgrade or change
> the semantics of various pieces knowing that if we violate any
> downstream assumptions, those problems will be caught by the developer
> before finishing coding, "unit" testing, and checking in.

In the sense of JUnit, I have used that approach. In that case you create a
harness, and some use cases to run against your code, testing that
preconditions produce correct post conditions. That typically stands
outside the actual program code.

> If you
> don't use assertions, your programs probably continue to do bad things
> in the sections you haven't well tested and you have to infer the
> problem from the tea-leaves at the point where you finally figure out
> the the program has done something wrong (like crashed)--that doesn't
> work so well on a 600K line program, where there are huge blocks of
> code you have never read much less understand or wrote.

It probably also depends on the nature of the product whether such things
are generally useful. You seem to have something akin to a huge Karnaugh
map. Probably much more suited to such structured evaluation than the
kinds of systems I've worked on. Also bear in mind that I do use
exceptions in similar ways.

> Now, to bring this back to the cpp. Our assertion code is a set of
> cpp macros. Originally, they were just the macros supplied by the C++
> compiler. However, because that C++ assertion support was written as
> cpp macros, when we realized that we wanted something more
> sophisticated than what our C++ vendor provided, we were able to
> customize it for ourselves. Moreover, because we now have our own cpp
> macros, we can use several different compilers and have our system
> work the same way. (And, yes, just like the XERCES code you were
> complaining about, not all of our target compilers are "modern" so we
> have some macros that deal with broken compilers that we are REQUIRED
> to support.)

I understand that such things are required in some cases. There also seems
to be a tendency to imply 'we would have done it like this anyway' in many
cases. I understand that it can add flexibility to your code base if you
can systematically change your namespace name throughout the code base by
modifying a macro somewhere. There are other ways of accomplishing such
things which preserve and indeed exploit the integrity of the language. If
the code base has a predictable and regular structure, it is quite easy to
perform systematic global manipulations. I've done it in various
circumstances. Such a task is an anathema to the sensibilities of may C
and C++ programmers, for understandable reasons.

> (This by the way is a flaw in JAVA. If I go to a web-site that has
> JAVA that is poorly written and only works with one version of the
> spec and that isn't the version installed on my machine, the web-site
> is broken.
It sounds ancient. There was a significant change between the 1.x and 2.x
Java versions that impacts the GUI.

> What does one do when one has two different web sites,
> that both require different versions of the spec?

I believe there are ways of addressing that problem. Solaris used to have
three versions of Java installed, and was able to pick the right one for
every app somehow.

> In C++ the web site
> author can write his code to be compatible not only with the newest
> spec, but also with older versions (perhaps with less functionality),
> so that the user can pick an old version of the compiler and have all
> the code be happy--maybe not as "fancy" as one would like, but
> working!

That's a completely different issue. With Java, you are running an applet
on your local JVM. With a page served out with C++ you are either getting
HTML served to you, or you are running some kind of pluggin that has to be
specifically compiled for your OS and hardware. If its the former, Java
can do that in ways there are completely indistinguishable from what a C++
server will do. If you are talking about running a pluggin, then I can
assure you with the utmost confidence there are _more_ compatability issues
with C++ than with Java.
 

> And, what is the beauty of those macros (besides their portability),
> is that our primary source code (the uses of those macros) is easy to
> read. The syntax of the assert (and other macros) is quite simple and
> obvious. That is only doable because they are macros. If they
> weren't macros, some of the behind-the-scene-stuff like determining
> the current object would have to be present in the source code of each
> use.

I don't follow here. How can a macro determine the current object without
some kind of intentional intervention? I'm not saying it can't be done.
Perhaps you are talking about something similar to Qt's moc?

> Without cpp, either the source code (at assertion use) would
> have to be much uglier or the "assertion support" would have to be
> built into the compiler. And if the assertion support were built into
> the compiler, we would only get what the C++ compiler vendor provided
> us, which would probably be a poor assertion package on most
> platforms. Also note that the sophistication of our assertion support
> has grown with our code. If it wasn't done via macros, the
> behind-the-scenes stuff that cpp hides would have to have been changed
> at every assertion use when we realized that the was "a better way" to
> do things, as we have numerous times.

It sounds like macros are working well for you. And there certainly is
merit in 'if it ain't broke, don't fix it'. At the same time, I have to
wonder whether you would not have discovered an equally elegant approach
using other techniques. I also have to wonder what other internal features
of the language would have evolved to fill such needs. I can also
appreciate that macros may serve you better in supporting backward
compatibility. What I'm striving for is a way of doing things better if
you can afford a clean start.

Take careful not that I am not actually advocated abolishing the CPP, nor am
I advocating the abolishment of the #include. I simply want superior means
of doing some of the things the CPP is currently used for.

> In a language without cpp, we
> simply wouldn't have bothered to do it, and we wouldn't have been
> nearly as productive as a result.

I'll have to take that as an opinion, not a conclusion. I've never used
them, but Java supports some kind of assertion. And as I mentioned earlier
there is JUnit as well.

> So, that's the beauty of cpp, it lets one write simple obvious code
> and put behind it something sophisticated that makes the code do the
> right thing. It lets one do that in a compiler independent manner and
> do so even in the pressence of seriously broken compilers. And, it
> lets us "the application developers" do it and does not make us
> dependent on our compiler vendors.

Again, I have to wonder if the situation is a clear cut as you say it is.
I've seen 'pre-processing' done with Java, and I've seen some rather
inventive manipulations of Lisp which transcend the core language to add
functionality. I doubt it's likely to happen, but I suspect that if the
CPP were removed from the language, people would rediscover sed and awk in
a hurry.

> Oh, and by the way, I think that by "cleverly" using function
> prototypes that match our macros, we get nice code completion of the
> macros in our IDE--the best of both worlds.

Simple code completion really isn't much of an issue. I am talking about
far more sophisticated features such as being able to locate any class and
import the fully qualified class name by typing a few characters of the
name, and hitting a key combo. Also virtually complete error detection
before you compile.
> Note, somewhere you wrote that you can do some of the same things with
> sed and make. If you don't like cpp, why would you want to impose an
> external macro processor (that's what you are using sed for in that
> scenario) on your code? At least with cpp, you can know that you have
> something that is portable. For the longest time, I used systems that
> didn't even have sed on them. I may still do so. I don't know. It
> isn't something I would use. Moreover, with sed macros, your IDE has
> no hope of knowing exactly how your code will be transformed before
> being compiled. That is much worse than cpp. (I can just imagine how
> our development environment would be obscure if to get assertions, we
> had to preprocess all our code with sed scripts. Wouldn't that be a
> joy???)

I wasn't fully serious when I said that. OTOH, over the years, I've
encountered a good deal of that kind of thing. Also worth mentioning is
that asserts are really not something I see a a significant problem. At
worst I think they are a bit tacky. 

-- 
"[M]y dislike for the preprocessor is well known. Cpp is essential in C
programming, and still important in conventional C++ implementations, but
it is a hack, and so are most of the techniques that rely on it. ...I think
the time has come to be serious about macro-free C++ programming." - B. S.

Relevant Pages

  • Re: Cpp Considered Harmful
    ... > That's the difference with assertions. ... > features all the times. ... Stroustrup's alternative of using templates rather than macros overly ... the real argument for retaining the CPP would be that it is ...
    (comp.lang.cpp)
  • Re: Cpp Considered Harmful
    ... via a "pin" and an assertion ... to bring this back to the cpp. ... they were just the macros supplied by the C++ ... so that the user can pick an old version of the compiler and have all ...
    (comp.lang.cpp)
  • Re: Reflections on a classic Lisp Paper
    ... lisp dialects. ... user-defined special forms - Macros, Fexprs, and Nlambda. ... compilable because the compiler just couldn't do it. ...
    (comp.lang.lisp)
  • Re: Doing mini-languages in CL
    ... > Thats it in a nutshell. ... I think the detail to note is that the Macro facility is a Compiler ... simply put you may well be able to leverage CL macros in building your ...
    (comp.lang.lisp)
  • Re: Why doesnt Lisp automatically differentiate functions and macros?
    ... what stops a Lisp machine from figuring automatically which ... small subset of things macros can do that you are thinking is all they can ... This requires the compiler to know how to do things. ... things that the compiler writer didn't think to, ...
    (comp.lang.lisp)