Michael Jennings wrote: > 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 > > Hi Michael, i didnt read the doxy changements. But no it's ok. It's faster and it allocates less memory as before!
good job! thanks too :) ------------------------------------------------------------------------- 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