64bits et C++
clampin
Membre
Bonjour,
Ma question va peut être vous paraà®tre idiote, mais je vais tout de même la poser...
J'ai lu que Carbon n'a pas droit au 64bit avec Léopard. Carbon étant déclaré en mort lente chez Apple.
Est-ce que cela veut dire que l'accès au 64bits sera définitivement fermé a ceux programment en C/C++ ? ou bien C/C++ est "par nature" uniquement qu'en 32bits et donc Apple a bien raison de "l'abandonné" et pousser Cocoa et Objective-C ?
A+
Ma question va peut être vous paraà®tre idiote, mais je vais tout de même la poser...
J'ai lu que Carbon n'a pas droit au 64bit avec Léopard. Carbon étant déclaré en mort lente chez Apple.
Est-ce que cela veut dire que l'accès au 64bits sera définitivement fermé a ceux programment en C/C++ ? ou bien C/C++ est "par nature" uniquement qu'en 32bits et donc Apple a bien raison de "l'abandonné" et pousser Cocoa et Objective-C ?
A+
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Tu confonds langage et runtime.
En 64 bits, rien ne t'empêche de faire des programmes en C ou C++. Ils fonctionneront bien (avec les options de compilations qui vont bien, comme celle que Schlum t'indique).
Par contre, dès l'instant où tu voudras utiliser des frameworks Apple (par exemple, tout ce qui concerne l'interface graphique) devra se faire en Obj-C.
A noter que Carbon ce n'est que du C.
Et Obj-C, mise à part la gestion des classes/objets, c'est du C aussi.
Enfin, l'IOKit (la couche système dans laquelle sont développés les drivers) est en C++.
Donc, la mort de C et C++ à cause du 64 bits, c'est uniquement dans tes rêves.
Dernière chose, tu peux même faire de l'Obj-C++, c'est à dire pragrammer en C++ tout en conservant la possibilité d'utiliser les classes/objets Obj-C (et donc de pouvoir utiliser les frameworks Apple).
Pour conclure, des pans entiers (du moins sous 10.4) de l'interface graphique sont fondamentalement codés dans Carbon et non dans cocoa.
Les classes cocoa (je pense par exemple à NSMenu) ne font que des redirections vers les procédures Carbon.
Aussi, je ne sais pas si sous 10.5, ils ont pû tout ré-écrire, mais Carbon est toujours un élément fondamental de OS X.
Donc son abandon ne se fera pas rapidement.
.
Bah disons, que c'est Foundation qui est arrivé en premier puis Core Foundation a été conçu à partir du travail effectué dans Foundation, et maintenant la plupart des class-clusters de Objective-C sont conçus sous le capot en utilisant des types de CF.
C'est ce qu'on peut appeler la magie d'Objective-C.
Sinon, 64 bits est adapté aux langages, mais pas à certains frameworks, comme Carbon je crois.
Donc tu peux très bien compiler ton code en 64 bits sans problème à priori.
Ouais, enfin maintenant CF est quand même la base du runtime Objective-CÂ :P (j'ai pas réussi à trouver les dates de naissances de CF et de Foundation ; mais j'imagine que Foundation est né avec l'Objective-C et NextStep)
CF a même en général de l'avance sur Foundation... Comme CoreGraphics a de l'avance sur les fonctions graphique de AppKit.
Par exemple, il est toujours impossible avec NSBezierPath de dessiner d'un coup l'intérieur et le bord (stroke & fill), alors que c'est possible avec CG depuis un bail !
Mais bon, on dérive du sujet là Â
La base du runtime d'Objective-C ? ??? Je suis d'accord sur le fait que beaucoup de classe de Foundation utilise en fait des types opaques de CF, mais je doute fort qu'il y ait un quelconque rapport avec le runtime... Qui lui relève de la bibliothèque Objective-C.
En fait, la séparation entre Foundation et AppKit est apparue avec OpenStep.
(suis tombé là dessus en cherchant sa date de naissance... Mais après coup c'est vrai que ça paraà®t bizarre...)
Et une référence à "CoreFoundation"...
Donc il y a peut-être un petit quelque-chose quand même ???
Oui, sans doute