🚀 go-pugleaf

In article 0804961108400001@news.aimnet.com, mike_duigou@fwb.com (Mike Duigou)
writes:
>While reading parts of the April 1995 draft I noticed that the section on
>preprocessing seemed to be pretty much the same as the ANSI C
>preprocessor. Was there a concious descision to make no changes?

Yes. The intent is to make preprocessing behave exactly the same way,
except of course for the predefined macros __STDC__ and __cplusplus.

It is hoped that eventually the preprocessor can be eliminated. The
presence of the preprocessor makes code analysis very difficult for
programs and for humans. Macros are dangerous for numerous reasons.
Conditional compilation in practice turns out to make code less
understandable and less maintainable than other techniques that do not
depend on preprocessing. In principle, an "include" directive could
be added to the language proper, eliminating the need for #include.
Few indeed are the preprocessor functions that cannot be achieved
equally well in the C++ language proper already. (Realistically, we
probably cannot eliminate the preprocessor. But we don't have to
encourage its use.)

>One change I was hoping for was the inclusion
>of a non-fatal "#warning" directive to match the fatal '#error" directive.
>(hey, the compiler can make both errors and warnings, why can't I?). As
>you probably know, a number of compilers support the #warning directive.

We've been through this discussion many times. The #error directive isn't
required to be fatal. All that is required is that it cause a message to
be emitted. It is difficult to specify "fatal" versus "non-fatal" in a
system-independent way. For example, I assume you mean that an #error
directive should prevent the program from being linked or run, since the
failure would occur at compile time. But what about a pure interpreter?
The program could be already executing when the #error directive was
encountered. We don't like to require things in the standard that
make it impossible to have conforming implementations that would be
otherwise useful.

Adding non-standard directives like #warning is not very programmer-
friendly. The #pragma mechanism exists precisely as a hook to add
special behavior without causing compile failures on systems that
don't have the facility. Implementors who want to add a programmer
warning facility would be better advised to make it "#pragma warning".

>Additionally, adding some reccomended pragmas such as ...

There is no end to things that might be nice. "Recommending" something
in the standard has no real meaning. Either that something is required,
in which case you can depend on it being available, or it is not
required, in which case you cannot depend on it being available.

Pragmas, in my view, are best used for things which do not affect
program semantics. "Pragma warning" is an example of such a pragma.
"Pragma once" is an example of a pragma which does affect the meaning
of a program, and can cause compile failures when the code is moved to
a system that doesn't support it. Worse still (IMHO) are pragmas that
change meaning without affecting legality. Your code then inexplicably
behaves differently on different systems.
---
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                             ]