Hi, 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. Best, Sascha > > 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