howlett@netcom.com (Scott Howlett) writes:

|>  Steve Clamage <stephen.clamage@eng.sun.com> wrote:
|>
|>  [...]
|>
|>  > The fundamental error is sprinking system dependencies throughout
|>  > your application code. Instead you should write for an
|>  > abstract system and implement the abstract system for each
|>  > platform of interest.
|>  >
|>
|>  I agree completely with this, and I certainly am in favor of minimizing
|>  use of CPP where possible, but in certain cases I find that I seemingly
|>  have no choice, for example:
|>
|>  1) I use a set of macros for exception handling keywords (try, catch,
|>  throw, etc.) which maps properly onto custom exception handling mechanisms
|>  that several different application frameworks (MFC, for example)
|>  require. In the past, they also provided limited support for exception
|>  handling on compilers which did not support it directly.

Using macros is not necessarily conditional compilation.  In fact, I use
them extensively to avoid conditional compilation.  (It's almost the
only use I do make of macros).  For example:

 GB_BEGIN_TRY
  //  Do something dangerous
 GB_CATCH( ... )
  //  Undo it
  GB_RETHROW ;
 GB_END_TRY

If the system doesn't support macros, GB_BEGIN_TRY expands to "if ( 1
)", and GB_CATCH to "else if ( cond )".  (Come to think about it, this
would result in "else if ( ... )" in the above.  Which shouldn't
compile.  But apparently does on the few compilers I use without
exceptions.)

The macros are defined in a system dependant header file, with a
separate file for each system.  Current policy is to keep these files in
separate directories; an earlier policy used #include MACHINE_FILE, with
the requirement to compile with a -DMACHINE_FILE=... directive.

|>  2) I have a template which is used on one compiler which supports
|>  (and requires) the 'typename' keyword, and on another which doesn't
|>  know about it at all. This pretty much requires that somewhere I have
|>  CPP code which tests to see which compiler I'm using and #defines
|>  typename if I'm using the brain-damaged one.

Again: typename should be a macro, defined in a system dependant header
file.

|>  3) I have a small class which is used in a high-performance environment
|>  and it has different implementations for different platforms. I really
|>  want this class to be a concrete class, and I don't want to introduce
|>  the overhead of having it use a handle / body internally. I have the
|>  choice of either having duplicate class definitions for each platform
|>  or having one definition which internally uses conditional compilation.
|>
|>  In my experience, the latter has been more maintainable because if I need
|>  to change something about the class, I don't have to magically remember
|>  to go to the "other" source file and change it too - the "other" source
|>  is staring me right in the face.
|>
|>  Of course the prudent thing to do is to shove the platform dependencies
|>  down such that the number of classes which need this is very small, and
|>  is pretty much limited to framework classes which normally won't be
|>  touched during application development anyway.

In practice, I'm not as rigorous as avoiding conditional compilations as
is Steve Clamage.  I find it easier, for example, to maintain a single
preprocessor symbol, GB_HASNEWCAST, for example, in multiple files, and
use conditional compilation to define the macros actually used in a
single, global header, e.g.:

 #if GB_HASNEWCAST
 #define GB_const_cast( t , o )          (const_cast< t >(o))
 #define GB_static_cast( t , o )         (static_cast< t >(o))
 #define GB_reinterpret_cast( t , o )    (reinterpret_cast< t >(o))
 #else
 #define GB_const_cast( t , o )          ((t)(o))
 #define GB_static_cast( t , o )         ((t)(o))
 #define GB_reinterpret_cast( t , o )    ((t)(o))
 #endif

The alternative would be to require the definition of the three macros
in each of the system dependant files -- not a big deal either.  And
this header is the ONLY place conditional compilation is allowed in my
code.

--
James Kanze      home:     kanze@gabi-soft.fr        +33 (0)1 39 55 85 62
                 office:   kanze@vx.cit.alcatel.fr   +33 (0)1 69 63 14 54
GABI Software, Sarl., 22 rue Jacques-Lemercier, F-78000 Versailles France
     -- Conseils en informatique industrielle --
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

James Kanze wrote:
>
> John David Galt <jdg@but-i-dont-like-spam.boxmail.com> writes:
>
> |>  *  Math works differently (not just things that need to be system-specific,
> |>     like INT_MAX, sizeof(various types), and the negative-number format, but
> |>     things like the values of (-3) % 8 and 0x1234 >> 2, which ought to be
> |>     the same everywhere).
>
> Well, the last is:-) (but only because 0x1234 is positive).

Not on my 13-bit Ersatz 9000 CPU!

--

Ciao,
Paul

(Please remove the "strip_these_words_" prefix from the return
address, which has been altered to foil junk mail senders.)
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Steve Clamage <stephen.clamage@eng.sun.com> wrote:

[...]

> The fundamental error is sprinking system dependencies throughout
> your application code. Instead you should write for an
> abstract system and implement the abstract system for each
> platform of interest.
>

I agree completely with this, and I certainly am in favor of minimizing
use of CPP where possible, but in certain cases I find that I seemingly
have no choice, for example:

1) I use a set of macros for exception handling keywords (try, catch,
throw, etc.) which maps properly onto custom exception handling mechanisms
that several different application frameworks (MFC, for example)
require. In the past, they also provided limited support for exception
handling on compilers which did not support it directly.

2) I have a template which is used on one compiler which supports
(and requires) the 'typename' keyword, and on another which doesn't
know about it at all. This pretty much requires that somewhere I have
CPP code which tests to see which compiler I'm using and #defines
typename if I'm using the brain-damaged one.

3) I have a small class which is used in a high-performance environment
and it has different implementations for different platforms. I really
want this class to be a concrete class, and I don't want to introduce
the overhead of having it use a handle / body internally. I have the
choice of either having duplicate class definitions for each platform
or having one definition which internally uses conditional compilation.

In my experience, the latter has been more maintainable because if I need
to change something about the class, I don't have to magically remember
to go to the "other" source file and change it too - the "other" source
is staring me right in the face.

Of course the prudent thing to do is to shove the platform dependencies
down such that the number of classes which need this is very small, and
is pretty much limited to framework classes which normally won't be
touched during application development anyway.

- Scott

--
Scott Howlett, howlett@netcom.com
"If trees could scream, would we be so cavalier about cutting them
down? We might, if they screamed all the time, for no good reason."
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

"Paul D. DeRocco" <strip_these_words_pderocco@ix.netcom.com> wrote:

> James Kanze wrote:
> >
> > John David Galt <jdg@but-i-dont-like-spam.boxmail.com> writes:
> >
> > |>  *  Math works differently (not just things that need to be system-specific,
> > |>     like INT_MAX, sizeof(various types), and the negative-number format, but
> > |>     things like the values of (-3) % 8 and 0x1234 >> 2, which ought to be
> > |>     the same everywhere).
> >
> > Well, the last is:-) (but only because 0x1234 is positive).
>
> Not on my 13-bit Ersatz 9000 CPU!

Perhaps not, but then you aren't working with a C++ compiler.  C++
requires that 0x1234 be positive.

Michael M Rubenstein
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Steve Clamage wrote:
> [lots of sensible stuff snipped]

I think I agree with most of what you say.  I certainly
believe in hiding details behind common interfaces etc etc.
My point is that the preprocessor can still be useful.  This
doesn't mean that that I would abandon good practice.  What I am
complaining about is people giving examples of bad practice
using the preprocessor and then claiming that this is evidence
that the preprocessor is a "bad thing" and should be abolished.

Steve gave the example
> #if defined(__EXTENSIONS__) || ((__STDC__ - 0 == 0 && \
>     !defined(_POSIX_C_SOURCE))) || defined(_XOPEN_SOURCE)
>   #if defined(__EXTENSIONS__) || __STDC__ == 0 || \
>       defined(_XOPEN_SOURCE)
>     ...
>     #if !defined(_XOPEN_SOURCE)
>       ...
>     #endif
>     ...
>   #endif
>   ...
> #endif

This is appalling code but please don't blame the preprocessor.
If these were run-time tests rather than compile-time tests
and used 'if' rather than '#if' it would still be bad code.
Should we therefore abolish 'if' too?  No, shoot the programmer
who wrote it!

> The proof of this pudding lies in the existence of commercial
> libraries that work exactly this way. You program in terms of
> the abstract window system, and link in a library implementation
> for the window system you are using.

Ah, but just because the library is distributed in different
file that doesn't mean that it doesn't have shared source files
and #ifdefs.  I have distributed libraries built this way.  I have
hidden the system dependencies behind an abstract interface.  I have
also found the occasional #if very helpful in implementing such
libraries!

The message I responded was part of a discussion about adding
"global if"s to C++ to replace the preprocessor.  So, we abolish
the preprocessor and add "global if"s to replace its functionality.
What have we achieved?  Nothing more than respellng "#if"!!  Did no
one appreciate my little joke:

> Steve Clamage also wrote:
> >
> > For example, I suppose you were thinking of something like
> >         if( INT_MAX < 0xFFFFFFFF )
> >                 typedef long INT;
> >         else
> >                 typedef int INT;
> > Assuming existing semantics of "if", this example puts different
> > definitions of INT in the same scope and is not allowed.
> >
> > You could use braces:
> >         if( INT_MAX < 0xFFFFFFFF ) {
> >                 typedef long INT;
> >         } else {
> >                 typedef int INT;
> >         }
>
> I like this idea, but think that alternative syntax might help
> (if only to clearly mark out compiler-time "if"s from run-time
> ones).  How about:
>
>     #if (INT_MAX < 0xFFFFFFFF)
>         typedef long INT;
>     #else
>         typedef int INT;
>     #endif
>
> That seems fairly neat!

I am afraid I do fail to see why the "global if"s are good but the
"#if"s bad!

Maybe some people can find no use for the preprocessor.  Maybe some
programmers shouldn't be let near it.  It's not ideal but I find it
useful.  There are often alternatives, but they are often worse
than the original.  I resent having a useful facility taken away
from me because others can't use it safely!

-- jP --
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

"Paul D. DeRocco" <strip_these_words_pderocco@ix.netcom.com> writes:

|>  James Kanze wrote:
|>  >
|>  > John David Galt <jdg@but-i-dont-like-spam.boxmail.com> writes:
|>  >
|>  > |>  *  Math works differently (not just things that need to be system-specific,
|>  > |>     like INT_MAX, sizeof(various types), and the negative-number format, but
|>  > |>     things like the values of (-3) % 8 and 0x1234 >> 2, which ought to be
|>  > |>     the same everywhere).
|>  >
|>  > Well, the last is:-) (but only because 0x1234 is positive).
|>
|>  Not on my 13-bit Ersatz 9000 CPU!

If 0x1234 is not positive, the implementation is not conforming.
INT_MAX must be at least 32767 (0x7fff).

--
James Kanze      home:     kanze@gabi-soft.fr        +33 (0)1 39 55 85 62
                 office:   kanze@vx.cit.alcatel.fr   +33 (0)1 69 63 14 54
GABI Software, Sarl., 22 rue Jacques-Lemercier, F-78000 Versailles France
     -- Conseils en informatique industrielle --
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Julian Pardoe wrote:
>
> Steve Clamage wrote:
> > [lots of sensible stuff snipped]
>
> I think I agree with most of what you say.  I certainly
> believe in hiding details behind common interfaces etc etc.
> My point is that the preprocessor can still be useful.  This
> doesn't mean that that I would abandon good practice.  What I am
> complaining about is people giving examples of bad practice
> using the preprocessor and then claiming that this is evidence
> that the preprocessor is a "bad thing" and should be abolished.

And my point (from experience) is that once you start down the
garden path of conditional compilation, the code accretes more
and more conditionals until it becomes unmaintainable.

Example:
 #ifdef MSWINDOWS
     something
 #else
     something else
 #endif
Now you add a third platform. The natural thing is to add a third
clause. Next, you split off Win3.1, Win95, NT3.5, NT4.0, with sub-
conditionals. Soon you have a real mess.

It is not just inept programmers who will bring about the problem;
it is inherent in the decision to use conditional compilation in
the first place.

> > The proof of this pudding lies in the existence of commercial
> > libraries that work exactly this way. You program in terms of
> > the abstract window system, and link in a library implementation
> > for the window system you are using.
>
> Ah, but just because the library is distributed in different
> file that doesn't mean that it doesn't have shared source files
> and #ifdefs.  I have distributed libraries built this way.

Yes, but conditional compilation would have been a choice, not a
requirement. Similarly, you might have chosen to write spaghetti
code instead of structured code and hidden it in the library.
IMHO those would have been wrong choices.

Also, I don't understand the comment about "shared source files
and #ifdefs". I advocate shared source files, but without #ifdefs.

Split off the bits that differ among implementations, and share
the remainder of the code. Adding a platform then does not require
touching any existing code; you just add new definition files for
the new platform. A change in an existing platform does not require
touching any shared code; you only modify the platform-specific files.

--
Steve Clamage, stephen.clamage@eng.sun.com
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

On 05 May 97 03:28:03 GMT, Steve Clamage <stephen.clamage@eng.sun.com>
wrote:

>Mike Rubenstein wrote:
> > Steve Clamage <stephen.clamage@eng.sun.com> wrote:
> >  > Paul D. DeRocco wrote:
> >  > > Does anyone know if the standards committee ever considered allowing
> >  > > "if" statements (with constant expressions) at the global level, as an
> >  > > alternative to conditional compilation using #if or #ifdef? Its main
> >  > > advantage is that it would allow conditional compilation to be based on
> >  > > "const" constants and enum values, instead of #define symbols, thus
> >  > > pulling more stuff out of the realm of the preprocessor into "real" C++.
> >  > > It also might allow a greater degree of precompilation. Does anyone see
> >  > > any disadvantages?
> >  >
> >  > I don't believe it was ever considered by the C++ Committee.

Hello. May I make a comment? I used to read this group regularly about
a year or two ago, and have just recently resumed. If this has been
covered before, I apologize, and would ask for a few pointers. Thanks.

How much has been thought about regarding full meta-programming
capability in C++? When templates were introduced, and started to be
refined, I was sure that since the metaprogramming cat had been let
out of the bag, so to speak, it would blossom into a full feature of
the language. That really hasn't happened, and I was curious why.

No doubt most of you have seen template source for a class that
calculates the value of a factorial recursively at compile time. If it
can be done, then why force the use of a hack of the template
construct, rather than implement a regular meta-function? I realize
that this will not happen before C++ is standardized, but why not put
it on the ballot for the next revision, in the hopes that C++ will
evolve into a full-featured language for the year 2000+ and beyond,
capable of supporting all metaprogramming idioms, as long as they do
not violate the spirit of C++ and its existing framework.

What I propose, is the introduction of the 'meta' keyword, which would
function much like the template keyword, with a few minor differences.

It could function as a compile-time if, by using information available
at compile time:

const bool foo = true;

meta if (foo)
 //dothis
else
 //dothat


To calculate a factorial at compile time:

meta factorial(int value)
{
 return value * factorial(value-1);
}

const int fac10 = factorial(10);


Now, obviously this would take some thinking and some work, but I
think it will prove useful in the long run, the general idea being
support of full compile-time programming. The benefit from this would
be a whole universe of programming possibilities that are not possible
any other way. Once you escape from the level of "real" code, and
reach meta- level, you can then code meta-meta- programs, etc. It
opens up a whole new universe of possibilities. Consider that you
could write meta-code that would generate other meta-code, etc.
(Can templates generate other templates?)

Instead of using something like MS's AppWizard, you could use a
metaprogram and extend it/parameterize it however you needed.

Comments?
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Videoman wrote:
>
> What I propose, is the introduction of the 'meta' keyword, which would
> function much like the template keyword, with a few minor differences.
>
> It could function as a compile-time if, by using information available
> at compile time:
>
> const bool foo = true;
>
> meta if (foo)
>         //dothis
> else
>         //dothat
>
> To calculate a factorial at compile time:
>
> meta factorial(int value)
> {
>         return value * factorial(value-1);
> }
>
> const int fac10 = factorial(10);

One of the limitations of template-based metaprogramming is that it can
only operate on integer types, not floating point types, since templates
can only be parameterized by integers. Someone suggested that this
limitation was due to the potential difficulty, in cross-compiler
environments, of making it possible for the compiler to do full floating
point arithmetic in a manner that's compatible with the target machine.
(It's pretty easy for ints, even in the worst case.)

With respect to your proposed "meta" functions, either the language
would have to restrict such functions from using floats, or the compiler
would have to have a full emulator of the target machine's floating
point unit.

--

Ciao,
Paul

(Please remove the "strip_these_words_" prefix from the return
address, which has been altered to foil junk mail senders.)
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Steve Clamage <stephen.clamage@Eng.Sun.COM> wrote:
>>> Some programming shops, including my former company and some groups
>>> here at Sun, ban the use of conditional compilation entirely, on
>>> the grounds that such code is too hard to maintain, and alternatives
>>> are available which are acceptable and often superior.

> I'm talking about code like this:

> #if defined(__EXTENSIONS__) || ((__STDC__ - 0 == 0 && \
>     !defined(_POSIX_C_SOURCE))) || defined(_XOPEN_SOURCE)
>   #if defined(__EXTENSIONS__) || __STDC__ == 0 || \
>       defined(_XOPEN_SOURCE)
>     ...
>     #if !defined(_XOPEN_SOURCE)
>       ...
>     #endif
>     ...
>   #endif
>   ...
> #endif

> Trying to sort through this to figure out what is going on
> and what code is active is a real challenge.

That's a great rule, for an ideal world; and it works, if your code only
needs to run on one platform.  But the first time you write something that
is supposed to work on Solaris, HP-UX, IBM MVS, OpenVMS, _and_ Windows NT,
you'll find it's impossible without lots of conditionals.  Even if we
ignore operating-system differences such as the format of a file path, you
run into things like:

*  Math works differently (not just things that need to be system-specific,
   like INT_MAX, sizeof(various types), and the negative-number format, but
   things like the values of (-3) % 8 and 0x1234 >> 2, which ought to be
   the same everywhere).

*  Important feature packages (templates, exceptions, <stdarg.h>, and the
   STL; not to even mention <pipe.h>, <sysconf.h>, BSD sockets, pthreads,
   and X-Windows) not only are not supported on all systems, but there
   isn't even a portable #if-test to check whether any one of them is
   supported.  You have to put in separate "#ifdef system_name" blocks for
   each system to find out.  (Yes, I know, this is an issue for POSIX and
   other standards bodies as well.  But the first four items are C++
   standard issues, and adding __STDCPP__ would solve those.)

Eliminating conditionals is a worthy goal, but to achieve it, the standard
has _got_ to start making all systems work the same in most of these ways.
It can be done.  Fortran (both -78 and -90) does it, and is better for it.

Otherwise, you might as well call it an RFC or something else, because it
sure doesn't set any _standards_.

John David Galt
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

John David Galt wrote:
>
> Steve Clamage <stephen.clamage@Eng.Sun.COM> wrote:
> >>> Some programming shops, including my former company and some groups
> >>> here at Sun, ban the use of conditional compilation entirely, on
> >>> the grounds that such code is too hard to maintain, and alternatives
> >>> are available which are acceptable and often superior.
>
> > I'm talking about code like this:
>
> > #if defined(__EXTENSIONS__) || ((__STDC__ - 0 == 0 && \
> >     !defined(_POSIX_C_SOURCE))) || defined(_XOPEN_SOURCE)
> >   #if defined(__EXTENSIONS__) || __STDC__ == 0 || \
> >       defined(_XOPEN_SOURCE)
> >     ...
> >     #if !defined(_XOPEN_SOURCE)
> >       ...
> >     #endif
> >     ...
> >   #endif
> >   ...
> > #endif
>
> > Trying to sort through this to figure out what is going on
> > and what code is active is a real challenge.
>
> That's a great rule, for an ideal world; and it works, if your code only
> needs to run on one platform.  But the first time you write something that
> is supposed to work on Solaris, HP-UX, IBM MVS, OpenVMS, _and_ Windows NT,
> you'll find it's impossible without lots of conditionals.

I was speaking specifically about code that that must run on a wide
variety of unrelated platforms. It was for such a scenario in my
previous company that we evolved the rule. Our code got simpler and
easier to maintain when we eliminated conditional compilation.

The basic principle is that you isolate system dependencies into
modules and project header files. You create versions of those files
for each platform, and put them in platform-specific directories.
The build process picks up files from the directory (or directories) for
the appropriate platform.

C++ makes this process particularly convenient. You create abstract
base classes that encapsulate the functionality you want, then
derive from those classes and implement the functions as needed.

--
Steve Clamage, stephen.clamage@eng.sun.com
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Steve Clamage wrote:
>
> Gerard Weatherby wrote:
> >
> > Steve Clamage wrote:
> > > Some programming shops, including my former company and some groups
> > > here at Sun, ban the use of conditional compilation entirely, on
> > > the grounds that such code is too hard to maintain, and alternatives
> > > are available which are acceptable and often superior.
> >
> > Could you explain at least briefly the alternatives?  For example,
> > what's the alternative to the assert macro?
>
> Using the assert macro does not require you to write any code
> that has conditional compilation.
>
> I'm talking about code like this:
>
> #if defined(__EXTENSIONS__) || ((__STDC__ - 0 == 0 && \
>     !defined(_POSIX_C_SOURCE))) || defined(_XOPEN_SOURCE)
>   #if defined(__EXTENSIONS__) || __STDC__ == 0 || \
>       defined(_XOPEN_SOURCE)
>     ...
>     #if !defined(_XOPEN_SOURCE)
>       ...
>     #endif
>     ...
>   #endif
>   ...
> #endif
>
> Trying to sort through this to figure out what is going on
> and what code is active is a real challenge.

Yes, one can write bad code in any language; that doesn't
mean one has to.

You suggest gathering all one's system dependent stuff into
special files and having one version per system.  Well, I'm
not sure that having multiple source files is necessarily better
that having some #ifdefs, especially if the files are long
and the number of conditional differences small.

Steve Clamage also wrote:
>
> For example, I suppose you were thinking of something like
>         if( INT_MAX < 0xFFFFFFFF )
>                 typedef long INT;
>         else
>                 typedef int INT;
> Assuming existing semantics of "if", this example puts different
> definitions of INT in the same scope and is not allowed.
>
> You could use braces:
>         if( INT_MAX < 0xFFFFFFFF ) {
>                 typedef long INT;
>         } else {
>                 typedef int INT;
>         }

I like this idea, but think that alternative syntax might help
(if only to clearly mark out compiler-time "if"s from run-time
ones).  How about:

    #if (INT_MAX < 0xFFFFFFFF)
        typedef long INT;
    #else
        typedef int INT;
    #endif

That seems fairly neat!

I know that the preprocessor is not ideal and that it is open to
abuse.  I still find uses for it -- uses that can't easily be
replaced by other features (tho' clever use of templates
might help in some cases).

Anti-CPP people often seem like anti-goto people: so set in their
opposition to the "bad" feature that they will tolerate any amount
of bad code to avoid it.  We've all seen those horrible Pascal
loops where to avoid a simple "break" we have "while"s with conditions
that are impossible to figure out.

(And I wonder if the excessively "clever use of templates" is really
an improvement over a simple #define -- especially given the
mess that some current compilers seem to make of templates.)

-- jP --
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

John David Galt <jdg@but-i-dont-like-spam.boxmail.com> writes:

|>  Steve Clamage <stephen.clamage@Eng.Sun.COM> wrote:
|>  >>> Some programming shops, including my former company and some groups
|>  >>> here at Sun, ban the use of conditional compilation entirely, on
|>  >>> the grounds that such code is too hard to maintain, and alternatives
|>  >>> are available which are acceptable and often superior.
|>
|>  > I'm talking about code like this:
|>
|>  > #if defined(__EXTENSIONS__) || ((__STDC__ - 0 == 0 && \
|>  >     !defined(_POSIX_C_SOURCE))) || defined(_XOPEN_SOURCE)
|>  >   #if defined(__EXTENSIONS__) || __STDC__ == 0 || \
|>  >       defined(_XOPEN_SOURCE)
|>  >     ...
|>  >     #if !defined(_XOPEN_SOURCE)
|>  >       ...
|>  >     #endif
|>  >     ...
|>  >   #endif
|>  >   ...
|>  > #endif
|>
|>  > Trying to sort through this to figure out what is going on
|>  > and what code is active is a real challenge.
|>
|>  That's a great rule, for an ideal world; and it works, if your code only
|>  needs to run on one platform.  But the first time you write something that
|>  is supposed to work on Solaris, HP-UX, IBM MVS, OpenVMS, _and_ Windows NT,
|>  you'll find it's impossible without lots of conditionals.

I've not found this to be true.  In fact, the only conditional
compilations I have in my code is in one header file, and this could be
avoided as well, at the cost of some extra lines of code.

The usual solution is to isolate the system dependant stuff behind
firewalls (usually, in C++ at least, a class interface).  The
implementation behind the walls is system dependant, and you have to
maintain a version for each system supported.  But this is done by
separate source files, in a separate directory, and not by conditional
compilation.

|>  Even if we
|>  ignore operating-system differences such as the format of a file path, you
|>  run into things like:
|>
|>  *  Math works differently (not just things that need to be system-specific,
|>     like INT_MAX, sizeof(various types), and the negative-number format, but
|>     things like the values of (-3) % 8 and 0x1234 >> 2, which ought to be
|>     the same everywhere).

Well, the last is:-) (but only because 0x1234 is positive).

Generally, it's quite possible (and IMHO preferrable) to write code
which doesn't depend on these characteristics.  My configuration file
contains a #define HIBYTE1ST, for example, but in well over ten years
since it's been there, I've used it exactly once, and that was only in
an optimization issue (bit hacking an IEEE double in order to get a good
first approximation for Newton-Ralston).

|>  *  Important feature packages (templates, exceptions, <stdarg.h>, and the
|>     STL; not to even mention <pipe.h>, <sysconf.h>, BSD sockets, pthreads,
|>     and X-Windows) not only are not supported on all systems, but there
|>     isn't even a portable #if-test to check whether any one of them is
|>     supported.  You have to put in separate "#ifdef system_name" blocks for
|>     each system to find out.  (Yes, I know, this is an issue for POSIX and
|>     other standards bodies as well.  But the first four items are C++
|>     standard issues, and adding __STDCPP__ would solve those.)

These are the things you hide behind class barriers.  In the past, I've
had programs which read directories, portable to Unix (both version 7
and Berkley) and MS-DOS, without a single conditional compilation.  The
functional interface was the same in both cases, and the implementation
was maintained in completely different source files.

--
James Kanze      home:     kanze@gabi-soft.fr        +33 (0)1 39 55 85 62
                 office:   kanze@vx.cit.alcatel.fr   +33 (0)1 69 63 14 54
GABI Software, Sarl., 22 rue Jacques-Lemercier, F-78000 Versailles France
     -- Conseils en informatique industrielle --
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Julian Pardoe wrote:
> Steve Clamage wrote:
> > I'm talking about code like this:
> >
> > #if defined(__EXTENSIONS__) || ((__STDC__ - 0 == 0 && \
> >     !defined(_POSIX_C_SOURCE))) || defined(_XOPEN_SOURCE)
> >   #if defined(__EXTENSIONS__) || __STDC__ == 0 || \
> >       defined(_XOPEN_SOURCE)
> >     ...
> >     #if !defined(_XOPEN_SOURCE)
> >       ...
> >     #endif
> >     ...
> >   #endif
> >   ...
> > #endif
> >
> > Trying to sort through this to figure out what is going on
> > and what code is active is a real challenge.
>
> Yes, one can write bad code in any language; that doesn't
> mean one has to.
>
> You suggest gathering all one's system dependent stuff into
> special files and having one version per system.  Well, I'm
> not sure that having multiple source files is necessarily better
> that having some #ifdefs, especially if the files are long
> and the number of conditional differences small.

You certainly do NOT want to duplicate entire source files
just to avoid conditional compilation. That does not aid
program maintainability.

> Anti-CPP people often seem like anti-goto people: so set in their
> opposition to the "bad" feature that they will tolerate any amount
> of bad code to avoid it.

I advocate no such thing, and I don't tolerate bad code. Nor
will the other experienced programmers I know who avoid using
macros and conditional compilation.

The fundamental error is sprinking system dependencies throughout
your application code. Instead you should write for an
abstract system and implement the abstract system for each
platform of interest.

The classic example is windowing systems. If you want a system
to be portable among, for example, MS Windows, Macintosh, Motif,
OpenWindows, DECWindows, etc, the worst thing you can do is
insert #if #elif #elif #elif #elif #endif sequences every place
you need to use a window function.

Instead, you could create an abstract Window class that has
the functionality you need, and which can be instantiated
reasonably on all the systems of interest. Maybe it winds up
being the least common denominator, or maybe you put up with
inefficiencies on some systems in order to use more advanced
features everwhere. You then implement concrete derived classes
for each platform of interest. Your application contains
no conditional code.

The proof of this pudding lies in the existence of commercial
libraries that work exactly this way. You program in terms of
the abstract window system, and link in a library implementation
for the window system you are using.

Java may represent this idea carried to its logical conclusion.
It defines a complete virtual machine and display system. Java
compiled byte code can (if you avoid local extensions to Java)
run as-is on any system that implements the JVM. (Ummm, if
we also ignore the changing definition of Java.)
--
Steve Clamage, stephen.clamage@eng.sun.com
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

I don't think it is a recent change. I've been using it for years.
There are cases when the construction (and destruction)
of an object does some serious work and the statement
like the one below do the right thing

if (obj.IsConflict ())
    ConflictResolution resolution (obj);

Actually, I don't normally write code like this, but I used it in a
tutorial.
Bartosz

| Right you are (although this is a fairly recent change in C++).
| My point remains, however. The normal statement emantics of
| C and C++ are not what you want for this case.
|
| --
| Steve Clamage, stephen.clamage@eng.sun.com
| ---
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Steve Clamage <stephen.clamage@eng.sun.com> writes:

> Some programming shops, including my former company and some groups
> here at Sun, ban the use of conditional compilation entirely, on
> the grounds that such code is too hard to maintain, and alternatives
> are available which are acceptable and often superior.

... such as?

i think the GNU autoconf model of feature-based "conditional
compilation" is actually quite maintainable.

meem

--
::  meem@gnu.ai.mit.edu   ::   voice 314/935-1353  ::   pager 800/652-2699  ::
::   pgp fingerprint:   E7 E8 1A 95 F2 06 6A D6   6A 11 44 D6 6A 6B 93 9B   ::
:: GCS v3.12: a-- C+++ UL++++ US++++ UB+++ P++ L+++>++++++ E+>+++ W+ N++ K+ ::
::            w+ O@ M- V- PS+ Y+ PGP++ t+ 5 X R- tv- b DI++ D+ G h+ r- z-   ::
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Steve Clamage <stephen.clamage@eng.sun.com> wrote:

 > Paul D. DeRocco wrote:
 > > Does anyone know if the standards committee ever considered allowing
 > > "if" statements (with constant expressions) at the global level, as an
 > > alternative to conditional compilation using #if or #ifdef? Its main
 > > advantage is that it would allow conditional compilation to be based on
 > > "const" constants and enum values, instead of #define symbols, thus
 > > pulling more stuff out of the realm of the preprocessor into "real" C++.
 > > It also might allow a greater degree of precompilation. Does anyone see
 > > any disadvantages?
 >
 > I don't believe it was ever considered by the C++ Committee.
 >
 > In any case, you wouldn't really have an ordinary "if" statement,
 > since keeping the semantics of normal "if" statements would not
 > give you any capability you don't already have.
 >
 > For example, I suppose you were thinking of something like
 >  if( INT_MAX < 0xFFFFFFFF )
 >   typedef long INT;
 >  else
 >   typedef int INT;
 > Assuming existing semantics of "if", this example puts different
 > definitions of INT in the same scope and is not allowed.
 >
 > You could use braces:
 >  if( INT_MAX < 0xFFFFFFFF ) {
 >   typedef long INT;
 >  } else {
 >   typedef int INT;
 >  }
 > but now INT is not visible in the scope where you want it.
 >
 > In other words, you would have what looks like normal syntax, but
 > it would need completely different semantic rules. I don't
 > remember ever seeing a proposal to invent such a replacement for
 > the preprocessor.

One of us is confused.  As I read the draft these are equivalent --
neither puts the typedefs in the same scope.  From draft 6.4:

 If the substatement in a selection-statement is a single
 statement and not a compound-statement, it is as if it was
 rewritten to be a compound-statement containing the original
 substatement.  [Example:

          if (x)
              int i;

 can be equivalently rewritten as

          if (x) {
              int i;
          }

 Thus after the if statement, i is no longer in scope.  ]


Michael M Rubenstein
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Gerard Weatherby wrote:
>
> Steve Clamage wrote:
> > Some programming shops, including my former company and some groups
> > here at Sun, ban the use of conditional compilation entirely, on
> > the grounds that such code is too hard to maintain, and alternatives
> > are available which are acceptable and often superior.
>
> Could you explain at least briefly the alternatives?  For example,
> what's the alternative to the assert macro?

Using the assert macro does not require you to write any code
that has conditional compilation.

I'm talking about code like this:

#if defined(__EXTENSIONS__) || ((__STDC__ - 0 == 0 && \
    !defined(_POSIX_C_SOURCE))) || defined(_XOPEN_SOURCE)
  #if defined(__EXTENSIONS__) || __STDC__ == 0 || \
      defined(_XOPEN_SOURCE)
    ...
    #if !defined(_XOPEN_SOURCE)
      ...
    #endif
    ...
  #endif
  ...
#endif

Trying to sort through this to figure out what is going on
and what code is active is a real challenge.

--
Steve Clamage, stephen.clamage@eng.sun.com
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Mike Rubenstein wrote:
 >
 > Steve Clamage <stephen.clamage@eng.sun.com> wrote:
 >
 >  > Paul D. DeRocco wrote:
 >  > > Does anyone know if the standards committee ever considered allowing
 >  > > "if" statements (with constant expressions) at the global level, as an
 >  > > alternative to conditional compilation using #if or #ifdef? Its main
 >  > > advantage is that it would allow conditional compilation to be based on
 >  > > "const" constants and enum values, instead of #define symbols, thus
 >  > > pulling more stuff out of the realm of the preprocessor into "real" C++.
 >  > > It also might allow a greater degree of precompilation. Does anyone see
 >  > > any disadvantages?
 >  >
 >  > I don't believe it was ever considered by the C++ Committee.
 >  >
 >  > In any case, you wouldn't really have an ordinary "if" statement,
 >  > since keeping the semantics of normal "if" statements would not
 >  > give you any capability you don't already have.
 >  >
 >  > For example, I suppose you were thinking of something like
 >  >      if( INT_MAX < 0xFFFFFFFF )
 >  >              typedef long INT;
 >  >      else
 >  >              typedef int INT;
 >  > Assuming existing semantics of "if", this example puts different
 >  > definitions of INT in the same scope and is not allowed.
 > ...
 >
 > One of us is confused.  ...  From draft 6.4:
 >
 >         Thus after the if statement, i is no longer in scope.

Right you are (although this is a fairly recent change in C++).
My point remains, however. The normal statement emantics of
C and C++ are not what you want for this case.

--
Steve Clamage, stephen.clamage@eng.sun.com
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Steve Clamage <stephen.clamage@eng.sun.com> writes:

|>  I don't see this suggestion as much of an improvment over using the
|>  preprocessor. Code that uses conditional compilation (or this
|>  suggested equivalent) becomes very hard to read and understand, and
|>  gets worse over time as it accretes new conditionals
|>  This proposed change would make conditional compilation more
|>  widespread, since you could do more with it. (Analagous to
|>  increasing the power of the preprocessor to become a full-blown
|>  macro language.)

I might add that the proposal (allowing normal if outside of a function,
to implement conditional compilation) has the disadvantage of not making
the conditional compilation visible.  I don't like the preprocessor in
general, but given that it obeys significantly different semantics (and
even syntax) than the rest of the language, I like the fact that its use
requires a special character which sticks out like a sore thumb.

|>  Some programming shops, including my former company and some groups
|>  here at Sun, ban the use of conditional compilation entirely, on
|>  the grounds that such code is too hard to maintain, and alternatives
|>  are available which are acceptable and often superior.

Entirely, or just in functions or source files?  (I have two or three
header files which use it extensively, and pretty much ban it outside of
them.)

--
James Kanze      home:     kanze@gabi-soft.fr        +33 (0)1 39 55 85 62
                 office:   kanze@vx.cit.alcatel.fr   +33 (0)1 69 63 14 54
GABI Software, Sarl., 22 rue Jacques-Lemercier, F-78000 Versailles France
     -- Conseils en informatique industrielle --
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Does anyone know if the standards committee ever considered allowing
"if" statements (with constant expressions) at the global level, as an
alternative to conditional compilation using #if or #ifdef? Its main
advantage is that it would allow conditional compilation to be based on
"const" constants and enum values, instead of #define symbols, thus
pulling more stuff out of the realm of the preprocessor into "real" C++.
It also might allow a greater degree of precompilation. Does anyone see
any disadvantages?

--

Ciao,
Paul

(Please send e-mail to mailto:pderocco@ix.netcom.com instead of the
return address, which has been altered to foil junk mail senders.)
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Paul D. DeRocco wrote:
> Does anyone know if the standards committee ever considered allowing
> "if" statements (with constant expressions) at the global level, as an
> alternative to conditional compilation using #if or #ifdef? Its main
> advantage is that it would allow conditional compilation to be based on
> "const" constants and enum values, instead of #define symbols, thus
> pulling more stuff out of the realm of the preprocessor into "real" C++.
> It also might allow a greater degree of precompilation. Does anyone see
> any disadvantages?

I don't believe it was ever considered by the C++ Committee.

In any case, you wouldn't really have an ordinary "if" statement,
since keeping the semantics of normal "if" statements would not
give you any capability you don't already have.

For example, I suppose you were thinking of something like
 if( INT_MAX < 0xFFFFFFFF )
  typedef long INT;
 else
  typedef int INT;
Assuming existing semantics of "if", this example puts different
definitions of INT in the same scope and is not allowed.

You could use braces:
 if( INT_MAX < 0xFFFFFFFF ) {
  typedef long INT;
 } else {
  typedef int INT;
 }
but now INT is not visible in the scope where you want it.

In other words, you would have what looks like normal syntax, but
it would need completely different semantic rules. I don't
remember ever seeing a proposal to invent such a replacement for
the preprocessor.

Now for my personal opinion:

I don't see this suggestion as much of an improvment over using the
preprocessor. Code that uses conditional compilation (or this
suggested equivalent) becomes very hard to read and understand, and
gets worse over time as it accretes new conditionals
This proposed change would make conditional compilation more
widespread, since you could do more with it. (Analagous to
increasing the power of the preprocessor to become a full-blown
macro language.)

Some programming shops, including my former company and some groups
here at Sun, ban the use of conditional compilation entirely, on
the grounds that such code is too hard to maintain, and alternatives
are available which are acceptable and often superior.

--
Steve Clamage, stephen.clamage@eng.sun.com
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Paul D. DeRocco <strip_these_words_pderocco@ix.netcom.com> wrote:
>Does anyone know if the standards committee ever considered allowing
>"if" statements (with constant expressions) at the global level, as an
>alternative to conditional compilation using #if or #ifdef? Its main
>advantage is that it would allow conditional compilation to be based on
>"const" constants and enum values, instead of #define symbols, thus
>pulling more stuff out of the realm of the preprocessor into "real" C++.
>It also might allow a greater degree of precompilation. Does anyone see
>any disadvantages?

Scoping and execution order.  The latter would generate complaints by
people who would abuse this system, so I don't really count that.  But
consider:

#if defined(USE_LARGE_TIME_VALUE)
     typedef unsigned long   time_t;
#else
     typedef unsigned short  time_t;
#endif

The problem with your scheme is that there is an implicit scope
attached to the if, i.e.:

if(useLargeTimeValue) {
     typedef unsigned long   time_t;
} // typedef goes out of scope
else {
     typedef unsigned short  time_t;
} // typedef goes out of scope

I'm undecided on whether implicit promotion of the enclosed scope is a
good idea.
--
David A. Cuthbert (henry.ece.cmu.edu!dacut)
Graduate Student, Electrical and Computer Engineering
Data Storage Systems Center, Carnegie Mellon University
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Steve Clamage wrote:
> Some programming shops, including my former company and some groups
> here at Sun, ban the use of conditional compilation entirely, on
> the grounds that such code is too hard to maintain, and alternatives
> are available which are acceptable and often superior.

Could you explain at least briefly the alternatives?  For example,
what's the alternative to the assert macro?
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

dacut@henry.ece.cmu.edu (David A. Cuthbert) writes:

>Paul D. DeRocco <strip_these_words_pderocco@ix.netcom.com> wrote:
>>Does anyone know if the standards committee ever considered allowing
>>"if" statements (with constant expressions) at the global level, as an
>>alternative to conditional compilation using #if or #ifdef? Its main
>>advantage is that it would allow conditional compilation to be based on
>>"const" constants and enum values, instead of #define symbols, thus
>>pulling more stuff out of the realm of the preprocessor into "real" C++.
>>It also might allow a greater degree of precompilation. Does anyone see
>>any disadvantages?
>
>Scoping [...]
>The problem with your scheme is that there is an implicit scope
>attached to the if, i.e.:

OK, so how about conditional declarations using the conditional-expression
syntax (`... ? ... : ...')?

Instead of

 #define USE_LARGE_TIME_VALUE

 #ifdef USE_LARGE_TIME_VALUE
 typedef unsigned long time_t;
 #else
 typedef unsigned short time_t;
 #endif

you would use

 const bool use_large_time_value = true;

 typedef (use_large_time_value ? unsigned long : unsigned short) time_t;


P.S.  I think I forgot to add a smiley somewhere.
      This suggestion would solve the technical problem with scopes, but I'm
      not really seriously proposing it.  I don't think the benefits would
      be worth the increase in language complexity.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Steve Clamage wrote:
>
> For example, I suppose you were thinking of something like
>         if( INT_MAX < 0xFFFFFFFF )
>                 typedef long INT;
>         else
>                 typedef int INT;
> Assuming existing semantics of "if", this example puts different
> definitions of INT in the same scope and is not allowed.
>
> You could use braces:
>         if( INT_MAX < 0xFFFFFFFF ) {
>                 typedef long INT;
>         } else {
>                 typedef int INT;
>         }
> but now INT is not visible in the scope where you want it.
>
> In other words, you would have what looks like normal syntax, but
> it would need completely different semantic rules. I don't
> remember ever seeing a proposal to invent such a replacement for
> the preprocessor.

That's true. Perhaps a different keyword than "if" should be used
(groan). I'd suggest that a global "if" would really be a different
animal, and the braces in your example wouldn't create a separate scope
(just as extern "C" { ... } doesn't create a scope). It really would
function more like the preprocessor #if, but representable as part of
the parse tree.

> Now for my personal opinion:
>
> I don't see this suggestion as much of an improvment over using the
> preprocessor. Code that uses conditional compilation (or this
> suggested equivalent) becomes very hard to read and understand, and
> gets worse over time as it accretes new conditionals
> This proposed change would make conditional compilation more
> widespread, since you could do more with it. (Analagous to
> increasing the power of the preprocessor to become a full-blown
> macro language.)

As I pointed out, its main benefit would be that it would allow more of
the constants on which conditional compilation is based to be moved from
#defines to regular const definitions. This in turn makes them visible
inside debuggers, which usually throw up their hands and ignore
everything to do with the preprocessor.

> Some programming shops, including my former company and some groups
> here at Sun, ban the use of conditional compilation entirely, on
> the grounds that such code is too hard to maintain, and alternatives
> are available which are acceptable and often superior.

I agree. I use exactly one conditional flag in my code, which
distinguishes between debug and non-debug, and I produce exactly two
versions of everything.

--

Ciao,
Paul

(Please send e-mail to mailto:pderocco@ix.netcom.com instead of the
return address, which has been altered to foil junk mail senders.)
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]