incubator-celix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sascha Zelzer <>
Subject Re: [Native-OSGi] Usage of arrays vs collections
Date Tue, 05 Jun 2012 16:12:10 GMT

On 06/04/2012 08:40 PM, Pepijn Noltes wrote:
> Hi All,
> On Mon, Jun 4, 2012 at 3:01 PM, Alexander Broekhuis
> <>  wrote:
>> Hi,
>> I'm working on extracting the OSGi API's from Celix to the Native-OSGi
>> project. Celix uses a utils library through which Lists and Maps are
>> provided.
>> How do we want to solve this in the API? Following the OSGi API, often a
>> simple array is used (Celix uses an ArrayList in those cases). But the Java
>> Collection/Dictionary etc are also used.
>> A simple/portable solution would be to use arrays with an additional return
>> parameter for places where a collection/list is used. For example:
>> int bundleContext_getBundles(bundle_context_t context, bundle bundles[],
>> int *entries);
>> A similar solution can be used for Dictionaries as well, a simple key/value
>> struct can be used.
>> How do we want to solve this? I don't know of any standard C library, and
>> what about C++?
> C++ has C++ Standard Library (STD), which contains arrays, queues,
> maps, etc and is - if i am correct - part of the C++ standard.
> Because C does not have this, I think the purposed solution is a good one.
I agree with Pepijn here that imposing a (very small) set of utility 
functions/structs on the API is acceptable. I would personally always 
favour ease of use (concerning the API) over strictly sticking to "pure 
C". If there exists a small C library which we could embed or from which 
we could extract relevant structures for the API, then go for it.

Even for the C++ API, there are some places where I would like to 
introduce custom data structures to make the life of the API user easier 
and/or more type-safe.


> An other option is to make the needed C collections part of the OSGi
> API. Which has the advantages that we can use linked arrays, hash
> maps, etc. The drawback is that we impose a API for something which is
> clearly not part of OSGi.
> Greetings,
> Pepijn

View raw message