Re: glib uses wrong prefix for base-2 units
On Wed, 03 Jun 2009 16:07:37 -0700 Brian J. Tarricone bj...@cornell.edu wrote: * It would avoid ambiguity and consumer confusion: http://en.wikipedia.org/wiki/Binary_prefix#Consumer_confusion Arguably, using KiB etc. in the user interface could confuse the user just as much. I make the same argument here as I made last time: I'd rather the idiots presume I can't spell, then the experts presume I can't count. In other words, pandering to the uninformed is no way to educate them and fix the situation. Yes; we messed up 30 years ago and said k when we meant Ki. Oops. Sorry about that. Lets not do it wrong for another 30, please? -- Paul LeoNerd Evans leon...@leonerd.org.uk ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: PGP signature ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Review of gnio, round 1
On Sun, 10 May 2009 17:29:48 +0300 Stefan Kost enso...@hora-obscura.de wrote: Alexander Larsson schrieb: With gnome 2.26 out and the GResolver branch landed it is time to start look at merging the gnio network code into gio. I'm posting this here, plus CC:ing the involved people instead of on bugzilla in order to get feedback from others who may be interested but unaware of this work. Its a bit late - Is there an object called GResolver? If so could that be named GNameResolver or something simillar - or would it be GNIOResolver?. I feel GResolver sounds too generic. Speaking of GResolver, in the API (which I'm currently staring at here: http://git.gnome.org/cgit/glib/diff/gio/gresolver.h?h=gresolverid=05507dce1f540581028e8be0e220e68c44fade2f ) I don't see any attempt at the gai()-style hostname + servicename resolver. Where's the ability to connect to, say, www.google.com:http? Half the point of gai+gni was to unify the separate operations of hostname-IP and servicename-port, so they're in one combined place. gai() can therefore support things like SRV records, which the previous pair of gethostbyname+getservbyname cannot. Unless perhaps I'm looking at the wrong part, or there's a more up-to-date version somewhere? -- Paul LeoNerd Evans leon...@leonerd.org.uk ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: PGP signature ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Review of gnio, round 1
On Tue, May 12, 2009 at 09:41:53AM -0400, Dan Winship wrote: On 05/12/2009 05:22 AM, Paul LeoNerd Evans wrote: Speaking of GResolver, in the API (which I'm currently staring at here: http://git.gnome.org/cgit/glib/diff/gio/gresolver.h?h=gresolverid=05507dce1f540581028e8be0e220e68c44fade2f ) I don't see any attempt at the gai()-style hostname + servicename resolver. Where's the ability to connect to, say, www.google.com:http? Half the point of gai+gni was to unify the separate operations of hostname-IP and servicename-port, so they're in one combined place. gai() can therefore support things like SRV records, which the previous pair of gethostbyname+getservbyname cannot. You're mixing up two very different things. getaddrinfo *does not* use SRV records. When you pass a (non-numeric) string to getaddrinfo for service, it just looks that string up in /etc/services to translate it to a port number, and returns that port number (regardless of whether or not that service is really running on the host). Ah; I wasn't quite clear enough in my statement. I didn't mean that e.g. GNU libc's _implementation_ of getaddrinfo() currently today actually does a SRV lookup, merely the RFC 2553 _interface_ which defines getaddrinfo() has to hand all the information that such a lookup would require, so an implementation can, in theory, do it. GResolver intentionally does not support doing the servicename-port mapping thing that getaddrinfo/getsrvbyname does though, because it's a bad API; you can't know for sure what's going to be in /etc/services on any given machine, and in particular, if you're using some very new protocol, it's very likely that some people are going to try to run your application on machines that don't have that protocol listed in /etc/services. So it's always better to just provide your own #define FOOBAR_PORT with the right port number, and then use that, rather than crossing your fingers and hoping that GResolver will be able to map foobar to the right number for you. Hmm.. I guess that's fair enough then I suppose; though surely that's not a reason not to provide the _ability_ to do so, simply a discouragement for applications developers to try to actually make use of it, in this manner..? -- Paul LeoNerd Evans leon...@leonerd.org.uk ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: Digital signature ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: g_malloc overhead
On Sun, 18 Jan 2009 17:43:57 +0100 Martín Vales mar...@opengeomap.org wrote: Other overhead i see is the open dir/file funtions, where in windows we need do the utf8 to utf16 everytime in windows. If JAVA,.NET and Qt use utf16 by default why in gnome world we use utf8 by default?. Probably one of the biggest reasons, is that UTF-8 does not use \0 octets, whereas UTF-16 does. This means that UTF-8 data can transparently pass through all of the usual str*() functions in C, such as strlen(), strcpy(), etc... -- Paul LeoNerd Evans leon...@leonerd.org.uk ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: g_malloc overhead
On Sun, 18 Jan 2009 17:43:57 +0100 Martín Vales mar...@opengeomap.org wrote: Other overhead i see is the open dir/file funtions, where in windows we need do the utf8 to utf16 everytime in windows. If JAVA,.NET and Qt use utf16 by default why in gnome world we use utf8 by default?. Probably one of the biggest reasons, is that UTF-8 does not use \0 octets, whereas UTF-16 does. This means that UTF-8 data can transparently pass through all of the usual str*() functions in C, such as strlen(), strcpy(), etc... -- Paul LeoNerd Evans leon...@leonerd.org.uk ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: PGP signature ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Bikeshedding the invisible-char
On Mon, 19 Jan 2009 20:07:09 -0600 Federico Mena Quintero feder...@novell.com wrote: I'm arguing for committing openSUSE's patch based on the following unquestionable criteria: Do you have any numbers on the glyph coverage of these two characters in a variety of common fonts? Are either of them glaringly missing anywhere? -- Paul LeoNerd Evans leon...@leonerd.org.uk ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: PGP signature ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: g_malloc overhead
On Mon, Jan 26, 2009 at 12:57:28PM -0500, Owen Taylor wrote:
On Mon, 2009-01-26 at 18:30 +0100, Martín Vales wrote:
Yes, i only talked about the overhead with utf8 outside of glib, only that.
Perhaps the only solution is add more suport to utf16 in glib with more
methods.
There's zero point in talking about a solution until you have profile
data indicating that there is a problem.
Indeed. UTF-16 is horribly broken by design, and any attempt made to
migrate in the direction _towards_ it is a flawed one, and should be
avoided.
UTF-8 is backward-compatible with the legacy str*() functions in C,
which, like it or not, will be around for a while yet.
* It makes sure not to embed any ASCII NUL ('\0') in the stream unless
it means it, as U+, which makes it work with these functions.
* UTF-8 has nice properties in substring matches - grep can work on
UTF-8 despite not knowing it, because no valid UTF-8 string ever appears
falsely as a substring of another.
* This also means that the only occurance of '\n' in a UTF-8 stream is
a real one. This means that cat, head/tail, awk, etc... can properly
detect where the linefeeds are. 'head' can print, say, the first 3
lines of UTF-8 text without knowing it's UTF-8.
* UTF-8 can be sorted by only sorting the encoded bytes. sort can sort
a UTF-8-encoded text file. The order of the Unicode strings, is the
same as the bytewise-sorted order of the raw bytes that encode it.
This list goes on.
Meanwhile, on the other end of the spectrum, storing Unicode data as
decoded 32bit integers makes some sense. It means string indexing
operations are constant-width - the substring between the 4th and 9th
characters in such an array will be known to lie between the 16th and
36th bytes. The presence of combining characters, and double-width
glyphs does make this transformation a bit harder, effectively reducing
the advantage such a scheme has.
Compared to that, UTF-16 offers NONE of these advantages. UTF-16 cannot
be passed through any legacy str*() function, nor will it work in grep,
sed, awk, cut, sort, head, tail, or in fact _any_ of the standard UNIX
text tools. Nor can UTF-16 be array indexed in constant time, because of
the surrogate pairs used to encode codepoints outside of the BMP (Basic
Multilingual Plane).
In Summary - UTF-16. Don't. Just Don't.
--
Paul LeoNerd Evans
leon...@leonerd.org.uk
ICQ# 4135350 | Registered Linux# 179460
http://www.leonerd.org.uk/
signature.asc
Description: Digital signature
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Lacking of a ref-counted string.
On Sat, 23 Aug 2008 09:58:12 -0400
Havoc Pennington [EMAIL PROTECTED] wrote:
If you're talking about converting existing APIs to refcounted
strings, that's a very different proposal from just adding some kind
of refcounted string feature. It would break thousands of apps, or
else duplicate hundreds of API entry points ...
Personally, I didn't have in mind a change of existing API; simply an
addition of something new:
typedef struct {
gchar *str;
gsize len;
gint refcount;
} GCString;
GCString *g_cstring_new_static(gchar *data);
GCString *g_cstring_new_from_gstring(GString *clone);
GCString *g_cstring_ref(GCString *str);
void g_cstring_unref(GCstring *str);
should be sufficient for immutable strings. copy-on-write mutable ones
would probably want allocated length in the struct too, and add something
like
GCString *g_cstring_dup(GCString *clone);
which can then sit in the beginning of the modifier functions, looking
something like
GCstring *g_cstring_append(GCstring *s, gchar *data)
{
if(s-refcount 1)
s = g_cstring_dup(s);
/* now modify s */
return s;
}
From my experience using GString I'd find the following macro useful;
#define GCSTR(s) (s?s-str:NULL)
Then you can
printf(Hello, my name is %s\n, GCSTR(s));
a little safer.
Or note that C requires the address of a struct must be the address of
its first member; so a simple cast is sufficient
printf(Hello, my name is %s\n, (gchar*)s);
--
Paul LeoNerd Evans
[EMAIL PROTECTED]
ICQ# 4135350 | Registered Linux# 179460
http://www.leonerd.org.uk/
signature.asc
Description: PGP signature
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Lacking of a ref-counted string.
On Wed, 20 Aug 2008 21:07:39 -0400 Havoc Pennington [EMAIL PROTECTED] wrote: If we think of GLib features as either for C, or for language bindings in general, or for vala, this particular feature seems like it would be *only* for vala - refcounted strings would be pretty strange in plain C, and just overhead for other language bindings that already have native string types they have to convert gchar* to. I personally have quite often wanted refcounted GStrings in normal programs that I've written; i.e. entirely unrelated to VALA. -- Paul LeoNerd Evans [EMAIL PROTECTED] ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: PGP signature ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK 3.0: an app developer's view
On Tue, 17 Jun 2008 10:05:28 +0100 Martyn Russell [EMAIL PROTECTED] wrote: Glade has been doing this for years. It is much quicker for an application developer to use Glade to define menus, windows, dialogs, etc than it is to code then *statically*. I say statically because you don't need to recompile your program to change some slight detail of the menu layout or labelling. This bears a huge advantage as far as I am concerned. It's a trend everyone has been making for years, and I very much support it. 20 years ago, everyone was hand-coding assembly routines. 10 years ago, C was king. Today, more and more behaviour is moving into higher level constructs, softcode, bytecode interpreters, etc.. This is a good thing. CPUs get faster all the time. Memory and hard disks get bigger and cheaper all the time. Programmers only ever get more expensive. Engineering is always about tradeoffs between resources. The resources we have are both computer, and programmer. Because the former keeps getting faster and cheaper, it makes sense every so often to have a shift of ideas, a great move where we decide the computer is good enough to take on what we now decide is the boring menial tasks we as programmers can't be bothered to do. 30 years ago, everyone hand-picked their registers for individual assembly statements. Nowadays, I bet most programmers couldn't even identify the register-colouring algorithm in their compiler; it's something that's just done for them. Who's to say what, in 20 or 30 years time, compilers and other programmer tools will be doing for us. I suspect very strongly that building UIs automatically around some description of the task to be solved, will fall under their remit. -- Paul LeoNerd Evans [EMAIL PROTECTED] ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GTK 3.0: an app developer's view
On Tue, 17 Jun 2008 10:05:28 +0100 Martyn Russell [EMAIL PROTECTED] wrote: Glade has been doing this for years. It is much quicker for an application developer to use Glade to define menus, windows, dialogs, etc than it is to code then *statically*. I say statically because you don't need to recompile your program to change some slight detail of the menu layout or labelling. This bears a huge advantage as far as I am concerned. It's a trend everyone has been making for years, and I very much support it. 20 years ago, everyone was hand-coding assembly routines. 10 years ago, C was king. Today, more and more behaviour is moving into higher level constructs, softcode, bytecode interpreters, etc.. This is a good thing. CPUs get faster all the time. Memory and hard disks get bigger and cheaper all the time. Programmers only ever get more expensive. Engineering is always about tradeoffs between resources. The resources we have are both computer, and programmer. Because the former keeps getting faster and cheaper, it makes sense every so often to have a shift of ideas, a great move where we decide the computer is good enough to take on what we now decide is the boring menial tasks we as programmers can't be bothered to do. 30 years ago, everyone hand-picked their registers for individual assembly statements. Nowadays, I bet most programmers couldn't even identify the register-colouring algorithm in their compiler; it's something that's just done for them. Who's to say what, in 20 or 30 years time, compilers and other programmer tools will be doing for us. I suspect very strongly that building UIs automatically around some description of the task to be solved, will fall under their remit. -- Paul LeoNerd Evans [EMAIL PROTECTED] ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: PGP signature ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Smooooth scrolling gtk
On Thu, Mar 27, 2008 at 09:38:37AM +0100, Xavier Bestel wrote: A very long time ago (over half a decade actually!) Søren Sandmann posted a patch[1] that added smooth scrolling to gtk. For some reason that patch was never integrated in mainline, but at least Gentoo patched their gtk with it. +1 Aren't there noises afoot for a more generic animated UIs framework coming to GTK? ((A certain amount of Apple fanboyism I suspect ;) )) In any case, if such a framework does appear, surely a smooth scroll will fall out of it as a natural consequence, and doesn't need consideration separately? -- Paul LeoNerd Evans [EMAIL PROTECTED] ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: Digital signature ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: g_format_file_size_for_display()
On Tue, 18 Dec 2007 23:01:22 +0100 Sven Neumann [EMAIL PROTECTED] wrote: We should also decide then whether the displayed size should use MB or MiB, see http://en.wikipedia.org/wiki/Mebibyte and http://www.iec.ch/zone/si/si_bytes.htm I for one would like to vote in favour of the kiB/MiB/etc.. scheme for powers-of-2, reserving kB/MB/etc.. strictly for powers-of-10. Trying to cuddle users by protecting them from the confusing MiB unit will only lead to even more confusion about 1000 vs 1024. Better to be consistent eveywhere, even if it means sometimes people have to learn what ki means. -- Paul LeoNerd Evans [EMAIL PROTECTED] ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: PGP signature ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: g_format_file_size_for_display()
On Tue, 18 Dec 2007 22:13:56 + Paul LeoNerd Evans [EMAIL PROTECTED] wrote: I for one would like to vote in favour of the kiB/MiB/etc.. scheme for Oops. Apparently it's KiB (capital 'K') to mean 2^10. How's that for consistency? :) -- Paul LeoNerd Evans [EMAIL PROTECTED] ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: PGP signature ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Static compose table in gtkimcontextsimple.c
On Tue, 4 Dec 2007 08:31:30 +0200 Tor Lillqvist [EMAIL PROTECTED] wrote: The sequences you list are exactly of the straightforward kind that in my opinion can and should be handled algorithmically. I.e. a dead accent followed by a letter can be mapped to the corresponding precomposed character without an explicit table. Really..? Last time I checked, the precomposed letters weren't in any particularly easy-to-find locations; I looked them up by typing them in xterm and seeing what unicode sequences were generated. I have a patch in bug #321896 that implements such an algorithm (and which would handle your cases, too.) Basically it's waiting for a second opinion from the GTK+ maintainers. Perhaps we could subtly poke them here then to remind them? :) -- Paul LeoNerd Evans [EMAIL PROTECTED] ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: PGP signature ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Static compose table in gtkimcontextsimple.c
On Tue, 04 Dec 2007 05:38:56 + Simos Xenitellis [EMAIL PROTECTED] wrote: If you would like to help with bug 321896 it would be great. The current state is on how to make the table much smaller, even with the addition of more keysyms. There is a script that converts en_US.UTF-8/Compose into a series of arrays that should be easy for GTK+ to work on. OK, I've had a good read through that bug, and now I'm confused again. Can someone explain why GTK has to have this large table compiled into it..? I thought X itself provided ways to perform input composition into Unicode strings. Otherwise, why do I have a file /usr/share/X11/locale/en_US.UTF-8/Compose Can we just use that? -- Paul LeoNerd Evans [EMAIL PROTECTED] ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: PGP signature ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Static compose table in gtkimcontextsimple.c
On Thu, 06 Dec 2007 12:12:39 -0500 Owen Taylor [EMAIL PROTECTED] wrote: Note also that loading /usr/share/X11/locale/en_US.UTF-8/Compose That's not quite what I meant. What I meant was, I thought that the X11 server did some of this work for us? So can we not ask it to do that? Or have I misunderstood how it works, and that this is really a clientside thing done by Xlib? -- Paul LeoNerd Evans [EMAIL PROTECTED] ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: PGP signature ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Static compose table in gtkimcontextsimple.c
I notice there's a large table of compose sequences in gtkimcontextsimple.c. Is there any particular logic to the exact sequences listed here, or would it be acceptable to add some more? I'd quite like to have some mappings of Esperanto characters added; namely: GDK_dead_circumflex, GDK_C, 0, 0, 0, 0x0108, /* LATIN_CAPITAL_LETTER_C_WITH_CIRCUMFLEX */ GDK_dead_circumflex, GDK_G, 0, 0, 0, 0x011D, /* LATIN_CAPITAL_LETTER_G_WITH_CIRCUMFLEX */ GDK_dead_circumflex, GDK_H, 0, 0, 0, 0x0124, /* LATIN_CAPITAL_LETTER_H_WITH_CIRCUMFLEX */ GDK_dead_circumflex, GDK_J, 0, 0, 0, 0x0134, /* LATIN_CAPITAL_LETTER_J_WITH_CIRCUMFLEX */ GDK_dead_circumflex, GDK_S, 0, 0, 0, 0x015C, /* LATIN_CAPITAL_LETTER_S_WITH_CIRCUMFLEX */ GDK_dead_circumflex, GDK_c, 0, 0, 0, 0x0109, /* LATIN_SMALL_LETTER_C_WITH_CIRCUMFLEX */ GDK_dead_circumflex, GDK_g, 0, 0, 0, 0x011D, /* LATIN_SMALL_LETTER_G_WITH_CIRCUMFLEX */ GDK_dead_circumflex, GDK_h, 0, 0, 0, 0x0125, /* LATIN_SMALL_LETTER_H_WITH_CIRCUMFLEX */ GDK_dead_circumflex, GDK_j, 0, 0, 0, 0x0135, /* LATIN_SMALL_LETTER_J_WITH_CIRCUMFLEX */ GDK_dead_circumflex, GDK_s, 0, 0, 0, 0x015D, /* LATIN_SMALL_LETTER_S_WITH_CIRCUMFLEX */ GDK_dead_caron, GDK_U, 0, 0, 0, 0x01D3, /* LATIN_CAPITAL_LETTER_U_WITH_CARON */ GDK_dead_caron, GDK_u, 0, 0, 0, 0x01D4, /* LATIN_SMALL_LETTER_U_WITH_CARON */ Should I submit a patch? -- Paul LeoNerd Evans [EMAIL PROTECTED] ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: Digital signature ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Concept behind GtkTreeView
On Tue, 7 Aug 2007 15:22:09 +0530 Prasanna Kumar K [EMAIL PROTECTED] wrote: Hi, Can anyone please explain what is the relation between GtkTreeView - GtkTreeStore - GtkTreeModel. Because they're the newer MVC design http://en.wikipedia.org/wiki/Model-view-controller and why GtkTree, GtkCTree, GtkList, GtkCList are deprecated.. Because, by comparison, they're not. HTH, -- Paul LeoNerd Evans [EMAIL PROTECTED] ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: PGP signature ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Extra GString functions
A while ago I submitted some patches to add some extra GString functions: +GString* g_string_clone (const GString *orig); +GString* g_string_new_printf(const gchar *format, + ...) G_GNUC_PRINTF (1, 2); +GString* g_string_new_vprintf (const gchar *format, + va_list args); +void g_string_vprintf (GString *string, + const gchar *format, + va_list args); +void g_string_append_vprintf(GString *string, + const gchar *format, + va_list args); +GString* g_string_slice (GString *string, + guintpos, + guintlen); I haven't heard any feedback at all on these, good or bad. I note they're not in the latest CVS. Can I ask if anyone has any comments on these functions? I consider them useful - I use them all the time in my own code. Furthermore, at least the vsprintf() functions are required to wrap certain things in was that cannot be done with the non-vargs versions. If there are no objections, I would like to see these merged in to the main code. I consider one main advantage of open-source projects being that improvements can be made by 3rd parties - this is one such case. Comments, anyone? -- Paul LeoNerd Evans [EMAIL PROTECTED] ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: PGP signature ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: using literal zero for NULL
On Mon, Mar 20, 2006 at 11:53:35PM -0800, mikecorn wrote: I just tried rebuilding my GTK apps for a 64 bit Linux system (Fedora core 5), and had an ugly surprise: random segmentation faults. I traced at least one of them to my lazy habit of using a literal zero in place of NULL for an optional function argument or end-of-arg-list indicator. I speculate that the compiler is supplying a 32 bit zero where a 64 bit zero is needed. Correct? If so, it seems this is a compiler bug, since the type conversion should be automatic. Can someone confirm this? Sounds about right. I hit this issue a lot trying to build tla on AMD64. I find, as well as keeping the compiler happy, using the right named constants is good for readability. Consider the following three lines: foo(FALSE); bar(0); baz(NULL); Their argument might compile to the same value each time; but to the reader, each gives a different impression as to its meaning. The first is a boolean negative value; you might expect to see foo(TRUE) somewhere else. The second is the numerical concept of zero; you might expect to see a different number elsewhere, e.g. bar(10). The third is a pointer which currently points at nothing but might some other times point at some valid object. I've never worked out why anybody needs to type 0 when they could type NULL. Given all the random segfaults, and type errors, and readability concerns and whatnot, are your fingers _really_ that lazy? -- Paul LeoNerd Evans [EMAIL PROTECTED] ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: Digital signature ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Typedef inconsistency for gsize and gssize
On Thu, 9 Feb 2006 10:23:06 -0500 (EST) [EMAIL PROTECTED] (Morten Welinder) wrote: But, yes, glib uses non-standard C in lots of ways, this just being one of them. That said, so does POSIX. E.g. C99 does not require that a void* can hold a function pointer, but POSIX does. -- Paul LeoNerd Evans [EMAIL PROTECTED] ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Why no g_string_append_vprintf() ?
On Wed, Dec 21, 2005 at 10:28:50AM -0800, Alan M. Evans wrote:
http://bugzilla.gnome.org/show_bug.cgi?id=164446
A patch was already submitted in January. Still UNCONFIRMED.
Yes, I've had a look at that patch. It's not very efficient; it
allocates a new string buffer big enough to hold the string, then fills
it, then strdup()s it into the GString, then frees the first buffer.
That's unnecessary.
My method is:
void g_string_append_vprintf(GString *str, const gchar *fmt, va_list args)
{
gsize len = g_printf_string_upper_bound(fmt, args) + 1;
g_string_maybe_expand(str, len);
g_vsnprintf(str-str + str-len, len, fmt, args);
str-len += len;
}
This doesn't double-allocate the buffer and then incur an unnecessary
strcpy().
We can then trivially wrap
void g_string_vprintf(GString *str, const gchar* fmt, va_list args)
{
g_string_truncate(str, 0);
g_string_append_vprintf(str, fmt, args);
}
Finally this would allow another function I added, because I noticed I
keep doing:
GString *str = g_string_new(NULL);
g_string_append_printf(str, fmt, ...);
return str;
Instead, we just
return g_string_new_printf(fmt, ...);
Any thoughts on these? Should I submit a patch containing that lot?
--
Paul LeoNerd Evans
[EMAIL PROTECTED]
ICQ# 4135350 | Registered Linux# 179460
http://www.leonerd.org.uk/
signature.asc
Description: Digital signature
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Why no g_string_append_vprintf() ?
On Wed, Dec 21, 2005 at 10:58:44PM +, Paul LeoNerd Evans wrote:
Yes, I've had a look at that patch. It's not very efficient; it
allocates a new string buffer big enough to hold the string, then fills
it, then strdup()s it into the GString, then frees the first buffer.
That's unnecessary.
My method is:
void g_string_append_vprintf(GString *str, const gchar *fmt, va_list args)
{
gsize len = g_printf_string_upper_bound(fmt, args) + 1;
g_string_maybe_expand(str, len);
g_vsnprintf(str-str + str-len, len, fmt, args);
str-len += len;
}
This doesn't double-allocate the buffer and then incur an unnecessary
strcpy().
Well, I've done some benchmarking in this, and acutally I'd like to
retract that statement.
My method is slightly faster in a few trivial cases, for example a
format with no conversions, or just %s, by somewhere around 5%. But,
this comes at the cost of being quite a bit slower (sometimes 50%) if
the format is more complex (I tried %s%d%s for example). I suspect
this might be because of the extra processing at having to scan the
format string and arguments list twice, count up the lengths of string
arguments passed in, that sort of thing. This only happens once in the
function in its original form.
In short; I'll leave it as it is. :)
--
Paul LeoNerd Evans
[EMAIL PROTECTED]
ICQ# 4135350 | Registered Linux# 179460
http://www.leonerd.org.uk/
signature.asc
Description: Digital signature
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Some new GString functions - constructors
On Tue, Dec 20, 2005 at 07:09:35PM -0500, Owen Taylor wrote: Isn't a lot of code; if it was a common operation, then sure I'd get annoyed writing it over and over again. But unless you are using GString as your string type (which I think is wrong), it strikes me as quite rare. Yes; that's fair enough. I mentioned all the functions I created in my code, just to see what the general thoughts from the list were. I did specifically remark that the split functions in particular would be a point of discussion. I'm quite prepared to accept that they don't really belong in GLib. -- Paul LeoNerd Evans [EMAIL PROTECTED] ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: Digital signature ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Contributing a GLib patch / CVS?
I've been developing a program over the last 2 years that quite heavily uses GStrings for lots of its work. As a result, I've collected up a useful set of extra functions I think GLib would benefit from. My plan was to submit a number of patches, with groups of related functions added in each patch. It's typical to check out latest CVS source for a project when submitting such a patch. I am however, having difficulty finding a CVS source for GLib. There's no mention on either the www.gnome.org or www.gtk.org sites about it. What is the accepted submission method for this? Do you work to some CVS source, or should I just download latest stable tarball, and submit a patch based off that? -- Paul LeoNerd Evans [EMAIL PROTECTED] ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: Digital signature ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Contributing a GLib patch / CVS?
On Tue, Dec 20, 2005 at 02:47:32PM -0500, Tristan Van Berkom wrote: CVSROOT=:pserver:[EMAIL PROTECTED]:/cvs/gnome cvs co glib Ahh wonderful. And thanks for the speedy reply - most helpful. I now have a checkout; I'm presuming a standard ./autogen.sh ; make procedure here. Any special configure options that would be recommended in this case? Or would the defaults, whatever they are, be suitable for building a test library for these additions? -- Paul LeoNerd Evans [EMAIL PROTECTED] ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: Digital signature ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Why no g_string_append_vprintf() ?
GLib defines a function to append data in a GString using a printf-like call, void g_string_append_printf(GString *str, const gchar *fmt, ...); Is there any reason why a va_list-version isn't provided as well for this? Without that, it is impossible to further wrap va-list or ...-style functions which would call this one. If there is no overriding reason why not, I'd like to start my patches with one that exports this. -- Paul LeoNerd Evans [EMAIL PROTECTED] ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: Digital signature ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Some new GString functions - constructors
As promised earlier, here's a patch with some new functions for GString. I'll split them up with related changes, so this is just the first of a sequence. There's 3 functions added here, g_string_clone, g_string_new_lenz, and g_string_slice. Each is a constructor, to return a new GString object. * g_string_clone() is a convenient wrapper to take a copy of an existing GString; g_string_clone(s) == g_string_new(s-str) Except it returns NULL if s == NULL. * g_string_new_lenz() is similar to g_string_new_len(), only it appends a terminating nul byte to the string buffer, making it safe to printf() or use as a normal gchar* string. * g_string_slice() returns a new GString containing just a portion of the given string. I wasn't quite sure how to implement these, in terms of writing new code, or just calling one of the other functions. And also I'm rather new to the documentation system, so I hope I've done those right. Comments / suggestions / corrections would be most appreciated. --- Some other ideas I have planned at least two other patches. The first to add two new constructors that I find quite useful in my code: GString* g_string_new_sprintf(const gchar *fmt, ...); GString* g_string_new_vsprintf(const gchar *fmt, va_list args); These are a little more convenient than the g_string_new() / g_string_sprintf() pair, especially if the contructed string is being return'd from a function. The other has some other useful functions: gboolean g_string_caseequal(GString *s1, GString *s2); gint g_string_indexof(GString *str, gchar c); void g_string_destroy(GString *str); The latter is a function which would simply wrap g_string_free(str, TRUE); but whose type makes it usable as a GDestroyNotify callback. I also have some slightly more special-purpose functions which I find useful, but I'm not sure of their place in such a general-purpose library as GLib. These are: GString* g_string_pull_token(GString *str); // Deletes a token from the beginning of str, and returns it GString* g_string_pull_line(GString *str); // Deletes a line from the beginning of str, and returns it Finally, I have some which I find useful for dealing with lists of strings. A trivial typedef GList GStringList; and some functions GStringList* g_string_split(GString *str, gchar c); GString* g_string_list_fold(GStringList *list, const char *sep); void g_string_list_free(GStringList *list, gboolean free_str, gboolean free_data); I'd be interested to hear opinions on these ideas; especially the later ones. It's quite possible that these are too special-purpose to warrant inclusion in GLib. Though I have found them quite useful in my programs, so I though I'd at least suggest inclusion, and see what the general opinion is. -- Paul LeoNerd Evans [EMAIL PROTECTED] ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ Index: docs/reference/glib/glib-sections.txt === RCS file: /cvs/gnome/glib/docs/reference/glib/glib-sections.txt,v retrieving revision 1.134 diff -u -r1.134 glib-sections.txt --- docs/reference/glib/glib-sections.txt 19 Dec 2005 21:22:29 - 1.134 +++ docs/reference/glib/glib-sections.txt 20 Dec 2005 22:14:52 - @@ -1794,8 +1794,11 @@ FILEstrings/FILE GString g_string_new +g_string_clone g_string_new_len +g_string_new_lenz g_string_sized_new +g_string_slice g_string_assign g_string_sprintf g_string_sprintfa Index: docs/reference/glib/tmpl/strings.sgml === RCS file: /cvs/gnome/glib/docs/reference/glib/tmpl/strings.sgml,v retrieving revision 1.28 diff -u -r1.28 strings.sgml --- docs/reference/glib/tmpl/strings.sgml 20 Dec 2005 04:44:25 - 1.28 +++ docs/reference/glib/tmpl/strings.sgml 20 Dec 2005 22:14:52 - @@ -46,6 +46,15 @@ @Returns: the new #GString. +!-- # FUNCTION g_string_clone # -- +para + +/para + [EMAIL PROTECTED]: [EMAIL PROTECTED]: + + !-- # FUNCTION g_string_new_len # -- para Creates a new #GString with @len bytes of the @init buffer. Because a length is @@ -57,6 +66,16 @@ @Returns: a new #GString. +!-- # FUNCTION g_string_new_lenz # -- +para + +/para + [EMAIL PROTECTED]: [EMAIL PROTECTED]: [EMAIL PROTECTED]: + + !-- # FUNCTION g_string_sized_new # -- para Creates a new #GString, with enough space for @dfl_size bytes. @@ -68,6 +87,17 @@ @Returns: the new #GString. +!-- # FUNCTION g_string_slice # -- +para + +/para + [EMAIL PROTECTED]: [EMAIL PROTECTED]: [EMAIL PROTECTED]: [EMAIL PROTECTED]: + + !-- # FUNCTION g_string_assign # -- para Copies the bytes from a string into a #GString, destroying any previous @@ -91,6 +121,7 @@ /para @Deprecated: This function has been renamed to g_string_printf(). +!-- # Unused Parameters
Re: Some new GString functions - constructors
On Tue, Dec 20, 2005 at 02:43:43PM -0800, Alan M. Evans wrote: GStrings are already guaranteed to have a nul terminating byte, aren't they? Ah; yes, in fact, they are. I had thought they weren't, in the case of calling g_string_new_len(), because I tried it one time and found a bug. I'd just presumed that it wasn't nul-terminated, so went and added the _lenz() constructor instead. On reading the gstring.c file, I note actually yes, this constructor should nul-terminate the string. I guess my _lenz() constructor is rather useless now then. Sorry about that... I guess that means the g_string_slice() constructor could actually be written quite easily by wrapping g_string_new_len() instead. -- Paul LeoNerd Evans [EMAIL PROTECTED] ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: Digital signature ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Some new GString functions - constructors
On Wed, Dec 21, 2005 at 12:00:52AM +0100, Emmanuele Bassi wrote: Can you please open a bug inside http://bugzilla.gnome.org and attach the patch there? Tracking patches on Bugzilla makes things easier than on a mailing list. Shall do. Apart from g_string_new_lenz() which I don't understand, the _clone() and _slice() functions looks intersting. Sorry about that one. See other mail... I'd added _lenz() on account of a misunderstanding of how g_string_new_len() works - I thought it didn't guarantee nul-termination, but it does. I'll resubmit another patch, and add to bugzilla, without that function. gint g_string_indexof(GString *str, gchar c); This would be useful with Unicode support, or with a gunichar variant. Hmm A tricky question. In this simple case of looking for a gchar, it's just scanning for a byte. As soon as we bring in Unicode, the question is asked what encoding is it..? I guess we mean UTF-8 here? Is it accepted that all Unicode strings are UTF-8 encoded? I can have a go at a Unicode-aware _indexof(), sure... but currently I just wrap g_strchr() for that case, so I'd need to know how to handle it in UTF-8. snip Also, a gchar ** g_string_tokenize (GString *str, const gchar *token, gsizelenght); Could be interesting, instead of creating a new StringList type, since, if you want a list of GString, you can always iterate on the returned strings vector. Hmm.. That one seems a little messy to me. GString in, GString out. Or gchar* in, gchar* out. If it takes in a GString*, but returns a gchar**, that's sort of a mix of types. I don't know how anyone else feels about that, but it doesn't quite feel right to me. -- Paul LeoNerd Evans [EMAIL PROTECTED] ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: Digital signature ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Some new GString functions - constructors
On Tue, Dec 20, 2005 at 03:26:45PM -0800, Alan M. Evans wrote:
Not entirely certain I like this. See below.
GStringList* g_string_split(GString *str, gchar c);
Seems to me this should return a gchar** a-la g_strsplit().
I take that back. I can always use g_strsplit() on the GString contents.
On further consideration, I suppose that your GList contains GStrings,
not gchar pointers. Still not certain that g_string_split() is the best
name. And not certain that GList is the best container for the returned
data. Do you really not mind 24 bytes of overhead for every returned
token? (12 bytes for GList + 12 bytes for GString)
Yes; I realised this would be quite a contentious issue; I wanted to
throw it open for debate.
My gut feeling, as I said in the other thread, is that a raw gchar**
doesn't really feel right. We're dealing with a GString nice shiney
wrapped type here...
Though I do take your point of the overhead of a GList.
Any number of possible ways to do this now strike me:
GPtrArray* g_string_split_array();
GString** g_string_split_strv(); // returns NULL-terminated array
Or, we could at this juncture try something new and funky.
Suppose instead we could do this:
GString str;
g_string_init(str);
g_string_append_len(...);
I.e. keep the GString struct itself as a real variable, rather than just
throwing pointers to it about the place, then we could construct a
GArray* g_string_split_array();
To return an array of GString structs themselves, rather than GString*
pointers. This would also have other benefits, like being able to
contain a plain GString struct inside a larger struct type.
Compare
struct {
...
GString* name;
};
printf(My name is %s\n, me-name-str);
vs:
struct {
...
GString name;
};
printf(My name is %s\n, me.name-str);
If you could use a bare GString inside a larger structure like that, it
would have immediate savings in terms of memory allocation overheads,
pointer dereference overheads, and general code neatness.
This idea would require two new functions:
void g_string_init(GString *str);
void g_string_fini(GString *str);
Which would do most of the work of g_string_new() and g_string_free()
respectively, apart from the initial struct allocation / final struct
free().
Thoughts on that one?
--
Paul LeoNerd Evans
[EMAIL PROTECTED]
ICQ# 4135350 | Registered Linux# 179460
http://www.leonerd.org.uk/
signature.asc
Description: Digital signature
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Some new GString functions - constructors
On Wed, Dec 21, 2005 at 12:33:23AM +0100, Emmanuele Bassi wrote: EIther way, you would have another type out: GStringList would be a G(S)List of GString; you would have to use: GSList *iter; /* or GList *iter; */ for (iter = stringlist; iter != NULL; iter = iter-next) do_something ((GString *) iter-data); to iterate though the list, which would break the least-surprise principle, since you would have to use a G(S)List pointer to iterate through a GStringList. Yes; PLS is broken there. As mentioned in the other thread; I'll summarise here. I could return: GPtrArray* GString** // NULL-terminated GArray*// of raw GString structs, rather than GString* pointers. This last one has interesting ramifications.. See other thread for detail. -- Paul LeoNerd Evans [EMAIL PROTECTED] ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: Digital signature ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Some new GString functions - constructors
On Tue, Dec 20, 2005 at 06:31:01PM -0500, Owen Taylor wrote: At a high-level, I think there is a question of what GString is - should there be GString versions of everything you want to do with a char *? My opinion is no ... a GString is the equivalent of a Java StringBuffer .. it is a useful way to build and work with strings, but it isn't *a string*. That's a char *. It would be for example, wrong to pass a GString as an argument to a function that takes a string as an input parameter. Yes; I do see your point here... There is after all, no point in defining an operation to printf() a GString, when you might as well just use %s with s-str. That implies to me, for example: GList *g_string_split(GString *str, gchar c); Is wrong ... we already have g_strsplit(): Ahh.. That would miss half the point of my intention with this function. It is true that this function takes, as input, a GString. But that wasn't its raison d'etre. The point of this new function is its return value. Yes, we already have g_strsplit(). This returns a NULL-terminated array of NULL-terminated gchar* strings. My intended point of g_string_split() would be that it would return a collection of GString* objects. The convenience is that it wraps up the strings as GString*s. That said, I don't see why we need a new split function, on reflection. Maybe a: GString** g_string_new_strv(gchar** a); would be useful; it would return a NULL-terminated array of new GString*s, each one wrapping a string from the original array. Thus, to form a GString** one could gchar** sv = g_strsplit(original_string-str, delim); GString** gsv = g_string_new_strv(sv); g_strfreev(sv); So easily providing what I intended for g_string_split(), but being less added code, and more useful. That said, I'm still not 100% happy with a NULL-terminated GString* array. Other threads give alternative ideas I have for these. (Sidenote: g_strsplit() takes a char * delimiter. This has the big benefit of handling UTF-8 and ascii equally well.) Ah yes; a most useful property. -- Paul LeoNerd Evans [EMAIL PROTECTED] ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: Digital signature ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Naked GString operations [was: Re: Some new GString functions - constructors]
(Appologies for the pun in the subject; I couldn't help myself.. :) ) On Tue, Dec 20, 2005 at 03:52:28PM -0800, Alan M. Evans wrote: void g_string_init(GString *str); void g_string_fini(GString *str); Which would do most of the work of g_string_new() and g_string_free() respectively, apart from the initial struct allocation / final struct free(). Mine are called g_string_init() and g_string_done(). snip By using g_string_init() instead of g_string_new() and pointers, I save myself four malloc() calls -- a big deal when I have thousands of these structs running about. And the bonus is that I can still use all the spiffy GString support functions. I've never dared submit my additions for fear of Owen calling my ideas ridiculous. (That's a joke. Owen, please don't ridicule me...) Well... perhaps now is the time to ask the list for opinions.. I for one would quite like to see something like this... Baring no objections to the idea, perhaps I'll make such a change the subject of my next patch submission. Arguments for: * Improvements in malloc() or other allocation space overheads * Improvements in nested pointer dereferencing * Ability to build a GArray* containing multiple GString objects Observations: * Any function currently taking a GString* can't free or otherwise modify the GString* object itself, only the data contained with it. Such functions would not be affected by these 'naked' GStrings. * There are no g_string_ functions which take a GString** and attempt to modify it. Arguments against: * It does complicate the API slightly. * Any code using a GString* cannot automatically know whether it was head-allocated, or just points at a variable somewhere. Whether any code would actually want to know, or care about such a condition, I am not currently sure. [PS: I'm not overly attached to _fini(), _done() seems just as nice.] -- Paul LeoNerd Evans [EMAIL PROTECTED] ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: Digital signature ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Some new GString functions - constructors
On Wed, Dec 21, 2005 at 01:19:59AM +0100, Øyvind Kolås wrote: At least in my sources, and where they draw inspiration from there is a larger precedence for the suffix _dup, rather than _clone. g_string_dup() also works, yes.. I'm not overly attached to the name. Thoughts anyone? -- Paul LeoNerd Evans [EMAIL PROTECTED] ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: Digital signature ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Naked GString operations [was: Re: Some new GString functions - constructors]
On Wed, Dec 21, 2005 at 12:07:14AM +, Paul LeoNerd Evans wrote:
void g_string_init(GString *str);
void g_string_fini(GString *str);
Actually, it occurs to me. If we wanted to give certain future
guarantees about GString, we could do something like the following:
#define GSTRING_STATIC_INIT { .str = NULL; .len = 0; .allocatedlen = 0; }
...
GString s = GSTRING_STATIC_INIT;
in the case of local or global variables, of only one GString (i.e. the
common case). This wouldn't work for arrays or other weird cases, but it
would avoid even the need for a call to the function to initialise it.
The downside here is that the initial representation of an empty
GString would need to be compile-time constant, if it would be used in
this manner.
Thoughts?
--
Paul LeoNerd Evans
[EMAIL PROTECTED]
ICQ# 4135350 | Registered Linux# 179460
http://www.leonerd.org.uk/
signature.asc
Description: Digital signature
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: public barrier functions
On Mon, Dec 12, 2005 at 10:41:55PM +0100, Sebastian Wilhelmi wrote: And while I am at it, would it be possible to change the atomic operations to inline functions? I'd think it is much better inline single-instruction functions as otherwise the call overhead is too great. That would make it impossible to fix the corresponding implementations also for already compiled programs, should bugs surface (which they already did) and it would also make it impossible to guarantee, that all programs really use the same implementation, i.e. with inline functions one module could use the asm version (because gcc is used) and the second module would use the mutex versions (because another compiler is used). That would be very bad of course. Yes, I'd agree here. I think it's more important to have a consistent library of such operations across all programs, an an easy way to apply bugfixes, than it is to have down-to-the-cycle optimisation. But I'd be interested to see some benchmarks; see how much this actually matters. Run a typical program twice; once with functions and once with some inlines/macros. It's quite likely that in a real-world program, the ratio of time it actually spends doing the atomic operation function calls, to the amount of CPU time in general, will actually be rather small indeed. Such an optimisation is likely to be of little actual benefit, for the cost it brings. -- Paul LeoNerd Evans [EMAIL PROTECTED] ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: Digital signature ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: landing g_slice_*() in glib
On Fri, 02 Dec 2005 09:44:04 +0100 Alexander Larsson [EMAIL PROTECTED] wrote: Also, are you making GType use g_slice for allocation of objects instead of memchunks (if n_preallocs is set)? And what of the allocators used by GString / GList / GSlist / ...? Will they be using g_slice now too..? -- Paul LeoNerd Evans [EMAIL PROTECTED] ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: PGP signature ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: g_list_prepend() does not call g_list_first()
On Thu, 01 Dec 2005 09:11:30 -0800 Alan M. Evans [EMAIL PROTECTED] wrote: I believe that this is a reasonable behavior. But it should be documented. I am inclined to agree. Anyone with any sense, as you point out, would keep a pointer to the head of the list; thus making g_list_prepend() equivalent to e.g. perl's unshift operator on lists. Though documenting its behaviour would be wise; if only in case anyone relies on this in code, and a reader stumbles upon it not realising... That said, by specifically not moving to the head of the list, this makes it into an equivalent of g_list_insert_before(), when passed the same GList* as both arguments. Is this intended / desirable / noticed? -- Paul LeoNerd Evans [EMAIL PROTECTED] ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: PGP signature ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: comments on g_list_slice / g_list_splice
On Wed, 30 Nov 2005 00:57:42 -0500 ANDREW PAPROCKI, BLOOMBERG/ 731 LEXIN [EMAIL PROTECTED] wrote: GList * g_list_slice(GList *list, GList *link, gint n_links); GList * g_list_remove_slice(GList *list, GList *link, gint n_links); GList * g_list_splice(GList *list, GList *splice_list, gint position); GList * g_list_splice_before(GList *list, GList *splice_list, GList *sibling); I added myself GPtrArray* g_ptr_array_slice(const GPtrArray* orig, guint first, gint last); I have found it more useful to pass offset indexes. For arrays this is the only sensible choice, but for lists it's somewhat harder to say what is the correct way of indexing them. Offset count, or link node pointer? Either way, the presence of functions which do that job, sound very useful. -- Paul LeoNerd Evans [EMAIL PROTECTED] ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: PGP signature ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: warnings on ignoring return value on some list operations
On Thu, 24 Nov 2005 16:35:59 +0100 (CET) Tim Janik [EMAIL PROTECTED] wrote: unless you strongly object to it, i still think we should add the attribute to all list functions that can return modified lists. it'll be stricter and thus may require some adaptions when introduced, but better in the long-term because it helps people to avoid easy errors. (Hi all... new to this list but long-time user of GLib) Just my two cents (Euros, naturally). I think it sounds a great idea. 99% of cases which hit will the warning, will be genuine accidents... In the 1% of cases where you really do know it is safe to ignore, it will, as others have pointed out, be simple enough to avoid. (Shame that casting the return to void doesn't work though... :/ ) -- Paul LeoNerd Evans [EMAIL PROTECTED] ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: PGP signature ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
