On 2009-01-21, David Schleef <d...@entropywave.com> wrote: > I'm not a big fan of this patch, since I don't think it moves us > closer to the optimal data structure for storing an array of > pictures. At some point, I'd like to have a combined SchroPicture > and SchroEncoderFrame, which means that SchroQueue can be renamed > SchroPictureQueue and have a more picture-oriented API. > > So this one is a no.
I don't see that you gain anything particularly by doing that over what i've done here. Having a useful Queue data structure can be useful, not requiring spurios extra stuff in it seems even better; The only optimality in having internal representation of picture numbers inside the queue ADT would be to avoid a dereference; our queues aren't hit that hard surely? That said, this implementation could look slightly nicer if there were a schro_queue_delete_at(...). ..david ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ Schrodinger-devel mailing list Schrodinger-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/schrodinger-devel
