Degraded C++ error messages.

[Carlo Wood]

On Fri, Nov 07, 2003 at 10:28:33PM +0100, Gabriel Dos Reis wrote:
> That is what I call expression-based messages.  Sorry if I didn't word it
> clearly. 

About "how to format the error messages", I'd like to suggest
the following.

An error message should be as short as possible, yet still
specify what exactly is "the problem".  This means that
a clear descriptive message needs to be output that differentiates
the different places in the gcc source code (equivalent to
the different types of "problems") and that somehow a reference
needs to put in that message that point to the "objects"
involved.  Especially those object references need to be as
short as possible imho.

For example;  suppose we have the following code:


  x = y + z - r;  g = h - k * i;

Type of problem occuring: a binary expression for two types 
is requested that does not exist.
Information need: "No such function (alternatives: ..."
                  "Name of binary expression"
		  "Very short reference to the two elements
		   involved."
For example:
error: No such function: operator-(std::string&, float&) in `h - k * i'


This might seem to give not enough information, but it is the
type of message that helps the programmer the quickest.

What strikes myself the most from the above rather abstract
analysis (the example being less abstract of course ;) is that
BOTH, the types involved AND the expressions are needed.
The expressions are needed to locate the place in the source
code (human programmer pattern matches this output with the
source line in order locate place of problem) AND the types
are needed in order to explain the root of the problem.
Leaving out either will make the error message incomplete.

More to the point, leaving out the operator-() part will
explain nothing to the programmer, we really need that part.
But leaving out the expression will make understanding this
error only possible by looking at the source code line and
in the case that there is only one operator- on that line.

Now, the originally posted error message (by 3.3):

troep.cc:6: error: request for member `base' in `*(&std::vector<_Tp,
   _Alloc>::begin() [with _Tp = int, _Alloc =
   std::allocator<int>]())->__gnu_cxx::__normal_iterator<_Iterator,
   _Container>::operator->() const [with _Iterator = int*, _Container =
   std::vector<int, std::allocator<int> >]()', which is of non-aggregate type `
   int'

Would, using the above strategy, become something like:

troep.cc:6: error: request for member `base' in non-aggregate type
   `int', in `v.begin()->base()'.

There is no need to meantion the type of v, v.begin() or its operator->().

-- 
Carlo Wood <carlo@alinoe.com>