On Sun, 09 Sep 2007 02:37:18 +0200, Pierre Habouzit wrote: > On Sat, Sep 08, 2007 at 11:50:34PM +0000, Andreas Ericsson wrote: >> But this introduces handy but, strictly speaking, unnecessary overhead >> as well, meaning, in short; 'D is slower than C, but easier to write >> code in'. > > That's BS. See the strbuf API I've been pushing recently ? It has > simplified git's code a lot, because each time git had to deal with a > growing string, it had to deal with at least three variables: the buffer > pointer, the current occupied length, and its allocated size. That was > three thing to have variable names for, and to pass to functions. > > Now instead, it's just one struct. D gives that gratis. There is no > performance loss because you _need_ to do the same. How do you deal with > dynamic arrays if you dont't store their lenght and size somewhere ? Some string APIs don't store the size, some include the bytes in the "struct" itself using the struct hack, in C. For instance ustr uses 3 bytes more than strdup(), by default, for "small" strings[1] -- which includes a size, length, reference counting and a "memory failure occured" error. On the other extreme, C++ strings or Vstr take up much more than 12/24[2] bytes (because they are designed to be used differently) and strbuf itself takes up 16/20[2] bytes. Note that I'm not saying you shouldn't use a decent string API, quite the opposite, but assuming that "whatever is embedded in the language" is good enough for all purposes is far from reality. [1] 1-255 bytes is "small", for obvious reasons you need one more byte after that (note that "", 0 byte strings, don't take any bytes to store with ustr). [2] 32bit/64bit sizes -- James Antill -- james@xxxxxxx C String APIs use too much memory? ustr: length, ref count, size and read-only/fixed. Ave. 44% overhead over strdup(), for 0-20B strings http://www.and.org/ustr/ - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
