From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24255 invoked by alias); 9 May 2003 10:26:01 -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 24180 invoked by uid 71); 9 May 2003 10:26:01 -0000 Date: Fri, 09 May 2003 10:26:00 -0000 Message-ID: <20030509102601.24176.qmail@sources.redhat.com> To: nobody@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org, From: Michael Nielsen Subject: Re: c++/10680: Inlining in inheritance seems broken. Reply-To: Michael Nielsen X-SW-Source: 2003-05/txt/msg00722.txt.bz2 List-Id: The following reply was made to PR c++/10680; it has been noted by GNATS. From: Michael Nielsen To: gcc-gnats@gcc.gnu.org, gcc-bugs@gcc.gnu.org, mike@thetroubleshooters.dk, nobody@gcc.gnu.org, gcc-prs@gcc.gnu.org, mn@onair.dk Cc: Subject: Re: c++/10680: Inlining in inheritance seems broken. Date: Fri, 09 May 2003 12:18:12 +0200 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=10680 Is this the correct spot to send a response to a closed PR ? Eh, you only answered one of the issues, the other issue was that. --fkeep-inline-functions combined with -O3, or -finline-functions, causes errors in the STL headers. But the line you qoute, means that in reality, the compiler should generate an error when compiling, when someone has an inline method in any section other than private:, because any method defined in the public: and protected: areas of a class are meant to be reusable farther down the class hierachy. (though wether an error or warning, something should be generated, because it does not work, when you use the definition that have been cited in the bug report.). The current way it is implemented, a function can be inlined in either the cpp file, or the header, or both, in some of the cases, you cannot determine from the header file that the method is unavailable farther down, this makes it tricky to export API's, or to develop using an api. So it may be in accordance with the language definition, but it does not make sense the way it is implemented. The compiler should emit some warning, or error, when someone tries to access a function that (in reality) is not visible from the caller, or when someone inlines a public/protected function, that will become unavailable farther down. An inline function can in effect cause this situation, overriding the public, and protected keywords. Of course this is just IMHO. regards Michael Nielsen.