43 votes

utilisation statique de NSString par rapport aux constantes NSString en ligne

En Objective-C, ma compréhension est que la directive @"foo" définit une constante NSString. Si j'utilise @"foo" dans plusieurs endroits, le même immuable NSString objet est référencé.

Pourquoi dois-je voir cet extrait de code si souvent (par exemple dans UITableViewCell réutilisation):

static NSString *CellId = @"CellId";
UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:CellId];
if (cell == nil) {
    cell = [[UITableViewCell alloc] initWithStyle:style reuseIdentifier:CellId];

Au lieu de simplement:

UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:@"CellId"];
if (cell == nil) {
    cell = [[UITableViewCell alloc] initWithStyle:style reuseIdentifier:@"CellId"];

Je suppose que c'est pour me protéger de faire une faute de frappe dans le nom de l'identificateur que le compilateur ne marcherait pas. Mais Si si, ne pourrais-je pas simplement:

#define kCellId @"CellId"

et d'éviter la statique NSString * bits? Ou ai-je raté quelque chose?

59voto

Tom Dalling Points 10656

Il est recommandé de transformer les littéraux en constantes pour les raisons suivantes:

  1. Cela permet d'éviter les fautes de frappe, comme vous l'avez dit
  2. Si vous voulez changer la constante, il suffit de la changer à un endroit

Je préfère utiliser static const NSString* static NSString* const parce que c'est légèrement plus sûr que #define . J'ai tendance à éviter le pré-processeur à moins d'en avoir vraiment besoin.

36voto

alex gray Points 5089

J'aime toutes les réponses ici sans un exemple simple de comment bien déclarer un... pour...

Si vous voulez la constante d'être visible de l'extérieur (ie. "global").... le déclarer comme tel dans un en-tête...

extern NSString *const MyTypoProneString;

et de le définir dans un .m le fichier, en DEHORS de tout @implementation comme...

NSString * const MyTypoProneString = @"iDoNtKnOwHoW2tYpE";

Cela dit... si vous voulez simplement un static const qui EST LOCAL à votre classe de mise en œuvre (ou même une certaine méthode!)... il suffit de déclarer la chaîne à l'INTÉRIEUR de la mise en œuvre (ou méthode) comme...

static NSString *MavisBeacon = @"She's a freakin' idiot";

EDIT Bien que je n'montrer comment faire cela... je ne suis pas encore convaincu que ce style est en quelque sorte mieux que le ridiculement plus court, plus simple, et moins répétitive SEULE déclaration, à la..

#define SomeStupidString @"DefiningConstantsTwiceIsForIdiots"

Utiliser #defines '... ils sont beaucoup moins ennuyeux.. il suffit de ne pas laisser le préprocesseur-joueur-haters vous obtenir vers le bas.

9voto

outis Points 39377

Vous devez créer la variable statique const .

Une différence entre une variable statique et une macro est que les macros ne fonctionnent pas bien avec les débogueurs. Les macros ne sont pas non plus sensibles au type.

La plupart des conseils static-var-vs-macro pour C et C ++ s’appliquent à Obj-C.

3voto

kiamlaluno Points 11856

Il n’est pas garanti que lors de l’utilisation de @"foo" dans plusieurs emplacements, le moteur d’exécution utilise le même stockage pour ceux-ci, et ne sera certainement pas le cas entre les limites de l’unité de compilation ou de la bibliothèque.
Je préférerais utiliser static NSString *string = @"foo" , surtout avec beaucoup de chaînes littérales.

2voto

Darren Points 13973

Je suppose que c'est pour me protéger de faire une faute de frappe dans le nom de l'identificateur que le compilateur ne marcherait pas.

Correct. C'est juste défensif de base en programmation. Le résultat compilé (espérons-le) est le même dans les deux cas.

Mais Si si, ne pourrais-je pas simplement:

#define kCellId @"CellId"

et d'éviter la statique NSString * bits? Ou ai-je raté quelque chose?

Oui. Mais l' kCellId symbole serait globalement défini, au moins dans votre unité de compilation. La déclaration d'une variable statique fait le symbole locales à ce bloc.

Vous verrez généralement chaîne de constantes définies comme des variables globales ou statiques variables plutôt que de préprocesseur. Cela permet de s'assurer que vous êtes seulement affaire avec une seule instance de chaîne entre les différentes unités de compilation.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X