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(
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 nu
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
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
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 ?
> >
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 laz
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 "ma
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.
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(
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 l
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
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 struc
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
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
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 terminati
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.
--
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 a
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 fi
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.
19 matches
Mail list logo
