This is ridiculous!

[Tomás]

#include <string>
#include <iostream>
using std::cout;
using std::endl;

void FunctionThatMod ifies(std::stri ng &a)
{
a = "You've been modified.";
}
int main()
{
std::string const a("Untouchable. ");
std::string &b = a; //Actually compiles with error!
FunctionThatMod ifies(b);
std::cout << b;
}
Compiler gives me a warning. I think it should give me a downright error,
and I want it to give me a downright error.

Firstly, does the Standard say whether this should generate a warning or
an error?

Secondly, do compilers have an option whereby you can make it give an
error? If so, I'll be using it.
-Tomás

[Old Wolf]

Kaz Kylheku wrote:

Old Wolf wrote:

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.