Re: [gtk-list] GTK++ proposal writes:

> After the original GTK toolkit evolved to the GTK+ toolkit, which
> added object oriented principles to the C language, I feel that now is
> the right time to go one step further - GTK++ - a C++ version of GTK+.

Already done. It's called Qt :-).

> Before I say more, I realise that people are working at creating
> bindings for C++, and other bindings exist for many other languages as
> well, however, I believe that many of the bindings created break the
> original aims of GTK+ - to be a fast, small and efficient toolkit for
> programming the X Window System.

While gtk+ is still fast and efficient (at least by today's standards
and on today's machines), it's no longer small. Bindings don't change
this quite much.

> Many bindings created thus far are either extremely criptic, add
> unrequired code bulk, or are lacking in features found in GTK+.

Rewriting it in C++ certainly won't change that. Actually, I think it
would make things worse. Prying in the gtk+ object model from another
language is already hard, but it can be done. At least with Gtk--, you
can actually derive a gtk+ widget and override its signals (don't know
about other bindings). I doubt such a thing would be possible if gtk+
was written in C++.
> A C++ version would greatly simplify the learning curve of the
> toolkit, especially in creating new widgets for the library.

Probably, but it would add the learning curve of C++, next to which
the gtk+ one is but a mole hill.

> Your thoughts, criticisms and concerns would be greatly appreciated.

I don't think this will never happen, and that among all the reasons
why not, some are actually quite good.

Before I make my point, let me say that I like C++ very much. I think
the the real advance of this decade in programming isn't Java, it's
the STL (ok, the STL is actually based on old ideas, but so is
Java). And now that we have egcs, I wouldn't start writing anything
mildly large in another language.

However, I don't like C++ enough not to be aware of its shortcomings,
be they inherent to the language or due to bad implementations
(although with the Standard finally completed, these fortunately tend
to slowly disappear).

So here goes :

- C++ is too complicated. I recently read on Kernel Traffic a quote
  about a similar debate about the Linux kernel : "handing C++ to the
  average programmer is like handing a loaded .45 to a
  chimpanzee". This is very true.

  By "too complicated" I mean that it's ten times as big as C and also
  much more complex. So it takes much longer for the average
  programmer to get used to it, and before that much head-scratching
  and frustration will occur, often enough to make him abandon.

  This also means that while in C you don't have so many ways to goof
  around and shoot yourself in the foot, in C++ you have hundreds. A
  bad or simply inexperienced programmer can still produce something
  more or less useable in C, not in C++.

- C++ requires much more hardware ressources to develop with. The
  language is more complex, so is the compiler. You can develop in C
  using a Pentium with 32Mb of RAM and be quite comfortable. The
  latest version of egcs requires a P-II 300 and 64Mb to "feel" the

- Compilers are only catching up with the Standard. Currently, on Unix
  there is only egcs. I believe Sun's CC 5.0 will also be quite close,
  but that's all AFAIK. It will take another year or so before this
  actually improves.

- There are still many problems with linking together pieces of C++
  code compiled with different compilers. Distributing pre-compiled
  libs and binaries would become a nightmare (instead of one per
  platform, you'd have one per platform/compiler combination).

> I feel that many other programmers would be happy to help.

I don't think so. One more reason is that C++ isn't very much liked
among the hacker community (for the reasons above, plus a whole bunch
of "religious" ones), and I think one of the reasons Gnome was formed
was as a reaction against the use of C++ by KDE.

> Perhaps the Gtk-- and VDK authors could chip in too!



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]