An Empirical Analysis of CPP Use

[Steven T. Hatton]

pag.csail.mit.e du/~mernst/ pubs/c-preprocessor-tse2002.pdf

Abstract:
This is the first empirical study of the use of the C
macro preprocessor, Cpp. To determine how the preprocessor is
used in practice, this paper analyzes 26 packages comprising 1.4
million lines of publicly available C code. We determine the
incidence of C preprocessor usage?whether in macro definitions,
macro uses, or dependences upon macros?that is complex,
potentially problematic, or inexpressible in terms of other C or
C++ language features. We taxonomize these various aspects of
preprocessor use and particularly note data that are material to
the development of tools for C or C++, including translating from
C to C++ to reduce preprocessor usage. Our results show that,
while most Cpp usage follows fairly simple patterns, an effective
program analysis tool must address the preprocessor. The intimate
connection between the C programming language and Cpp, and Cpp?s
unstructured transformations of token streams often hinder both
programmer understanding of C programs and tools built to
engineer C programs, such as compilers, debuggers, call graph
extractors, and translators. Most tools make no attempt to
analyze macro usage, but simply preprocess their input, which
results in a number of negative consequences; an analysis that
takes Cpp into account is preferable, but building such tools
requires an understanding of actual usage. Differences between
the semantics of Cpp and those of C can lead to subtle bugs
stemming from the use of the preprocessor, but there are no
previous reports of the prevalence of such errors. Use of C++ can
reduce some preprocessor usage, but such usage has not been
previously measured. Our data and analyses shed light on these
issues and others related to practical understanding or
manipulation of real C programs. The results are of interest to
language designers, tool writers, programmers, and software
engineers.
--
If our hypothesis is about anything and not about some one or more
particular things, then our deductions constitute mathematics. Thus
mathematics may be defined as the subject in which we never know what we
are talking about, nor whether what we are saying is true.-Bertrand Russell

[Zorro]

Thank you. After all, only those who write code are qualified to do
realistic research. This is valuable in quantifying a major source of
obscure defects.

Regards,
Z.
http://www.zhmicro.com
http://distributed-software.blogspot.com

[Steven T. Hatton]

Zorro wrote:

Thank you. After all, only those who write code are qualified to do
realistic research. This is valuable in quantifying a major source of
obscure defects.

Regards,
Z.
http://www.zhmicro.com
http://distributed-software.blogspot.com

I believe this is an expansion or variation of an article that appeared in
the 12th IEEE International Workshop on Program Comprehension (IWPC'04)
papers:

http://etheses.uwaterloo.ca/display.cfm?ethesis_id=390

Giving Meaning to Macros, by Mennie, Christopher

Abstract:
"With the prevalence of legacy C/C++ code, issues of readability and
maintainability have become increasingly important. When we consider the
problem of refactoring or migrating C/C++ code, we see the significant role
that preprocessor directives play. It is partially because of these
preprocessor directives that code maintenance has become extremely
difficult.

"This thesis describes a method of fact extraction and code manipulation to
create a set of transformations which will remove preprocessor directives
from the original source, converting them into regular C/C++ code with as
few changes as possible, while maintaining readability in the code. In
addition, some of the subtle issues that may arise when migrating
preprocessor directives are explored. After discussing the general
architecture of the test implementation, an examination of some metrics
gathered by running it on two software systems is given."

--
If our hypothesis is about anything and not about some one or more
particular things, then our deductions constitute mathematics. Thus
mathematics may be defined as the subject in which we never know what we
are talking about, nor whether what we are saying is true.-Bertrand Russell

[Zorro]

Thanks again. This is of particular interest to me because some time
ago I argued against the subtle uses of the preprocessor in connection
with BOOST initiative. I appreciate your bringing this matter up.

Regards,
Z.

[Ira Baxter]

"Steven T. Hatton" <ch********@ger mania.sup> wrote in message
news:6K******** ************@sp eakeasy.net...

pag.csail.mit.e du/~mernst/ pubs/c-preprocessor-tse2002.pdf

Abstract:
This is the first empirical study of the use of the C
macro preprocessor, Cpp. [snip] The intimate
connection between the C programming language and Cpp, and Cpp?s
unstructured transformations of token streams often hinder both
programmer understanding of C programs and tools built to
engineer C programs, such as compilers, debuggers, call graph
extractors, and translators. Most tools make no attempt to
analyze macro usage, but simply preprocess their input, which
results in a number of negative consequences; an analysis that
takes Cpp into account is preferable, but building such tools
requires an understanding of actual usage.

While we don't take into account all the uses of Cpp,
our DMS tool for processing C and C++ *do* handle a surprisingly
wide variety of source code containing Cpp directives,
and we manage to analyze/transform that code without
expanding or wrecking the directives. Yes, this is pretty
unique.

DMS has been used on major C and C++ reengineering tasks.

See http://www.semdesigns.com/Products/F...pFrontEnd.html.
--
Ira D. Baxter, Ph.D., CTO 512-250-1018
Semantic Designs, Inc. www.semdesigns.com