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

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

[Andrew Lunn]

Hi Folks

Could somebody who is better at C++ than me take a look at this
warning gcc 4.0.2 is giving. Using the "Monkey's typing Shakespeare"
approach did not get me very far...

/home/lunn/eCos/work/install/include/cyg/kernel/thread.inl:630: warning: 'cyg_bool Cyg_ThreadQueue::empty()' was used before it was declared inline
/home/lunn/eCos/work/install/include/cyg/kernel/thread.hxx:565: warning: previous non-inline declaration here

        Thanks
                Andrew

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

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

[Billy]

Andrew Lunn wrote:
> Hi Folks
> 
> Could somebody who is better at C++ than me take a look at this
> warning gcc 4.0.2 is giving. Using the "Monkey's typing Shakespeare"
> approach did not get me very far...
> 
> /home/lunn/eCos/work/install/include/cyg/kernel/thread.inl:630: warning: 'cyg_bool Cyg_ThreadQueue::empty()' was used before it was declared inline
> /home/lunn/eCos/work/install/include/cyg/kernel/thread.hxx:565: warning: previous non-inline declaration here

Do like 'remove' (just above), and lose the 'inline' qualifier
in thread.hxx:565.  The 'inline' qualifier in the _definition_
should be enough, eh?

The usage:   "inline foo();" (with a semicolon) smells fishy.

Maybe you tried that already.

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

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

[Billy]

Billy wrote:
> Andrew Lunn wrote:
> 
>> Hi Folks
>>
>> Could somebody who is better at C++ than me take a look at this
>> warning gcc 4.0.2 is giving. Using the "Monkey's typing Shakespeare"
>> approach did not get me very far...
>>
>> /home/lunn/eCos/work/install/include/cyg/kernel/thread.inl:630: 
>> warning: 'cyg_bool Cyg_ThreadQueue::empty()' was used before it was 
>> declared inline
>> /home/lunn/eCos/work/install/include/cyg/kernel/thread.hxx:565: 
>> warning: previous non-inline declaration here
> 
> 
> Do like 'remove' (just above), and lose the 'inline' qualifier
> in thread.hxx:565.  The 'inline' qualifier in the _definition_
> should be enough, eh?
> 
> The usage:   "inline foo();" (with a semicolon) smells fishy.
> 
> Maybe you tried that already.

This might help:
http://www.parashift.com/c++-faq-lite/inline-functions.html#faq-9.9


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

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

[Andrew Lunn]

On Fri, Oct 21, 2005 at 05:29:36PM -0400, Billy wrote:
> Andrew Lunn wrote:
> >Hi Folks
> >
> >Could somebody who is better at C++ than me take a look at this
> >warning gcc 4.0.2 is giving. Using the "Monkey's typing Shakespeare"
> >approach did not get me very far...
> >
> >/home/lunn/eCos/work/install/include/cyg/kernel/thread.inl:630: warning: 
> >'cyg_bool Cyg_ThreadQueue::empty()' was used before it was declared inline
> >/home/lunn/eCos/work/install/include/cyg/kernel/thread.hxx:565: warning: 
> >previous non-inline declaration here
> 
> Do like 'remove' (just above), and lose the 'inline' qualifier
> in thread.hxx:565.  The 'inline' qualifier in the _definition_
> should be enough, eh?
> 
> The usage:   "inline foo();" (with a semicolon) smells fishy.
> 
> Maybe you tried that already.

Yep, tried that, same error.

        Andrew

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

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

[Alexander Neundorf]

On Saturday 22 October 2005 09:50, Andrew Lunn wrote:
> On Fri, Oct 21, 2005 at 05:29:36PM -0400, Billy wrote:
...
> > The usage:   "inline foo();" (with a semicolon) smells fishy.
> >
> > Maybe you tried that already.
>
> Yep, tried that, same error.

Maybe it helps to have a look at the preprocessed file ?

Bye
Alex

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

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

[Andrew Lunn]

On Sat, Oct 22, 2005 at 03:24:55PM +0200, Alexander Neundorf wrote:
> On Saturday 22 October 2005 09:50, Andrew Lunn wrote:
> > On Fri, Oct 21, 2005 at 05:29:36PM -0400, Billy wrote:
> ...
> > > The usage:   "inline foo();" (with a semicolon) smells fishy.
> > >
> > > Maybe you tried that already.
> >
> > Yep, tried that, same error.
> 
> Maybe it helps to have a look at the preprocessed file ?

Yes, it did. I think i now understand it.

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.

        Andrew

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

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

[Paul D. DeRocco]

> 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