Jaki rodzaj optymalizacji oferuje const w C / C++? (jeśli w ogóle)

Przed udzieleniem jakiejkolwiek odpowiedzi, chcę podkreślić, że powodem używania lub nie używania const naprawdę powinno być poprawność programu i jasność dla innych programistów, bardziej niż dla optymalizacji kompilatora; to jest, dokonywanie parametru const dokumenty, że metoda nie będzie modyfikować tego parametru, a dokonywanie funkcji member const dokumenty, że ten członek nie będzie modyfikować obiektu, którego jest członkiem (przynajmniej nie w sposób logiczny zmieniający wyjście z każdego innego const funkcja członka). Pozwala to na przykład programistom uniknąć tworzenia niepotrzebnych kopii obiektów (ponieważ nie muszą się martwić, że oryginał zostanie zniszczony lub zmodyfikowany) lub uniknąć niepotrzebnej synchronizacji wątków(np. wiedząc, że wszystkie wątki po prostu czytają i nie mutują danego obiektu).

Pod względem optymalizacji kompilator może dokonać, przynajmniej teoretycznie, choć w trybie optymalizacji, który pozwala mu na pewne niestandardowe założenia to może złamać standardowy kod C++, rozważ:

for (int i = 0; i < obj.length(); ++i) {
   f(obj);
}

Załóżmy, że funkcja length jest oznaczona jako const, ale w rzeczywistości jest kosztowną operacją(powiedzmy, że faktycznie działa w czasie O (n) zamiast O(1)). Jeśli funkcja f przyjmuje swój parametr za pomocą referencji const, kompilator może potencjalnie zoptymalizować tę pętlę do:

int cached_length = obj.length();
for (int i = 0; i < cached_length; ++i) {
   f(obj);
}

... ponieważ fakt, że funkcja f nie modyfikuje parametru gwarantuje, że funkcja length zwróci ten sam wartości za każdym razem, gdy obiekt się nie zmienił. Jednakże, Jeśli f jest zadeklarowane, aby przyjmować parametr przez zmienną referencję, to length musiałby być ponownie obliczony przy każdej iteracji pętli, ponieważ f mógł zmodyfikować obiekt w sposób powodujący zmianę wartości.

Jak zaznaczono w komentarzach, zakłada to szereg dodatkowych zastrzeżeń i będzie możliwe tylko przy wywołaniu kompilatora w niestandardowym trybie, który pozwala mu na wykonanie dodatkowych założenia (takie jak to, że metody const są ściśle funkcją ich danych wejściowych i że optymalizacje mogą zakładać, że kod nigdy nie użyje const_cast do konwersji parametru referencyjnego const do zmiennego odniesienia).

Parametry funkcji:

const nie ma znaczenia dla pamięci odniesienia. To jak Wiązanie ręki za plecami optymalizatora.

Załóżmy, że wywołujesz inną funkcję (np. void bar()) w foo, która nie ma widocznej definicji. Optymalizator będzie miał ograniczenie, ponieważ nie ma możliwości sprawdzenia, czy bar zmodyfikował parametr funkcji przekazany do foo (np. poprzez dostęp do pamięci globalnej). Możliwość modyfikacji pamięci na zewnątrz i aliasingu wprowadzenie istotnych ograniczeń dla optymalizatorów w tym obszarze.

Chociaż nie pytałeś, const wartości dla parametrów funkcji pozwalają na optymalizację, ponieważ optymalizator ma zagwarantowany obiekt const. Oczywiście koszt skopiowania tego parametru może być znacznie wyższy niż korzyści optymalizatora.

Zobacz: http://www.gotw.ca/gotw/081.htm

Deklaracje zmiennych: const int i = 1234

To zależy gdzie jest zadeklarowane, kiedy jest tworzony, oraz Typ. Ta kategoria jest w dużej mierze tam, gdzie istnieją optymalizacje const. Modyfikowanie const obiektu lub znanej stałej jest niezdefiniowane, więc kompilator może dokonać pewnych optymalizacji; zakłada, że nie wywołujesz niezdefiniowanego zachowania i wprowadza pewne gwarancje.

const int A(10);
foo(A);
// compiler can assume A's not been modified by foo

Oczywiście, optymalizator może również zidentyfikować zmienne, które się nie zmieniają:

for (int i(0), n(10); i < n; ++i) { // << n is not const
 std::cout << i << ' ';
}

Deklaracje funkcji: const char* foo()

Nieistotne. Pamięć odniesienia może być modyfikowana zewnętrznie. Jeśli zmienna zwrócona przez foo jest widoczna, to optymalizator może dokonać optymalizacji, ale nie ma to nic wspólnego z obecnością/brakiem const na typie zwracanym przez funkcję.

Ponownie, const wartość lub obiekt jest inny:

extern const char foo[];

SomeClass* const pObj tworzy stały obiekt typu wskaźnik. Nie istnieje bezpieczna metoda zmiany takiego obiektu, więc kompilator może na przykład buforować go do rejestru z odczytem tylko jednej pamięci, nawet jeśli jego adres jest brany.

Pozostałe nie włączają żadnych optymalizacji, chociaż kwalifikator const w typie wpłynie na rozdzielczość przeciążenia i prawdopodobnie spowoduje wybranie różnych i szybszych funkcji.

Dokładne efekty const różnią się dla każdego kontekstu, w którym jest używany. Jeśli const jest używany podczas deklarowania zmiennej, jest fizycznie const i znajduje się w pamięci tylko do odczytu.

const int x = 123;

Próba odrzucenia const - ness jest nieokreślona:

Chociaż const_cast może usuwać stałość lub zmienność z dowolnego wskaźnika lub odniesienia, używając wynikowego wskaźnika lub odniesienia do zapisu do obiektu, który został zadeklarowany const lub aby uzyskać dostęp do obiektu, który został zadeklarowana zmienna wywołuje nieokreślone zachowanie. cppreference / const_cast

Więc w tym przypadku kompilator może przyjąć, że wartość x jest zawsze 123. Otwiera to pewien potencjał optymalizacji (propagacja stałych)

Dla funkcji to inna sprawa. Przypuszczać:

void doFancyStuff(const MyObject& o);

Nasza funkcja {[5] } może wykonać dowolną z następujących czynności z o.

1. nie modyfikować obiektu.
2. Odrzuć konsternację, a następnie zmodyfikuj obiekt
3. modify an mutable data member of MyObject

Zauważ, że jeśli wywołasz naszą funkcję z instancją MyObject, która została zadeklarowana jako const, wywołasz niezdefiniowane zachowanie za pomocą #2.

Pytanie Guru: czy poniższe wywołują nieokreślone zachowanie?

const int x = 1;
auto lam = [x]() mutable {const_cast<int&>(x) = 2;};
lam();