Hello Gerel.
I've done a test on some functions from the list interface, it
seems to work right.
Nice.
Here is the test and the output.
These tests could be used as a base to define the unit tests for the
list module.
Now I need to integrate it in pdf-stm-* and the rest (should be
trivial).
Yes. Since the API of our list module is a subset of the gl_list API
it should be easy to adapt the existing code.
OTOH the interface allows the user to define a callback for element
deallocation
and not for element allocation. A more consistent treatment would be to
either
allocate and deallocate at the List module level or at the caller level, that
callback I feel will bring us troubles later.
[...]
So the new list creation interface would be:
pdf_list_t pdf_list_create (pdf_list_element_equals_fn_t equals_fn,
pdf_size_t elt_size, pdf_bool_t
allow_duplicates);
Of course, you can strongly disagree with me and ignore all this :-)
I think that the allocation of the memory used by the elements of the
list should be managed out of the list module. Note that the dispose
procedure is defined _outside_ the logic of the list module (that is
why it is defined as a callback), so strictly speaking we are doing an
"external" memory management.
Thanks.
