Advertisement
Front, Kernel, Security, Distributions, Development. See your byline here on LWN.net.
| |||||||||||||
|
| |||||||||||||
Connect KDE apps using D-BUS (IBM developerWorks)Connect KDE apps using D-BUS (IBM developerWorks)Posted Jul 30, 2004 22:51 UTC (Fri) by edmundd (guest, #14677)Parent article: Connect KDE apps using D-BUS (IBM developerWorks)
Despite the title, the article is more Glib-centered. The author told me that the IBM editor slipped the KDE in there :)
(Log in to post comments)
Not necessarily a bad thing Posted Jul 30, 2004 23:36 UTC (Fri) by AnswerGuy (guest, #1256) [Link] glib is a set of C libraries to provide a large number of functions andstructures that are generally useful. They are somewhat object oriented, but they are not present as C++ classes and don't require that you use OO methods.
glib has nothing to do with the GUIs or toolkits. In GNOME those are built
JimD
Not necessarily a bad thing Posted Jul 31, 2004 6:29 UTC (Sat) by boudewijn (subscriber, #14185) [Link] On the other hand, glib should be used by no C++ program, since there arefar better solutions of C++ to manipulate common datastructures..
Not necessarily a bad thing Posted Jul 31, 2004 12:49 UTC (Sat) by rjw (guest, #10415) [Link] Except that D-BUS is *not* based on glib.
Because of the boneheaded decision to shove an object system into glib, rather than a separate library (it was understandable to take it out of gtk+), a lot of people (with their own object system) don't like it, and have decided that glib as a whole is a gnome conspiracy to ruin the purity of C++. Another strike against glib is the insistence on having typedefs for even the most basic types eg: (void*)-> gpointer . This makes it a horrific pain to lift glib-using code into a non glib context. Surely they can depend on standard C types by now?
All this makes it impractical to have glib as a dependency ( especially for system level stuff). Dbus contains copies of all the glib bits it uses.
However, it does have both GObject/glib and qt integration - allowing you to bridge it to either object system.
So:
Even funnier than this is that the main opponents to GObject, KDE, don't use their languages supplied string and container classes : they have their own stuff from qt. Luckily the containers are now stl compliant..
I'm just waiting till someone creates an implementation of libc that implements everything using the stl underneath... that'll be the flamewar to end them all.
Not necessarily a bad thing Posted Jul 31, 2004 14:31 UTC (Sat) by sandy_pond (guest, #9734) [Link] "glib as a whole is a gnome conspiracy to ruin the purity of C++" "object system in in C : pretty distasteful to C++ purists" I wish these C++ purists would understand that C++ is a superset of C. C++ objects are implemented in C. "I'm just waiting till someone creates an implementation of libc that implements everything using the stl underneath... that'll be the flamewar to end them all."Why don't these C++ purists go off and write there own Linux++ and leave those who just want to make thing work together alone. While there at it they can write a "pure" C++ compiler.
Not necessarily a bad thing Posted Jul 31, 2004 20:35 UTC (Sat) by nix (subscriber, #2304) [Link] I wish these C++ purists would understand that C++ is a superset of C.But it is not. It is a near superset, getting rapidly less so with the release of C99. That does not mean that good C style and good C++ style are identical: far from it. C++ objects are implemented in C.I can't work out just what on earth this is meant to mean. The only case I can think of of a C++ object being implemented in C code is GNU libio, and that is specific to a single C++ ABI and only does such horrible hackery in order to ease the implementation of ios_base::sync_with_stdio().
Not a superset Posted Aug 1, 2004 2:17 UTC (Sun) by pkturner (subscriber, #2809) [Link] [C++] is a near superset, getting rapidly less so with the release of C99.On the contrary, the discrepancies that arise from this 5-year-old (rapidly??) standard are in retreat. Quoting Herb Sutter from the C/C++ User's Journal, At the Fall 2003 meeting, C and C++ already decided to adopt large parts of each other's work... at this Spring 2004 meeting, the C++ committee decided to adopt the C99 library extensions
Not necessarily a bad thing Posted Aug 2, 2004 7:36 UTC (Mon) by anselm (subscriber, #2796) [Link] > C++ objects are implemented in C.That used to be the case back when Bjarne Stroustrup was still in charge and the canonical C++ compiler was AT&T's »cfront«, which compiled C++ to C. For the last fifteen years or so at least, most C++ compilers have been emitting assembly code directly, just the way C compilers do. G++, for example, started out as an alternative front-end to the GCC code-generating back-end, not as a C++-to-C compiler. Anselm
Not necessarily a bad thing Posted Jul 31, 2004 16:58 UTC (Sat) by hp (subscriber, #5220) [Link] GObject *is* in a separate library. It's called "/usr/lib/libgobject-2.0.so" on my system.
Not necessarily a bad thing Posted Aug 1, 2004 16:04 UTC (Sun) by rjw (guest, #10415) [Link] This isn't enough for the worriers: it needs to be distributed separately.
Not necessarily a bad thing Posted Aug 1, 2004 13:22 UTC (Sun) by marduk (subscriber, #3831) [Link] I mostly agreed with this statement until I heard the words "conspiracy" and "purity of C++". Then I had to laugh.
Not necessarily a bad thing Posted Aug 1, 2004 20:13 UTC (Sun) by dcoutts (guest, #5387) [Link] Glib is not just common data structures, the other part of Glib (not the semi-separate GObject library) is an event loop system.
Not all C programs want to use this event loop. Eg some network daemons might want their own (glibs main loop is good even for network programming but was originally designed with an X connection in mind). Qt has its own main loop system, python & other language run-time systems also have their own.
Connect KDE apps using D-BUS (IBM developerWorks) Posted Aug 2, 2004 8:19 UTC (Mon) by evgeny (guest, #774) [Link] The title now reads "Connect desktop apps using D-BUS". ;-)
|
|
||||||||||||