This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: kernel API
- From: Jonathan Larmour <jifl at eCosCentric dot com>
- To: "Koeller, T." <Thomas dot Koeller at baslerweb dot com>
- Cc: "ecos-discuss (E-Mail)" <ecos-discuss at sources dot redhat dot com>
- Date: Thu, 24 Apr 2003 03:12:08 +0100
- Subject: Re: [ECOS] kernel API
- References: <850597605E79D21182830008C7A4B9CF1EB425B0@COMM1>
Koeller, T. wrote:
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.
It does because things like cyg_handle_t's and cyg_thread's are opaque (if
people try and use the definitions in kapidata.h it's on their own head!).
The same thing would apply to a C++ API. The individual members from the
underlying implementation would not be exposed - in fact C++'s access
control would do this better than the C API could.
But we wouldn't be providing any more functionality than the C API really
- just making it more efficient for C++ users, and making it fit into the
OO paradigm better.
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...
Well that's indeed one of the reasons why we are where we are today :-).
But if someone wants to come up with a serious proposal for a C++ API
(with the intention of implementing whatever results from the discussion
:-)), naturally it will be considered!
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