Josh de Kock (2018-02-04): > The main benefit of the opaque pointers is the flexibility of how components > are stored/represented internally, and being able to change/extend it with > no API changes (only additions). Sure there is the question of 'how efficient > is it?', but it's not really a relevant question considering how frequently > the iteration functions are called (not much relative to other parts of the > library where efficiency is more crucial).
Sorry, I forgot to answer that part. Using an index has the same good properties. And so does returning the list at once (I ask again: did you read the suggestion properly? It is not about returning an internal array containing the list, it is about building a new array to return it to the caller; it exposes no internal at all.) Therefore, this argument cannot be use to decide between the three possibilities. Using an iterator with an opaque pointer has the drawback of forcing the iteration order: always in order, always from the beginning. It also has the drawback of requiring documentation on the validity of the opaque pointer. This is an API we intend to keep for a long time, we should try to pick the best one, the one that gathers the most consensus. Regards, -- Nicolas George
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list email@example.com http://ffmpeg.org/mailman/listinfo/ffmpeg-devel