On Wed, 2007-12-05 at 19:38 +0000, Krzysztof Foltman wrote:
> Lars Luthman wrote:
> > Yeah, if it's sorted. I don't really think it's needed though, iterating
> > through a couple of hundreds of strings (in extreme cases) isn't that
> > much work to do at instantiation time.
> >
> Well, let's imagine we need to find 50 URIs in the pool of 200. How many
> strcmps is that?
>
> Extreme example, I know. But if it's going to be used as generic
> URI-to-int translation (not just event type-related), then who knows.
>
> Why decide to use something which has O(M*N) and not O(M*log(N)) (or
> even O(M)) average complexity, if the difference in amount of work for
> plugin developers is hardly noticable?
Assuming someone provides code to manage the symbol table, the increased
work on plugin authors is 0 (you can still do an ignorant linear search
through sorted array).
Might as well.
I think it would be better if the symbol thing was just a (simple) API
where the implementation is left up to the host (or whatever), rather
than defining some specific data structure to send to the plugin. We
can deal with the details of a really good symbol system later...
-DR-
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Thu Dec 6 08:15:02 2007
This archive was generated by hypermail 2.1.8 : Thu Dec 06 2007 - 08:15:02 EET