------- Additional Comments From dave at boost-consulting dot com 2005-03-26
12:57 -------
Subject: Re: Do not print default template arguments in error messages
"gdr at integrable-solutions dot net" <[EMAIL PROTECTED]> writes:
> ------- Additional Comments From gdr at integrable-solutions dot net
> 2005-03-26 04:13 -------
> Subject: Re: Do not print default template arguments in error messages
>
> "dave at boost-consulting dot com" <[EMAIL PROTECTED]> writes:
>
> [...]
>
> | Please, I'm begging you not to go down this road. GCC is one of the
>
> I know you have strong opinions on what compilers should print; we had
> part of this discussions on -core and it did not seem like that was a
> universal solution that handles all the cases.
First, I don't know if I've misunderstood what you meant by "show how
it was written," so I'd really appreciate if you'd clarify that before
we go any further down this road. To make it easy on you, let me try
to be very clear about what I fear. If you run this through the
Comeau on-line compiler:
template <class T>
struct foo1
{
// ...
typedef T* pointer;
};
template <class T>
struct foo2
{
// ...
typedef T** pointer; // oops, should've been T*
};
template <class U, class V>
struct bar
{
bar( V v )
{
U u = v;
}
};
template <class U, class V>
struct baz
{
baz()
{
bar<
typename foo1<U>::pointer,
typename foo2<V>::pointer
> b(0);
};
};
baz<int,int> x;
You'll get a message that says:
line 20: error: a value of type "foo2<int>::pointer" cannot be
used to initialize an entity of type "foo1<int>::pointer"
U u = v;
^
detected during:
instantiation of "bar<U, V>::bar(V) [with U=foo1<int>::pointer,
V=foo2<int>::pointer]" at line 32
instantiation of "baz<U, V>::baz() [with U=int, V=int]" at line 36
It is the appearance of "foo1<int>::pointer" and "foo2<int>::pointer"
in the error message, rather than "int*" and "int**", that I'm
concerned about. Nothing in the error message points at
the definition of foo1 or foo2 above, so the user gets no help in
understanding which one might be the true cause of the error. And
even if it pointed at foo1 or foo2, in general the real source of
foo2<T>::pointer could easily have been some other template:
template <class T>
struct foo1
{
typedef typename foobar<T>::value_type* pointer;
};
This happens very typically in the standard library, where nested
types are transferred and modified from allocators into containers and
so forth. I want to be sure that GCC continues to show "int*"
and "int**" in these cases.
> I'm going to scheme that handle the majority of the cases right.
Assuming your intention is to do what I fear (otherwise, please ignore
the rest):
On what basis can you say that? Have you got some measurement of what
the majority of cases look like, and an objective way to understand
what "right" is?
No solution universally handles all the cases perfectly, but we can
make some objective analysis of how tractable it is to find any given
piece of important information in the various schemes. Going down the
EDG path may make a few kinds of analysis incrementally easier, but it
makes other kinds vastly harder, to the point of being nearly
impossible. I keep a copy of GCC on hand at all times just for
situations like this, no mater what compiler I'm using. I find it
ironic that if GCC makes the change I fear, the only compiler left
that yields workable error messages in these kinds of situations will
be from Microsoft.
> | only compilers that gets it right today (VC8 will follow), and all
> | the ones that try to follow the "show how it was written" rule
> | often give errors that are, for all practical purposes, unusable.
> | If you make GCC work like the others, it will be a leap backwards
> | and a terrible disservice to users.
>
> yes, you're entitled to your opinions.
This is very disappointing. Condescencion is entirely uncalled for.
I won't claim to know what your level of expertise is, but I know I've
done more comparative research on template-related error messages than
most people. If you care about GCC's usability you ought at least to
take what I say seriously.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912
