RE: [ECOS] kernel API

["Koeller, T." <Thomas dot Koeller at baslerweb dot com>]

The current C API appears to be a 1:1 mapping of the C++
interfaces onto C functions, it does not provide much
abstraction anyway. I also cannot see how it would do this.
Imagine a thread class were extended to require an additional
constructor argument. This could be hidden by the C API
function by changing cyg_thread_create() to provide a
default value for the new parameter, preserving te original
function signature, and adding a new function named
cyg_thread_create_ex() that takes an additional argument.
However, C++ provides much more elegant mechanisms to
achieve this without namespace pollution (arguments with
default values, overloading), so the 'abstraction' provided
by the C API would in fact make things more difficult, not
easier.

I do not want to overly stress this point. I will continue to
use the C++ API, as will others. I guess the probability of
the C++ interfaces being removed and replaced by something
entirely different is rather low anyway, so it is probably
not all that important...

tk
----------------------------------------------- 
Thomas Koeller, Software Development 

Basler Vision Technologies 
An der Strusbek 60-62 
22926 Ahrensburg 
Germany 

Tel +49 (4102) 463-390 
Fax +49 (4102) 463-46390

mailto:Thomas dot Koeller at baslerweb dot com 
http://www.baslerweb.com 




> -----Original Message-----
> From: Jonathan Larmour [mailto:jifl at eCosCentric dot com]
> Sent: Tuesday, April 22, 2003 11:28 PM
> To: Koeller, T.
> Cc: ecos-discuss (E-Mail)
> Subject: Re: [ECOS] kernel API
> 
> 
> Koeller, T. wrote:
> > [snip]
> > For all the reasons listed above, I am raising the
> > topic again. My proposal is to award the status of
> > an officially supported API to the C++ kernel API, too.
> 
> The problem is that we have to have flexibility to change how 
> the kernel 
> _implementation_ works, even if the _interface_ has to say 
> the same. Right 
> now the C++ stuff is just directly what is required by the 
> implementation. 
> Defining the internal API to be "official" will tie our hands 
> unreasonably 
> in the future if the API is to have any stability (and 
> stability is one of 
> the defining features of an API really!).
> 
> If there was a C++ API, it would have to be a separate veneer 
> over the 
> internal C++ API. In the first instance, using inline 
> functions etc. this 
> could be pretty much a  burden-free veneer over the internal 
> C++ API, but 
> if sensibly designed would give us the flexibility to change the 
> implementation without worrying about messing up the interface.
> 
> So that _could_ be a slight improvement over the C API by 
> removing some of 
> the overhead. But no-one has yet done such a thing of course 
> :-), and it 
> _isn't_ just a case of defining one to the other since there 
> does have to 
> be some level of abstraction in order to hide the internals.
> 
> Given that people are either happy with the C API, or not too worried 
> about using the internal C++ API directly, this hasn't been a 
> priority for 
> any of the main developers in the past. Personally I would have no 
> objections to a sensibly designed C++ API that fulfilled the 
> requirements 
> above. Nick G obviously might have a little bit more to say in how it 
> should be done of course ;-).
> 
> Jifl
> -- 
> eCosCentric    http://www.eCosCentric.com/    The eCos and 
> RedBoot experts
> --[ "You can complain because roses have thorns, or you ]--
> --[  can rejoice because thorns have roses." -Lincoln   ]-- 
> Opinions==mine
> 

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