chaud cocoa, chaud chaud...
- Créateur du sujet Vivid
- Date de début
pour cocoa, il est préférable de coder en objectiveC, qui n'est pas du C++, mais une évolution du c pour faire de la programmation objet (comme le C++, mais c'est une autre branche de l'évolution).
Il y a l'objectiveC++ qui allie les 2 langage, mais c'est pas la question...
je ne pense pas qu'il soit facile de faire du cocoa en C puisque justement Cocoa est une librairie de classes orienté objet pour macOSX.
Ensuite, tout dépends de ce que tu entends par Cocoa. Si c'est juste pour l'interface graphique, tu peux tout a fait faire ton interface graphique en Cocoa/ObjectiveC et le reste de ton appli en c. Mais tu perds l'avantage de la programmation objet. Cocoa offre toute une série de classes d'objets non graphique qui sont bien utile (les listes, les dictionnaires, les chaines, ... )
pourquoi ne veux tu faire que du C ?
Il y a l'objectiveC++ qui allie les 2 langage, mais c'est pas la question...
je ne pense pas qu'il soit facile de faire du cocoa en C puisque justement Cocoa est une librairie de classes orienté objet pour macOSX.
Ensuite, tout dépends de ce que tu entends par Cocoa. Si c'est juste pour l'interface graphique, tu peux tout a fait faire ton interface graphique en Cocoa/ObjectiveC et le reste de ton appli en c. Mais tu perds l'avantage de la programmation objet. Cocoa offre toute une série de classes d'objets non graphique qui sont bien utile (les listes, les dictionnaires, les chaines, ... )
pourquoi ne veux tu faire que du C ?
le C++ comme tout langage orienter objet; beaucoup de fonctionalites, pratique quelque part, mais en definitive, pour etre clair, je m'enmerde :sleep: et cette desagreable impression d'avoir une distance entre toi et ta machine, de plus ces instructions 'romancer' :rolleyes: ... pas lisible trop fouillis.
Le C++ ne m'apporte aucun plaisir, j'aime pas ces langages a la 'lego'.
Apparement du monde s'y met, mais meme pour des gros projets, de l'organisation de la riguer et le C suffit amplement, pourquoi changer...
je programme pour programmer par pour que l'on programme a ma place. Et ces ce que fait tout ces langages orientes objets.
Alors les 'managers' (QuickDraw manager...) c'est terminer?
il existe un lien qui repertories toutes ces fonctions (ou api)? du style de mon bouquin 'Programmation Mac avec think pascal' qui te donne les principales fonctions, une vue precise sur chaque fonction, avec une vue generale sur chaque manager qui les emplois.
Le C++ ne m'apporte aucun plaisir, j'aime pas ces langages a la 'lego'.
Apparement du monde s'y met, mais meme pour des gros projets, de l'organisation de la riguer et le C suffit amplement, pourquoi changer...
je programme pour programmer par pour que l'on programme a ma place. Et ces ce que fait tout ces langages orientes objets.
Alors les 'managers' (QuickDraw manager...) c'est terminer?
il existe un lien qui repertories toutes ces fonctions (ou api)? du style de mon bouquin 'Programmation Mac avec think pascal' qui te donne les principales fonctions, une vue precise sur chaque fonction, avec une vue generale sur chaque manager qui les emplois.
Bonjour,
pour utiliser Cocoa, il faut programmer soit en objective-c soit en Java (mais Apple a décidé d'abandonné le portage de Cocoa sur ce langage : donc objective-c).
L'objective-c comme Java ou C++ est un langage objet. Il est en fait une sur-couche du C pour implémenter l'utilisation des objets. C'est une autre façon de penser la programmation, rien à voir avec des langages procéduraux comme le Pascal ou le C. Et c'est justement cette programmation orientée objet qui permet de faire une API comme Cocoa. Mais il est très difficile de faire un lien entre ces deux technologies.
Si tu veux utiliser Cocoa, tu jettes ton bouquin de programmation en Pascal, et tu achètes "Cocoa par la pratique" ainsi qu'un livre de programmation orientée objet
Si tu veux continuer à programmer en C, il faudra te contenter des API Carbon (condamnées à cours terme car non portées sur x86 mais pour le moment tout à fait utilisable).
Désolé pour ce changement de technologie mais tu es victime du "progrès". Et si tu t'y mets, tu te rendras vite compte que contrairement à ce que tu penses, les langages objets donnent du code beaucoup plus simple et plus clair que la programmation procédural (voir les exemples d'Apple tel que le navigateur web sans une seule ligne de code, ou l'éditeur de texte écrit en 5 mn). Et il permet des choses qui ne seraient possibles qu'à grand coup de macros dans tous les sens, ce qui est très peu élégant; ces langages permettent de produire du code plus facilement réutilisable. Un exemple : essaies de faire un programme de calcul matriciel sur toutes sortes d'objets (entiers, réels, flottants, complexes, matrices, ...) en C et un en C++, tu verras la différence. Mais je ne dit pas que cela sera exécuter plus vite La programmation d'une interface graphique est aussi un bon exemple de l'utilisation d'un langage objet.
pour utiliser Cocoa, il faut programmer soit en objective-c soit en Java (mais Apple a décidé d'abandonné le portage de Cocoa sur ce langage : donc objective-c).
L'objective-c comme Java ou C++ est un langage objet. Il est en fait une sur-couche du C pour implémenter l'utilisation des objets. C'est une autre façon de penser la programmation, rien à voir avec des langages procéduraux comme le Pascal ou le C. Et c'est justement cette programmation orientée objet qui permet de faire une API comme Cocoa. Mais il est très difficile de faire un lien entre ces deux technologies.
Si tu veux utiliser Cocoa, tu jettes ton bouquin de programmation en Pascal, et tu achètes "Cocoa par la pratique" ainsi qu'un livre de programmation orientée objet
Si tu veux continuer à programmer en C, il faudra te contenter des API Carbon (condamnées à cours terme car non portées sur x86 mais pour le moment tout à fait utilisable).Désolé pour ce changement de technologie mais tu es victime du "progrès".
Et si tu t'y mets, tu te rendras vite compte que contrairement à ce que tu penses, les langages objets donnent du code beaucoup plus simple et plus clair que la programmation procédural (voir les exemples d'Apple tel que le navigateur web sans une seule ligne de code, ou l'éditeur de texte écrit en 5 mn). Et il permet des choses qui ne seraient possibles qu'à grand coup de macros dans tous les sens, ce qui est très peu élégant; ces langages permettent de produire du code plus facilement réutilisable. Un exemple : essaies de faire un programme de calcul matriciel sur toutes sortes d'objets (entiers, réels, flottants, complexes, matrices, ...) en C et un en C++, tu verras la différence. Mais je ne dit pas que cela sera exécuter plus vite La programmation d'une interface graphique est aussi un bon exemple de l'utilisation d'un langage objet.
Je savait pas qu'ils avait imposer Objective-C!
impossible de faire du Pascal, du fortran...? si quand meme, non?
impossible de faire du Pascal, du fortran...? si quand meme, non?
il est possible d'utiliser n'importe quel langage (pourvu qu'un compilo le supporte) pour faire une appli en ligne de commande, mais pour utiliser Cocoa, il faut faire de l'objectiveC (vu que les nauveauté ne sont plus sur java)
Vivid a dit:
Je ne suis pas d'accord avec toi.
Je trouve la lecture de l'objectiveC relativement simple. En C la gestion de la mémoire est relativement lourde. Les notion d'héritage est également très lourde à mettre en place en C alors que c'est la base des langages objets.
Pour être encore plus proche de ta machine, il reste encore l'assembleur...
Le problème d'un langage objet, c'est qu'il ne faut pas partir tout de suite dans le code (comme c'est possible en C). Il faut passer par une phase d'analyse et de conception afin de bien repertorier les classes. Sinon c'est le bordel complet (quand on arrive à ses fins). Alors oui, au départ ca peut paraitre très lourd et anti productif, alors qu'en fait, c'est beaucoup plus souple et facile une fois que l'analyse est faite.
BooBoo a dit:
"pourvu qu'un compilo le supporte" c'est a dire realbasic par exemple, qui interface lui meme ces acces sur le systeme.
"pour faire une appli en ligne de commande"=>GCC? en meme temps si tu peut pas ouvir une fenetre, afficher des couleurs, comme en C standard?
Vivid a dit:
je ne comprends pas trop ta question:
par "ouvir une fenetre, afficher des couleurs" tu veux dire faire une interface graphique ? dans ce cas, c'est possible en C (par la librairie Carbon) mais pas en cocoa.
Je ne connais pas realBasic, mais je suppose que le language utilisé est le basic (tu n'as donc pas le choix du langage). Son interface avec sa librairie graphique doit également êter en basic.
Mais qu'est-ce qu'il dit :eek:
Si carbon n'existe plus sous x86, il n'y aura pas grand chose qui fonctionnera, même pas cocoa
En fait c'est classic qui disparaît sous x86 ...
Vivid, j'ai une super idée pour toi, programme en assembleur, là tu maitrises vraiment ce que tu fais
Plus sérieusement, sous OS X tu peux programmer dans une foule de langages (ex C, C++, ObjC, Java, Perl, Ruby, Eiffel ...)
Chaque langage possède ses qualités et il convient de choisir le plus approprié à ce que l'on veut faire. Pour un utilitaire en ligne de commande, le C. Pour du developpement web, PHP, java , etc.
Tous les OS modernes possèdent des interfaces graphiques sophistiquées et les langages objets sont tout à fait adaptés à la gestion de ces interfaces, car elles se composent elles mêmes d'une multitude d'objets (fenêtre, bouton, menu, etc)
Un lien qui pourra t'aider http://www.chibineko.org/article5.shtml
Pour en revenir à ton langage préféré, le C, l'API carbon possède tout ce qu'il faut pour faire des applis aussi complexes qu'en cocoa, mais je te souhaite bien du courage
mpergand a dit:Mais qu'est-ce qu'il dit :eek:
Si carbon n'existe plus sous x86, il n'y aura pas grand chose qui fonctionnera, même pas cocoa
En fait c'est classic qui disparaît sous x86 ...
Vivid, j'ai une super idée pour toi, programme en assembleur, là tu maitrises vraiment ce que tu fais
Plus sérieusement, sous OS X tu peux programmer dans une foule de langages (ex C, C++, ObjC, Java, Perl, Ruby, Eiffel ...)
Chaque langage possède ses qualités et il convient de choisir le plus approprié à ce que l'on veut faire. Pour un utilitaire en ligne de commande, le C. Pour du developpement web, PHP, java , etc.
Tous les OS modernes possèdent des interfaces graphiques sophistiquées et les langages objets sont tout à fait adaptés à la gestion de ces interfaces, car elles se composent elles mêmes d'une multitude d'objets (fenêtre, bouton, menu, etc)
Un lien qui pourra t'aider http://www.chibineko.org/article5.shtml
Pour en revenir à ton langage préféré, le C, l'API carbon possède tout ce qu'il faut pour faire des applis aussi complexes qu'en cocoa, mais je te souhaite bien du courage
c'est peut-etre plus facile, mais je pense pas qu'il y est des applications cocoa revolutionnairement plus complexe que ce que l'on a fait jusqu'a present, non?.
Je pense que tu veut parler de l'interface graphique, aqua.
Carbon marchera sans Rosetta ?mpergand a dit:Mais qu'est-ce qu'il dit :eek:
Si carbon n'existe plus sous x86, il n'y aura pas grand chose qui fonctionnera, même pas cocoa
En fait c'est classic qui disparaît sous x86 ...
Il me semble qu'Apple préconise d'utiliser Cocoa pour faire des applications utilisables à la fois sous PPC et sous x86 ? Et si actuellement Cocoa repose sur Carbon, rien ne dit que ce sera encore le cas dans quelques années ou que cette APi sera accessible aux développeurs.
Donc si on débute, vaut mieux se mettre à l'objective-c et à Cocoa plutôt que de se lancer dans Carbon.
Sur ce LIEN il est dit que:
Pour que Carbon disparaisse, il faudrait qu'il existe un équivalent CoreServices de tous les managers Carbon, ce qui est loin d'être le cas.
D'autre part, pour tous ceux qui rêvent de voir une version Cocoa de Photoshop ou Office, il faut vous convaincre que cela n'arrivera jamais. ObjectiveC/Cocoa est inadapté pour ce type de grosses applications portables. Adobe utilise ces propres biblios mathématique, graphique et de fenêtrage (en open source http://opensource.adobe.com/group__asl__overview.html) et ça risque pas de changer de sitôt
Pour que Carbon disparaisse, il faudrait qu'il existe un équivalent CoreServices de tous les managers Carbon, ce qui est loin d'être le cas.
D'autre part, pour tous ceux qui rêvent de voir une version Cocoa de Photoshop ou Office, il faut vous convaincre que cela n'arrivera jamais. ObjectiveC/Cocoa est inadapté pour ce type de grosses applications portables. Adobe utilise ces propres biblios mathématique, graphique et de fenêtrage (en open source http://opensource.adobe.com/group__asl__overview.html) et ça risque pas de changer de sitôt
Merci pour le lien vers l'ASL. je ne savais pas qu'Adobe avait développé ses propres librairies pour faire les interfaces de ses applications.
En tout cas, ça fait une librairie cross-plateforme de plus pour développer des applications open-source.
En tout cas, ça fait une librairie cross-plateforme de plus pour développer des applications open-source.
comme je les comprends , l'ayants fait moi meme pour m'amuser, independant et libre...
De l'investissement a long terme. Et quand tu passe d'une machine, a une autre, tu as le plaisir de te rendre compte que ton appli n'est pas 'vide', sans sa plate-forme d'origine.
, l'ayants fait moi meme pour m'amuser, independant et libre... De l'investissement a long terme. Et quand tu passe d'une machine, a une autre, tu as le plaisir de te rendre compte que ton appli n'est pas 'vide', sans sa plate-forme d'origine.
