Powiel możliwe:
Constants and compiler optimization in C++Czy const pomaga optymalizatorowi? C++
Niech święte wojny rozpocząć: Słyszałem wiele różnych opinii na temat przydatności const w C++. Oczywiście ma zastosowania w deklaracjach funkcji członkowskich itp. Ale jak użyteczne jest to jako modyfikator zmiennych (a raczej stałych)? Czy rzeczywiście pomaga optymalizatorowi, jeśli pozostała część kodu pozostanie taka sama?
const nie pomaga optymalizatorowi.
Od const można wyrzucać z const_cast, możliwe jest pisanie programów, które używają const w wielu miejscach, a następnie rzucił ją i modyfikować zmienne w każdym razie, z zachowaniem określonej zgodnie z normą. Dlatego też kompilator musi przyjrzeć się faktycznemu kodowi programu, aby określić, które zmienne są modyfikowane, i prawdopodobnie jest w tym całkiem dobry (na przykład może określić, że zmienna niezmienna jest niezmienna w stosunku do określonego bloku kodu i odpowiednio zoptymalizować).
Jeśli kompilator ślepo potraktował const jako gwarancję, że coś nie ulegnie zmianie, optymalizator złamie dobrze uformowane programy.
const jest funkcją czasu kompilacji, która pomaga programistom pisać poprawny kod, dodając pewne ograniczenia podczas kompilacji i wskazując kontrakt kodu (np. "Obiecuję, że nie zmienię tego parametru"). Nie ma nic wspólnego z optymalizacją. Chociaż niezmienniki są ważne dla optymalizatorów, nie ma to nic wspólnego ze słowem kluczowym const.
Istnieje jeden wyjątek: obiekty zadeklarowane jako const. Nie można ich modyfikować; nawet jeśli są przez rzutowanie, zachowanie jest niezdefiniowane. Jest trochę subtelności tutaj:
const int ci = 5;
const_cast<int&>(ci) = 5; // undefined behavior, original object declared const
int i = 5;
const int& ci2 = i; // cannot modify i through ci2, const reference
const_cast<int&>(ci2) = 5; // OK, original object not declared const
Więc gdy kompilator widzi const int ci prawdopodobnie robi założyć, że nigdy, przenigdy nie zmieni, ponieważ modyfikacji jest niezdefiniowane zachowanie. Jest jednak duża szansa, że nie jest to wąskie gardło w twoim programie, jest po prostu bardziej wyrafinowanym #define. Poza tym const jest słaby - tylko słowo kluczowe dla systemu typu.
Należy zauważyć, że odrzucanie constness na obiekcie, który jest z natury stały, jest niezdefiniowanym zachowaniem. –
Nie zaszkodzi i teoretycznie może pozwolić na pewne optymalizacje, więc równie dobrze można z niego korzystać - nie wiem, czy istnieją jakiekolwiek kompilatory produkcyjne.
Ogólnie, nie, to nie pomoże kompilatorowi. Ponieważ konstelacja może zostać odrzucona w sekundę zarówno w C, jak iw C++, kompilatorowi trudno byłoby uzyskać niezbędne założenia dotyczące spełnionych wymagań dotyczących kodu w celu optymalizacji.
To powiedziawszy, poprawność const powinna być zawsze używana dla innych korzyści.
Cóż, tak, można go odrzucić, ale jeśli zrobisz to za kompilatorami, doprowadzi to do niezdefiniowanego zachowania. Jeśli używasz normalnego rzutowania, kompilator zna dokładny punkt, z którego musi zrzucić stałą. –
Istnieje wiele przypadków, w których modyfikator const nie pomoże optymalizatorowi, z prostego faktu, że kompilator może już stwierdzić, czy zmieniono zmienną, czy nie. Największą korzyścią płynącą z const jest, moim zdaniem, powiedzenie kompilatorowi, czy programista chce zmodyfikować tę zmienną, co jest przydatne przy znajdowaniu pewnych typów błędów semantycznych w czasie kompilacji, zamiast w czasie wykonywania. Każdy błąd, który możesz przenieść do czasu kompilacji, to ogromny wzrost wydajności programisty.
Powiedziałbym, że jest to trochę przesadzone. Dla trywialnych rzeczy tak, kiedy przekroczysz granicę wywołania, no cóż ... W każdym razie dobrze jest pomyśleć o brakującym modyfikatorze const jako semantycznym błędzie, który musi zostać naprawiony. –
To zależy od optymalizatora, czyż nie? – dmckee