On Mon, Aug 4, 2008 at 3:16 AM, Nathan Ingersoll <[EMAIL PROTECTED]> wrote: > On Sat, Aug 2, 2008 at 9:49 AM, Gustavo Sverzut Barbieri > <[EMAIL PROTECTED]> wrote: >> >> I don't want everyone to always use it, it can be kept as a helper and >> people who wish to have an abstract data model (usually void *) and >> access it as a list can provide the iterator. I use it in my mvc >> lists, something like: model_set(void *model, eina_iterator_t >> *(*accessor_constructor)(void *model)) and whenever I want to iterate >> the whole list, I delete the old, create a new and start the loop. > > I think the iterator should be absolutely required to access the list > contents. There have been many bugs in code that uses evas_lists > simply because the API is designed to maintain references into > internal structures (the list nodes). The mempool makes this even more > difficult to debug since the nodes are not freed, and are often > re-used as other list nodes. Even if they are not re-used, they can > contain pointers within the remnants of the list and so appears valid.
my personal experience with such is different. I see more and more people used to manipulate these lists, and if you make it clear you should not modify list while iterating, or you have to take double-care, then errors go to 0. Often I use kernel like macros to do iteration, and they even have macros to deal with lists that can change. I guess the point of direct access is to make it fast, we can make them more safe by using these macros. And the point of iterators is to make various data type access uniform, I can get the iterator for a list, array, chuncked list, hash, ... As for the mempool, AFAIK eina has changeable subsystems, we can do like others and have one subsystem that just malloc/free for ease of debug. >> It's a bit different as it's an external structure, you can create as >> much iterators or accessors as you want and use them in different >> ways. What you CAN'T is modify the iterated/accessed object while it's >> in use. > > This is basically what we've been proposing for ecore_lists except for > the non-modify requirement. What reason do you have for not allowing > any modifications through the iterators? Not a real reason, mostly due simplicity of implementation. If you want to make them modifications-proof, then just keep callbacks between created iterators and when you request some change you walk these and reset their internal pointers. It's a bit more complicated, but safer, yes. When doing such central things I often like to avoid over-engineering the common case, that is walking the objects without modifications, but trying to provide easy ways to do the others so users don't do mistakes. I think that linux kernel (include/linux/list.h) is a good example of that, it's low-overhead, well documented and safe to use. They provide list_for_each() and list_for_each_safe() (and similar) macros. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -------------------------------------- MSN: [EMAIL PROTECTED] Skype: gsbarbieri Mobile: +55 (19) 9225-2202 ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
