Développement Windows avec Objective-C

Question

Ayant récemment lu un sur Objective-C, il me semble un langage assez soigné avec beaucoup de fonctionnalités intéressantes.

Je n'ai pas l'intention de développer un iPhone, mais je comprends que GCC est capable de compiler du code Objective-C et donc je veux savoir - Objective-C est-il un langage alternatif viable au développement C99 pour Windows?

En particulier:

• Quelqu'un est-il en train de faire du développement Windows en utilisant Objective-C?
• Y a-t-il des composants d'exécution qui doivent être distribués avec mes applications?
• Je comprends que Objective-C est un sur-ensemble de C, cela signifie-t-il qu'il est possible d'utiliser n'importe quelle bibliothèque compatible C? (par exemple l'API Windows)
• Est-ce que j'obtiendrais la récupération de place dans mes applications?
• J'ai trouvé Cocotron et GNUstep qui sont souvent mentionnés quand on parle d'utiliser Objective-C sur d'autres plateformes, mais comme GCC peut déjà être utilisé pour compiler Objective-C, je ne comprends pas vraiment pourquoi j'en aurais besoin.
• Y a-t-il d'autres pièges ou pièges que je pourrais lancer en essayant le développement de Windows en utilisant Objective-C?

Answer 1

En ce qui concerne votre première question, je ne sais pas si quelqu'un est sérieusement faire du développement sur les fenêtres avec Objective-C, mais il peut y avoir, bien que ces chiffres seraient probablement moins que ceux qui font un travail sérieux avec un langage comme whitespace. Deuxièmement, vous auriez besoin, au minimum, de l'objectif c-runtime. Il y a deux temps d'exécution, le runtime de NeXT (maintenant Apple) et le runtime GNU Objective-C. Ils ne sont pas compatibles. Si vous êtes sur une plate-forme non-NeXT et non-Apple, comme windows, vous n'avez pas le choix, GNU runtime seulement.

Objective-C est un sur-ensemble de C, et oui vous pouvez utiliser l'API Win32 si vous le désirez directement dans votre code objectif-c. De plus, vous ne bénéficierez que de la récupération de place si vous utilisez un collecteur conservateur, et cela correspond aux bibliothèques que vous utilisez. En résumé: n °

Ce que GCC a en charge est le langage c-objectif et le runtime, pas de bibliothèque standard. Ce que GNU objc runtime vous fournit en termes de bibliothèque standard, c'est deux objets: Object, et la classe NXConstantString, qui est nécessaire pour prendre en charge la syntaxe @"". Object est simplement une classe de base. Pas très utile, hein? C'est pourquoi des frameworks comme Cocotron et GNUstep existent - pour vous donner accès à une implémentation de OPENSTEP/Cocoa. En ce qui concerne les pièges ou les pièges, oui: Votre application, même en utilisant Cocotron ou GNUstep peut ne jamais être portable sur le Mac par exemple, ou vous pouvez obtenir des bits comme des sélecteurs tapés dans l'exécution GNU objc, ou une pléthore d'autres problèmes. Laissez-moi finir de répondre à cette question en posant une autre question: Quels pièges ou pièges pourriez-vous rencontrer dans le ciblage .NET? Je suis sûr que certains, sinon la plupart, s'appliquent également dans ce cas. Pièges et pièges standard s'appliquent.

J'espère que cela aide.

Answer 2

Il n'y a pas encore de solution mature. Si vous développez la solution elle-même, vous pouvez le faire quand même. Mais si vous n'êtes pas, ce n'est pas le moment.

Pour les outils du compilateur, il y a LLVM/Clang qui sont open-source sous licence BSD. Le compilateur est sponsorisé par Apple, il compile donc complètement Objective-C et devient le compilateur principal pour Apple. Donc le compilateur n'est plus un problème.

Le problème est la bibliothèque d'environnement d'exécution. Le langage Objective-C dépend de son exécution. Le runtime définit tout le comportement du système objet et d'autres. La bibliothèque d'environnement d'exécution est le système de noyau et différente avec la bibliothèque de cadre comme Cocoa ou Quartz. dans .NET, c'est CRE, pas la bibliothèque de classes de framework .NET. Sans exécution, le programme ne peut pas être exécuté comme un programme .NET exécuté sous Windows sans runtime .NET.

Pour plus de détails, consultez cette conversation: http://lists.cs.uiuc.edu/pipermail/cfe-dev/2010-January/007593.html