public inbox for gcc-prs@sourceware.org help / color / mirror / Atom feed
From: Michael Nielsen <mn@onair.dk> To: nobody@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org, Subject: Re: c++/10680: Inlining in inheritance seems broken. Date: Fri, 09 May 2003 10:26:00 -0000 [thread overview] Message-ID: <20030509102601.24176.qmail@sources.redhat.com> (raw) The following reply was made to PR c++/10680; it has been noted by GNATS. From: Michael Nielsen <mn@onair.dk> 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.
next reply other threads:[~2003-05-09 10:26 UTC|newest] Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top 2003-05-09 10:26 Michael Nielsen [this message] -- strict thread matches above, loose matches on Subject: below -- 2003-05-08 13:51 nathan 2003-05-08 13:16 mn
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20030509102601.24176.qmail@sources.redhat.com \ --to=mn@onair.dk \ --cc=gcc-prs@gcc.gnu.org \ --cc=nobody@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).