Michael Niedermayer (HE12025-04-08):
> As i have too many things to do already i did the most logic thing and
> started thinking about a new and unrelated idea.
>
> This is a list of problems and ideas, that everyone is welcome to add to and
> comment on.
>
> AVDictionary is just bad.
A few notes on the topic:
Steal a few ideas from BPrint, adapt them to a dictionary:
Include an initial buffer in the root structure.
Make the code tolerant to the size of the included buffer.
That ensures that the root structure can be allocated by the caller on
the stack.
Use a flat data structure with low overhead as long as the data fits in
the initial buffer and switch to a more efficient data structure when
dynamic allocation becomes needed.
A few points to decide:
Do we want only string → string, or do we want string → any or any →
any?
To handle any data structure, we can do:
const struct {
int (*clone)(void *, const void *);
void (*free)(void *);
void (*ref)(void *);
void (*unref)(void *);
int (*compare)(const void *, const void *);
unsigned (*hash)(const void *);
} *key_ops, *val_ops;
Supporting any kind of key or data can make it harder to use a flat data
structure, but we can manage.
The API should be designed to allow to avoid dynamic allocations, both
when adding and querying data. For query, consider all cases: if the
result is short lived, we can return the value inside the structure
itself; if the entry is removed from the structure immediately we can
return it (“my $v = delete $h{$k}” in perl).
Regards,
--
Nicolas George
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
