This is ridiculous!

[Dave]

God damn typo. Should've written:

Actuall compiles *without* error!


-Tomás

Interesting discussion anyHow!.
I tried the program on gcc version 4.0.2 20050901 (prerelease) (SUSE
Linux).
and it did not compile.
error: invalid initialization of reference of type 'std::string&'
from expression of type 'const std::string

 

[Old Wolf]

* Pete Becker:

It really does.

The 1998 C++ standard contains 135 instances of "error" being used as a
synonym for "ill-formed".

Is English your first language? You're confusing two different
meanings of the word "error". The meanings are:
1. Ill-formed code
2. A diagnostic that indicates the compiler found ill-formed code.

The OP was asking about error[2].

If this isn't clear; consider what would happen if the OP were
actually asking about error[1]. His sentence would become:

Firstly, does the Standard say whether this should
generate a warning or ill-formed code?

which is nonsensical. It's very clear to me (and to most English
speakers I would imagine) that the OP is asking about error[2],
ie. whether this code should generate a diagnostic indicative of
ill-formed code.

The Standard talks about error[1], as you point out,
but it does not talk about error[2] at all.

Pete Becker's entirely correct answer is that the C++ standard
requires the implementation to generate a diagnostic, but
this diagnostic is not required to bear any resemblance to
the ill-formed code.

The implementation is also permitted to generate an executable
which will exhibit undefined behaviour at runtime (which may
manifest itself as the const object appearing to change).

In another post you tried this counter-argument:
1. If the C++ standard actually means that, then [insert
ridiculous implementation] is valid.
2. Therefore, the standard does not mean what it says.

I'm sure you can see the problems in this line of
reasoning...

 

[Alf P. Steinbach]

* Old Wolf:

* Pete Becker:
It really does.

The 1998 C++ standard contains 135 instances of "error" being used as a
synonym for "ill-formed".

Is English your first language? You're confusing two different
meanings of the word "error". The meanings are:
1. Ill-formed code
2. A diagnostic that indicates the compiler found ill-formed code.

The OP was asking about error[2].

If this isn't clear; consider what would happen if the OP were
actually asking about error[1]. His sentence would become:

Firstly, does the Standard say whether this should
generate a warning or ill-formed code?

which is nonsensical. It's very clear to me (and to most English
speakers I would imagine) that the OP is asking about error[2],
ie. whether this code should generate a diagnostic indicative of
ill-formed code.

Natural language doesn't work like mathematical substitution. The base
meaning of "error" as as ill-formed code is the same in [1] and [2].
You might ponder why the pharse "ill-formed code" occurs in both your
points [1] and [2] if there is no connection...

The Standard talks about error[1], as you point out,
but it does not talk about error[2] at all.

It does. What it doesn't do is to say what form the error message
should have, e.g. whether it should include the word "error", or show
the face of Osama bin Laden on the screen, or implicitly refer to some
documentation that lists message numbers of messages diagnosing
violations of the standard's diagnosable rules, or what. The OP's
compiler evidently identifies error messages by including the word
"error" (although this is Usenet, and the information provided less than
complete, so there could be other possibilities, or special cases).


[snip]

In another post you tried this counter-argument:
1. If the C++ standard actually means that, then [insert
ridiculous implementation] is valid.
2. Therefore, the standard does not mean what it says.

I'm sure you can see the problems in this line of
reasoning...

Yes, your premise in 1 is incorrect, and even it were correct, the
conclusion in point 2 would be incorrect.

What I wrote was, paraphrased, that if only a literal reading of the
standard is adopted, then it allows a non-implemention of C++ to
formally be a 100% conforming implementation. It was not ridicolous, it
was simply not a C++ implementation in any respect. Furthermore, I
noted elsewhere that if only a literal reading of the standard is
adopted, then it's inconsistent in several places.

The two remaining unresolved points in this thread are (1) whether the
standard explicitly requires diagnostics of rule violations to be
identified as such, or only requires that implicitly (detrimental to my
argument, I have maintained that that is only an implicit requirement,
following from the kind of consideration you tried to mock above,
whereas others who have the opposing point of view on the error issue,
paradoxically maintain that it's an explicit requirement), and (2)
whether compilers actually _do_ identify such diagnostics, e.g. via use
of the words "error" versus "warning", and here I think they do and have
always done, albeit with the usual imperfectness of compilers, whereas
others maintain that they generally don't, which I find unconvincing.

Cheers,

- Alf

 

[Old Wolf]

You're confusing two different
meanings of the word "error". The meanings are:
1. Ill-formed code
2. A diagnostic that indicates the compiler found ill-formed code.

The OP was asking about error[2].

Natural language doesn't work like mathematical substitution.
The base meaning of "error" as as ill-formed code is the same
in [1] and [2].

No, it isn't. [1] is referring to code, and [2] is referring to an
indication. These are separate entities.

You might ponder why the pharse "ill-formed code" occurs in
both your points [1] and [2] if there is no connection...

There is a connection, but the meanings are not identical!

The message was generated in response to the piece of code,
but they are still two distinct items (really!)

The Standard talks about error[1], as you point out,
but it does not talk about error[2] at all.

It does. What it doesn't do is to say what form the error message
should have, e.g. whether it should include the word "error", or show
the face of Osama bin Laden on the screen

Right, what I should have said was: it does not make any
distinction between error indications, and other indications;
and in particular there is no discussion of differences between
an "error message" and a "warning message".

Whether a compiler labels a message as "error" or "warning"
is up to that compiler, and it does not render the implementation
non-conforming if a required diagnostic is labelled "warning".

 

[Alf P. Steinbach]

* Old Wolf:

You're confusing two different
meanings of the word "error". The meanings are:
1. Ill-formed code
2. A diagnostic that indicates the compiler found ill-formed code.

The OP was asking about error[2].

Natural language doesn't work like mathematical substitution.
The base meaning of "error" as as ill-formed code is the same
in [1] and [2].

No, it isn't. [1] is referring to code, and [2] is referring to an
indication. These are separate entities.

The base meaning is the same: ill-formed code. That's why you found it
necessary to include the phrase "ill-formed code" in both points. In
point [2] you're /using/ that meaning to talk about a diagnostic.


[snip]

Right, what I should have said was: it does not make any
distinction between error indications, and other indications;

Well, Jerry Coffin wrote, in response to "What's not [in the standard]
is how a compiler should distinguish output messages that refer to
ill-formed code, i.e. standards violations for pure C++", that

"The standard requires that it be documented."

Let's call this Requirement X.

I happen to not share Jerry's viewpoint, so as you can see there is no
universal agreement on this. You're on one end of the scale,
maintaining there is no requirement X; I'm in the middle somewhere,
maintaining there is an implicit requirement X; and Jerry is at the
other end, maintaining that there is an explicit requirement X.

and in particular there is no discussion of differences between
an "error message" and a "warning message".

That's generally not within the standard's domain.

So it's generally quite irrelevant.

There is however one exceptional case where I think it would be
appropriate if the standard made a distinction about what kind of
diagnostic should be issued, at a sufficient high level of abstraction
(i.e. not dictating the form of message class identification), namely
where you have a language extension. Alas, the standard only
distinguishes this diagnostic by noting that after issuing it, an
implementation can go on to translate (heh, here the standard actually
uses the word "compile", I didn't notice that!) and execute the program.
One implication is that in other error cases the implementation can't
or shouldn't execute the program, but that's nowhere stated outright; it
just makes the clarification meaningless if that was not the intent.

Whether a compiler labels a message as "error" or "warning"
is up to that compiler, and it does not render the implementation
non-conforming if a required diagnostic is labelled "warning".

That's right, but, so what?

There are several cases where that can happen. One is that the compiler
does not employ the "warning" versus "error" distinction, but some other
way of identifying standard violations. Another is that the compiler
implements a language extension, in which case a "warning" is IMO most
appropriate, since the code is not in error with respect to the extended
language (the standard still requires that use of the language extension
be diagnosed, and a quality compiler will offer a standards mode where
use of such extensions are diagnosed as plain errors). A third is that
the compiler is simply non-conforming, in that it doesn't identify
standard rule violations as such, in which case it cannot be rendered
non-conforming: it already is (assuming there is a requirement X).

 

[Jerry Coffin]

[ ... ]

Well, Jerry Coffin wrote, in response to "What's not [in the standard]
is how a compiler should distinguish output messages that refer to
ill-formed code, i.e. standards violations for pure C++", that

"The standard requires that it be documented."

Let's call this Requirement X.

I happen to not share Jerry's viewpoint, so as you can see there is no
universal agreement on this. You're on one end of the scale,
maintaining there is no requirement X; I'm in the middle somewhere,
maintaining there is an implicit requirement X; and Jerry is at the
other end, maintaining that there is an explicit requirement X.

Section 1.3.2 defines "diagnostic message" as: "an
implementation-defined subset of the implementation's
output messages."

Section 1.3.5 defines implementation defined behavior
saying that it's something that "...each implementation
shall document."

Section 1.4/2 says: "If a program contains a violation of
any diagnosable rule, a conforming implementation shall
issue at least one diagnostic message."

The only room for argument I see there is that 1.3.2 uses
only "implementation defined" rather than "implementation
defined behavior". While I generally favor reading the
standard pretty literally, I think in this case the
intent is obvious: an implementation is required to
document which messages are officially "diagnostics" and
which aren't.

That's generally not within the standard's domain.

So it's generally quite irrelevant.

Yes and no -- the standard (by my reading) requires that
the messages that are diagnostics be documented. How
that's documented is more or less irrelevant, but the
fact that it has to be documented in some way seems
pretty clear, at least to me.

 

[chenchen]

visual studio has a option which put all the warns to errors

 

[Old Wolf]

Yes and no -- the standard (by my reading) requires that
the messages that are diagnostics be documented. How
that's documented is more or less irrelevant, but the
fact that it has to be documented in some way seems
pretty clear, at least to me.

Agree with that. But it would be tedious for the user to look
up the documentation for every message to find out if it is
a required diagnostic or not; IMHO the standard ought to
say that the diagnostic itself contain a clue as to whether
it is one that's required by the standard, or whether it is
something specific to that implementation. (eg. [E] for
required diagnostics and [W] for others).

A slightly pedantic point: the pages you quote don't
guarantee that a user can distinguish between required
diagnostics and other ones, because other ones could
use exactly the same message text as a required
diagnostic (eg. consider a compiler that beeps once for
each diagnostic).

 

[Kaz Kylheku]

Yes and no -- the standard (by my reading) requires that
the messages that are diagnostics be documented. How
that's documented is more or less irrelevant, but the
fact that it has to be documented in some way seems
pretty clear, at least to me.

Agree with that. But it would be tedious for the user to look
up the documentation for every message to find out if it is
a required diagnostic or not; IMHO the standard ought to
say that the diagnostic itself contain a clue as to whether
it is one that's required by the standard, or whether it is
something specific to that implementation. (eg. [E] for
required diagnostics and [W] for others).

Such requirements would trample into the area of implementation design.


The users and implementors should decide whether they need such a
feature.

As a user, you should know the language well enough to know what is a
required diagnostic and what is not.

As an implementor, by distinguishing required diagnostics from the
superfluous ones, you are only helping the user write code that will be
portable to competitive compilers.

You are also being forced to separate the messages into two obvious
classes, which gives users a kind of license to ignore any of the
lesser ones that are not marked [E]. Implementors should be allowed to
decide what diagnostics are important.

Then there is the problem that there are errors which do not require
diagnostics. If the impelmentation finds undefined behavior, a
legitimate response is to stop translating the program. A [W]
diagnostic would not be appropriate for that situation.

The classification would have to be three-valued, something like [D]
[E] [W]: diagnosable syntax, constraint or semantic rule violation;
other kind of error such as undefined behavior, and stylistic warning.

This still sucks because some undefined behaviors are hard to analyze
for accurately. The analysis becomes a lot easier and cheaper if the
result does not have to be conclusive, but only come up with a
suspicion that something is wrong.

A suspected undefined behavior can't be classified as an error, whereby
translation of the program terminates. It's a warning: under some
conditions, perhaps undefined behavior can occur here. If you have some
run-time undefined behavior in an expression, it's not an error unless
you can prove that the final, linked executable program will actually
execute that expression, regardless of what inputs it is given. If a
division expression, x / y, occurs in the program, then a division
by zero can occur there only if execution reaches it, and the value of
y is zero. There may be some reason to suspect that it will happen,
without adequate proof that it does happen.

 

[Old Wolf]

IMHO the standard ought to
say that the diagnostic itself contain a clue as to whether
it is one that's required by the standard, or whether it is
something specific to that implementation. (eg. [E] for
required diagnostics and [W] for others).

The users and implementors should decide whether they need such a
feature.

Well, most implementers only implement things that lead to their
financial gain. Nobody is going to buy a compiler because it has
nice error messages and I'm sure they have better things (eg.
C99 compliance) to work on.

As a user, you should know the language well enough to know what is a
required diagnostic and what is not.

90% of people don't, as evinced by this newsgroup!
IMHO the compiler should have well-designed interaction with
its user -- novice users and experienced users alike.

As an implementor, by distinguishing required diagnostics from the
superfluous ones, you are only helping the user write code that will be
portable to competitive compilers.

That's drawing a long bow!

You are also being forced to separate the messages into two obvious
classes, which gives users a kind of license to ignore any of the
lesser ones that are not marked [E]. Implementors should be allowed to
decide what diagnostics are important.

As long as there is a switch for standard-compliant mode (be it
the default or not), I'd be happy.

Then there is the problem that there are errors which do not require
diagnostics. If the impelmentation finds undefined behavior, a
legitimate response is to stop translating the program. A [W]
diagnostic would not be appropriate for that situation.

Why not? Often the standard lists things as UB, but the compiler
finds it can do what the user intended. I think it's ideal that in case
the compiler translates the program and issues a warning that
the code might not work on other compilers.

This still sucks because some undefined behaviors are hard to analyze
for accurately. The analysis becomes a lot easier and cheaper if the
result does not have to be conclusive, but only come up with a
suspicion that something is wrong.

You don't have to diagnose UB. Of course it'd be helpful if
compilers did diagnose a bit more of it; eg. GCC 4 does
report when you violate the sequence point rules.