Tak, może.
Większość z nich const
jest wyłącznie dla korzyści programisty i nie pomaga kompilatorowi w optymalizacji, ponieważ ich odrzucenie jest legalne, a więc nie mówią kompilatorowi niczego przydatnego do optymalizacji. Jednak niektórych const
plików nie można (zgodnie z prawem) odrzucić i dostarczają one kompilatorowi przydatnych informacji do optymalizacji.
Na przykład dostęp do zmiennej globalnej zdefiniowanej za pomocą const
typu może być wbudowany, podczas gdy nie można wstawić tej bez const
typu, ponieważ może się to zmienić w czasie wykonywania.
https://godbolt.org/g/UEX4NB
C ++:
int foo1 = 1;
const int foo2 = 2;
int get_foo1() {
return foo1;
}
int get_foo2() {
return foo2;
}
jako M:
foo1:
.long 1
foo2:
.long 2
get_foo1():
push rbp
mov rbp, rsp
mov eax, DWORD PTR foo1[rip] ; foo1 must be accessed by address
pop rbp
ret
get_foo2():
push rbp
mov rbp, rsp
mov eax, 2 ; foo2 has been replaced with an immediate 2
pop rbp
ret
W praktyce należy pamiętać, że chociaż const
może poprawić wydajność, w większości przypadków nie będzie lub będzie, ale zmiana nie będzie zauważalna. Podstawową użytecznością const
nie jest optymalizacja.
Steve Jessop podaje inny przykład w swoim komentarzu do pierwotnego pytania, w którym pojawia się coś, o czym warto wspomnieć. W zakresie blokowym kompilator może wywnioskować, czy zmienna zostanie zmutowana i odpowiednio zoptymalizować, niezależnie od tego const
, ponieważ kompilator może zobaczyć wszystkie zastosowania zmiennej. W przeciwieństwie do powyższego przykładu, nie można przewidzieć, czy foo1
zostanie zmutowany, ponieważ można go zmodyfikować w innych jednostkach tłumaczeniowych. Przypuszczam, że hipotetyczny, czujący ultra-kompilator mógłby przeanalizować cały program i określić, czy można go uzyskać w trybie inline foo1
... ale prawdziwe kompilatory nie mogą.