From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17576 invoked by alias); 23 Oct 2005 06:48:02 -0000 Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Received: (qmail 17529 invoked by uid 22791); 23 Oct 2005 06:47:58 -0000 Received: from smtpauth04.mail.atl.earthlink.net (HELO smtpauth04.mail.atl.earthlink.net) (209.86.89.64) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Sun, 23 Oct 2005 06:47:58 +0000 Received: from [70.33.96.36] (helo=PAULD) by smtpauth04.mail.atl.earthlink.net with asmtp (Exim 4.34) id 1ETZe8-0004wJ-O5 for ecos-discuss@ecos.sourceware.org; Sun, 23 Oct 2005 02:47:56 -0400 From: "Paul D. DeRocco" To: "eCos Discuss" Date: Sun, 23 Oct 2005 06:48:00 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In-Reply-To: <20051022191126.GU7087@lunn.ch> X-ELNK-Trace: bd7d5d4e6f8f652c74cfc7ce3b1ad11381c87f5e519606887349926816570f93875d139f1da0bc28350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c Subject: RE: [ECOS] help with C++ needed.... X-SW-Source: 2005-10/txt/msg00185.txt.bz2 > From: Andrew Lunn > > thread.hxx declares the class Cyg_ThreadQueue which has a member > function empty. > > thread.inl contains the implementation of Cyg_ThreadQueue::empty() and > says it is an inline function. > > flag.hxx declares the class Cyg_Flag. It has a member variable queue > of type Cyg_ThreadQueue. It also declares a member function waiting() > which is inline and the implementation is given there and then. This > implementation is !queue.empty(). > > It is select.cxx which is giving the problem. At the beginning this does: > > #include // thread definitions > #include // flag definitions > #include // clock definitions > > #include > #include > > So the problem is that in flag.hxx the compiler has seen there is a > member function queue(), but it has not seems the implementation > yet. So it generates a function call and adds queue to its symbol > table as an out of line function. It later gets to see the > implementation of queue and finds its supposed to be an inline > function, but it has already generated code which assumes its an out > of line function, and so it generates the warning and generates code > for the out of line implementation of queue. > > So its looks like flag.hxx needs to include both thread.hxx and > thread.inl. > > Thats my theory anyway. I just need to test it. > > It might also be worth posting a gcc bug asking for them to make the > error message a bit easier to understand. It seems to me that the design of C++ makes it impossible to cleanly separate the interface from the implementation in the case of inline functions, and any attempt to do so is a hack that is doomed to provoke at least a compiler warning under some circumstance or another. Indeed, there are a couple of quickie inline functions at the end of thread.hxx, suggesting that someone had this problem before and hacked it by moving the definitions from thread.inl to thread.hxx. What's really fishy is that some of the inline functions in thread.inl are enormous. What's that all about? -- Ciao, Paul D. DeRocco Paul mailto:pderocco@ix.netcom.com -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss