J'ai lu dans plusieurs postes et dans les directives de code d'Apple que, dans les constantes de chaîne de l'objectif-C, doit être définie comme étant externe Merci Mise à jour: Dans ce cas, c'est bon d'utiliser un #define ou une meilleure approche? < / p> nstring * const my_constant; et que la directive #define doit être évitée. Pourquoi donc? Je sais que #define est exécuté à l'heure précompilie, mais toute la chaîne partagera la même adresse mémoire. Le seul avantage que j'ai lu était que si la constante doit être mise à jour ou modifiée, vous n'avez pas à recompiler tout votre projet. C'est donc la raison pour laquelle #define devrait être évitée?
5 Réponses :
Autant que je sache, Fichier d'en-tête:
fichier principal:
#define ne vous permet que de définir des constantes de cordle de style C. Pour créer un objet nstring constant, vous devez le déclarer dans l'en-tête, puis lui donner une valeur dans l'un de vos fichiers.
externe nsstring * myConstantsTring;
nsstring * myConstantsTring = @ "valeur de chaîne";
#define fait juste un texte remplacer donc je ne vois pas pourquoi #define msg @ "bonjour" ne fonctionnera pas
Asher Dunn: #define est un Directive de préprocesseur , ne faisant pas partie de la langue C elle-même (même norme ISO, mais une langue séparée). Tout ce qu'il fait est de créer une macro. Il n'y a pas de restriction sur quel texte vous pouvez définir comme valeur de la macro.
Ce n'est pas nécessairement garanti qu'il n'y aura qu'un seul objet NXConstantsTring pour un littéral de chaîne donné dans une application complète. Il semble assez probable que différentes unités de compilation puissent avoir des objets différents pour la même chaîne constante. Par exemple, si quelqu'un écrit un plugin, une chaîne constante sera générée pour que les occurrences de ce littéral nstring dans le plug-in puissent être générées pour des occurrences dans l'application hôte, et elles ne seront pas du point de pointeur.
Une raison pratique d'utiliser la constante par opposition à la définition est que vous pouvez faire des comparaisons directes (en utilisant ==) au lieu d'utiliser isequal: code>. Considérons: if ([[someArray lastObject] isEqual:STRING_CONSTANT])
{
...
}
Je vois que la réponse de Chuck contredit la mienne et je ne suis pas sûr de qui est correct.
La constante n'apparaîtrait pas "en place" partout où elle était utilisée dans le code. Les deux manières généreront des références aux objets NXCONSTANTSTRING. Il est vrai que plus peut être généré par des littéraux à chaîne, mais il sera presque certainement beaucoup moins d'un objet pour chaque littéral à chaîne dans le code.
Le meilleur argument que j'ai entendu est que const Strings apparaît dans le débogueur, tandis que les macros ne le font pas.
C'est une grande raison, vous ne pouvez pas "PO" (objet d'impression) une directive de définition de # définir. Aussi, comme indiqué par E.James, si vos constantes sont toutes équivalentes de pointeur, vous pouvez utiliser == pour tester l'égalité. + 1 pour toutes les bonnes réponses.
static NSString * const SERVER_URL = @"http://subdomain.domain.edu.ar/Folder/";