🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.std.c++
Article #3370

Re: #warning

#3370
From: Fergus Henderson
Date: Tue, 20 Feb 1996 18:49
63 lines
3412 bytes
clamage@Eng.Sun.COM (Steve Clamage) writes:

>Martin Bonner <mbonner@pires.co.uk> writes:
>>Following up from the discussion of "#if XXXX", is there
>>any chance of getting "#warning" into the standard? Or is it
>>too late
>>
>>It would be useful.  
>>It would be easy to implement.  
>>It would achieve something that cannot be achieved in any other way.  
>>
>>(Have I forgotten anything?)
>
>Yes, you forgot to say how it differs from #error, which is already in the
>draft (and in Standard C). The description of #error says only that it
>"causes the implementation to produce a diagnostic message that includes
>the specified sequence of preprocessing tokens."

Isn't this a bug in the standard?  Doesn't this mean that

	#error foobar
	int main() { return 0; }

is a strictly conforming program?  Yet no compiler I know of will accept it!

Surely the semantics specified for #error should say that it has the effect
of making the translation unit ill-formed.

The semantics for #warning should be what is currently specified for #error.

>The standard describes valid source-language constructs and the effect they
>have in an executing program. Details of compiler behavior cannot reasonably
>be discussed without placing undesirable constraints on implementations.

I disagree.  I think it would be quite possible to specify appropriate
semantics for #error and #warning without placing any undesirable constraints
on implementations.

As far as I can see, the only problem with #warning is not lack of
usefulness or difficulty of implementation, it is difficulty of
specifying appropriate semantics for it.  This difficulty is in part
caused by the existing structure of C++ draft standard.  If the C++
standard were structured like say the Ada standard, then it would be
very easy to state such things in "Implementation Advice" sections.

Another part of the problem is that although every compiler I know of
has a distinction between warnings and errors, the draft C++ standard
has no such distinction.

Nevertheless, I think these difficulties to not present any significant
obstacles to #warning.  It would be easy to fix the semantics for
#error and specify the semantics for #warning as I described above.

--
Fergus Henderson             	WWW: http://www.cs.mu.oz.au/~fjh
fjh@cs.mu.oz.au              	PGP: finger fjh@128.250.37.3
---
[ To submit articles: Try just posting with your newsreader.  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 
]
Technical Details
Message-ID: <4g91rh$kgn@mulga.cs.mu.OZ.AU>
Path: arc1-ca.pugleaf.net!chronicle.mti.sgi.com!austern
References: <270631188wnr@pires.co.uk> <4ftd0p$c5s@engnews1.Eng.Sun.COM>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!chronicle.mti.sgi.com!austern
From: fjh@munta.cs.mu.OZ.AU (Fergus Henderson)
Newsgroups: comp.std.c++
Subject: Re: #warning
Date: 20 Feb 1996 10:49:21 PST
Organization: Comp Sci, University of Melbourne
Approved: austern@isolde.mti.sgi.com
Message-ID: <4g91rh$kgn@mulga.cs.mu.OZ.AU>
References: <270631188wnr@pires.co.uk> <4ftd0p$c5s@engnews1.Eng.Sun.COM>
NNTP-Posting-Host: isolde.mti.sgi.com
X-Original-Date: 19 Feb 1996 05:29:21 GMT
X-Auth: PGPMoose V1.1 PGP comp.std.c++
 iQBVAwUBMSoXwky4NqrwXLNJAQE+cAH/XEofI8x1JBX6h0t4iPnkus15HWH2qDST
 Tj5jlK7/Cl1B4cBI8qIickFYZXCeM7sde2EiegLn27xWCzhZk78+Qw==
 =XkTc
Originator: austern@isolde.mti.sgi.com