Czy strlen zostanie obliczony wiele razy, jeśli zostanie użyty w warunku pętli?

Nie jestem pewien, czy poniższy kod może spowodować zbędne obliczenia, czy też jest specyficzny dla kompilatora?

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

Będzie strlen()obliczany za każdym razem, gdy iwzrośnie?

Tak, strlen()zostaną ocenione w każdej iteracji. Jest możliwe, że w idealnych okolicznościach optymalizator mógłby wywnioskować, że wartość się nie zmieni, ale ja osobiście nie polegałbym na tym.

Zrobiłbym coś takiego

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

lub ewentualnie

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

pod warunkiem, że łańcuch nie zmieni długości podczas iteracji. Jeśli tak, będziesz musiał albo dzwonić za strlen()każdym razem, albo obsługiwać to za pomocą bardziej skomplikowanej logiki.

Tak, za każdym razem, gdy używasz pętli. Wtedy za każdym razem obliczy długość struny. więc użyj tego w ten sposób:

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

W powyższym kodzie str[i]weryfikuje tylko jeden określony znak w ciągu w lokalizacjii każdym razem, gdy pętla rozpoczyna cykl, dzięki czemu zajmie mniej pamięci i jest bardziej wydajna.

Zobacz ten link, aby uzyskać więcej informacji.

W poniższym kodzie za każdym razem, gdy pętla strlenzostanie uruchomiona , policzy długość całego ciągu, który jest mniej wydajny, zajmuje więcej czasu i zajmuje więcej pamięci.

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

Dobry kompilator może nie obliczyć tego za każdym razem, ale nie sądzę, aby można było być pewnym, że robi to każdy kompilator.

Poza tym kompilator musi wiedzieć, że strlen(ss)to się nie zmienia. Jest to prawdą tylko wtedy, gdy ssnie jest zmieniane w forpętli.

Na przykład, jeśli używasz funkcji tylko do odczytu ssw forpętli, ale nie zadeklarujesz ssparametru -parameter as const, kompilator nie może nawet wiedzieć, że ssnie jest zmieniany w pętli i musi obliczyć strlen(ss)w każdej iteracji.

Jeśli ssjest typu const char *i nie odrzucasz tego, co constw pętli, kompilator może tylko wywołaćstrlen raz, jeśli optymalizacje są włączone. Ale z pewnością nie jest to zachowanie, na które można liczyć.

strlenWynik należy zapisać w zmiennej i użyć tej zmiennej w pętli. Jeśli nie chcesz tworzyć dodatkowej zmiennej, w zależności od tego, co robisz, możesz uciec od odwrócenia pętli w celu wykonania iteracji wstecz.

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

Formalnie tak, strlen() oczekuje się, że będzie wywoływana przy każdej iteracji.

W każdym razie nie chcę zaprzeczać możliwości istnienia jakiejś sprytnej optymalizacji kompilatora, która zoptymalizuje każde kolejne wywołanie strlen () po pierwszym.

Cały kod predykatu będzie wykonywany w każdej iteracji forpętli. Aby zapamiętać wynik strlen(ss)wywołania, kompilator musiałby przynajmniej to wiedzieć

1. Funkcja strlen była wolna od skutków ubocznych
2. Pamięć wskazywana przez ssnie zmienia się w czasie trwania pętli

Kompilator nie wie żadnej z tych rzeczy i dlatego nie może bezpiecznie zapamiętać wyniku pierwszego wywołania

tak . strlen będzie obliczana za każdym razem, gdy i wzrośnie.

Jeśli nie zmieniłeś ss z in the loop, oznacza to, że nie wpłynie to na logikę inaczej będzie to miało wpływ.

Bezpieczniej jest użyć następującego kodu.

int length = strlen(ss);

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

Tak, strlen(ss)będzie obliczyć długość w każdej iteracji. Jeśli w ssjakiś sposób zwiększasz, a także zwiększasz i; byłaby nieskończona pętla.

Tak, strlen()funkcja jest wywoływana za każdym razem gdy pętla jest oceniana.

Jeśli chcesz poprawić wydajność, zawsze pamiętaj, aby zapisać wszystko w zmiennych lokalnych ... To zajmie trochę czasu, ale jest bardzo przydatne ...

Możesz użyć kodu jak poniżej:

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

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

Tak, strlen(ss)zostanie obliczona przy każdym uruchomieniu kodu.

Obecnie nie jest to powszechne, ale 20 lat temu na platformach 16-bitowych poleciłbym to:

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

Nawet jeśli Twój kompilator nie jest zbyt inteligentny w optymalizacji, powyższy kod może jeszcze dać dobry kod asemblera.

Tak. Test nie wie, że ss nie zmienia się w pętli. Jeśli wiesz, że to się nie zmieni to napisałbym:

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

Arrgh, do cholery, nawet w idealnych okolicznościach będzie!

Na dzień dzisiejszy (styczeń 2018 r.) Oraz gcc 7.3 i clang 5.0, jeśli kompilujesz:

#include <string.h>

void bar(char c);

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

Więc mamy:

• ss jest stałym wskaźnikiem.
• ss jest zaznaczony __restrict__
• Ciało pętli nie może w żaden sposób dotknąć pamięci wskazywanej przez ss(no chyba, że ​​narusza __restrict__).

a mimo to oba kompilatory wykonują strlen() każdą pojedynczą iterację tej pętli . Niesamowity.

Oznacza to również, że aluzje / pobożne życzenia @Praetorian i @JaredPar nie sprawdzają się.

TAK, w prostych słowach. I nie ma małego nie w rzadkich warunkach, w których kompilator chce, jako krok optymalizacji, jeśli stwierdzi, że nie wprowadzono żadnych zmian ss. Ale w bezpiecznym stanie powinieneś pomyśleć, że TAK. Istnieją sytuacje, takie jak multithreadedprogram sterowany zdarzeniami, może on ulec błędom, jeśli uznasz to za NIE. Graj bezpiecznie, ponieważ nie poprawi to zbytnio złożoności programu.

Tak.

strlen() obliczane za każdym razem, kiedy i rośnie i nie jest zoptymalizowany.

Poniższy kod pokazuje, dlaczego kompilator nie powinien optymalizować strlen().

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

Z łatwością możemy to przetestować:

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

Stan pętli jest oceniany po każdym powtórzeniu, przed ponownym uruchomieniem pętli.

Uważaj również na typ używany do obsługi długości strun. powinno być size_ttym, co zostało zdefiniowane jak unsigned intw stdio. porównywanie i przesyłanie go do intmoże spowodować poważny problem z luką w zabezpieczeniach.

cóż, zauważyłem, że ktoś mówi, że jest domyślnie optymalizowany przez jakikolwiek "sprytny" nowoczesny kompilator. Przy okazji spójrz na wyniki bez optymalizacji. Próbowałem:
Minimalny kod C:

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

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

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

Mój kompilator: g ++ (Ubuntu / Linaro 4.6.3-1ubuntu5) 4.6.3
Polecenie do generowania kodu asemblera: 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
     .....

Rozwijając odpowiedź Prætoriana, polecam:

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

• autoponieważ nie chcesz przejmować się tym, który typ zwraca strlen. Kompilator C ++ 11 (npgcc -std=c++0x Nie do końca C ++ 11, ale typy automatyczne działają) zrobi to za Ciebie.
• i = strlen(s)ponieważ chcesz porównać 0(patrz poniżej)
• i > 0 ponieważ porównanie do 0 jest (nieco) szybsze niż porównanie z jakąkolwiek inną liczbą.

Wadą jest to, że musisz użyć i-1, aby uzyskać dostęp do znaków ciągu.