On Tuesday, 13 March 2007, at 01:53:57 (+0100), Peter Wehrfritz wrote: > Thanks committed. It is indeed much faster. I changed it slightly, > because your version had some problems with empty strings.
I intentionally left out the sanity checks at the beginning so I could test it without having too much macro overhead in the way. :) And I never really thought about how an empty delim string should be handled; your choice seems logical. On Tuesday, 13 March 2007, at 09:26:08 (+0100), St?phane Bauland wrote: > 1) Why ecore_str_vector_free was removed ? It's unnecessary. > 2) Do you think 2/3 optionals string's functions could be good to have > in ecore ? > - ecore_str_strdup_printf(format, ...) > - ecore_str_memcpy(void *, size) No. Completely unnecessary. > Hehe ! I got a memory leak here : > > ligne 165 (ecore_str.c) : s = strdup(str); > > looks like it isn't freed. Did you not read the code? or at least my mailing list message? "And as a bonus, you only have to free the array pointer and its first element." Thank you for dining at the Clueburger; please drive through. > Ok ok i solve memory leak... I don't know if it's a correct way to > remove it but apparently it's ok. No, this is completely wrong and demonstrates no understanding whatsoever of the underlying code. Ridiculous. On Tuesday, 13 March 2007, at 10:59:21 (+0100), Sebastian Dransfeld wrote: > Wrong fix! The user must free ret[0] && ret. No other > possibility. The question is whether this function should do a > destructive split or not. I take it you missed the "s = strdup(str)" at the beginning.... Did ANYBODY actually bother to see how the code works besides Peter? On Tuesday, 13 March 2007, at 11:38:27 (+0100), Vincent Torri wrote: > yes, you're right. I based my comment on what mej said. You misunderstood what mej said. See above. > Why not only returning &str, instread of str_array, which is > allocated for nothing, imho ? YHO is wrong. :) str_array holds the pointers to the tokens just like before. The difference is that I save a crapload of unnecessary malloc()/memcpy() calls by reusing memory I've already allocated. Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ <[EMAIL PROTECTED]> n + 1, Inc., http://www.nplus1.net/ Author, Eterm (www.eterm.org) ----------------------------------------------------------------------- "Windows 95: 32 bit extensions and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition." -- Unknown ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
