pnoltes opened a new pull request, #727:
URL: https://github.com/apache/celix/pull/727
This PR adds support for specific element types with celix_array_list.
With the currently implementation users should choice a array element type
during creation and when using the existing `celix_arrayList_create` function a
array list with an undefined element type is created. The undefined element
type should make the element type introduction backwards compatible.
A few things where I am not certain about / not fully happy about:
- I added a STRING and STRING_REF element type so that it is possible to
have an array list that owns string elements and an array list that only have
refs to strings. Downside is that this now results in a
`celix_arrayList_addString` which behaves differently based on the element
type. As result I think it is better to remove support for the STRING_REF.
- Currently asserts are used to ensure users can only call the correct
functions for a specific array element type. So a `celix_arrayList_addVersion`
on a celix array list created with `celix_arrayList_createVersionArray` will
give a runtime assert error. This is done both on the add and get functions. An
alternative could be to:
- Not do an assert check on the `celix_arrayList_get*` function, so that
user can - for example - retrieve the string pointer using
`celix_arrayList_get` instead of `celix_arrayList_getString`.
- Return a CELIX_ILLEGAL_ARGUMENT when a user calls a add function that
does not match the underlying type.
Concerning the asserts, my preference is to remove them in the
`celix_arrayList_get*` functions, but keep them in the `celix_arrayList_add*`
functions. I prefer not use the `CELIX_ILLEGAL_ARGUMENT` return value, because
we are then adding the need for runtime error checks on software errors. IMO
Ideally the only error return for celix array list functions is ENOMEM.
Note this PR also contains a small fix for push stream so that this compiles
with gcc 13.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
