›

Echecs : partie 3

muqaddarmuqaddar Administrateur
février 2007 modifié dans API AppKit #1
Revenir sur les coups

Déplacement entre les coups joués au moyen de boutons, avec mise à  jour de l'échiquier et de l'affichage.
Possibilité de modifier la partie depuis n'importe quel coup.

Sujets abordés:
- classe NSMutableArray
- classe NSData

Nouvelles méthodes:
-(IBAction)toStart:(id)sender;
-(IBAction)stepBack:(id)sender;
-(IBAction)stepForward:(id)sender;
-(IBAction)toEnd:(id)sender;

Méthodes modifiées:
-(void)initBoard;
-(void)mouseUp:(NSEvent *)theEvent;

Dans le prochain tutorial, on apprendra comment sauvegarder et charger une partie !

[Fichier joint supprimé par l'administrateur]

Réponses

  • fouffouf Membre
    12:21 modifié #2
    Toujours très bien

    Juste une question pour WIMP : pourquoi ne fais-tu pas un [super dealloc]; après le [game release]; dans la méthode dealloc justement ?

    Bonne continuation ;)
  • WIMPWIMP Membre
    12:21 modifié #3
    dans 1130773343:

    Juste une question pour WIMP : pourquoi ne fais-tu pas un [super dealloc]; après le [game release]; dans la méthode dealloc justement ?

    Pourquoi faudrait-il le faire ?
    ( C'est l'histoire du jésuite à  qui on demande "Pourquoi les jésuites répondent-ils toujours à  une question par une autre question?", et qui répond: "Pourquoi pas?" ) ;)
    Plus sérieusement, je ne suis pas jésuite, et je ne m'étais pas posé la question.
    En toute rigueur, et si j'en juge par d'autres exemples, ta remarque est juste:
    [game release] remet à  zéro le compteur sur game, ce qui libère son espace mémoire.
    [super dealloc] libère la mémoire occupée par ChessView.
    Mais tout ça n'affecte en rien l'exécution du programme. On pourrait se passer completement de dealloc, mais c'est à  déconseiller. On met dealloc par application du principe de précaution, pour être sur que la mémoire n'est pas encombrée inutilement une fois qu'on a quitté l'application.
    dealloc n'est jamais appelée par l'appli, et on n'est même pas certain qu'elle le soit quand on quitte, puisque la fenêtre est détruite par la même occasion.
  • SystemSystem
    novembre 2005 modifié #4
    dans 1130854580:

    On met dealloc par application du principe de précaution, pour être sur que la mémoire n'est pas encombrée inutilement une fois qu'on a quitté l'application.
    dealloc n'est jamais appelée par l'appli, et on n'est même pas certain qu'elle le soit quand on quitte, puisque la fenêtre est détruite par la même occasion.


    Dans ce cas bien précis, effectivement le [super dealloc] n'est pas indispensable (et même surcharger dealloc ne l'est pas en fait), car lorsqu'on quitte une application la mémoire est purgée sans suivre les procédures normales de deallocation (donc tout ce qui appartient à  l'application est détruit, dealloc ou pas) et que dans ton cas il n'y a qu'une vue qui est instanciée.

    Mais si tu penses vraiment que c'est un principe de précaution, c'est là  une "grave" erreur. Si tu oublies de le mettre, les objets créés ne seront jamais libérés (sauf lorsqu'on quitte l'application évidemment), seules les variables d'instance déclarées dans la sous-classe créée le seront, mais l'objet lui même non, car il faut pour cela appeler le dealloc de NSObject, et la seule façon de le faire est de mettre un [super dealloc] pour toutes les sous-classes qui surchargent cette méthode.

    Et comme le plus simple est de ne pas se prendre la tête, autant mettre systématiquement le [super dealloc]; à  la fin de la méthode dealloc (le mettre au début libérera l'objet, mais pas ses 'nouvelles' variables d'instance).
Connectez-vous ou Inscrivez-vous pour répondre.