RE: [ECOS] help with C++ needed....

["Paul D. DeRocco" <pderocco at ix dot netcom dot com>]

> 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 <cyg/kernel/thread.hxx>       // thread definitions
> #include <cyg/kernel/flag.hxx>         // flag definitions
> #include <cyg/kernel/clock.hxx>        // clock definitions
>
> #include <cyg/kernel/sched.inl>
> #include <cyg/kernel/thread.inl>
>
> 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