Dois-je toujours copier/Block_copy les blocs en vertu de l'ARC?

Edit:

Il s'est avéré l'examinant les adresses de la "capturé", les variables sont difficiles à interpréter, et pas toujours appropriée pour déterminer si un Bloc a été copié sur le tas ou se trouve encore sur le tas. Bien que la Spécification de Blocs de données ici BLOC DE SPÉCIFICATION DE MISE EN ŒUVRE, sera suffisante pour décrire les faits, je tente une approche complètement différente:

Qu'est ce qu'un Bloc de toute façon?

Ceci est un résumé de la Spécification officielle BLOC DE SPÉCIFICATION DE MISE EN ŒUVRE:

Un Bloc de code (comme une fonction) et une structure contenant plusieurs morceaux de données, des indicateurs et des pointeurs de fonction ET une variable longueur de la section "capturé variables".

Noter que cette structure est privé et la mise en œuvre définies.

Un Bloc peut être définie en fonction de la portée, où cette structure est créée dans la pile de la mémoire locale, ou elle peut être définie dans globales ou statiques portée, où la structure est créée en mémoire statique.

Un Bloc peut "importer" autres références de Bloc, les autres variables et __block les variables modifiées.

Lorsqu'un Bloc de références à d'autres variables, ils seront importés:

• Une pile locale (automatique) de la variable, va être "importés" par les moyens de rendre un "const copie".

• Un __block modifié variable sera importé par le biais de l'affectation d'un pointeur l'adresse de cette variable enfermé dans une autre structure.

• Variables globales seront simplement référencé (et non pas "importés").

Si une variable sera importé, le "capturé variable" vie dans la structure susmentionnée dans la variable longueur de la section. C'est, la "contrepartie" de la variable automatique (qui vit à l'extérieur du bloc) dispose d'un stockage à l'intérieur du bloc de la structure.

Depuis cette "capturé" variable est en lecture seule, le compilateur peut appliquer quelques optimisations: par exemple, nous avons vraiment seulement besoin un exemple de la capture de variable sur le tas, si jamais nous avons besoin d'une copie de la bloquer.

La valeur de la capture de variables sera définie lorsque le bloc littérale de l'expression sera évaluée. Cela implique également que le stockage de la capture de variables doit être accessible en écriture (qui est, pas de section de code).

La durée de vie de la capture de variables est une fonction: chaque invocation de ce bloc, il faudra une nouvelle copie de ces variables.

Capturé variables dans les Blocs qui vivent sur la pile sont détruits lorsque le programme des feuilles de l'instruction composée du bloc.

Capturé variables dans les Blocs qui vivent sur le tas sont détruits lorsque le bloc sera détruit.

Selon le Bloc de l'API, les versions 3.5:

D'abord, lorsqu'un bloc littérale est créé, cette structure existe sur la pile:

Lorsqu'un Bloc expression littérale est évalué les pile structure est initialisé de la façon suivante:

1. Une statique de la structure du descripteur est déclaré et initialisé de la façon suivante:

   un. L'appel de la fonction pointeur est défini à une fonction qui prend la structure de Bloc en tant que premier argument et le reste des arguments (le cas échéant) pour le Bloc et exécute le Bloc d'instruction composée.

   b. La taille du champ est la taille du Bloc suivant littérale de la structure.

   c. Le copy_helper et dispose_helper pointeurs de fonction sont fixées à chacune des fonctions d'assistance s'ils sont requis par le Bloc littérale.

2. Un pile (ou global) Bloc de données littérales structure est créé et initialisé de la façon suivante:

   un. L'isa est indiqué dans le champ adresse de l'externe _NSConcreteStackBlock, qui est un bloc de mémoire non fournies partie de libSystem, ou _NSConcreteGlobalBlock si c'est un statique ou au niveau du fichier de Bloc littérale.

   b. Le champ flags est réglé à zéro, sauf si il y a des variables importées dans le Bloc qui ont besoin de fonctions d'assistance pour le niveau du programme Block_copy() et Block_release() de l'exploitation, auquel cas la (1<<25) les drapeaux bit est défini.

Veuillez noter que c'est pour Bloc littéraux.

Selon la Objective-C Extensions de Blocs, le compilateur va traiter les Blocs comme objets.

Observations

Maintenant, il est difficile de trouver un code de test qui prouve à ces affirmations. Ainsi, il semble préférable d'utiliser le débogueur et le jeu symbolique des points d'arrêt sur les fonctions de

• _Block_copy_internal et

• malloc (qui doit être activé uniquement après le premier point d'arrêt a été frappé)

et exécutez ensuite adapté le code de test (comme les extraits de code ci-dessous) et d'examiner ce qui se passe:

Dans l'extrait de code suivant, nous créons un Bloc littéral et le passer à travers comme paramètre d'une fonction qui l'appelle:

typedef void (^block_t)(void);

void func(block_t block) {
    if (block) {
        block();
    }
}

void foo(int param)
{
    int x0 = param;
    func(^{
        int y0 = x0;
        printf("Hello block 1\n");
        printf("Address of auto y0: %p\n", &y0);
        printf("Address of captured x0: %p\n", &x0);
    });
}  

La sortie est comme suit:

Hello block 1
Address of auto y0: 0x7fff5fbff8dc
Address of captured x0: 0x7fff5fbff940

L'adresse de la "capturé" variable x0 indique fortement qu'il vit sur la pile.

Nous avons également définir un point d'arrêt à _Block_copy_internal - toutefois, il ne sera pas touché. Ceci indique que le Bloc n'a pas été copié sur le tas. Une autre preuve peut être faite avec des Instruments, qui ne montre pas les allocations en fonction foo.

Maintenant, si nous avons de créer et d'initialiser un bloc variable, paraît-il, le Bloc de données de la structure de l'original Bloc littérale initialement créé sur la pile, seront copiées sur le tas:

int capture_me = 1;
dispatch_block_t block = ^{ int y = capture_me; };

Au-dessus de cette copies le bloc qui a été initialement créé sur la pile. Cela peut tout simplement être dû à l'ARC et le fait que nous avons un bloc littéral sur la main droite, et le bloc variable block sur la main gauche sera attribué le bloc littérale - ce qui résulte en une Block_copy opération. Cela rend les Blocs apparaissent bien comme d'habitude Objective-C objets.

Les Allocations tracée avec des Instruments similaires de code ci-dessous

void foo(int param)
{
    dispatch_queue_t queue = dispatch_queue_create("queue", 0);

    int x0 = param;
    dispatch_block_t block = ^{
        int y0 = x0;
        printf("Hello block 1\n");
        printf("Address of auto y0: %p\n", &y0);
        printf("Address of captured x0: %p\n", &x0);
    };

    block();
}    

montrent, que le Bloc sera en effet copié:

À noter

• Lorsqu'un bloc ne rend pas compte de toutes les variables, c'est comme une fonction normale. Ensuite, il est préférable d'appliquer une optimisation, où un Block_copy opération ne fait rien, car il n'y a rien à copier. clang la met en œuvre avec prise de ces blocs globale "bloc".

• Lors de l'envoi de copy à un bloc de variables et affectation du résultat à une autre variable d'un bloc, par exemple:

  dispatch_block_t block = ^{
      int y0 = capture_me;
  };
  dispatch_block_t otherBlock = [block copy];

  copy sera un très pas cher opération, puisque le bloc block a déjà de stockage alloué pour le bloc de la structure qui peut être partagé. Ainsi, copy n'a pas besoin d'allouer du stockage de nouveau.

Revenir à la question

Pour répondre à la question de savoir si nous devons explicitement copie d'un bloc, dans certaines circonstances, par exemple:

@property (copy) block_t completion

[^{...} copy]

Bien, une fois que le bloc a été copié, n'importe quand, et sera ensuite assigné à la variable cible (un Bloc de variables), nous devrions être toujours en sécurité, sans explicitement la copie du bloc, puisqu'il est déjà dans le tas.

Dans le cas du bloc propriété, il doit être sûr si nous serait tout simplement wright:

@property dispatch_block_t completion;

et puis:

foo.completion = ^{ x = capture_me; ... };

Ce devrait être à l'abri depuis l'attribution d'un bloc littéral (qui vit sur la pile) le bloc sous-jacent variable _completion, permet de copier le bloc sur le tas.

Néanmoins, je voudrais encore vous recommandons d'utiliser l'attribut copy - puisqu'il est encore suggérée par les documents officiels comme les meilleures pratiques, et prend également en charge les anciennes Api où les Blocs ne se comportent pas comme d'habitude Objective-C objets et où il n'y a pas d'ARC.

Système existant Api permettra aussi de prendre soin de la copie d'un Bloc si nécessaire:

dispatch_async(queue, ^{int x = capture_me;});

dispatch_async() va faire de la copie pour nous. Donc, nous n'avons pas à s'inquiéter.

D'autres scénarios sont plus subtiles:

dispatch_block_t block;
if (condition) {
    block = ^{ ... };
}
else {
    block = ^{ ... };
}
dispatch_sync(queue, block);

Mais en réalité, c'est sûr: Le bloc littérale sera copié et assigné à la variable bloc block.

Cet exemple peut même paraître effrayant:

int x0 = param;
NSArray* array = [NSArray arrayWithObject:^{
    int y0 = x0;
    printf("Hello block 1\n");
}];

dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(1 * NSEC_PER_SEC)), queue, ^{
    block_t block = array[0];
    block();
});

Mais il semble, le Bloc littérale sera correctement copié comme un effet de l'attribution de l'argument (le Bloc) pour le paramètre (un id) dans la méthode arrayWithObject: qui copie le Bloc littérale sur le tas:

En outre, NSArray sera conserver l'objet passé en paramètre de la méthode arrayWithObject:. Cela provoque un autre appel à Block_copy()cependant, puisque le Bloc est déjà sur le tas, cet appel n'a pas allouer de l'espace de stockage.

Cela indique qu'un "conserver" un message envoyé à un Bloc littérale quelque part dans la mise en œuvre de arrayWithObject: serait également en effet de copier le Bloc.

Donc, quand avons-nous réellement besoin explicitement copier un Bloc?

Un bloc littérale - par exemple, l'expression:

^{...}

permettra de créer la structure du bloc sur la pile.

Donc, nous avons fait besoin de faire un copier uniquement dans les cas où nous avons besoin de le Bloquer sur le tas et si cela n'arrive pas "automatiquement". Cependant, il n'y a pratiquement pas de scénarios où c'est le cas. Même dans les cas où nous passons d'un Bloc comme un paramètre à une méthode qui n'a aucune idée de qui il s'agit d'un Bloc littérale et nécessite un copy (par exemple: arrayWithObject:), et, éventuellement, le récepteur envoie juste un conserver message à l'objet donné en paramètre, le Bloc sera copié sur le tas en premier.

Exemples où l'on peut utiliser explicitement copy, est l'endroit où nous n'avons pas attribuer un Bloc littérale à une variable d'un bloc ou d'un id, et donc de l'ARC ne peut pas comprendre qu'il a à faire une copie du bloc de l'objet ou a envoyer "conserver".

Dans ce cas, l'expression

[^{...} copy];  

permettra d'obtenir un autoreleased Bloc dont la structure se trouve sur le tas.