🚀 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                             ]

In article <4klsr0$ii4@engnews1.Eng.Sun.COM> clamage@Eng.Sun.COM
(Steve Clamage) writes:
>In article 0804961108400001@news.aimnet.com, mike_duigou@fwb.com
>(Mike Duigou) writes:
>>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.

So don't specify it.  I've seen the discussion go around a few times,
but I can't say I've ever understood the objection to requiring
#warning in the standard and letting the distinction be
implementation-defined.  The fact that there isn't a useful
distinction in some environments doesn't diminish the usefulness of a
#warning directive in the large number of environments which *do*
support such a distinction.  This wouldn't be the first item in
the standard that could be more usefully implemented in some
environments than in others.

>Adding non-standard directives like #warning is not very programmer-
>friendly.

Right; that's why it should not be non-standard.  As a non-standard
extension it's of fairly limited utility.  As a standard feature, it
would be useful in many environments, and particularly useful when
you're porting code to a new environment -- i.e., when the code you're
porting by definition can't have any compiler-specific #pragmas
available.  Its utility would lie in its portability; all compilers
would accept it, and the worst they'd do would be to behave exactly as
if they'd seen an #error.  Many compilers would do better than that.
The problem is that there is now no portable way to hint to the
compiler that it may as well go on processing after a particular
#error, even though the compiler is permitted to do so.

-David
-- 
============================================================================
David Wald      http://theory.lcs.mit.edu/~wald/     wald@theory.lcs.mit.edu
============================================================================
---
[ 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                             ]

In article <4klsr0$ii4@engnews1.Eng.Sun.COM> clamage@Eng.Sun.COM (Steve
Clamage) writes:

|> 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.

And `//' comments:-).  (Actually, I believe that there is a good chance
that the next revision of the C standard contain these as well.)

I'm not sure that I could write an example that would show the
difference, but wouldn't the fact that things like `and' are predefined
macros in a C, but keywords in C++, make a difference?
-- 
James Kanze           (+33) 88 14 49 00          email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
Conseils en informatique industrielle --
                            -- Beratung in industrieller Datenverarbeitung
---
[ 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                             ]