KDE3.4RC1: Incompatibility
Bernhard Rosenkraenzer
bero at arklinux.org
Mon Mar 14 22:22:48 GMT 2005
On Monday 14 March 2005 21:45, Scott Wheeler wrote:
> But you won't get around that with a C API. Without operator overloading
> you can't fix:
>
> GString *s = g_string_new("foo");
> gchar c = s[10];
>
> Even if you reimplement the API in Qt, you'd still have just overrun some
> buffer. Where glib offers such things semantically (i.e. GList), the
> bounds are also checked.
So let's fix the code that uses it (by making it use Qt or at least libstdc++)
rather than reinventing the same crap --- the problem with glib isn't that
it's huge or that its memory footprint is extremely large, the problem is
that it's an inherently broken way to implement things (as proven by this
example), and that it's completely superfluous, it doesn't do anything Qt or
libstdc++ won't do...
Fixing the apps that use it to use something else (QtCore from Qt 4.0 seems a
good choice) shouldn't be too hard, just time consuming...
More information about the kde-core-devel
mailing list