›

Connaà®tre au run-time le runtime Objective-C

ChachaChacha Membre
11:07 modifié dans API AppKit #1
Oui, des fois, j'ai des questions bizarres.
Est-il possible, au run-time, de déterminer si le run-time Objective-C est en version 1 ou 2 ?

+
Chacha

Réponses

  • AliGatorAliGator Membre, Modérateur
    11:07 modifié #2
    C'est un peu de la triche mais... 
    [NSAutoreleasePool instancesRespondToSelector:@selector(drain)]

    Que le GC soit activé ou pas, en Obj-C 2.0 la méthode [tt]drain[/tt] existe (dans un cas il execute le GC dans l'autre il est équivalant à  un release) alors que dans le runtime OC 1.0 elle n'existe pas...

    J'ai pas trouvé de constante (fouiller dans NSObjCRuntime.h ?) qui donne un vrai numéro de version par contre...
  • Philippe49Philippe49 Membre
    août 2008 modifié #3
    dans 1218235559:

    J'ai pas trouvé de constante (fouiller dans NSObjCRuntime.h ?) qui donne un vrai numéro de version par contre...

    Certains fichiers d'entêtes (AvailabilityMacros.h) utilisent __OBJC2__ pour de la compilation conditionnelle, mais cela ne semble pas marcher dans un programme simple ??


    D'ailleurs y-a-t-il un endroit dans la doc ou sur les Technical Note qui fournirait un résumé de ces macros ?
  • Philippe49Philippe49 Membre
    11:07 modifié #4
    Bon c'est pour la compilation conditionnelle, mais il y a
    #if OBJC_NEW_PROPERTIES 

    source
  • ChachaChacha Membre
    août 2008 modifié #5
    dans 1218235559:

    C'est un peu de la triche mais... 
    [NSAutoreleasePool instancesRespondToSelector:@selector(drain)]

    Que le GC soit activé ou pas, en Obj-C 2.0 la méthode [tt]drain[/tt] existe (dans un cas il execute le GC dans l'autre il est équivalant à  un release) alors que dans le runtime OC 1.0 elle n'existe pas...

    Alors oui, c'est une bonne idée, mais en réalité c'est la version de l'AppKit que tu testes là , pas les capacités du langage. Mais bon, c'est très lié...


    J'ai pas trouvé de constante (fouiller dans NSObjCRuntime.h ?) qui donne un vrai numéro de version par contre...

    Moi non plus :(

    Quelques éclaircissements sur ma question: je suis en train de vous préparer un (mini) article pour les trucs & astuces, qui fait appel aux fonctions de base du run-time (class_addMethod...).
    Or, les fonctions (C) de manipulation de base ont changé depuis Objc-C 2.0, et les précédentes sont deprecated.

    J'aurais donc souhaité faire un code qui appelle automatiquement le bon jeu de fonctions d'après l'environnement. Le fait que ce soient des fonctions C et pas des méthodes Objective-C rend "difficile" l'introspection.

    Solution de secours : si libobjc ne dispose pas d'une fonction "getLibVersion()", on peut regarder soi-même si telle ou telle fonction existe...

        void* handle = dlopen("/usr/lib/libobjc.dylib", RTLD_LAZY | RTLD_NOLOAD);
         //je vous laisse vous documenter sur la signification des paramètres
        NSLog(@handle = %p, handle);
        void* f = !handle ? 0 : dlsym(handle, "class_addMethod");
        int objcVersion = (f != 0) ? 2 : 1;


    Je trouve juste que ce n'est pas très propre de spécifier "/usr/lib/libobjc.dylib" en dur dans le code. ça ne risque pas de changer de sitôt, mais bon...

    Y aurait-il moyen de récupérer un handle vers libobjc sans passer par dlopen, ou de pouvoir spécifier juste "objc" et non le chemin complet ? (cf les fonctions de dyld comme NSVersionOfLinkTimeLibrary()")

    Et au passage : NSVersionOfLinkTimeLibrary()/NSVersionOfRunTimeLibrary pourraient convenir, mais je ne comprends pas le numéro qui est renvoyé... ça me renvoie un million et quelques, donc je ne sais pas interpréter ce numéro comme "OC 1" ou "OC 2". Même en décomposant sur 4 octets, je ne retrouve pas de chiffres attendus.
    [edit]
    Ah, si, libobjc.dylib a bien un numéro de version de 227.0.0... mince alors, c'est pas bien clair...

    [/edit]


    +
    Chacha
Connectez-vous ou Inscrivez-vous pour répondre.