Quelle est la meilleure façon de créer des constantes dans Objective-C

156

Je crée un client Reddit à des fins d'apprentissage. J'ai besoin d'un fichier contenant des constantes. Je pensais importer le fichier dans le Reddit-Prefix.pchfichier pour rendre les constantes disponibles à tous les fichiers. Est-ce une bonne façon de faire les choses? Aussi, j'ai fait mes recherches et trouvé plusieurs méthodes pour créer des constantes, mais je ne sais pas laquelle utiliser:

  • #define macro
  • const
  • static const
  • extern const
  • enum

Alors, quelle est la voie préférée? Quelle est la convention? Je sais que "ça dépend" mais ma question plus spécifiquement est: Quels sont les cas d'utilisation de chacune de ces solutions?

De plus, si vous utilisez extern const, dois-je importer le fichier, ou les constantes seront-elles disponibles globalement sans importer le fichier?

Une chose que je pourrais logiquement conclure est que enumc'est le meilleur choix pour définir quelque chose comme des domaines d'erreur personnalisés (ai-je vraiment raison?). Mais qu'en est-il des autres?

objective-c  constants 
— Robert Audi
source
stackoverflow.com/questions/11153156/… s'il vous plaît visitez ce lien ... votre solution est dans ce post
— Utilisateur 1531343
3
@BhavikKama: C'est une question plus étroite opposant deux solutions spécifiques.
— Peter Hosey
pour - static const, #define, enum, ce lien est utile stackoverflow.com/questions/1674032/static-const-vs-define-in-c qui fournit une bonne explication sur ces 3 alternatives de const
— User 1531343
enumn'est utile que pour les valeurs intégrales. #defineet les constantes peuvent être de n'importe quel type de données.
— rmaddy
const, static constet extern constsont tous identiques sauf pour la portée. Il n'y a donc vraiment que trois choix.
— rmaddy

Réponses:

385

La première question est de savoir quelle portée vous voulez que vos constantes aient, qui sont en réalité deux questions:

  • Ces constantes sont-elles spécifiques à une seule classe ou est-il judicieux de les avoir partout dans l'application?
  • S'ils sont spécifiques à la classe, sont-ils destinés à être utilisés par les clients de la classe, ou uniquement au sein de la classe?

S'ils sont spécifiques et internes à une seule classe, déclarez-les en static consthaut du fichier .m, comme ceci:

static NSString *const MyThingNotificationKey = @"MyThingNotificationKey";

S'ils appartiennent à une seule classe mais devraient être publics / utilisés par d'autres classes, déclarez-les comme externdans l'en-tête et définissez-les dans le .m:

//.h
extern NSString *const MyThingNotificationKey;

//.m
NSString *const MyThingNotificationKey = @"MyThingNotificationKey";

Si elles doivent être globales, déclarez-les dans un en-tête et définissez-les dans un module correspondant, spécifiquement pour ces constantes.

Vous pouvez les mélanger et les assortir pour différentes constantes avec différents niveaux de globalité que vous voulez qu'elles soient, et pour différentes constantes globales qui ne vont tout simplement pas ensemble - vous pouvez les mettre dans des modules séparés, chacun avec son propre en-tête, si vous vouloir.

Pourquoi pas #define?

La vieille réponse est «les macros n'ont pas d'informations de type», mais les compilateurs d'aujourd'hui sont assez intelligents pour faire tout le contrôle de type pour les littéraux (vers lesquels les macros s'étendent) ainsi que pour les variables.

La réponse moderne est que le débogueur ne connaîtra pas vos macros. Vous ne pouvez pas dire [myThing addObserver:self forKey:MyThingNotificationKey]dans une commande de débogage si MyThingNotificationKeyest une macro; le débogueur ne peut le savoir que s'il s'agit d'une variable.

Pourquoi pas enum?

Eh bien, rmaddy m'a battu dans les commentaires: enumne peut définir que des constantes entières. Des choses comme les numéros d'identification de série, les masques binaires, les codes à quatre octets, etc.

À ces fins, enumc'est génial et vous devez absolument l'utiliser. (Encore mieux, utilisez les macros NS_ENUMetNS_OPTIONS .) Pour d'autres choses, vous devez utiliser autre chose; enumne fait rien d'autre que des entiers.

Et d'autres questions

Je pensais importer le fichier dans le fichier Reddit-Prefix.pch pour rendre les constantes disponibles pour tous les fichiers. Est-ce une bonne façon de faire les choses?

Probablement inoffensif, mais probablement excessif. Importez vos en-têtes de constantes là où vous en avez besoin.

Quels sont les cas d'utilisation de chacune de ces solutions?

  • #define: Assez limité. Honnêtement, je ne suis pas sûr qu'il y ait une bonne raison d'utiliser cela pour les constantes.
  • const: Idéal pour les constantes locales. De plus, vous devez l'utiliser pour celui que vous avez déclaré dans un en-tête et que vous définissez maintenant.
  • static const: Idéal pour les constantes spécifiques au fichier (ou à la classe).
  • extern const: Vous devez l'utiliser lors de l'exportation d'une constante dans un en-tête.

De plus, si vous utilisez extern const, dois-je importer le fichier, ou les constantes seront-elles disponibles globalement sans importer le fichier?

Vous devez importer le fichier, soit dans chaque fichier où vous l'utilisez, soit dans l'en-tête du préfixe.

— Peter Hosey
source
3
Pourquoi ne pas utiliser complètement static NSString *constdans le .hfichier?
— Iulian Onofrei
3
@IulianOnofrei: Vous pouvez, si c'est dans une application et non dans un framework. Si vous le faites static NSString *const foo = @"foo";, votre en-tête détermine ce qu'est la chaîne, et elle doit être la même partout - si jamais vous changez la chaîne et que différentes parties utilisent différentes versions de l'en-tête avec une chaîne différente, alors les chaînes ne correspondront pas à l'exécution temps. Dans un framework, vous souhaitez fournir un accès au symbole uniquement et laisser le framework être la seule source de la vraie valeur de ce symbole, afin que tout le monde obtienne la même chaîne d'un seul endroit. C'est ce qui externvous attire.
— Peter Hosey
Remarque supplémentaire sur les #defines: ils ne sont pas garantis d'avoir la même adresse en mémoire (selon la façon dont ils sont déclarés, ils peuvent allouer une nouvelle instance à chaque fois qu'ils sont utilisés), donc l'utilisation myObject == MyDefinene fonctionnera pas toujours comme prévu, mais le myObject == MyStaticConstfera.
— Ben Leggiero
Est-ce que ça a du sens dans l'orthographe comme static NSString *constau lieu de static NSString const*?? Des différences?!
— kokos8998
@ kokos8998 fait-il une différence? Oui. static NSString const *est le même que static const NSString *et signifie "un pointeur (modifiable) vers une NSString constante" - ce qui est un peu inutile ici car NSString est déjà immuable. Ce que vous voulez uniquement static NSString * const- qui est un "pointeur constant vers une chaîne NSS"
— David
8

FOUNDATION_EXPORT

Pensez à utiliser FOUNDATION_EXPORTpour un peu plus de compatibilité que externcar il est défini dans la fondation et compile aux formats compatibles pour C, C ++ et Win32.

Tel que défini dans NSObjCRuntime.h

#if defined(__cplusplus)
#define FOUNDATION_EXTERN extern "C"
#else
#define FOUNDATION_EXTERN extern
#endif

#if TARGET_OS_WIN32

    #if defined(NSBUILDINGFOUNDATION)
        #define FOUNDATION_EXPORT FOUNDATION_EXTERN __declspec(dllexport)
    #else
        #define FOUNDATION_EXPORT FOUNDATION_EXTERN __declspec(dllimport)
    #endif

    #define FOUNDATION_IMPORT FOUNDATION_EXTERN __declspec(dllimport)

#else
    #define FOUNDATION_EXPORT  FOUNDATION_EXTERN
    #define FOUNDATION_IMPORT FOUNDATION_EXTERN
#endif
— Steve Moser
source
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.