Est-ce que strlen sera calculé plusieurs fois s'il est utilisé dans une condition de boucle?

Je ne sais pas si le code suivant peut provoquer des calculs redondants ou est-il spécifique au compilateur?

for (int i = 0; i < strlen(ss); ++i)
{
    // blabla
}

Sera strlen()calculé à chaque fois que iaugmente?

Oui, strlen()sera évalué à chaque itération. Il est possible que, dans des circonstances idéales, l'optimiseur puisse en déduire que la valeur ne changera pas, mais je ne me fierais personnellement pas à cela.

Je ferais quelque chose comme

for (int i = 0, n = strlen(ss); i < n; ++i)

ou éventuellement

for (int i = 0; ss[i]; ++i)

tant que la chaîne ne changera pas de longueur pendant l'itération. Si c'est le cas, vous devrez soit appeler à strlen()chaque fois, soit le gérer selon une logique plus compliquée.

Oui, chaque fois que vous utilisez la boucle. Ensuite, il calculera à chaque fois la longueur de la chaîne. alors utilisez-le comme ceci:

char str[30];
for ( int i = 0; str[i] != '\0'; i++)
{
//Something;
}

Dans le code ci-dessus str[i]ne vérifie qu'un caractère particulier dans la chaîne à l'emplacement ichaque fois que la boucle démarre un cycle, donc cela prendra moins de mémoire et sera plus efficace.

Consultez ce lien pour plus d'informations.

Dans le code ci-dessous, chaque fois que la boucle s'exécute strlen, la longueur de la chaîne entière sera comptée, ce qui est moins efficace, prend plus de temps et prend plus de mémoire.

char str[];
for ( int i = 0; i < strlen(str); i++)
{
//Something;
}

Un bon compilateur peut ne pas le calculer à chaque fois, mais je ne pense pas que vous puissiez être sûr que chaque compilateur le fait.

En plus de cela, le compilateur doit savoir que strlen(ss)cela ne change pas. Ceci n'est vrai que s'il ssn'est pas modifié en forboucle.

Par exemple, si vous utilisez une fonction en lecture seule sur ssdansfor loop mais que vous ne déclarez pas le ssparamètre -paramètre comme const, le compilateur ne peut même pas savoir que ce ssn'est pas changé dans la boucle et doit calculer strlen(ss)à chaque itération.

Si ssest de type const char *et que vous ne rejetez pas le constness dans la boucle, le compilateur ne peut appeler strlenqu'une seule fois, si les optimisations sont activées. Mais ce n'est certainement pas un comportement sur lequel on peut compter.

Vous devez enregistrer le strlenrésultat dans une variable et utiliser cette variable dans la boucle. Si vous ne souhaitez pas créer de variable supplémentaire, en fonction de ce que vous faites, vous pourrez peut-être vous en sortir en inversant la boucle pour itérer en arrière.

for( auto i = strlen(s); i > 0; --i ) {
  // do whatever
  // remember value of s[strlen(s)] is the terminating NULL character
}

Formellement oui, strlen()on s'attend à ce qu'il soit appelé à chaque itération.

Quoi qu'il en soit, je ne veux pas nier la possibilité de l'existence d'une optimisation intelligente du compilateur, qui optimisera tout appel successif à strlen () après le premier.

Le code du prédicat dans son intégralité sera exécuté à chaque itération de la forboucle. Afin de mémoriser le résultat de l' strlen(ss)appel, le compilateur aurait besoin de savoir qu'au moins

1. La fonction strlenétait sans effet secondaire
2. La mémoire pointée par ssne change pas pendant la durée de la boucle

Le compilateur ne sait ni l'une ni l'autre de ces choses et ne peut donc pas mémoriser en toute sécurité le résultat du premier appel

Oui . strlen sera calculé à chaque fois que i augmente.

Si vous n'avez pas changé ss avec dans la boucle , cela n'affectera pas la logique, sinon cela affectera.

Il est plus sûr d'utiliser le code suivant.

int length = strlen(ss);

for ( int i = 0; i < length ; ++ i )
{
 // blabla
}

Oui, le strlen(ss)calculera la longueur à chaque itération. Si vous augmentez ssd'une manière ou d'une autre le i; il y aurait une boucle infinie.

Oui, la strlen()fonction est appelée à chaque fois que la boucle est évaluée.

Si vous voulez améliorer l'efficacité, pensez toujours à tout sauvegarder dans des variables locales ... Cela prendra du temps mais c'est très utile.

Vous pouvez utiliser le code comme ci-dessous:

String str="ss";
int l = strlen(str);

for ( int i = 0; i < l ; i++ )
{
    // blablabla
}

Oui, strlen(ss)sera calculé à chaque exécution du code.

Pas courant de nos jours mais il y a 20 ans sur les plates-formes 16 bits, je recommanderais ceci:

for ( char* p = str; *p; p++ ) { /* ... */ }

Même si votre compilateur n'est pas très intelligent en matière d'optimisation, le code ci-dessus peut encore donner un bon code d'assemblage.

Oui. Le test ne sait pas que ss n'est pas modifié à l'intérieur de la boucle. Si vous savez que cela ne changera pas, j'écrirais:

int stringLength = strlen (ss); 
for ( int i = 0; i < stringLength; ++ i ) 
{
  // blabla 
} 

Arrgh, ça va, même dans des circonstances idéales, bon sang!

À partir d'aujourd'hui (janvier 2018), et gcc 7.3 et clang 5.0, si vous compilez:

#include <string.h>

void bar(char c);

void foo(const char* __restrict__ ss) 
{
    for (int i = 0; i < strlen(ss); ++i) 
    {
        bar(*ss);
    }
}    

Donc nous avons:

• ss est un pointeur constant.
• ss est marqué __restrict__
• Le corps de la boucle ne peut en aucun cas toucher la mémoire pointée par ss(enfin, sauf s'il viole le __restrict__).

et encore , les deux compilateurs exécutent strlen() chaque itération de cette boucle . Incroyable.

Cela signifie également que les allusions / vœux pieux de @Praetorian et @JaredPar ne fonctionnent pas.

OUI, en termes simples. Et il y a un petit non dans une condition rare dans laquelle le compilateur le souhaite, comme étape d'optimisation s'il constate qu'il n'y a pas du tout de modifications apportées ss. Mais en bon état, vous devriez le penser comme OUI. Il y a des situations comme un programme in multithreadedet event, il peut devenir bogué si vous le considérez comme NON. Soyez prudent car cela n'améliorera pas trop la complexité du programme.

Oui.

strlen()calculé à chaque fois lorsqu'il iaugmente et n'est pas optimisé.

Le code ci-dessous montre pourquoi le compilateur ne doit pas optimiser strlen().

for ( int i = 0; i < strlen(ss); ++i )
{
   // Change ss string.
   ss[i] = 'a'; // Compiler should not optimize strlen().
}

Nous pouvons facilement le tester:

char nums[] = "0123456789";
size_t end;
int i;
for( i=0, end=strlen(nums); i<strlen(nums); i++ ) {
    putchar( nums[i] );
    num[--end] = 0;
}

La condition de boucle est évaluée après chaque répétition, avant de redémarrer la boucle.

Faites également attention au type que vous utilisez pour gérer la longueur des chaînes. ce devrait être celui size_tqui a été défini comme unsigned intdans stdio. le comparer et le convertir intpeut causer de sérieux problèmes de vulnérabilité.

eh bien, j'ai remarqué que quelqu'un dit qu'il est optimisé par défaut par n'importe quel compilateur moderne "intelligent". En passant, regardez les résultats sans optimisation. J'ai essayé:
Code C minimal:

#include <stdio.h>
#include <string.h>

int main()
{
 char *s="aaaa";

 for (int i=0; i<strlen(s);i++)
  printf ("a");
 return 0;
}

Mon compilateur: g ++ (Ubuntu / Linaro 4.6.3-1ubuntu5) 4.6.3
Commande pour la génération du code d'assemblage: g ++ -S -masm = intel test.cpp

Gotten assembly code at the output:
    ...
    L3:
mov DWORD PTR [esp], 97
call    putchar
add DWORD PTR [esp+40], 1
    .L2:
     THIS LOOP IS HERE
    **<b>mov    ebx, DWORD PTR [esp+40]
mov eax, DWORD PTR [esp+44]
mov DWORD PTR [esp+28], -1
mov edx, eax
mov eax, 0
mov ecx, DWORD PTR [esp+28]
mov edi, edx
repnz scasb</b>**
     AS YOU CAN SEE it's done every time
mov eax, ecx
not eax
sub eax, 1
cmp ebx, eax
setb    al
test    al, al
jne .L3
mov eax, 0
     .....

En élaborant sur la réponse de Prætorian, je recommande ce qui suit:

for( auto i = strlen(s)-1; i > 0; --i ) {foo(s[i-1];}

• autocar vous ne voulez pas vous soucier du type de retour de strlen. Un compilateur C ++ 11 (par exemplegcc -std=c++0x , pas complètement C ++ 11 mais les types automatiques fonctionnent) le fera pour vous.
• i = strlen(s)parce que vous voulez comparer à 0(voir ci-dessous)
• i > 0 parce que la comparaison à 0 est (légèrement) plus rapide que la comparaison à tout autre nombre.

L'inconvénient est que vous devez utiliser i-1pour accéder aux caractères de la chaîne.