From: Jean-Michel Reghem <[EMAIL PROTECTED]>Bonjour Jean-Michel,
Reply-To: "CyberMac" <[EMAIL PROTECTED]>
To: "CyberMac" <[EMAIL PROTECTED]>
Subject: Interface graphique en C++ (was: Re: [CCMC] Gestion de la m�moire sous OS X ?)
Date: Wed, 19 Feb 2003 11:19:50 +0100
eva _242_ �crivait ( Wednesday 19/02/2003 10:56 ) dans le message ci-dessous:
---
Je ne peux qu'encourager les gens d�sireux de comprendre les entrailles de OS.X d'utiliser <carbon.h> ou <cocoa.h> et faire un "projet" dans ProjetctBuilder. Personnellement j'ai boss� 6 ans avec Visual C++ qui est un tr�s bon produit M$(le seul � mes yeux) mais project builder (bien que manquant de fonctions int�ressantes) reste un superbe outil de d�veloppement, et �conomiquement imbattable, surtout qu'il est livr� avec des tonnes de tools (MallocBrowser, objectDescriptor, ...).
Tiens, tant que j'y suis ...
Est-il possible d'utiliser les biblioth�ques et framework graphiques de Mac OS X (genre les boites de dialogues, les applications fen�tr�es, les acc�s aux fichiers prefs .plist, etc...) directement en c++ et pas en objective C dans Project Builder?
C'est pas que j'ai pas envie d'apprendre l'objective C, mais j'ai pas vraiment le temps ;-)
<private>
et puis raphael, entre nous, j'accroche pas vraiment � la syntaxe bizarre de l'ObjectiveC ;-) ... mais bon, c'est peut-�tre parce que je le connais mal ;-)
</private>
a+
Jean-Michel
---
Oui tout a fait, derri�re ProjectBuilder se cache GCC ... et donc ANSI C && C++ enabled.
<carbon.h> utilise la norme d'�criture C++ (instantiation, EventLoop, h�ritage, polymorphisme (bien que je n'ai jamais d� encore utiliser le polymorphisme dans ma carri�re ... mais c'est un super d�bat pour se faire des ennemis ... j'�vite d'en parler)).
La suite des devTools comprends d'ailleurs Interface Builder permettant de g�n�rer les framework de fa�on +/- simple ... Je n'ai pas encore bcp d'exp�rience avec ses termes, encore trop habitu� aux nomenclatures Redmond.
Mais in fine, pour avoir fait une petite interface graphique pour entrer des pr�f�rences, etc... et cr�er des petits fichiers CSV, je n'ai utilis� que le C++.
Cocoa permet objective C, mais je n'ai jamais mis les mains l� dedans ... Il y a beaucoups de d�bats pertinents qui le justifient ou qui l'injustifient ... D�bat de passionn�s et de th�oriciens ...
En fait, ma devise est de faire toujours K.I.S.S. (Keep It Simple Stupid, que l'on pourrait traduire par "L'efficacit� r�side dans la simplicit�". Attention : Simplicit� != Simplicisme, je me r�p�te mais bon .. �a doit �tre l'�ge ... Faut bien que je me trouve une excuse hein!).
Donc, je fais tout ce que je peux en ANSI C, quitte � simuler du C++. Je pr�f�re de loin des typedef et autres pointeurs sur structures que des "classes" par d�finition "bo�tes noires" ... J'ai pass� des semaines � d�bugger une app dont on me jurait que les classes �taient exemptes de bug car en production depuis 5 ans sans le moindre p�pin... Eh ben c'�tait �a le p�pin ... Le polymorphisme, les classes abstraites et les h�ritages dynamiques c'est beaux ... �a fait bien en soir�e et �a en j�te ... Et puis �a fait tr�s mode... J'ai perdu quelques copains � cause de discussions sur le sujet. Eux ne jurant que par l'UML et les classes abstraites et les technologies avanc�es C++. Moi faisant le m�me en ANSI C et en 10x plus simple (3x plus long aussi mais .... lisible => facile � d�bugger).
Cette soci�t� � perdu des millions de francs pour d�bugger cette app (qui n'avait pas de r�els bugs ... enfin pas assez m�chants pour faire crasher l'app... parfois quelques memset un peu "limite" mais bon... quand on n'ulise pas Lint...) car elle a fait d�velopper ses classes � la "Modern Style" o� tout est question d'h�ritage et d'astuces propres au C++ (que je ne d�nigre pas en soit, loin s'en faut ! ... mais qui parfois est utilis� � tort car il n'apporte rien par rapport � l'ANSI C dans un cadre d�fini mis � part une complexit� inutile).
Et d�bugger du C++ bourr� de technologies "abstraites" prend infiniment plus de temps que d�bugger de l'ANSI C (quoi qu'on peut en discutter longement, j'ai d�j� vu des trucs ANSI C de super hautes voltiges, genre liste cha�n�es sur liste cha�n�es, pointant sur structures comprennant elles-m�mes d'autres structures, et au final tu as un truc imbuvable genre memset(pHandle, *****pHdefAutoRecognize) ou autre a->b->c->d.e->f ...). Personnellement, mais je suis loin d'�tre un g�nie ou un guru, de toute ma carri�re je n'ai jamais du arriver � de tels folies ... Et pourtant pour avoir mis les mains jusqu'au trognon dans MQseries, .... il me semble que cette forme d'�criture pour esth�tes (1 programme = 1 ligne) est tout sauf intelligente, c'est plut�t l'exemple parfait d'un ratage total de l'analyse et de la compr�hension des objects. Je serais le Boss, je vire illico les autheurs de tels abobinations... Ca sera non maintenable � terme et presqu'impossible de faire travailler divers cellules de d�veloppeurs en parall�le sur une telle syntaxe.
Sur le site d'Apple (Support) il y a pas mal d'exemples d'utilisations en C++ pour utiliser les objects graphiques du GUI. (Je parle tjs de ProjectBuilder mais les sources sont 100% compatibles avec Code Warrior aussi).
Pour Objective C, je ne peux rien en dire car je ne connais pas du tout... Je pense que c'est encore un "effet de mode"... Faire et D�faire c'est toujours du travail .... Il faut bien g�n�rer une �conomie ...
Ooops je deviens cynique! Il y a probablement une normalisation d'�criture qui doit plaire ou d�plaire.... Question de go�t...
Mais au final, la question que je me pose dans chaque d�veloppement et choix des outils est : "Qu'est-ce qui est r�ellement utile ?". Le but �tant une lisibilit� et une maintenance irr�prochable. Mon code est sans cesse envoy� au canada, aux states et parfois en France... Il faut donc que je fasse :
1) Tr�s lisible (Mieux vaut faire en 10 lignes plut�t qu'en 2. L'orgeuil en prends un coup, mais je suis exempt de ce defaut. J'en ai bien d'autres notes !)
2) Commenter. On ne commente jamais assez. Quand je vais dans le gestionnaire de source CVS ou VSS (M$), c'est fou les codes � la sauce "nouveau programmeur du futur" ... 2 commentaires pertinents comprenant la date et le nom de l'autheur (comme si VSS ou CVS ne permettait pas de le savoir) sur un source C++ > 870 lignes de "haute voltige").
3) Ansi C au maximum quand on peut se le permettre. C'est ANSI et royallement portable. Les compilos des TACL ne comprennent pas // mais /*.... Et pourtant Dieu seul sait si tout le monde utilise // m�me dans des sources .c
Voil�. En esperant avoir pu t'�clairer un peu sur le sujet...
Bien � toi,
JM.
/* Fin du Roman, back to reality */
_________________________________________________________________
--
Avec i-mode, vivez une toute nouvelle experience de la communication et des services en ligne. Plus d�info sur http://www.imode.be
CyberCafe 2.0 <http://www.cybercafe.tv> Chaque Mardi 19h15 sur La 2!
Desabonnement par email : <mailto:[EMAIL PROTECTED]>
