Sorry about the delay on this Dylan, but it's in CVS now. You are
correct about the limitations in the ecore_list's. I have been
planning to add handle's to the lists for a while, but it has not been
a high priority. I think this could be done by splitting the current
list into two structures, a list structure and a handle structure. The
handle structure would contain the current pointer, the current index,
and a reference back to the main list structure. I also would like to
remove the separate list and dlist and just make the list a doubly
linked list. This would allow us to maintain the current API, but
provide expanded features for implementations that require multiple
references inside a list.
On 4/24/05, Dylan Shell <[EMAIL PROTECTED]> wrote:
> I've been messing w/ the Ecore Lists. I've found a simple example of a minor
> inconsistency between Ecore_DList and Ecore_List when they ought to
> behave similarly. (I've got an explanation of the changes in addition to
> the patch because last time I sent a patch, it was immediately trumped
> with a better idea...)
>
> Take the ecore/examples/list_example.c
> change line 23 from:
> ecore_list_goto_index(list, 2);
> to:
> ecore_list_goto_index(list, 1);
>
> Compile and run, and you'll get the following output:
> --- Current List ---
> first
> second
> last
>
>
> Now, go through the source, replace every "Ecore_List" with "Ecore_DList" and
> every "ecore_list_" with "ecore_dlist_"
>
> Compile and run again, you get:
> --- Current List ---
> first
> last
> second
>
> I hunted around a bit to find the bug: the implemention of
> ecore_dlist_goto_index has a slight issue when called with a list in which
> list->current == NULL.
>
> In the case of singly-linked list, there is a _ecore_list_goto_first which
> obviously sets list->current.
>
> But, it seems to me that list->index shouldn't ever be set to something
> without
> the list->current pointing to that (except when the list is empty and
> list->index == 0, or the list has items and list->index == x where x >
> list->nodes-1). If you agree, then it looks like _ecore_list_append_0(...)
> should set the list->current = end, around line 370 (ecore_list.c)
>
> Line 1326 should be:
> if (.... || index < 0)
> Because an index == 0 is perfectly acceptable (as it is fine for
> list_goto_index)
>
> Also Line 1329 should read:
> if (ECORE_LIST(list)->index >= ECORE_LIST(list)->nodes)
>
> Because if list->index == list->nodes, and list->current == NULL, and then
> searching
> backward fails.
>
>
> While on the topic of the ecore_list and ecore_dlist, I do feel that the
> implementation is somewhat inadequate because there is no way to store an
> pointer (or some contextual information) so that a particular element can be
> returned to in \Theta(1) time. The "current index" stored within the list
> provides only one such contextual pointer, but the user will generaly need an
> unlimited number of them. The evas_list does far better in this regard,
> maintaining numbered indicies makes this difficult for ecore_lists...
> is there a reason why the ecore_lists use indicies?
>
> Dylan.
>
> Index: ecore_list.c
> ===================================================================
> RCS file: /cvsroot/enlightenment/e17/libs/ecore/src/lib/ecore/ecore_list.c,v
> retrieving revision 1.13
> diff -u -r1.13 ecore_list.c
> --- ecore_list.c 4 Jan 2005 22:45:05 -0000 1.13
> +++ ecore_list.c 25 Apr 2005 01:36:30 -0000
> @@ -369,6 +369,7 @@
> if (list->first == NULL) {
> list->first = end;
> list->index = 0;
> + list->current = end;
> }
>
> list->nodes++;
> @@ -1322,10 +1323,10 @@
> if (ecore_list_is_empty(ECORE_LIST(list)))
> return FALSE;
>
> - if (index > ecore_list_nodes(ECORE_LIST(list)) || index < 1)
> + if (index > ecore_list_nodes(ECORE_LIST(list)) || index < 0)
> return FALSE;
>
> - if (ECORE_LIST(list)->index > ECORE_LIST(list)->nodes)
> + if (ECORE_LIST(list)->index >= ECORE_LIST(list)->nodes)
> _ecore_list_goto_last(ECORE_LIST(list));
>
> if (index < ECORE_LIST(list)->index)
>
>
>
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Tell us your software development plans!
> Take this survey and enter to win a one-year sub to SourceForge.net
> Plus IDC's 2005 look-ahead and a copy of this survey
> Click here to start! http://www.idcswdc.com/cgi-bin/survey?id=105hix
> _______________________________________________
> enlightenment-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click
_______________________________________________
enlightenment-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
