Toujours la bonne vieille tarte à la crème du programme lisible en n'importe quel langage, gna, gna, gna. Le problème, c'est qu'il y a des livres entiers qui démontrent le contraire. Juste un exemple, la modularité. Dans un langage qui laisse au programmeur le soin d'allouer et désallouer la mémoire, il est très difficile d'avoir une vraie modularité, à cause des structures qui passent d'un module à un autre : qui est responsable des créations et des destructions ? Comment gérer le partage de données entre deux listes ? etc.
Comme en C++ tu peux en partie te démerder avec les destructeurs, tu as déjà fait un grand pas en avant par rapport au C. Voilà pourquoi il sera toujours plus facile de faire du modulaire en C++ qu'en C (et ne vient pas me baratiner avec le comptage de références, c'est de la grosse merde, le GC du pauvre). Voilà aussi pourquoi le développement est beaucoup plus rapide en Java qu'en C++, puis qu'en C.
[^] # C/C++
Posté par boubou . En réponse à la dépêche le site de Ximian fait peau neuve. Évalué à 3.
Comme en C++ tu peux en partie te démerder avec les destructeurs, tu as déjà fait un grand pas en avant par rapport au C. Voilà pourquoi il sera toujours plus facile de faire du modulaire en C++ qu'en C (et ne vient pas me baratiner avec le comptage de références, c'est de la grosse merde, le GC du pauvre). Voilà aussi pourquoi le développement est beaucoup plus rapide en Java qu'en C++, puis qu'en C.
D'autre part, il existe des bindings Python et Java pour KDE (cf http://developer.kde.org/language-bindings/index.html(...) ). Si j'ai bien compris (cf http://webcvs.kde.org/cgi-bin/cvsweb.cgi/kdebindings/README?rev=1.4(...) ) il y a aussi des bindings C et Perl, mais bon, je ne suis pas certains qu'on puisse tout faire avec, où même que ça soit facile. Ca semble en plein développement (cf http://dot.kde.org/983311036/(...) )