Thanks Kai. I do have what I hope is a more specific subjective reason for
saying that I think the existing diagnostics should be changed. Fundamentally,
what is provided in the messaging is not an indication of what is wrong, but an
indication of what is required to repair the fault. My objections then become:
1: As an old man full of wisdom, most developers can't distinguish a
'primary-expression' from a washing machine. Further, to determine
what correction might be needed most users would have to research
the C++ standard (or other standardized document supported by the
g++ development community) to find out exactly what constitutes a
'primary-expression'.
2: It puts an obligation on the g++ development community to ensure
that the messaging is consistent with documentation and that if the
term 'primary-expression' changes then g++ will change the messaging
to conform to the new term.
3: The cause of the error is more specific than it's solution. The cause
of the fault is the user (in this case me) provided something that
was wrong. It wasn't the lack of a 'primary-expression' but the
existence of the illegal constructs. My conjecture is that if the
message says "you did this wrong" then the user would have an easy
time of finding a fix.
I don't argue with the details of my wording. My intent is not to show that I
am a better wordsmith but that the existing diagnostic messages are not
specific enough. From Item 1: above, in order for the average user to fix the
error the user must research the terms used, then compare the syntax given with
the actual fault, and then fix the error. If the message say "this is the
fault", the research goes the way of the woolly-mammoth.
The paradigm is that the message should provide the minimum amount of
information required to identify the syntax/semantics which caused the failure.
art
--- On Mon, 4/13/09, Kai Henningsen <kai.ext...@googlemail.com> wrote:
> From: Kai Henningsen <kai.ext...@googlemail.com>
> Subject: Re: messaging
> To: "Arthur Schwarz" <aschwarz1...@verizon.net>
> Cc: gcc@gcc.gnu.org
> Date: Monday, April 13, 2009, 11:12 PM
> Arthur Schwarz schrieb:
> > In the following code fragment:
> >
> > # include <ios>
> > # include <fstream>
> > # include <istream>
> >
> > using namespace std;
> > void CommandLine(int argc, char** argv);
> > int main(int argc, char** argv) {
> > CommandLine(argc, argv[]);
> > ifstream x.open(argv[1], ios:in);
> > ofstream y.open(argv[1], ios::in);
> > return 0;
> > };
> >
> > g++-4 messaging is:
> >>> g++-4 x.cpp
> > x.cpp: In function 'int main(int, char**)':
> > x.cpp:8: error: expected primary-expression before ']'
> token
> > x.cpp:10: error: expected primary-expression before
> ':' token
> >
> > A recommendation and reason for change is:
> > 1: x.cpp:8 error: illegal to pass an array without
> subscript value as an argument
> > The given message is accurate but
> non-expressive of the reason
> > for failure.
>
> Actually, in this case I'd say that the original message is
> perfectly fine, and your suggestion is rather confusing.
> However, what one could say here is something like "[] is
> only allowed in declarations".
>
>
> > 3: cpp:10 error: illegal scope resolution operator
> ':'
> > From memory, there are three uses of ':'
> in C++
> > ':' label terminator,
> <label>:
> > ':' case in a switch
> statement, case <value>:
> > ':' scope resolution
> operator, "::"
> > The given diagnostic message is
> deceptive.
>
> Could perhaps say "':' is not a scope resolution operator",
> unless someone comes up with a use case where it is ...
>
