Re: Degraded C++ error messages.

[Gabriel Dos Reis <gdr at integrable-solutions dot net>]

Martin Sebor <sebor@roguewave.com> writes:

| Gabriel Dos Reis wrote:
| 
| ...
| > | > I much prefer the error message that displays expressions (althougth it
| > | > could be improved), but some people seems to like the "typed" ones --
| > | > it should be recalled that C++ expressions can not be consistently and
| > | > accurately captured by types only.  I find it quite unreadable.
| > | | I am sad to hear that you like expressions more - because those
| > are
| > | definitely less readable.
| > Are you saying that
| > 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'
| > is more readale than
| > troep.cc:6: request for member `base' in
| > `*v.vector<int,allocator<int> >::begin()', which is of non-aggregate
| > type `int'
| > ?
| > (I think quite the opposite is true)
| 
| Something can certainly be said for both: I find that the latter is
| a lot more concise and, in this case, immediately obvious even to a
| novice to template programming what the problem is. The former is
| more complete and informative, but the extra detail is, IMO, likely
| to confuse inexperienced users (especially since the detail involves
| implementation details).

Yup.  On average, I find that the type-based messages, almost, always
come with too many details (usually, implementation details) that
confuses the messages.  Also, there is the issue of trying to reflect
lvaluness by references which, from time to time, obscures the message.

| Incidentally, in the elaborated messages I suggest putting the [with
| T = ..., U = ...] bit at the very end of the message, not in the
| middle as shown above. As it is, it might be easy to miss the text
| that follows the template parameter list.

Yes.  This is most desirable.  However, given the current mess in
cp/error.c, it is not as easily done since format flags and code pathes
tend to vary unpredicatbly.  That is one the reason I wrote the new
pretty-printer.  It remains to activate it.

| In any case, the legibility of compiler diagnostics is likely to be
| a subjective issue. It would be nice if the text could be customized,
| say by allowing users to expand the types in place (for essentially
| the latter effect, i.e., without the [with T = ...] bit). It would
| also be helpful if it was possible (perhaps as an option controlled
| by some mapfile) to substitute typedefs for complicated types, say
| std::string instead of the more verbose "std::basic_string<_CharT,
| _Traits, _Alloc> [with _CharT = char, _Traits = std::char_traits<char>,
| _Alloc = std::allocator< char> >]."

this is easier to do with the new pretty=printer than cp/error.c.

-- Gaby