Discussion :

[Gugelhupf]

Bonjour,

Swift semble être un langage de haut niveau, dont le fonctionnement ressemble plus ou moins aux technologies Java et .NET, mais dont la syntaxe s'approche plus du Python.

Je ne voudrais pas dire de bêtise, mais il me semble que pour Android (Dalvik), le mécanisme est le même que sur PC, la JVM interprète du bytecode. Tandis que sur Windows Phone, le code C# est compilé en binaire (meilleure économie pour les batteries certainement).
1. Jusqu'à présent, les appareils mobiles d'Apple n'intègre pas de GC, mais est-ce que cela va changer avec Swift ? Quel est le mécanisme "d'interprétation" d'un programme Swift ?
2. Est-ce que Swift est utilisable sur les appareils mobiles uniquement, ou bien toute la gamme Apple ? (Macbook etc)

Cordialement,

[Pierre Louis Chevalier]

Salut,

Je ne voudrais pas dire de bêtise, mais il me semble que pour Android (Dalvik), le mécanisme est le même que sur PC, la JVM interprète du bytecode. Tandis que sur Windows Phone, le code C# est compilé en binaire (meilleure économie pour les batteries certainement).

Dans les deux cas c'est pareil, c'est du JIT (just in time compiler), ça n'est donc ni du compilé classique (comme pour le C), ni de l’interprété, c'est entre les deux, c'est plus performant que de l'interprété.

Par contre swift est compilé, comme objective C.

2. Est-ce que Swift est utilisable sur les appareils mobiles uniquement, ou bien toute la gamme Apple ? (Macbook etc)

Il est dispo aussi sur Mac.

[Gugelhupf]

Concernant Windows Phone j'ai trouvé cette information sur internet :

TIL: Windows Phone 8 doesn't use a JIT compiler. Instead it uses a cloud-based optimizing compiler that automatically generates "almost done" native images for all apps, which are then quickly finalized on the phone itself in order to produce a native executable.

Source.

[Tibimac]

Il n’y a pas de GC mais il y a ARC (Automatic Reference Counting) qui est un système plus performant qu’un GC et qui de fait est utilisé par un grosse majorité de développeur iOS (je dis grosse majorité dans le doute, mais je n’en connait pas un seul qui ne l’utilise pas).

[yimson]

Bonjour,

SVP, quelqu'un pourrait-il expliquer le principe de fonctionnement du ARC ?

Cheers.

[Tibimac]

Bonjour @yimson : voici un lien qui explique cela avec plus de détail mais pas trop : http://www-igm.univ-mlv.fr/~dr/XPOSE...re/memory.html

[bredelet]

Bonjour,

SVP, quelqu'un pourrait-il expliquer le principe de fonctionnement du ARC ?

Cheers.

Le principe de départ est le compteur de références (non automatique), qui associe à chaque variable un nombre indiquant combien il existe de références à un objet. Quand le compteur atteint zéro, la mémoire de l'objet est libérée.

Par la suite le langage Objective C a introduit les "autorelease pools". Une variable spéciale est déclarée par exemple au début des fonctions. Après quoi, tout objet sur lequel tu invoque autorelease est attaché à cette variable (autorelease pool). Quand l'exécution atteint la fin de la fonction, les variables locales sont éliminées de la pile. Quand la variable spéciale est éliminée de la pile, toutes les variables attachées perdent une référence - et la plupart du temps leur mémoire est libérée.

Avec le compteur de références automatique, c'est simplement le compilateur qui met des déclarations d'autorelease pool et des appels à autorelease, retain (incrémente le compteur) et release (décrémente le compteur) là où il faut.

Mais pour bien fonctionner, il faut que l'utilisateur d'ARC annote les références à d'autres objets avec weak quand l'objet qui contient la référence n'est pas le "propriétaire" de l'objet référencé, de façon à éviter les références en boucle. Il n'est pas toujours facile de bien s'y prendre et à mon avis c'est l'obstacle principal à la démocratisation du langage.

Voir aussi les cours et tutoriels de formation pour apprendre la programmation swift.