In article 270631188wnr@pires.co.uk, 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."

I suspect you have in mind that somehow #error would halt compilation
and #warning would not, but we don't get to talk about those things in
the standard. There needn't be a separate compilation stage, for example,
and an implementation is not required to differentiate between "compile
time" and "run time". Consider a pure interpreter that seems to execute
source code directly, or a "just-in-time" system that compiles a module
or part of a module on the fly the first time it is referenced.

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.
---
Steve Clamage, stephen.clamage@eng.sun.com
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy is
  in http://reality.sgi.com/employees/austern_mti/std-c++/policy.html. ]

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?)

Martin Bonner
Pi Technology, Milton Hall, Cambridge, ENGLAND
+44 1223 441256
mbonner@pires.co.uk
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy is
  in http://reality.sgi.com/employees/austern_mti/std-c++/policy.html. ]

>>>>> "SC" == Steve Clamage <clamage@Eng.Sun.COM> writes:

 SC> you forgot to say how it differs from #error

 SC> I suspect you have in mind that somehow #error would halt compilation
 SC> and #warning would not, but we don't get to talk about those things in
 SC> the standard.

Then the difference would be implementation defined.
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  Moderation policy:
  http://reality.sgi.com/employees/austern_mti/std-c++/policy.html. ]

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
]

Steve Clamage (clamage@Eng.sun.com) wrote:
|                                                            Other languages
| may define a particular environment where you can talk about compilation,
| or linking, or known formats of data types, etc,

Such as :

[intro.memory]  "A byte ... is composed of a contiguous sequence of bits,
... The least significant bit is called the low-order bit ..."

[lex]  "Translation units can be separately translated and then later
linked to produce an executable program."

[lex.phases]  "Library components are linked ..."

[lib.iterator.tags]  "... so that the function can select the most
efficient algorithm at compile time.  To facilitate this, the library
introduces category tag classes which are used as compile time tags ..."

[lib.valarray.access]  "This property indicates an absence of aliasing and
may be used to advantage by optimising compilers(4)."

[lib.container.requirements] (Table 2) "compile time"  "compile time"
"compile time"  "compile time"  "compile time"  "compile time" ...

|                                                   but we have chosen not
| to do so with C++.

I think not.
---
[ 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
]