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.


Carlo Wood <carlo@alinoe.com> writes:

| On Fri, Nov 07, 2003 at 05:16:47PM +0100, Gabriel Dos Reis wrote:
| > | ~>g++-cvs-3.4 troep.cc
| > | troep.cc: In function `int main()':
| > | troep.cc:6: error: expected type-name
| > | troep.cc:6: error: expected `::'
| > | troep.cc:6: error: expected `~'
| > | troep.cc:6: error: expected identifier
| 
| This particular case seems to be duplicate of
| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9851
| 
| So I won't report it again.
| 
| That PR is assigned to you.
| How is the status of it?

The current situation is that I'm trying to come up with
expression-based error messages that are at least as informative as
previous GCC releases.

| 
| > 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)

Note that type-based messages don't conveniently and accurately
capture expressions that 

   v.begin()->base();

(this is something I slowly come to realize when working on
signature-based vs. usage pattern-based concepts).

|  I'll give more examples of the unreadable
| cases that I run into when I run into them, in this thread - and leave
| the 'excepted' type of error message for what they are as being reported
| and known already anyway.

Sure, they would be helpful.

-- Gaby


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