Conditional compilation sans the cpp

[Steven T. Hatton]

I've made no secret of the fact that I really dislike the C preprocessor in
C++. No aspect of the language has caused me more trouble. No aspect of
the language has cause more code I've read to be difficult to understand.
I've described it as GOTO's on steroids, and that's what it is!.

One argument against abolishing it it that it is useful for conditional
compilation when porting code, etc. Well, it seems to me C++ supports that
natively. According to TC++PL(SE) §24.3.7.2 if a block of code is
bracketted with an if(CONDITION){. ..} the entire expression is "compiled
away" when CONDITION==fals e.

Can this not be used in place of the typical #ifdef ... #endif used for
conditional compilation?
--
STH
Hatton's Law: "There is only One inviolable Law"
KDevelop: http://www.kdevelop.org SuSE: http://www.suse.com
Mozilla: http://www.mozilla.org

[Kai-Uwe Bux]

Steven T. Hatton wrote:

I've made no secret of the fact that I really dislike the C preprocessor
in
C++. No aspect of the language has caused me more trouble. No aspect of
the language has cause more code I've read to be difficult to understand.
I've described it as GOTO's on steroids, and that's what it is!.

One argument against abolishing it it that it is useful for conditional
compilation when porting code, etc. Well, it seems to me C++ supports
that
natively. According to TC++PL(SE) §24.3.7.2 if a block of code is
bracketted with an if(CONDITION){. ..} the entire expression is "compiled
away" when CONDITION==fals e.

Can this not be used in place of the typical #ifdef ... #endif used for
conditional compilation?

This will work in many places, however, there are some instances where your
idea would not work, namely when the code is not within the body of a
function:

(a) the preprocessor allows you to conditionally include files.
(b) it allows to change the signature of a function.
(c) it allows to include or exclude certain members in a class.

Probably, there is way more.
Best

Kai-Uwe Bux

[lilburne]

Steven T. Hatton wrote:

I've made no secret of the fact that I really dislike the C preprocessor in
C++. No aspect of the language has caused me more trouble. No aspect of
the language has cause more code I've read to be difficult to understand.
I've described it as GOTO's on steroids, and that's what it is!.

One argument against abolishing it it that it is useful for conditional
compilation when porting code, etc. Well, it seems to me C++ supports that
natively. According to TC++PL(SE) §24.3.7.2 if a block of code is
bracketted with an if(CONDITION){. ..} the entire expression is "compiled
away" when CONDITION==fals e.

Can this not be used in place of the typical #ifdef ... #endif used for
conditional compilation?

#ifdef DEVELOPMENT
#ifdef USE_DEBUG
#define DEBUG_FUNC(FUNC ) FUNC
#else
#define DEBUG_FUNC(FUNC )
#endif
#endif

int sort(class Collection& col, sortType type)
{
// sort the collection some how
...

DEBUG_FUNC(chec k_sorted(col,ty pe));
}

is less clutter than:

int sort(class Collection& col, sortType type)
{
// sort the collection some how
...

if (DEBUG_FUNC) {
check_sorted(co l,type);
}
}

and you still have the problem of how to get the compiler to know that
DEBUG_FUNC is always false?

Then there is also <cassert> or your favourite replacement.

[Karl Heinz Buchegger]

"Steven T. Hatton" wrote:

I've made no secret of the fact that I really dislike the C preprocessor in
C++. No aspect of the language has caused me more trouble. No aspect of
the language has cause more code I've read to be difficult to understand.
I've described it as GOTO's on steroids, and that's what it is!.

One argument against abolishing it it that it is useful for conditional
compilation when porting code, etc. Well, it seems to me C++ supports that
natively. According to TC++PL(SE) §24.3.7.2 if a block of code is
bracketted with an if(CONDITION){. ..} the entire expression is "compiled
away" when CONDITION==fals e.
But it nevertheless runs through the compiler.

Can this not be used in place of the typical #ifdef ... #endif used for
conditional compilation?

Not in all cases.

Consider:
You want to write a function that deals with directories. On one
system the calls for this are callled eg. GetFirstFile, GetNextFile.
On another system the very same calls are called eg. GetFirst, GetNext.
On a third system the whole mechanism works in a complete different
way.
So the point is here: While on system A there are functions GetFirstFile and
GetNextFile, those functions aren't even available on system B or system C. So
you need a way to 'hide' those function calls from the compiler.

#ifdef SYSTEM_A

i = GetFirstFile( Directory );
while( i ) {
i = GetNextFile( FileName );
Process( FileName );
}

#else if SYSTEM_B

i = GetFirst( Directory );
while( i ) {
i = GetNext( FileName );
Process( FileName );
}

#else if SYSTEM_C

ReadDirectory( Directory, DirStruct );
for( i = 0; i < DirStruct.NrEnt ries; ++ i )
Process( DirStruct( File[i] );

#endif

When compiling for SYSTEM_A you actually need the compiler to not even
*see* the code for implementations in SYSTEM_B or SYSTEM_C, since SYSTEM_A
simple doesn't have that functions available.

--
Karl Heinz Buchegger
kb******@gascad .at

[Steven T. Hatton]

lilburne wrote:

int sort(class Collection& col, sortType type)
{
// sort the collection some how
...

DEBUG_FUNC(chec k_sorted(col,ty pe));
}

is less clutter than:

int sort(class Collection& col, sortType type)
{
// sort the collection some how
...

if (DEBUG_FUNC) {
check_sorted(co l,type);
}
This form is more consitant with C++, more immediately intelligible, and
doesn't require the code to be modified behind my back. If you are really
concerned about clutter you could do this:

if (DEBUG_FUNC) {check_sorted(c ol,type);}

Or depending on its return type:

if (DEBUG_FUNC && check_sorted(co l, type){}
and you still have the problem of how to get the compiler to know that
DEBUG_FUNC is always false?
const DEBUG_FUNC=fals e;
Then there is also <cassert> or your favourite replacement.

I'm not really sure why I need those. What does assert give me that I can't
get from native C++? If the sensible thing were done, there would be a way
to deterministicly resolve names in progams to declarations and definitions
in libraries as needed without the use of header files. Such a mechanism
could be used to locate the definition of DEBUG_FUNC whereever it may be
relative to the code you are compiling. I'm assuming it is a C++ constant,
and not a macro mangle. But as a general rule, I dislike the use of
globals. Be they functions, classes, variables, or constants. I would not
want to encourage such proactices as a general means of changing the
character of a program.

I really wish someone with the power to influence what goes into the
Standard would identify a means to accomplish the few things of value that
the cpp provides in a way that is more deterministic, coherent and
deterministic.

I've come to believe the greatest advantage Java has over C++ regarding ease
of use is not introspection, not garbage collection, not the elimination of
user manipulated pointers, not the restriction against using assignment as
a boolean condition, not the lack of MI, not the simpler and more uniform
syntax, not the extensive set of easy to use libraries. What Java has
over C++ is that it doesn't use the CPP. And it has, hands down, a better
exception handling mechanism. It is simply too hard to build tools that
can evaluate your code in the context of your development environment with
the incoherence introduced by the CPP.

Stroustrup's comment in §24.3.7.2 regarding the use of NDEBUG in conjunction
with /assert/ is: "Like all macro magic, this use of NDEBUG is too
low-level, messy, and error-prone.

A simple example of what is fundamentally wrong with C++'s reliance on the
#include <header> approach is when I tried using /size_t/ in a translation
unit that didn't #include anything else from the Standard Library. It was
undefined. The way I found it was to look it up in ISO/IEC 14882:2003 and
discovered it is defined in #include <cstddef>. The fact that /size_t/ had
always been available without my #including <cstddef> means there are
multiple paths through the headers that can result in such identifiers
being introduced into my code silently. That is a bad thing. It leads to
dependencies on things I am not aware of. THAT DOESN'T SCALE!
--
STH
Hatton's Law: "There is only One inviolable Law"
KDevelop: http://www.kdevelop.org SuSE: http://www.suse.com
Mozilla: http://www.mozilla.org

[lilburne]

Steven T. Hatton wrote:

lilburne wrote:

int sort(class Collection& col, sortType type)
{
// sort the collection some how
...

DEBUG_FUNC(chec k_sorted(col,ty pe));
}

is less clutter than:

int sort(class Collection& col, sortType type)
{
// sort the collection some how
...

if (DEBUG_FUNC) {
check_sorted(co l,type);
}

This form is more consitant with C++, more immediately intelligible, and
doesn't require the code to be modified behind my back. If you are really
concerned about clutter you could do this:

if (DEBUG_FUNC) {check_sorted(c ol,type);}

Or depending on its return type:

if (DEBUG_FUNC && check_sorted(co l, type){}

To say that the rewrite you habe given reduces clutter you can't have
had the privilege of looking at functions that have these
DEBUG_FUNC(...) statements every two or three lines.

and you still have the problem of how to get the compiler to know that
DEBUG_FUNC is always false?

const DEBUG_FUNC=fals e;

How do you get that into the program? By having different headers, or by
editing a header? If the former how do you choose between the headers?
If the later how do you deal with the recompilation of 100s of source files?

Then there is also <cassert> or your favourite replacement.

I'm not really sure why I need those. What does assert give me that I can't
get from native C++?

Earlier you were discussing rectangles and points. The nearest thing we
have is a 3d box. This is the code for returning what we consider the
maximum point of a 3d box, which is pretty typical of our 'one-line'
functions:

Point3D Box3D::max() const
{
ASSERT_STATE(!i nvalid(),"Box3D ::max");
ASSERT_STATE(m_ arr[1][0] < infinity(),"Box 3D::max | infinite");
ASSERT_STATE(m_ arr[1][1] < infinity(),"Box 3D::max | infinite");
ASSERT_STATE(m_ arr[1][2] < infinity(),"Box 3D::max | infinite");)
return Point3D(m_arr[1][0],m_arr[1][1],m_arr[1][2]);
}


Stroustrup's comment in §24.3.7.2 regarding the use of NDEBUG in conjunction
with /assert/ is: "Like all macro magic, this use of NDEBUG is too
low-level, messy, and error-prone.

Anyone not using /assert/ has messy, error-prone code.

A simple example of what is fundamentally wrong with C++'s reliance on the
#include <header> approach is when I tried using /size_t/ in a translation
unit that didn't #include anything else from the Standard Library. It was
undefined. The way I found it was to look it up in ISO/IEC 14882:2003 and
discovered it is defined in #include <cstddef>. The fact that /size_t/ had
always been available without my #including <cstddef> means there are
multiple paths through the headers that can result in such identifiers
being introduced into my code silently. That is a bad thing. It leads to
dependencies on things I am not aware of. THAT DOESN'T SCALE!

Well there are many projects applications that contain 1,000,000s of
lines of code. The application I work on has about 10,000,000. Defines
in header files and conditional compilations really aren't a problem.

[Steven T. Hatton]

Karl Heinz Buchegger wrote:

"Steven T. Hatton" wrote:

I've made no secret of the fact that I really dislike the C preprocessor
in
C++. No aspect of the language has caused me more trouble. No aspect of
the language has cause more code I've read to be difficult to understand.
I've described it as GOTO's on steroids, and that's what it is!.

One argument against abolishing it it that it is useful for conditional
compilation when porting code, etc. Well, it seems to me C++ supports
that
natively. According to TC++PL(SE) §24.3.7.2 if a block of code is
bracketted with an if(CONDITION){. ..} the entire expression is "compiled
away" when CONDITION==fals e.

But it nevertheless runs through the compiler.

It would appear that is the case with g++. I doesn't simply ignore
unreachable code. I know Stroustrup and some others have been playing with
a design for some kind of macro firewall that is supposed to isolate code
from an effects from the preprocessor. But that can't be completely
effective. The CPP is capable of rewriting any code not exclusively
protected, and if you depend on any of the stuff it mangles, all bets are
off.

I fully understand that the CPP has been used to to some great stuff. The
damn thing's been around since the mid 70s or so. It couldn't have
survived this long if it wasn't useful. I probably have most of my major
problems with understanding what it's doing to me under normal
circumstances behind me. OTOH, if Stroustrup has been stung by other
people's macros mangling his code, I'm sure it can and will happen to a
mere mortal like me.

Not only that, but take a look at a translation unit some time. I was in
shock when I saw everything the CPP sucked in to build a tiny little file.
There's got to be a better way!

--
STH
Hatton's Law: "There is only One inviolable Law"
KDevelop: http://www.kdevelop.org SuSE: http://www.suse.com
Mozilla: http://www.mozilla.org

[Karl Heinz Buchegger]

"Steven T. Hatton" wrote:

I fully understand that the CPP has been used to to some great stuff. The
damn thing's been around since the mid 70s or so. It couldn't have
survived this long if it wasn't useful. I probably have most of my major
problems with understanding what it's doing to me under normal
circumstances behind me.

My understanding is this:
The CPP is nothing else then a glorified text editor that runs before
the actual compiler even sees the source code. The tricky thing is:
The text editor is controlled by a programming language and the tricky
part is that the statements of that programming language are embedded
in the text to edit itself.

--
Karl Heinz Buchegger
kb******@gascad .at

[Dietmar Kuehl]

"Steven T. Hatton" <su******@setid ava.kushan.aa> wrote:

One argument against abolishing it it that it is useful for conditional
compilation when porting code, etc. Well, it seems to me C++ supports that
natively. According to TC++PL(SE) §24.3.7.2 if a block of code is
bracketted with an if(CONDITION){. ..} the entire expression is "compiled
away" when CONDITION==fals e.

However, the body of the function is still analysed for correctness,
i.e. it just an optimization not really conditional compilation. To some
extend you can use template for conditional compilation: a template which
is not instantiated is not checked for correctness to some degree.
--
<mailto:di***** ******@yahoo.co m> <http://www.dietmar-kuehl.de/>
<http://www.contendix.c om> - Software Development & Consulting

[Thomas Matthews]

lilburne wrote:

Steven T. Hatton wrote:

lilburne wrote:

Well there are many projects applications that contain 1,000,000s of
lines of code. The application I work on has about 10,000,000. Defines
in header files and conditional compilations really aren't a problem.

On large programs that have produce many combinations, the
defines become a large problem. I've worked on projects
where the OS command line was not large enough to support
all the #defines.

I prefer using standard interfaces and letting the linker
or build script choose which source file to implement
the interface with.

For example, my project at work as a lot of
#ifdef PLATFORM_IS_BIG _ENDIAN
#else
#endif
for converting message fields to the native byte ordering.

I would rather have a single function:
value = Apply_Endian_Co nversion(old_va lue);
and have different implementations that the build
script chooses. IMHO, this technique provides cleaner
code (easier to read) and fewer compilation and
porting problems.

--
Thomas Matthews

C++ newsgroup welcome message:
http://www.slack.net/~shiva/welcome.txt
C++ Faq: http://www.parashift.com/c++-faq-lite
C Faq: http://www.eskimo.com/~scs/c-faq/top.html
alt.comp.lang.l earn.c-c++ faq:
http://www.comeaucomputing.com/learn/faq/
Other sites:
http://www.josuttis.com -- C++ STL Library book