Jean-Michel (et eva),
Pour répondre à la question originale, tu peux accéder à quelques fonctionalités Cocoa via CoreFoundation(.h) qui est une API C pure. Tu n'y trouveras pas les fonctionnalités graphique de Cocoa (AppKit). Pour ça, il faut utiliser Carbon (C) (ou un toolkit basé sur Carbon, genre Qt ou autre FLTK...).
Je suis plutôt d'accord avec l'analyse de "eva _242_", un maximum en C, lisibilité du code (et le C++ est mauvais pour ça). .. Et j'applique ça à la lettre au quotidien. Je ne suis pas d'accord quand au phénomène de mode de l'Objective C et de Cocoa. Ayant utilisé quelques toolkits en C, C++ (MFC, FLTK, BeOS), ainsi que Cocoa et Java, voici pour moi les avantages de Cocoa/Objective C:
- Productivité
Les outils (interface builder...), la simplicité de la syntaxe rendent les développement très, très rapides. Il faut toutefois passer par une phase d'apprentissage.
- Maintenabilité
Les interfaces graphique Cocoa (NIB files) ne sont pas du code généré par la machine. Ce sont des objets graphiques (fenętres...) qui sont créés et archivés. Lorsque l'application démarre, elle désarchive ces objets et rétablit les connections avec le reste du code. Cela signifie qu'on peut changer complètement (et sans recompiler) une interface du moment que les "connections" sont préservées.
En deux mots, avec Cocoa, on se concentre sur le code "intelligent" et on dessine de jolies interfaces à la souris. Le code est lisible, compact et performant. 2 développeurs Cocoa peuvent réaliser le męme travail qu'une équipe de 10 développeurs MFC, à męme compétence et męme expérience. Pour l'instant, cela profite surtout à Apple qui étoffe son offre logicielle de jour en jour, et à moindre frais.
Je dirais qu'on ne doit pas essayer d'utiliser l'Objective C comme alternative à C ou C++. L'Objective C est très souple et se prète bien à la gestion d'une application. C et C++ sont plus adaptés à du code efficace, bas niveau (genre algorithmes...). Les 3 sont complémentatires.
Je pense aussi que Objective C/Cocoa n'est pas reconnu à sa juste valeur pour l'instant; et cela est dû à la politique d'Apple. Cela peut changer dans 3 cas de figures:
- Apple ressuscite la Yellow Box (implémentation des librairies Cocoa pour Windows)
- Apple sort Mac OS X pour INTEL
- GNUstep (implémentation Open Source de Cocoa pour Windows et UNIX) accélère son développement.
Raphael
On Wednesday, February 19, 2003, at 12:38 PM, eva _242_ wrote:
From: Jean-Michel Reghem <[EMAIL PROTECTED]>
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:
---
<snip>
<private>Bonjour Jean-Michel,
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.
-- 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]>
