pointeur, Handle

[Vivid]

Bijour,

sous Cocoa, les handles et pointeurs sont toujours utiliser je suppose?

je trouve cela ou dans la doc Apple, data management ?

je m'instruis, je m'instruis... :sleep:

 

[Dr_cube]

Salut,

Je ne suis pas sûr d'avoir compris la question, mais oui, les pointeurs sont constamment utilisés. Dès que tu crées un nouvel objet tu récupères un pointeur sur cet objet. On ne manipule quasiment que des pointeurs en Cocoa.

 

[Vivid]

Salut,

Je ne suis pas sûr d'avoir compris la question, mais oui, les pointeurs sont constamment utilisés. Dès que tu crées un nouvel objet tu récupères un pointeur sur cet objet. On ne manipule quasiment que des pointeurs en Cocoa.

ca ok, j'ai vue, desole j'ai pas ete precis, je parlait des pointeurs et handle sur un type de variable quelconque.

la mémoire sous X est gerer comme sous Os 9; la fragmentation avec les pointeurs, l'utilisation des Handles ?

NewHandle ou New Pointeur sont devenus des classes ?

je doit etre lourd

 

[ntx]

Je pense que tu est encore trop dans les API C de Mac OS classique. Cocoa n'a plus rien à voir, il n'y a plus du tout de notion de handler. Cette notion n'existe plus que dans les librairies C encore utilisées par Apple, en programmation objet cela n'a pas de sens, et encore moins en obj-c où tout objet est un pointeur.

 

[Vivid]

Je pense que tu est encore trop dans les API C de Mac OS classique. Cocoa n'a plus rien à voir, il n'y a plus du tout de notion de handler. Cette notion n'existe plus que dans les librairies C encore utilisées par Apple, en programmation objet cela n'a pas de sens, et encore moins en obj-c où tout objet est un pointeur.

effectivement...
en tout cas j'accroche pas, tres vite cela devient bordelique, ces imbrications, recursivitées...
enfin je trouve, j'ai pas finit mon bouquin non plus.

En plus c'est dommage ne plus y avoir acces (handle...) aussi 'profondement'

 

[ntx]

Je ne te suis pas là, tu veux avoir accès à quoi ? Quelle récursivité ?
J'espère que tu as capté que Cooca et Obj-C, c'est de la programmation objet plus du procédural.

 

[Anonyme]

Je travaillais avec codewarrior auparavant et j'avais modifié Powerplant (sheet window, drawer window, etc ....). Puis je l'ai transformé en universal binary.

Voici le lien.

J'ai eut du mal à me décider à faire le saut sous Cocoa.

La logique est différente.

Mais je ne reviendrais pas en arrière, c'est trop efficace.

Tout ce que je faisais auparavant je le fais actuellement en 5 à 10 fois plus court.

Je n'utilise pas les bindings ni le garbage collector car le premier est trop fixé pour faire des customs parts, le deuxième je n'aime pas car on programme ensuite n'importe comment.

Les bindings sont intéressants mais trop opaques. Quand il s'agit de chercher un bug ou de pousser le concept plus loin, on rencontre beaucoup de problème.

On ne sait jamais d'ou vient le bug.

Je t'encourage à faire le pas.

A+

Philippe.

 

[Vivid]

Je ne te suis pas là, tu veux avoir accès à quoi ? Quelle récursivité ?
J'espère que tu as capté que Cooca et Obj-C, c'est de la programmation objet plus du procédural.

peut-être pas de récursivité, mais d'imbrication entre les Objects (p.261 cocoa par la pratique).

ce n'est plus procédural mais dans (cocoa par la pratique) page 31, la figure 2.28 parle bien de boucle d'evenement. Il y a bien un evenement ou des evenement possible dans une file d'attente.

puisque tu connait mieux que moi cocoa, quel sont les changements dans la gestion des pointeurs et de la memoire par rapport a Os 9, meme si j'ai ma petite idee.

 

[Anonyme]

Les pointeurs sont toujours présents dans cocoa.

Maintenant les handles le sont aussi, si tu mixes du code Carbon/Cocoa.

Quand j'ai migré mon projet à l'époque je l'ai fait en trois temps :
• CW à Xcode dans une premier temps sous PowerPlant.
• Puis ensuite de Powerplant à Powerplant/Cocoa sous objectiveC++.
• Puis je vire à vitesse accéléré tout code Carbon actuellement.

La gestion des handles ne se justifie plus actuellement.
- j'ai tout viré, il me reste de 5% de code en Handle avec des petites partie en PicHandle ou AliasHandle.

Mais tout est plus puissant sous cocoa.

Je suis partie en fait d'APW (Apple programmer workshop) puis je suis passé à MPW (Macintosh programming workshop) à l'époque sous système GSOS sous Apple IIGS puis MacOS sous système 7. Avec la gestion pur GetNextEvent et WaitNextEvent.

J'ai connu les début de CW et de Powerplant la migration OS 7-9 à OS X.


Handle/Pointer se résume je dirais à une logique qui vient de la toolbox batit à l'époque pour un langage non objet au départ (Pour du pascal ou du C et non du C++).

Le handle permettait de stoquer "les données de du pointeur" dans une certaine mesure (PicHandle par exemple).

Il faut oublier maintenant.


Tout est actuellement basé sur un logique objet/méthode : gestion des devices, gestions des fichiers, des threads tout de A à Z.

Les pointeurs existent donc toujours mais plus mais pointe toujours sur des objets qui contiennent des méthodes pour accéder au données.

Je me souviens de :
- la gestion des proxy icon à l'époque, actuellement cela se fait automatiquement.
- les threads coopératifs avec les yield et les récupération dans la gestion des évéments, ou Multiprocessing Api que j'utilise encore.
- la gestion des noms longs a été une horreur et le passage des FSSpec au FSRef, beurk.
- la gestion des resources forks quel horreur quand on devait faire une traduction (ResEdit) ou Rez/Derez sous MPW.
- etc ...

Au secours quel horreur.

Il faut penser actuellement objet et non plus code, mieux MVC !!!!! (Model vue controlleur).

J'ai eut beaucoup de mal avec cela.

Je pensais trop complexe, je voulais réinventer la roue.

Actuellement je cherche NS (NextStep) et non plus Carbon anciennement CFM anciennement Toolbox Mac.

Un conseil : essayes d'oublier tes réflexes !

Les Handles ne se justifient plus actuellement.

Pour cocoa par la pratique il y a quelque petites choses d'outdated.

Il vaudrait mieux utiliser Xcode 2.5 d'abord avant Xcode 3.0 ou 3.1.



A+

Philippe.

 

[ntx]

peut-être pas de récursivité, mais d'imbrication entre les Objects (p.261 cocoa par la pratique).

Désolé mais je n'ai pas la même version du livre que la tienne. Le but d'un framework est de fournir un cadre d'objets réutilisables donc oui des objets utilisent d'autres objets.

ce n'est plus procédural mais dans (cocoa par la pratique) page 31, la figure 2.28 parle bien de boucle d'evenement. Il y a bien un evenement ou des evenement possible dans une file d'attente.

Dans ma version le titre du graphique est "Timeline", il ne s'agit pas à proprement de la boucle de gestion des événements comme on peut la rencontrer dans d'autres API mais une présentation dans le temps du fonctionnement de l'application et du moment où interviennent les différentes fonctions implémentées dans les objets qui gèrent l'application. Dans Cocoa il n'y a pas de boucle d'événements à gérer.

puisque tu connait mieux que moi cocoa, quel sont les changements dans la gestion des pointeurs et de la memoire par rapport a Os 9, meme si j'ai ma petite idee.

Tu n'es plus en C donc tu n'as plus à allouer et libérer tes pointeurs via les fonctions C standards alloc, malloc ou free. Tu dois utiliser la mécanique obj-c qui utilise un constructeur, gère un compteur d'instances et désalloue l'objet quand le compteur tombe à zéro. C'est d'ailleurs le même genre de mécanique qu'en Java sauf que là elle est cachée.

Pour le reste pas mieux que Phil

 

[Vivid]

ok !

Cela me donne une impression bizarre... une certaine séparation avec la machine.

En tout ca vos reponses sont claire

 

[Céroce]

Juste pour compléter ce qui a été dit: les handles sous OS < 10, sont des pointeurs sur des pointeurs, ce qui permettait de déplacer les blocs en mémoire pour limiter sa fragmentation. Sous OS 10, l'espace mémoire est virtualisé, c'est à dire qu'il y a un composant, la MMU, qui convertit les pointeurs d'un espace mémoire virtuel vers l'espace mémoire (absolu) du microprocesseur.

C'est difficile d'expliquer mieux en quelques lignes, mais tu peux toujours chercher sur le net des explication sur la virtualisation de l'espace mémoire.

 

[Didier Guillion]

Juste pour compléter ce qui a été dit: les handles sous OS < 10, sont des pointeurs sur des pointeurs, ce qui permettait de déplacer les blocs en mémoire pour limiter sa fragmentation. Sous OS 10, l'espace mémoire est virtualisé, c'est à dire qu'il y a un composant, la MMU, qui convertit les pointeurs d'un espace mémoire virtuel vers l'espace mémoire (absolu) du microprocesseur.

C'est difficile d'expliquer mieux en quelques lignes, mais tu peux toujours chercher sur le net des explication sur la virtualisation de l'espace mémoire.

Là je ne comprends pas. Quel rapport entre un handle et la virtualisation de la mémoire ?
Sous OS 10 les handles restent des pointeur sur des pointeurs.

Cordialement

 

[Vivid]

Là je ne comprends pas. Quel rapport entre un handle et la virtualisation de la mémoire ?
Sous OS 10 les handles restent des pointeur sur des pointeurs.

Cordialement

Il voulait peut-être dire que depuis la Virtualisation, il n'y a plus de risque de fragmentation de la ram, d'ou la fin de l'intérêt des Handles.

 

[Didier Guillion]

A mon avis, l'avantage des handles est de pouvoir fournir une reference fixe a une zone de données dont la taille peut varier facilement.
Un peu la difference entre NSArray et NSMutableArray en Obj-c

Cordialement

 

[Céroce]

Là je ne comprends pas. Quel rapport entre un handle et la virtualisation de la mémoire ?
Sous OS 10 les handles restent des pointeur sur des pointeurs.

Le problème de la fragmentation de la mémoire existe dans les deux cas.

Sous Classic, un pointeur pointe sur une adresse absolue. Si tu accèdes à l'adresse 0x3000, le bus d'adresse du micro sera effectivement positionné à la valeur 0x3000.
-> Pour pouvoir déplacer des blocs en mémoire, il faut utiliser des pointeurs sur des pointeurs.

Sous Unix, chaque processus possède son propre espace d'adressage. Il est tout à fait possible que dans deux processus différents, deux pointeurs aient la valeur 0x3000. Seulement, les adresses sont converties par la MMU, ainsi le bus d'adresse sera mis à 0x00203000 quand le premier processus y accède et à 0x00213000 quand le deuxième y accède (c'est un exemple).
-> Pour déplacer des blocs en mémoire, l'OS reprogramme la MMU pour modifier la translation d'adresse.

Certains sauront expliquer avec d'avantage de détails, mais le principe est là. Quant aux handles sous OS X, ce n'est à mon avis qu'un héritage pour que les vieilles applis Carbon puissent tourner.

 

[tatouille]

effectivement...
en tout cas j'accroche pas, tres vite cela devient bordelique, ces imbrications, recursivitées...
enfin je trouve, j'ai pas finit mon bouquin non plus.

En plus c'est dommage ne plus y avoir acces (handle...) aussi 'profondement'

KVO key value observer c'est un peu ce principe, delegate ecetera ca existe belle est bien
c'est aussi tres dur au debut de trouver son code beautifier, pour ce qui est de la mem c'est une gestion protegee
il y a bien sur des outils pour partager des zones de mem entre differente appli, shm, regarde comment fonctionne une nszone, tu peux avoir cette profondeur d'access en obj-c overloader, overwriter ecetera, il y a dans la meme idee "get or apply a pointer by name" @protocol

 

[Vivid]

KVO key value observer c'est un peu ce principe, delegate ecetera ca existe belle est bien
c'est aussi tres dur au debut de trouver son code beautifier, pour ce qui est de la mem c'est une gestion protegee
il y a bien sur des outils pour partager des zones de mem entre differente appli, shm, regarde comment fonctionne une nszone, tu peux avoir cette profondeur d'access en obj-c overloader, overwriter ecetera, il y a dans la meme idee "get or apply a pointer by name" @protocol

merci.