This is ridiculous!

A

Alf P. Steinbach

* Pete Becker:
The standard does not require "error" messages nor "warnings".

That is literally correct, it requires diagnostics.

It does not require that anything not compile.

That is literally correct, the word "compiler" occured just once in an
early version, then was removed.

The only requirement on
ill-formed programs is that the compiler issue a diagnostic.

And I think that is literally correct, too.

But this feels like talking to a robot.

All your comments are completely irrelevant. Do you not understand what
"error" means? Do you not understand the 135 relevant usages of that
word in the standard? Do you not understand what the OP asked?
 
P

Pete Becker

Bo said:
Even if there is an "error" the translator can issue its diagnostic
(required), see that it was an obvious typo, and then continue with
the translation.

Or do whatever the implementor decides. The requirement for an
ill-formed program is only that the compiler issue a diagnostic. That's
the hook for implementation-specific extensions: the compiler issues a
diagnostic then handles the extension.
 
P

Pete Becker

Alf said:
All your comments are completely irrelevant. Do you not understand what
"error" means? Do you not understand the 135 relevant usages of that
word in the standard? Do you not understand what the OP asked?

To repeat the original question, which may have gotten lost in the noise:
Compiler gives me a warning. I think it should give me a downright error,
and I want it to give me a downright error.

Seems quite clear: he's disappointed that the compiler only gave a
warning message, he wants it to give an error message and decline to
compile the program. There is no such requirement in the language
definition. In particular, "It should not compile" is wrong.
 
A

Alf P. Steinbach

* Pete Becker:
To repeat the original question, which may have gotten lost in the noise:


Seems quite clear: he's disappointed that the compiler only gave a
warning message, he wants it to give an error message and decline to
compile the program. There is no such requirement in the language
definition.

In one sense you're right about that.

Formally, a C++ compiler is free to compile ill-formed Visual Basic
source code, or a letter to mom.

As long as it issues some diagnostic, which could be as subtle as doing
absolutely nothing (the diagnostic in this case being the absence of a
toggling of the NumLock LED indicator on the keyboard, for example).


In particular, "It should not compile" is wrong.

Nope.

You have substituted a context where you interpret the question as to
what the standard literally requires of a compiler, which is nothing,
since the standard does not mention compilers; in particular, it does
not define that they are C++ implementations.

But let's assume that a compiler (plus runtime support, etc.) is a C++
implementation, and not just an implementation, but a conforming one.

Can that compiler accept an ill-formed program text? Yes, formally it
can, and you have stated that yourself. Can it decline to accept a
well-formed program text? Yes, formally it can, it can say, by not
blinking the keyboard's NumLock LED, "Sorry, I ran out of memory", or
whatever (the standard uses language such as "within its resource
limits" to cater for this possibility), and also because when you follow
requirements down into their most basic details, you must always find
them expressed using words that are not themselves defined by the
standard. Does the standard then place any real hard constraints on
this conforming implementation? Nope, none whatsoever.

In the literally formal, the viewpoint you have chosen, there is
therefore no such thing as a C++ implementation, because it could be
anything, and still literally satisfy the standard's rules.

Therefore that is /meaningless/.
 
K

Kaz Kylheku

osmium said:
There must be a word for that. You actually know *less* after reading the
definition than you did before you read it!

You know that an implementation has output messages, and that not all
of them are necessarily considered diagnostics.

The implementation defines which messages are diagnostics, which means
that there has to be an accompanying document that lists them or
indicates how they can be recognized from among other messages.

When the standard requires a situation to be diagnosed, one of these
messages must appear from the implementation.
 
A

Alf P. Steinbach

* Pete Becker:
Alf P. Steinbach wrote:

Sigh. The original question asked, in part,


And you replied to that with:


Where in the standard did you find this?

By now you should have understood what "error" means, as the word is
used in the standard and by the OP.

But I'll explain it once more: it means "ill-formed".

Regarding the standard's rules for cv-qualification and conversions, I
don't think it's true that you're unable to find them. I don't think
your question is truthful, I think it is argumentative. However, for
the sake of discussion I'll /assume/ that your question is truthful,
that you really want a little help here.

A quick search now yielded that a very similar example is given at the
end §8.5.3/5 with the explanation "error: type qualifiers dropped". You
should understand that I did not consult the standard regarding the
original question, and in particular I did not check out this example,
which I now have provided on your direct request. The question was and
is basic, trivial, and it's just coincidental that this example exists.

But in spite of my assumption above, I'm sure that if you respond it
will be along the lines of examples in the standard not being normative,
or some such context-switching and literal-minded irrelevant argument,
at a stroke rendering all 135 examples meaningless to win a discussion.
 
P

Pete Becker

Alf said:
* Pete Becker:



By now you should have understood what "error" means, as the word is
used in the standard and by the OP.

Again: the OP asked whether this should "generate a warning or an error".
But I'll explain it once more: it means "ill-formed".

I see. So your answer to the question whether that should "generate a
warning or an error" is that it should "generate an ill-formed".
Regarding the standard's rules for cv-qualification and conversions, I
don't think it's true that you're unable to find them.

I didn't say anything about the rules for cv-qualification. I asked you
where you found a requirement to issue an error message rather than a
warning, since that's what the question explicitly asked about.
 
A

Alf P. Steinbach

* Pete Becker:
Again: the OP asked whether this should "generate a warning or an error".


I see. So your answer to the question whether that should "generate a
warning or an error" is that it should "generate an ill-formed".

Is that a question?

I didn't say anything about the rules for cv-qualification. I asked you
where you found a requirement to issue an error message rather than a
warning, since that's what the question explicitly asked about.

It might seem, from this posting, that you still haven't understood what
"error" means.

But you snippped the standard's example I gave in response to your
question, which to my mind means you now really do understand what
"error" means as used in the standard and by the OP, and that you are
now just obstinately argumentative.

With "error" meaning "ill-formed", the meaning of "warning" is easy to
deduce, given the definition of "diagnostic": it is the set of other
possible diagnostics. Current compilers label them as warnings. Given
that, you don't need to deduce the meaning: you should already know it.
 
P

Pete Becker

Alf said:
> With "error" meaning "ill-formed", the meaning of "warning" is easy
to > deduce, given the definition of "diagnostic": it is the set of other
> possible diagnostics. Current compilers label them as warnings.

Remarkable. You've turned no normative words in the standard into a
requirement that no compiler conforms to.

Once again, for the benefit of anyone who may still be reading this
well-named thread: the C++ Standard requires "a diagnostic" for an
ill-formed program. That's all.
 
P

Pete Becker

Pete said:
Once again, for the benefit of anyone who may still be reading this
well-named thread: the C++ Standard requires "a diagnostic" for an
ill-formed program. That's all.

Whoops, it requires less than that. It requires "a diagnostic message"
for a program that violates any diagnosable rule. Some of the rule whose
violation makes a program ill-formed are not diagnosable rules.
 
A

Alf P. Steinbach

* Pete Becker:
to > deduce, given the definition of "diagnostic": it is the set of other

Remarkable. You've turned no normative words in the standard into a
requirement that no compiler conforms to.

That's incorrect in several ways.

Including that your statement is at odds with reality: most modern
compilers do issue compilation errors for the OP's construct.

But the most basic error in your statement is the flawed deduction that
a compiler that compiles the OP's source code can be conforming, in any
practical sense.

A compiler that compiles that is not conforming in any practical sense.

Are you still going on about what you can deduce from literal
definitions, ignoring reality and context? As should be clear by now,
that's /nothing/. The C++ standard is not a completely formal document,
nor could it be, and so via the literal interpretation rule you end up
with undefined words (like "diagnostic"), always; moreover, with the
literal interpretation the standard is formally inconsistent in several
places, and nothing (or anything at all, depending on your preferences)
can be deduced from inconsistency, which is a well-known fallacy.

Once again, for the benefit of anyone who may still be reading this
well-named thread: the C++ Standard requires "a diagnostic" for an
ill-formed program. That's all.

Yes. And the C++ standard differentiates between different kinds of
diagnostics. And includes at least one example, shown earlier, where
this particular kind of ill-formedness is labeled an "error".
 
P

Pete Becker

Alf said:
But the most basic error in your statement is the flawed deduction that
a compiler that compiles the OP's source code can be conforming, in any
practical sense.

There's no deduction involved. The standard requires the implementation
to issue a diagnostic. It did.
 
J

Jerry Coffin

[ ... ]
By now you should have understood what "error" means, as the word is
used in the standard and by the OP.

But I'll explain it once more: it means "ill-formed".

Sorry Alf, but here you're just plain wrong.

The standard (at least generally) uses phrasing like "it
is an error if ..." to mean something like "code is ill
formed if ...", that much is true.

The OP, in strong contrast, was clearly using "error" to
mean an error message. Specifically, that the code in
question would NOT be successfully translated.

The standard does not require any such thing under any
circumstances.

The standard requires the implementation to issue a
diagnostic message if any diagnosable rule is violated.
The standard defines the diagnosable rules, and requires
the implementation to define what it considers a
diagnostic.

The marketplace, not the standard, decides anything
beyond that. In particular, most compilers (including the
OP's, apparently) issue a warning for his code. Most
compilers also allow you to elevate warnings to be
treated as error messages (i.e. that code that produces
that message will not be successfully translated). Some
do so only on a blanket basis (i.e. all warnings are
treated as errors) while others allow more selectivity in
doing so -- i.e. you have greater granularity in choosing
which warnings will be treated as errors.

The details of that, however, are clearly specific to the
compiler and off-topic here though, because they have to
do with how you run the compiler, not with the language.
 
A

Alf P. Steinbach

* Jerry Coffin:
[ ... ]
By now you should have understood what "error" means, as the word is
used in the standard and by the OP.

But I'll explain it once more: it means "ill-formed".

Sorry Alf, but here you're just plain wrong.

The standard (at least generally) uses phrasing like "it
is an error if ..." to mean something like "code is ill
formed if ...", that much is true.

The OP, in strong contrast, was clearly using "error" to
mean an error message. Specifically, that the code in
question would NOT be successfully translated.

The standard does not require any such thing under any
circumstances.

The standard requires the implementation to issue a
diagnostic message if any diagnosable rule is violated.
The standard defines the diagnosable rules, and requires
the implementation to define what it considers a
diagnostic.

The marketplace, not the standard, decides anything
beyond that. In particular, most compilers (including the
OP's, apparently) issue a warning for his code. Most
compilers also allow you to elevate warnings to be
treated as error messages (i.e. that code that produces
that message will not be successfully translated). Some
do so only on a blanket basis (i.e. all warnings are
treated as errors) while others allow more selectivity in
doing so -- i.e. you have greater granularity in choosing
which warnings will be treated as errors.

The details of that, however, are clearly specific to the
compiler and off-topic here though, because they have to
do with how you run the compiler, not with the language.

Apart from the phrasing "most compilers" (I really don't think that's
correct) the above sounds eminently reasonable.

It makes it seem as if it's just a matter of degree, outside the scope
of the standard; warning, error, one can be treated as the other,
they're all just diagnostics.

Until you consider the following seemingly conforming C++
implementation, which you can implement in a few minutes time using a
script language. It is a C++ implementation, let's call it OhLaLa
because it is 100% conforming, perfect!, that takes a C++ source file,
or fileset (translation unit that comprises a program), and executes it,
all according to the C++ standard's rules. It's done as follows:

1) If the source code compiles with no errors (output suppressed)
using a compiler B that compiles and only compiles well-formed
source code without errors, delete all result files and issue a
diagnostic "error: out of memory, sorry". This per the "available
resources" clause in §1.4/2 of the standard.

2) Otherwise, if B fails to compile the source code, issue a
diagnostic "warning: extension used", and run a program that spams
all heads of state in Europe (it will always be the same program)
and calls the OS' process exit function; which program, let's call
it S, constitutes the effect of the provided C++ source code. The
language extension is simply that any compilation failure using B
means that the effect of S should be prepended to the effect of the
code minimally adjusted, in some sense, so that it would compile
using B. This is per §1.4/8, which allows extensions that do not
alter the behavior of well-formed programs.

Effectively the OhLaLa C++ implementation is, as I see it, a 100%
conforming C++ implementation when all that's required is what a literal
reading of the standard imposes on a conforming implementation.

However, _I_ wouldn't call OhLaLa a conforming implementation. I would
not even call it a C++ implementation, since the C++ source code does
not influence any effect of submitting the source code to OhLaLa, other
than turning off the single pre-defined effect (and we could, if not for
dramatic impact, turn off that effect so that the C++ source code would
influence absolutely nothing). So as I see it there's something missing
from the literal interpretation picture, and it even begins to seem a
teeny tiny bit unreasonable, don't you think?
 
J

Jerry Coffin

[ ... ]
Apart from the phrasing "most compilers" (I really don't think that's
correct) the above sounds eminently reasonable.

Would you settle for "many compilers" instead? I haven't
tried to do a survey (especially in the embedded space
and such) so maybe I'm just deceived by the compilers I
happen to use, and falsely assume most of the others have
similar capabilities.

[ ... ]
Effectively the OhLaLa C++ implementation is, as I see it, a 100%
conforming C++ implementation when all that's required is what a literal
reading of the standard imposes on a conforming implementation.

In terms purely of conforming with the standard, I think
that's probably correct.
However, _I_ wouldn't call OhLaLa a conforming implementation. I would
not even call it a C++ implementation, since the C++ source code does
not influence any effect of submitting the source code to OhLaLa, other
than turning off the single pre-defined effect (and we could, if not for
dramatic impact, turn off that effect so that the C++ source code would
influence absolutely nothing). So as I see it there's something missing
from the literal interpretation picture, and it even begins to seem a
teeny tiny bit unreasonable, don't you think?

Actually, I think you could leave out most (all?) of
section 2 of your description of OhLaLa and still have a
conforming implementation of C++.

You seem to want the standard to require enough that a
conforming implementation at least stands some chance of
being useful. At one time I'd have agreed vehemently. I
can still sympathize, but can't really agree anymore. The
reason is simple: such rules would take considerable time
and effort to make, but I seriously doubt they'd make any
real difference. Right now Comeau is the only C++
compiler that makes a serious attempt at full conformance
(though rumor has it that Intel unofficially supports
export as well) At the same time, most compilers go well
beyond the requirements of the standard in terms of
attempting to provide useful warnings, error messages,
etc.

Given that I think it would take a lot of time and effort
and provide no real benefit, I think I'd rather see time
spent on endeavors I think would be more fruitful.

I don't believe, however, that just because the standard
makes no meaningful requirements in a given area that we
can treat it as requiring things that just aren't there.

If you're really convinced that the standard _should_
have stronger requirements in this area, the obvious
thing to do would be to write up a proposal, and submit
it to the committee. It wouldn't be a new language
feature, so I believe the committee would still accept it
as a proposal for the next version of the standard. I
really think it's a waste of time though -- there are
enough good compilers being given away freely today that
I really don't think stopping a useless one from being
able to claim it's conforming would really accomplish
much.
 
A

Alf P. Steinbach

* Jerry Coffin:
[ ... ]
Apart from the phrasing "most compilers" (I really don't think that's
correct) the above sounds eminently reasonable.

Would you settle for "many compilers" instead? I haven't
tried to do a survey (especially in the embedded space
and such) so maybe I'm just deceived by the compilers I
happen to use, and falsely assume most of the others have
similar capabilities.

[ ... ]
Effectively the OhLaLa C++ implementation is, as I see it, a 100%
conforming C++ implementation when all that's required is what a literal
reading of the standard imposes on a conforming implementation.

In terms purely of conforming with the standard, I think
that's probably correct.
However, _I_ wouldn't call OhLaLa a conforming implementation. I would
not even call it a C++ implementation, since the C++ source code does
not influence any effect of submitting the source code to OhLaLa, other
than turning off the single pre-defined effect (and we could, if not for
dramatic impact, turn off that effect so that the C++ source code would
influence absolutely nothing). So as I see it there's something missing
from the literal interpretation picture, and it even begins to seem a
teeny tiny bit unreasonable, don't you think?

Actually, I think you could leave out most (all?) of
section 2 of your description of OhLaLa and still have a
conforming implementation of C++.

You seem to want the standard to require enough that a
conforming implementation at least stands some chance of
being useful.

Well, it's much stronger than that: wherever the standard does not
explictly require anything at all (and I mean a non-requirement, the
non-requirement of /anything/, as with the 100% conforming OhLaLa "C++
implementation" which isn't a C++ implementation at all), there is IMO
an implicit requirement. OhLaLa, while being literally formally
correct, would not pass any C++ conformance test, I think. That's
because such tests reflect the implicit requirement of usefullness,
which out of any context might seem wooly, but which constrains things.


[snip]
I don't believe, however, that just because the standard
makes no meaningful requirements in a given area that we
can treat it as requiring things that just aren't there.

Here's what I think is in the standard regarding the OP's question.
First, that as standard C++ this ill-formed code. Second, that it's
ill-formed code that requires a diagnostic. And third, implicitly, that
that diagnostic should make it clear that the code is ill-formed as
standard C++, which AFAIK is the case for all diagnostics that the
standard requires, there being no requirement (AFAIK) of diagnostics for
well-formed code.

The third, implicit requirement is, as I see it, the only way to make
sense of the standard's definition of "diagnostic", which just makes the
diagnostics a subset of the implementation's "output messages".

Current compilers and compilers back to the 1950s or thereabouts make it
clear that an output message refers to ill-formed code by labeling the
message as an "error", and/or by including phrases such as "language
extension", and make clear that messages that don't refer to ill-formed
code are such by labeling them as "warnings" (w/o "language extension").

The effective requirement on such a compiler is then to produce an
"error" message, unless a language extension is involved, in which case
the message might include the phrase "language extension" or the like.

If you're really convinced that the standard _should_
have stronger requirements in this area, the obvious
thing to do would be to write up a proposal, and submit
it to the committee.

No, as I see it the requirement is already there. What's not there is
how a compiler should distinguish output messages that refer to
ill-formed code, i.e. standards violations for pure C++. I don't think
that how-to belongs in the standard, but for a compiler that has
mutually exclusive and exhaustive subsets X and Y of output messages, Y
being the subset distinguished as denoting ill-formed program text, the
requirement in the OP's case is as I see that the compiler issues a Y
message; which with a conventional warning/error-compiler such as the
OP's compiler means an error message (subject to the little caveat about
language extensions I mentioned above -- with such a big sub-thread
evolving I don't save any keystrokes by omitting it!).

Cheers,

- Alf
 
A

Alf P. Steinbach

* Alf P. Steinbach:
Current compilers and compilers back to the 1950s or thereabouts

Before some nit-picker steps in here: I'm not referring to only C++
compilers, but to compilers back to early Fortran and Cobol.
 
P

Pete Becker

Jerry said:
The standard (at least generally) uses phrasing like "it
is an error if ..." to mean something like "code is ill
formed if ...", that much is true.

And, specifically, the standard never uses the word "error" in running
text to refer to a violation of a syntactic rule or semantic constraint.
What it does do is follow Stroustrup's pattern of giving code examples
with comments:

some_constuct; // error: explanation
some_other_constuct; // OK: explanation
 
J

Jerry Coffin

[ ... ]
Current compilers and compilers back to the 1950s or thereabouts make it
clear that an output message refers to ill-formed code by labeling the
message as an "error", and/or by including phrases such as "language
extension", and make clear that messages that don't refer to ill-formed
code are such by labeling them as "warnings" (w/o "language extension").

Fifteen years ago, national standards bodies (e.g ANSI
and BSI) had programs to validate and certify compilers
as conforming implementations of C.

As I recall, when I looked up the conditions for a couple
of validated compilers, they specified that most of the
official "diagnostics" were error messages, but at least
a couple were warning messages.

TTBOMK, there's never been an officially sanctioned
validation program in place for C++, but if there was,
I'd rather expect the same to be true for many C++
compilers as well.
The effective requirement on such a compiler is then to produce an
"error" message, unless a language extension is involved, in which case
the message might include the phrase "language extension" or the like.

While it might make good sense for such a thing to be
required, the simple fact is that it isn't -- and never
has been, and frankly I doubt it ever will be. If we ever
return to a situation where compiler validation is a hot
issue again (which wouldn't surprise me at some point) I
suspect that a message that say "warning" will still be
accepted as a diagnostic -- as long as it's thoroughly
documented.

[ ... ]
No, as I see it the requirement is already there.

From a marketing viewpoint, I agree -- most countries
have laws about "implied fitness for merchantability" or
something on that order.

From a standards viewpoint, I think you're dead wrong.
The C and C++ standards both do their best to state as
clearly as possible that there are no requirements above
or beyond those that are _explicitly_ stated in the
standard.
What's not there is
how a compiler should distinguish output messages that refer to
ill-formed code, i.e. standards violations for pure C++.

It requires documentation of what constitutes a
diagnostic. Admittedly, it doesn't attempt to define the
form of that documentation, but that would strike me as a
particularly poor idea.
I don't think
that how-to belongs in the standard, but for a compiler that has
mutually exclusive and exhaustive subsets X and Y of output messages, Y
being the subset distinguished as denoting ill-formed program text, the
requirement in the OP's case is as I see that the compiler issues a Y
message; which with a conventional warning/error-compiler such as the
OP's compiler means an error message (subject to the little caveat about
language extensions I mentioned above -- with such a big sub-thread
evolving I don't save any keystrokes by omitting it!).

The standard requires that it be documented. I suppose if
an implementation wanted to document it as being
distinguished by "error" vs. "warning" in the text of the
message, it could do so. Most compilers I've seen that
attempt to conform with this requirement have explicitly
listed the messages that were officially deemed to be
diagnostics. At least IIRC, the difference between
diagnostics and otherwise did not cleanly separate into
errors vs. warnings, at least in the cases I looked at.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top