Ce forum est en partie financé par l’affichage de publicités. Merci de désactiver votre bloqueur de publicités pour nous permettre de continuer à fournir ce service.

pointeur, Handle

Discussion dans 'Développement Mac' créé par Vivid, 17 Août 2008.

  1. Vivid

    Vivid Membre d’élite

    Inscrit:
    9 Août 2005
    Messages:
    1 130
    J'aime reçus:
    143
    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:
     
  2. Dr_cube

    Dr_cube Membre confirmé

    Inscrit:
    27 Février 2006
    Messages:
    385
    J'aime reçus:
    28
    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.
     
  3. Vivid

    Vivid Membre d’élite

    Inscrit:
    9 Août 2005
    Messages:
    1 130
    J'aime reçus:
    143
    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 :D
     
  4. ntx

    ntx Vénérable sage
    Club MacG

    Inscrit:
    15 Octobre 2004
    Messages:
    12 007
    J'aime reçus:
    361
    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.
     
  5. Vivid

    Vivid Membre d’élite

    Inscrit:
    9 Août 2005
    Messages:
    1 130
    J'aime reçus:
    143
    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'
     
  6. ntx

    ntx Vénérable sage
    Club MacG

    Inscrit:
    15 Octobre 2004
    Messages:
    12 007
    J'aime reçus:
    361
    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.
     
  7. Anonyme

    Anonyme Invité

    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.
     
  8. Vivid

    Vivid Membre d’élite

    Inscrit:
    9 Août 2005
    Messages:
    1 130
    J'aime reçus:
    143
    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.
     
  9. Anonyme

    Anonyme Invité

    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.
     
  10. ntx

    ntx Vénérable sage
    Club MacG

    Inscrit:
    15 Octobre 2004
    Messages:
    12 007
    J'aime reçus:
    361
    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.
    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.
    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 :zen:
     
  11. Vivid

    Vivid Membre d’élite

    Inscrit:
    9 Août 2005
    Messages:
    1 130
    J'aime reçus:
    143
    ok ! :)

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

    En tout ca vos reponses sont claire :up:
     
  12. Céroce

    Céroce Membre émérite

    Inscrit:
    6 Octobre 2004
    Messages:
    949
    J'aime reçus:
    32
    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.
     
  13. Didier Guillion

    Didier Guillion Membre d’élite
    Club MacG

    Inscrit:
    20 Juillet 2001
    Messages:
    3 244
    J'aime reçus:
    164
    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
     
  14. Vivid

    Vivid Membre d’élite

    Inscrit:
    9 Août 2005
    Messages:
    1 130
    J'aime reçus:
    143
    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.
     
  15. Didier Guillion

    Didier Guillion Membre d’élite
    Club MacG

    Inscrit:
    20 Juillet 2001
    Messages:
    3 244
    J'aime reçus:
    164
    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
     
  16. Céroce

    Céroce Membre émérite

    Inscrit:
    6 Octobre 2004
    Messages:
    949
    J'aime reçus:
    32
    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.
     
  17. tatouille

    tatouille Vétéran

    Inscrit:
    1 Juin 2004
    Messages:
    5 174
    J'aime reçus:
    494
    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
     
  18. Vivid

    Vivid Membre d’élite

    Inscrit:
    9 Août 2005
    Messages:
    1 130
    J'aime reçus:
    143
    merci.
     
Chargement...