* André Gillibert <metaentr...@gmail.com> schrieb: > This adds some level of indirection to access the data bytes, and some > space overhead. > For example, the string "hello" is 6 bytes long (including the zero > terminator), with GLIBC's malloc, it may occupy 8 bytes (or maybe 16 > bytes). > With your implementation, it would occupy twice as much memory.
No. With my approach, strings aren't a single bit longer. References to them require one more byte. (well, maybe more due padding). On certain platforms/architectures (eg. 64bit), we maybe even could put that single bit directly into the pointer (using the MSB if we can be sure the upper half is never used). > Moreover, the binary code using strings would be larger of a few bytes too. No. Plain access is not is not a single bit larger, ist just an offset. My string reference looks like this: typedef struct { gchar* str; unsigned char flags; } > And so, once g_strdup() has been called, a new dynamic string is > created. Consequently, very few strings would be static. g_strdup() wont be called (directly) very often. Code that is operating on my GCStry wont use that function, unless it really wants a physical copy (eg. as buffer, etc)m instead if uses G_CSTRY_COPY() which only copies non-static strings. > Storing the string as an array of bytes. The first byte of the array > would be the "static" bit, and the rest would be the string data. Yep, also a good idea. Makes the required stack space smaller than my approach. Perhaps could also be extended to do reference counting. But: I'm currently lacking sufficient coffeine level to type down a typedef+macro that a) makes writing string literals easy and b) make it compile-type typesafe. Perhaps something like: typedef { unsigned char flags; unsigned char str[1]; } GCStr; #define G_CSTR_LITERAL(s) ("\1" s) cu -- ---------------------------------------------------------------------- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weig...@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 ---------------------------------------------------------------------- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme ---------------------------------------------------------------------- _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list