From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31430 invoked by alias); 19 Nov 2002 16:06:04 -0000 Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-prs-owner@gcc.gnu.org Received: (qmail 31416 invoked by uid 71); 19 Nov 2002 16:06:03 -0000 Date: Tue, 26 Nov 2002 05:56:00 -0000 Message-ID: <20021119160603.31415.qmail@sources.redhat.com> To: nobody@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org, From: Gabriel Dos Reis Subject: Re: c++/8622: typename of base class Reply-To: Gabriel Dos Reis X-SW-Source: 2002-11/txt/msg00972.txt.bz2 List-Id: The following reply was made to PR c++/8622; it has been noted by GNATS. From: Gabriel Dos Reis To: "Patrick Laurent" Cc: , gcc-gnats@gcc.gnu.org Subject: Re: c++/8622: typename of base class Date: 19 Nov 2002 16:59:58 +0100 "Patrick Laurent" writes: | Hello | | Thank you very much for your two quick answers | | But I have to admit that I am still not convinced that gcc 3.2 is doing | right with the typedef in a base class. Well, that is a differenr matter ;-) GCC is behaving as required by the standard (actually it should give an error to make it non-negociable :-) | Please, I would like to know if there is a reason to this gcc property. standard requirement. | -I know that VC7 is quiet not the best compiler (It can't even undestand | Partial Template Specialisations), but this can't be an argument. I can't find anyone bringing up that argument; what did you mean? | In fact I | don't use VC7, but Intel Compiler 6 and gcc2.9.5. | | -It is perhaps deprecated yet, but it used to work with gcc2.9.5 GCC-2.95 was non conformant. | -I fand the "workarround" you mentionned but then the class hierarchy | doesn't make sense any more. Huh? | The "workarround" consists in making a new typedef in the derived class: | template struct B : public A { typedef typename | A::value_type value_type; ...} Yes. | -Is my use of several STL-structures not right any more? for exemple: | | #include | using namespace std; | | template | struct id_function : public unary_function | { | result_type operator()(const argument_type &x) const { return x; } Yes this is an error as the base class (a dependent type) is not or should not be examinated in the template definition. Yes, that may make the whole (unary|binary)_function<> thingies pointless. -- Gaby