glib in kdesupport: yes or no?

[Maks Orlovich]

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[1]. 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 
available!)

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 
fair.

glib (and I am not counting the .mo files):
214960 /usr/lib/libgobject-2.0.so.0.200.1*
10788  /usr/lib/libgmodule-2.0.so.0.200.1*
438976 /usr/lib/libglib-2.0.so.0.200.1*
14856 Feb  3 04:17 /usr/lib/libgthread-2.0.so.0.200.1*

Total:  679580

vs.
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

[1] 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 
net work.