This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC 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: C++ PATCH: PR 23293


"Giovanni Bajo" <giovannibajo@libero.it> writes:

> Mark Mitchell <mark@codesourcery.com> wrote:
>
>
>> That's clearly bad.  This patch makes us the canonical type variant
>> (i.e., the non-typedef variant) so that we get consistent, sensible
>> names in all scopes.
>>
>> I'm sure that someone will now file a PR saying that we've "regressed"
>> on reporting errors about types like "S<MyList>", which will now be
>> presented as "S<std::list <int, ... > >".  I guess that's a
>> regression, but not an important one, and this patch clearly makes
>> things more consistent.  (And, in many cases, you actually need the
>> non-typedef form of a template type in order to figure out why
>> deduction failed...)
>
>
> Please reconsider this patch. The fact that GCC was able to say S<MyList>
> instead of S<..15 lines of template dump..> was a very important feature for
> the C++ template community, especially Boost. It was so important that GCC was
> the preferred compiler in terms of template debugging *especially* for this.
> With this patch, you're making meta-debugging just as hard as any other
> compiler. It is indeed a *large* regression.
>
> I'm CC'ing David Abrahams who even wrote about this GCC feature in his book.
> I'm sure he has something to say about this too.

Well, I'm not yet sure that this is as bad as Giovanni says.

The thing that other compilers do that's *really* awful is presenting
something like:

      some_template< ...gobbledygook... >::some_nested_typedef
                                           ^^^^^^^^^^^^^^^^^^^
where

      int 

would do instead.  GCC didn't do that, and from what I can see above
nobody is proposing to make it do that.

GCC *does* present typedef names when those names are not nested
members of templates.  So, for example, we'd see

      std::string

as opposed to

      std::basic_string<char, char_traits<char> >

It seems as though Mark is proposing to change that.  I consider it a
very nice feature to have, and removing it would be a very real loss,
but not heinous.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com


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