g_strchug, g_strchomp, g_strstrip
Hello all! This may seem insignificant to some. But my projects usually involve many thousands of operations on potentially very long strings. All the little things start to add up. On a whim, I looked at the #define for g_strstrip: /* removes leading & trailing spaces */ #define g_strstrip( string ) g_strchomp (g_strchug (string)) Letting alone that I might prefer to make a proper function for this to avoid calling strlen() twice, isn't this definition backwards efficiency-wise? I mean that, if g_strchug() could call memmove(), wouldn't you want to do that *after* shortening the string with g_strchomp()? Also, g_strchug() unconditionally does: g_memmove (string, start, strlen ((gchar *) start) + 1); This should be wrapped in "if (string != start)" to avoid calling strlen() in the (rather common) case of not moving any bytes at all. I don't see any reason at all for not making these two changes. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GObject extension propose (GContainer)
On Sat, 2006-06-17 at 09:18, Tristan Van Berkom wrote: > Alan M. Evans wrote: > >>the lookup penalties are negligible. > >>type node/class lookups and is_a checks are O(1); > >>interface class lookups and conforms_to checks are O(ld(N)), where > >>N is the number of interfaces a type node conforms to. > > > >Your assertion that the penalties are negligable is not really supported > >by your response, unless the constant is also known for both orders.> > > > From my swift glance at gtype.c, it seems that in the case of > an interface, the implementing interface is searched on that class's > list of implementing interfaces... so when classes implement > hundreds of interfaces it might be a performance hit. My impression from the original question, which I didn't ask, was not so much about access to a large number of members. If a single variable needs to be examined many times then the performance penalty of a generic interface lookup can add up. In any case, I merely observed an assertion, "the lookup penalties are negligible," and the what appeared to be supporting data, the order of the lookups. This doesn't tell us what the penalty is, only that there is a penalty that gets worse as the number of members increases. Maybe the penalty is negligible, but the data presented didn't say so. That's all I was saying. > I dont think we've yet reached the day that we have to ditch good design > and avoid using interfaces because of performance woes, that would > be sorry day indeed... (I also dont think GTK+ code will be the only OO code > needing major refactoring in those areas too... if these interface > lookups weren't negligable) Indeed. I would certainly not advocate dispensing with good design. In fact, I usually advocate the purist design in my own software, and let Moore's Law fix the performance issues. But some cases still call for direct access for essential performance. I, too, would like to know the performance penalty of the generic interface. Being lazy, I suppose I will set up some experiment to discover it pragmatically. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GObject extension propose (GContainer)
On Fri, 2006-06-16 at 04:28, Tim Janik wrote: > On Fri, 16 Jun 2006, Gustavo J. A. M. Carneiro wrote: > > > Qui, 2006-06-15 às 13:00 -0400, Tristan Van Berkom escreveu: > > >> All of that just to say... I cannot count the times I've thought to > >> myself that > >> GtkContainer should really just be GContainerIface, and implemented by > >> whatever interested objects that want to parent other objects... > > > > That's interesting, but I wonder what is the runtime penalty of > > interface lookup compared to normal class structure lookup? Is it > > really OK to use an interface for this, or is it better just to add a > > new virtual methods to the GObject class? > > the lookup penalties are negligible. > type node/class lookups and is_a checks are O(1); > interface class lookups and conforms_to checks are O(ld(N)), where > N is the number of interfaces a type node conforms to. Your assertion that the penalties are negligable is not really supported by your response, unless the constant is also known for both orders. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: selected text is PRIMARY?
On Fri, 2006-04-14 at 14:02, Xavier Bestel wrote: > Yes there is. Witness Evolution and its load of widgets. In its first > versions, You had to focus the right widget to have keypress do what you > wanted (e.g. if the trash was last clicked, and you pressed the spacebar > to pagedown, the current mail was deleted instead). Tha was a mess and > now keypresses are interpreted nearly independently of the last widget > you clicked. This sounds to me like a problem with the application, not the toolkit; and certainly not with the system's Copy/Paste behavior. If "copying" the trash icon doesn't make sense in a particular application, then the application shouldn't do it. Similarly, if pressing spacebar while the trash icon is focussed does something unexpected, then it's the fault of the application. > Having Ctrl-C being dependant on the last clicked widget is a bad idea > in real life. Why? I'm serious. I just don't see where this causes problems "in real life." Why does X11 PRIMARY behavior need to be provided to the exclusion of proper Ctrl-C/Ctrl-V behavior. I can't think of a single application on any platform where Ctrl-C doesn't apply to the currently focussed widget. Although I doubt that it even comes up much in most applications -- who keyboard-navigates to a toolbar button and hits Ctrl-C? What would the user expect to happen in that case? > Your multiple selections look equally bad to me. Once again: Why? Because this is what a vast majority of users expect? Any argument formulated around the "X11 tradition" can be countered with the expectation of the supermajority of current computer users. Inasmuch as GTK is supposed to be cross-platform, it should at least support the convention that is prevalant on the two most popular desktop platforms. Ask a hundred typical users to select text in one app then select text in another, then ask them if the text in the first app is still selected. I'm willing to bet that 98 or 99 of them would, after being surprised by the question, probably respond, "Of course it is. Why wouldn't it be?" The existence of multiple selections in desktop applications has never confused users. At least I've never heard of it happening. Have you? In any case, nobody (certainly not me!) is suggesting dropping PRIMARY. Just allowing multiple selections would also allow sensible support for keyboard Copy/Cut/Paste. I don't see how multiple selections causes problems for using PRIMARY because, as I've said, middle-click pasting is virtually always done immediately after selecting, so there's never any question about what is going to be pasted. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: selected text is PRIMARY?
On Fri, 2006-04-14 at 11:14, Xavier Bestel wrote: > Le vendredi 14 avril 2006 à 19:28 +0200, Jernej Simončič a écrit : > > On Fri, 14 Apr 2006 19:14:17 +0200, Xavier Bestel wrote: > > > > > - One selection per application ? > > > - One selection per window ? > > > - One selection per widget ? > > > > I'd go for one selection per widget - I'm always annoyed in X when I select > > something, and my previous selection is erased (even though I do often use > > the middle-button pasting). > > Nice. And now when you press Ctrl-C, what happens ? Well, being merely a user, I would expect it to copy the selected object in the currently focussed widget. Is there something difficult or non-obvious about that? As for the pasting operation, I would expect that Ctrl-V would paste the object that was last copied or cut using Ctrl-C or Ctrl-X, regardless of PRIMARY selection. Further, middle-mouse pasting should occur with the last object selected with the mouse, regardless of Ctrl-C/Ctrl-X. I don't even think that PRIMARY selection requires a special visual cue to distinguish it from other selections. My argument here is that pasting from PRIMARY *always* occurs immediatly (or very soon after) selecting. It's inconceivable to me that someone would select with the mouse then leave their task for a long time and then return and paste with the middle button. I find this system to be very simple and flexible. Users who want to use PRIMARY-style pasting can do so. Users who want to use the Ctrl-C/Ctrl-V method can do so. User that have need of both are free to use them both. I fall into that last group. ___ 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 Wed, 2006-03-22 at 00:48, Paul LeoNerd Evans wrote: > 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? I'd say it's more a matter of taste. And your argument is mostly stylistic. Tastes differ. In fact, an unadorned zero works perfectly well in all cases except unprototyped function parameters. (This thread started with the error of passing zero in varargs, which are technically unprototyped even when the function is prototyped.) ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Character Table
On Thu, 2006-03-02 at 14:24, dwolfe wrote:
> for(n=32; n<1000; n++)
> {
> static gchar buf[8];
> g_sprintf(buf, "%c", n);
> printf("string:%s", buf);
>
> gchar *end;
> if(g_utf8_validate (buf, -1, &end))
Check "man 7 utf8" and perhaps you will understand why you are mostly
failing to produce valid UTF-8 characters this way.
Wrong list, by the way; try gtk-app-devel-list instead.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Depending on C99 (Re: GtkBindingSignal changes)
On Thu, 2006-01-05 at 08:26, Roger Leigh wrote: > anyone could download the latest MS compiler from the MS website, > so I don't think there's any good reason to restrict yourselves to > this compiler's capabilities. Only if having Visual Studio along with your compiler isn't a good reason. ___ 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, 2005-12-21 at 14:58, Paul LeoNerd Evans wrote: > 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, ...); I would welcome this addition. I do that *very* frequently. ___ 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, 2005-12-21 at 14:58, Paul LeoNerd Evans wrote: > 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. Sorry, I wasn't very clear. My point was not that there was already a patch, but that it was almost a year old and not yet triaged. Sort of an indication of the level of interest among the core developers... ___ 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 Tue, 2005-12-20 at 11:10, Paul LeoNerd Evans wrote: > 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. http://bugzilla.gnome.org/show_bug.cgi?id=164446 A patch was already submitted in January. Still UNCONFIRMED. ___ 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, 2005-12-20 at 15:38, Paul LeoNerd Evans wrote:
> 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?
Actually, you've hit on something I've implemented and used myself, but
for different reasons.
Mine are called g_string_init() and g_string_done(). In my situation, I
have, for example, a struct:
struct mydata {
GString one;
GString two;
GString three;
GString four;
};
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...)
___
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, 2005-12-20 at 15:18, Alan M. Evans wrote: > On Tue, 2005-12-20 at 14:36, Paul LeoNerd Evans wrote: > > > typedef GList GStringList; > > 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) > My opinion: GLib could use more support functions for string arrays. I do not take this back. ___ 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, 2005-12-20 at 14:36, Paul LeoNerd Evans wrote: > typedef GList GStringList; 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(). Whether or not this is more useful may depend on how you use it -- I use string arrays frequently, rarely use GLists of strings. But at least the naming would be more consistent. My opinion: GLib could use more support functions for string arrays. ___ 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, 2005-12-20 at 14:36, Paul LeoNerd Evans wrote: > * 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. GStrings are already guaranteed to have a nul terminating byte, aren't they? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: inlining glib functions (Was: public barrier functions)
On Tue, 2005-12-13 at 10:10, Gustavo J. A. M. Carneiro wrote: > This function is trivial. I doubt you'll ever find any new bugs in it. [...] > [ BTW, "if (str)" could be changed to "if (G_LIKELY(str))" ] Think about this. -- Alan M. Evans <[EMAIL PROTECTED]> ___ 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, 2005-12-01 at 08:36, ANDREW PAPROCKI, BLOOMBERG/ 731 LEXIN wrote: > Just wondering if there is a legacy reason why g_list_prepend() does not call > g_list_first() on the pointer passed in to ensure that it is prepending to > the > head of the list. The g_list_append() call ensure it is appending to the end, > and this is unintuitive to people. If this seems logical, is this a possible > addition to 2.10 since it would change API behavior? Or has this never been > done > because the impact was deemed to great versus the benefit? As documented at http://developer.gnome.org/doc/API/2.0/glib/glib-Doubly-Linked-Lists.html "Note that most of the GList functions expect to be passed a pointer to the first element in the list. The functions which insert elements return the new start of the list, which may have changed." I'm not aware of anyone who keeps track of a GList by keeping a pointer to some arbitrary element. Anyone with any sense, in my opinion, keeps a pointer to the head of the list and uses other pointers when iterating or referring to some arbitrary element. In any case, g_list_prepend() does have a coded (although poorly documented) behavior in the case of prepending to a middle element. A quick look at the code reveals that if the list pointer is a middle element then the new element will be properly placed in the middle of the list just before the referenced element. All pointers will be updated so that list integrity is maintained. I believe that this is a reasonable behavior. But it should be documented. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Pushing a NULL into g_async_queue
On Mon, 2005-02-28 at 22:19, James Henstridge wrote: > Alan M. Evans wrote: > > >Hello all. > > > >Is there some good reason for the prohibition on passing NULL data into > >g_async_queue_push()? I checked the glib sources and the only reason I > >could find is that data==NULL won't pass the g_return_if_fail(data) > >test. What is the reason for this seemingly arbitrary limitation? > > > > > This question is probably better suited to gtk-list or > gtk-app-devel-list -- gtk-devel-list is for discussion of development of > GTK. Really? I didn't think that discussion of the implementation details of glib belonged on either gtk-list nor gtk-app-devel-list. I was actually cautiously hopeful that this limitation might be lifted. > In answer to your question, consider the g_async_queue_try_pop() and > g_async_queue_timed_pop() functions. They will either return a value > from the queue, or NULL if no items exist. If you can store NULLs in > the queue, then the result becomes ambiguous. That's a pity. Using GINT_TO_POINTER is a convenient way to pass short messages through a queue. If I can't find a way to avoid zero as a value then I'll have to pass a pointer to an int, which means that I now have to worry about the lifespan of the int. I guess what this means is g_new(int) at one end and g_free() at the other -- yuck. Anyway, I don't mean to belabor the point. Hadn't noticed the timed_pop and try_pop ambiguity when perusing the sources for my answers. Thanks for the reply. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Pushing a NULL into g_async_queue
Hello all. Is there some good reason for the prohibition on passing NULL data into g_async_queue_push()? I checked the glib sources and the only reason I could find is that data==NULL won't pass the g_return_if_fail(data) test. What is the reason for this seemingly arbitrary limitation? Thanks. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
