glib in kdesupport: yes or no?
mo002j at mail.rochester.edu
Sun Mar 9 18:16:22 GMT 2003
On Sunday 09 March 2003 12:48 pm, Waldo Bastian wrote:
> On Sunday 09 March 2003 16:08, Neil Stevens wrote:
> > KDE has used almost exclusively the C++ language since its inception. I
> > don't think it's appropriate to try to undermine that choice in this
> > manner.
> KDE uses C++ because in most cases that is clearly the superior solution.
> However, in cases where the advantages of using C outweigh the advantages
> of C++, the decision has been made to use C.
Unfortunately, I am yet to see any case where such decision has been made
properly on the desktop-level. Most of the reasons listed by STW himself
were technically incorrect, or irrelevant to our scenario. (i.e. we don't
care about portability to platforms that don't have a C++ compiler
In many cases I think true the reason is simple: people don't know C++, and
are unwilling to learn. In which case this is not a technical decision. It
may be a valid human one, perhaps, but it's not on the same level as using
something because it's the best tool for the job.
> Your reasoning is solely based on gross generalisation. In most cases
> C++/Qt is superior to C/glib, however that doesn't rule out that in _some_
> cases C/glib is a better choice. In those cases KDE should use it.
If those case exist in a desktop scenario, which I am not convinced of, mainly
because I haven't seen any concrete examples.
> glib can be helpfull there by providing commonly needed functionality
> without repeatedly duplicating that functionality (which you would need to
> do if you didn't use glib or Qt) and without introducing rather large
> dependencies (C++/Qt is a much larger dependency than C/glib)
C++ + STL is bigger by all of 23K. Can't comment on the RSS, though, to be
glib (and I am not counting the .mo files):
14856 Feb 3 04:17 /usr/lib/libgthread-2.0.so.0.200.1*
702680 Feb 15 08:13 /usr/lib/libstdc++.so.5.0.3*
Yes, the C++ development platform is larger, but I don't think development
platform size is all that relevant. The KDE source trees are easily in
hundreds of megabytes upto a gigabyte and beyond, and I imagine GNOME is
somewhere around there, too, so installing g++ is hardly a big deal for most
developers. g++ AFAIK runs on all the platforms the two desktops support. So
it's not a portability blocker at all.
C++ is also an international standard, glib is proprietary. So I think if we
are to develop something to be made available to GNOME, a better solution
would be to base something on C++/STL and provide extern "C" interfaces. Just
like has been done by FAM developers
 i.e. I certainly undestand why i.e. the gcc folks are using C due to the
bootstrap issue, or why C is used for embedded devices. Those arguments,
however, don't apply to the desktop. And the "ease of binding" thing isn't at
all clear, since although interfacing to C is certainly easier, one has to
map additional semantics/OO structure on top, so that may actually be more
More information about the kde-core-devel