Re: [lmi] Code review: product editor

[Greg Chicares]

On 2007-3-5 16:07 UTC, Vadim Zeitlin wrote:
> On Thu, 01 Mar 2007 18:15:15 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> preprocessor--or especially the boost preprocessor library, which I
> GC> think we could then eliminate entirely.
> 
>  I have the impression that you see some benefit in eliminating the use of
> this library that I'm missing. As lmi uses several other boost libraries
> and so boost headers are available anyhow, what exactly is the problem with
> using this one?

I feel that macros make code harder to understand in general,
so I'd rather avoid them unless there's no reasonable
alternative. For example, I would find it difficult to modify
the macros in 'input_seq_test.cpp', even though I wrote them;
I'd rather eliminate them than maintain them. I left 'LMI_P'
in 'md5.hpp' because it's third-party code that "just works",
but I can't explain today what it does, much less the other
macros in 'md5.cpp'.

I've had to debug (someone else's) macros that generate class
definitions in the past, and found it difficult; in the end,
I wound up running the source through the preprocessor first
in order to get something I could comprehend. I had to do
that numerous times; I'm glad I stopped using that library.

Compiler error messages are harder to track down when they
point to complex macro definitions.

Macros that use token pasting to create names prevent tools
like 'grep' from working as easily as they otherwise would.

Preprocessor metaprogramming adds another yet obstacle to
comprehension. It requires us to understand a fundamentally
different paradigm for writing code, one that not every good
C++ programmer would already have mastered.

It's an inherent problem of macros that the code we see isn't
the same as the code the compiler sees, so the obstacles to
comprehensibility can't be removed. I'd rather seek another
way of doing things first, before writing a macro. In the
particular case at hand, we could eliminate macros and
preprocessor metaprogramming and get two class templates
instead of one; that's not as compact, sure, but I think it
would be a lot easier for me to work with--and I suspect
that it could be made into one single generic template class
that adds a non-type parameter.