On Sat, Sep 23, 2000 at 10:45:41PM -0400, Havoc Pennington wrote:
>
> David Odin <David Odin bigfoot com> writes:
> > Actually, it is a very good idea, but I think isn't very portable on
> > non-GNU platforms.
> >
> > I didn't know this function, and I saw this from the man page:
> > CONFORMING TO
> > This function is not part of the ANSI or POSIX standards,
> > and is not customary on Unix systems, but is not a GNU
> > invention either. Perhaps it comes from MS-DOS.
> >
> > Havoc, what do you think? Should I re-write my patch to use stpcpy() and
> > adding a test to configure.in?
> >
>
> If you did, you'd just write a g_stpcpy(), which would be implemented
> depending on a configure.in test, then use that.
>
> I don't have any opinion though whether it's better to use
> it. Probably only if we want g_stpcpy() in GLib anyway, and I don't
> know whether we do or not.
>
OK. Here is what I've done.
I've added a g_stpcpy() function to the glib, and use this function in
g_strjoin(), g_strjoinv() and g_strconcat(). Thus, the algorithms complexity
of these functions is reduced from O(n*n) to O(n), n being the length of the
resulting string.
If the g_stpcpy() isn't usefull, I'll rewrite my patch in order not to use
it (and the three functions would become even faster by avoiding a function
call...).
Tell me if the patch is applied.
Thanks,
DindinX
--
David Odin bigfoot com
Attachment:
diff.glib.gz
Description: application/gunzip