¿Se calculará strlen varias veces si se usa en una condición de bucle?

No estoy seguro de si el siguiente código puede causar cálculos redundantes o es específico del compilador.

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

¿ strlen()Se calculará cada vez que iaumente?

Si, strlen() se evaluará en cada iteración. Es posible que, en circunstancias ideales, el optimizador pueda deducir que el valor no cambiará, pero yo personalmente no confiaría en eso.

Haría algo como

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

o posiblemente

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

siempre que la cadena no cambie de longitud durante la iteración. Si es posible, deberá llamar strlen()cada vez o manejarlo con una lógica más complicada.

Sí, cada vez que use el bucle. Entonces cada vez calculará la longitud de la cuerda. así que úsalo así:

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

En el código anterior str[i]solo verifica un carácter en particular en la cadena en la ubicacióni cada vez que el bucle comienza un ciclo, por lo que tomará menos memoria y es más eficiente.

Consulte este enlace para obtener más información.

En el siguiente código, cada vez que se ejecute el bucle, strlense contará la longitud de toda la cadena, lo que es menos eficiente, toma más tiempo y requiere más memoria.

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

Es posible que un buen compilador no lo calcule siempre, pero no creo que pueda estar seguro de que todos los compiladores lo hagan.

Además de eso, el compilador tiene que saber que eso strlen(ss)no cambia. Esto solo es cierto si ssno se cambia enfor bucle.

Por ejemplo, si usa una función de solo lectura ssen el forbucle pero no declara el ssparámetro -com const, el compilador ni siquiera puede saber que ssno ha cambiado en el bucle y tiene que calcular strlen(ss)en cada iteración.

Si sses de tipo const char *y no está descartando el constness dentro del bucle, el compilador solo puede llamar strlenuna vez, si las optimizaciones están activadas. Pero ciertamente no se puede confiar en este comportamiento.

Debe guardar el strlenresultado en una variable y usar esta variable en el ciclo. Si no desea crear una variable adicional, dependiendo de lo que esté haciendo, es posible que se salga con la suya invirtiendo el ciclo para iterar hacia atrás.

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

Formalmente sí strlen() se espera que se llame para cada iteración.

De todos modos, no quiero negar la posibilidad de que exista alguna optimización inteligente del compilador, que optimizará cualquier llamada sucesiva a strlen () después de la primera.

El código de predicado en su totalidad se ejecutará en cada iteración del forciclo. Para memorizar el resultado de la strlen(ss)llamada, el compilador necesitaría saber que al menos

1. La función strlenestaba libre de efectos secundarios.
2. La memoria señalada por ssno cambia durante la duración del bucle

El compilador no sabe ninguna de estas cosas y, por lo tanto, no puede memorizar con seguridad el resultado de la primera llamada

si . strlen se calculará cada vez que aumente i.

Si no ha cambiado ss con en el bucle de medios que no afectará a la lógica de lo contrario afectará.

Es más seguro utilizar el siguiente código.

int length = strlen(ss);

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

Sí, strlen(ss)calculará la longitud en cada iteración. Si está aumentando el ssde alguna manera y también aumentando el i; habría bucle infinito.

Sí, la strlen()función se llama cada vez que se evalúa el bucle.

Si desea mejorar la eficiencia, recuerde siempre guardar todo en variables locales ... Tomará tiempo pero es muy útil ...

Puede usar código como el siguiente:

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

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

Sí, strlen(ss)se calculará cada vez que se ejecute el código.

No es común hoy en día, pero hace 20 años en plataformas de 16 bits, recomendaría esto:

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

Incluso si su compilador no es muy inteligente en la optimización, el código anterior puede resultar en un buen código ensamblador todavía.

Si. La prueba no sabe que ss no se cambia dentro del ciclo. Si sabe que no cambiará, escribiría:

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

Arrgh, lo hará, incluso en circunstancias ideales, ¡maldición!

A partir de hoy (enero de 2018) y gcc 7.3 y clang 5.0, si compila:

#include <string.h>

void bar(char c);

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

Entonces tenemos:

• ss es un puntero constante.
• ss está marcado __restrict__
• El cuerpo del bucle no puede de ninguna manera tocar la memoria apuntada por ss(bueno, a menos que viole el __restrict__).

y aún así , ambos compiladores ejecutan strlen() cada iteración de ese ciclo . Asombroso.

Esto también significa que las alusiones / ilusiones de @Praetorian y @JaredPar no funcionan.

SÍ, en palabras sencillas. Y hay un pequeño no en una condición poco común en la que el compilador desea hacerlo, como paso de optimización si encuentra que no se han realizado cambios en ssabsoluto. Pero en condiciones seguras deberías pensarlo como SÍ. Hay algunas situaciones como en multithreadedun programa impulsado por eventos, puede tener errores si lo considera un NO. Vaya seguro, ya que no mejorará demasiado la complejidad del programa.

Si.

strlen()calcula cada vez cuando iaumenta y no optimiza.

El siguiente código muestra por qué el compilador no debería optimizar strlen().

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

Podemos probarlo fácilmente:

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 condición del ciclo se evalúa después de cada repetición, antes de reiniciar el ciclo.

También tenga cuidado con el tipo que usa para manejar la longitud de las cadenas. debe ser lo size_tque se ha definido como unsigned inten stdio. compararlo y convertirlo en intpodría causar algún problema de vulnerabilidad grave.

bueno, noté que alguien dice que está optimizado por defecto por cualquier compilador moderno "inteligente". Por cierto, observe los resultados sin optimización. Intenté:
código C mínimo:

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

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

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

Mi compilador: g ++ (Ubuntu / Linaro 4.6.3-1ubuntu5) 4.6.3
Comando para la generación de código ensamblador: 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
     .....

Desarrollando la respuesta de Prætorian, recomiendo lo siguiente:

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

• autoporque no quiere preocuparse por qué tipo de strlen devuelve. Un compilador de C ++ 11 (p. Ej.gcc -std=c++0x , no completamente C ++ 11 pero los tipos automáticos funcionan) lo hará por usted.
• i = strlen(s)porque quieres comparar 0(ver más abajo)
• i > 0 porque la comparación con 0 es (ligeramente) más rápida que la comparación con cualquier otro número.

La desventaja es que tienes que usar i-1para acceder a los caracteres de la cadena.