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
