From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3577 invoked by alias); 26 Mar 2005 04:06:46 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 3563 invoked by alias); 26 Mar 2005 04:06:43 -0000 Date: Sat, 26 Mar 2005 04:06:00 -0000 Message-ID: <20050326040643.3562.qmail@sourceware.org> From: "gdr at integrable-solutions dot net" To: gcc-bugs@gcc.gnu.org In-Reply-To: <20040410193158.14912.schnetter@aei.mpg.de> References: <20040410193158.14912.schnetter@aei.mpg.de> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug c++/14912] Do not print default template arguments in error messages X-Bugzilla-Reason: CC X-SW-Source: 2005-03/txt/msg03062.txt.bz2 List-Id: ------- Additional Comments From gdr at integrable-solutions dot net 2005-03-26 04:06 ------- Subject: Re: Do not print default template arguments in error messages "giovannibajo at libero dot it" writes: | ------- Additional Comments From giovannibajo at libero dot it 2005-03-26 00:35 ------- | (In reply to comment #12) | | > Look at the most general template and same_type_p() with any default | > type. | | How can it work? The default parameter can be dependent on previous template | parameters. For instace, in vector, the default type in the most general | template would be something like std::allocator (with T being a previous | template parameter), while the type in the instantiation is something like | std::allocator. | | > Again that is better done with cxx-pretty-print.c | | I don't know what cxx-pretty-print.c is, exactly. cp/cxx-pretty-print.c | Is it currently used? Yes. Curently, the pretty-printing job is done by both error.c and cxx-pretty-print.c. But, the goal is to move the codes to the latter. | Everytime I step with GDB into an error()/warning()/info() call I only see code | from errors.c being used. My current patch is modifying errors.c because that | is what the FE currently uses, as far as I can tell. you're just mistaken. I have been modifying the codes for long time now, and I have an idea of the code path. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912