This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Degraded C++ error messages.


On Sat, Nov 08, 2003 at 02:38:02PM -0800, Matt Austern wrote:
> The "concept" proposal that Bjarne and Gaby are working
> on should help to some extent.  But in the mean time
> there's no real choice but to give error messages that
> contain enough information so that they can be used to
> tell what's wrong regardless of whether the error is in
> the template definition or the template instantiation.
> Hundred-line error messages are awful, but I don't think
> we have a choice yet.
> 
> 			--Matt

I have no problem with long error messages that exist
of multiple lines along the lines of "instantiated from here"
and such.  But an error messages related to a single location
should not be 100 lines long.

One such line can basically exist of:

<location>: error|warning: error/warning text with `type' and
more text and another `type', in `expression'.

Where `expression' then should look as much as possible as
the literal string that you see in the source code, because
its only intend should be to help the programmer locate the
exact location of the error (in principle a column number
would suffice: you could print the whole source line and
put an error at the place of the problem).

Errors that do not involve types somehow are not a problem,
they are ok as they are already.

When the types that need to be printed are template types, then
it is possible that those types become very large - and for
that we can think of a way to improve that.  But that is
not related to the problem at hand imho: a type is a type,
there is little you can change about that.  At most you can
think of printing the template parameters seperatedly, and
using standard or user defined typedefs to compress the type
that is printed.  Ie, instead of printing
std::basic_string<char, std::char_traits<char>, std::allocator<blah blah blah...
why not just print 'std::string'?  The message need to be
interpreted by humans after all.  Same for 'std::vector<UserType>'
etc.

-- 
Carlo Wood <carlo@alinoe.com>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]