W jaki sposób mogę zapobiec kompilacji moich "nieużywanych" zmiennych globalnych?

Question

Używam statycznej inicjalizacji, aby ułatwić proces rejestracji niektórych klas z fabryki w C++. Niestety, myślę, że kompilator optymalizuje "nieużywane" obiekty, które mają za zadanie wykonywać użyteczną pracę w swoich konstruktorach. Czy istnieje sposób, aby powiedzieć kompilatorowi, aby nie optymalizować zmiennej globalnej?

class SomeClass { 
    public: 
     SomeClass() { 
      /* do something useful */ 
     } 
}; 

SomeClass instance; 

Mój punkt przerwania w konstruktorze SomeClass nie zostaje trafiony. W moim rzeczywistym kodzie SomeClass znajduje się w pliku nagłówkowym, a instancja jest w pliku źródłowym, mniej lub bardziej samodzielnie.

EDYCJA: Jak można się domyślić, KJAWolf, kod ten jest faktycznie skompilowany do statycznej biblioteki, a nie do pliku wykonywalnego. Jego celem jest zarejestrowanie niektórych typów dostarczanych przez statyczną bibliotekę statyczną listę typów i ich twórców, dla fabryki, która następnie będzie czytać z konstrukcji. Ponieważ te typy są dostarczane z biblioteką, dodanie tego kodu do pliku wykonywalnego jest niepożądane.

Odkryłem również, że przenoszenie kodu do innego pliku źródłowego zawierającego inny istniejący kod działa poprawnie. Wygląda na to, że przyczyną problemu jest posiadanie pliku składającego się wyłącznie z tych globalnych obiektów. To tak, jakby ta jednostka tłumaczeniowa została całkowicie zignorowana.

Answer 1

Kompilator nie może optymalizować obiektów globalnych.
Nawet jeśli nigdy nie są używane.

Coś jeszcze dzieje się w kodzie.
Teraz, jeśli zbudowałeś statyczną bibliotekę z twoim globalnym obiektem, a ten globalny obiekt nie jest przywoływany z pliku wykonywalnego, nie zostanie on wciągnięty do pliku wykonywalnego przez linker.

Answer 2

Kompilator nigdy nie powinien optymalizować takich globali - jeśli to robi, jest po prostu zepsuty.

Answer 3

Aby zbudować Arthura Ulfeldta, volatile mówi kompilatorowi, że zmienna ta może się zmienić poza wiedzą o kompilatorze. Użyłem go do wstawienia instrukcji zezwalającej debuggerowi na ustawienie punktu przerwania. Jest także przydatny w rejestrach sprzętowych, które mogą zmieniać się w zależności od środowiska lub wymagać specjalnej sekwencji. tzn. rejestr odbioru portu szeregowego i pewne rejestry watchdoga.

Answer 4

można użyć

 
#pragma optimize off 
int globalVar 
#pragma optimize on 

ale nie wiem jeśli to działa tylko w Visual Studio (http://msdn.microsoft.com/en-us/library/chh3fb0k(VS.80).aspx).

Można również powiedzieć, że kompilator nie optymalizacji w ogóle, zwłaszcza jeśli debugowanie ...

Answer 5

Czy używasz gcc z gdb? W przeszłości wystąpił problem, w którym gdb nie mógł dokładnie ustawić punktów przerwania w konstruktorze.

Czy używasz również poziomu optymalizacji, który umożliwia kompilatorowi inline metody w definicji klasy.

Answer 6

Co powiesz na użycie słowa kluczowego volatile? Zapobiegnie to zbyt dużej optymalizacji kompilatora.

Answer 7

Mam taki sam problem z instalacją na VS2008. Znalazłem, że jeśli zadeklarujesz klasę z dllexport, nie zostanie ona zoptymalizowana.

class __declspec(dllexport) Cxxx 
{ 
. 
} 

Jednak generuje to wiele ostrzeżeń w moim przypadku, ponieważ muszę zadeklarować wszystkie klasy używane w tej klasie także jako dllexport.

Wszystkie optymalizacje są wyłączone (w trybie debugowania), nadal jest to zoptymalizowane. Również zmienna/pragma optymalizuje się. Na zmiennej globalnej utworzonej z tej klasy (w tym samym pliku cpp) itp. Nie działa.

Po prostu okazało się, że dllexport wymaga co najmniej włączenia plików nagłówkowych tych klas w innym pliku cpp od exe do pracy! Tak więc jedyną opcją jest dodanie pliku z wywołaniami do statycznych członków dla każdej klasy i dodanie tego pliku do wszystkich projektów, w których używane są te klasy.

Answer 8

Należy użyć opcji -whole-archive przy łączeniu. Patrz odpowiedź tutaj:

ld linker question: the --whole-archive option

Answer 9

Można wymusić, że jeden obiekt (Lista rodzajów) ciągnie kilka innych obiektów z nią częściowo łączenie je przed zbudowaniem kompletny statyczny lib.

Z GNU linker:

ld -Ur -o TypeBundle.o type1.o type2.o type3.o static_list.o 
ld -static -o MyStaticLib.a type_bundle.o other_object.o another_object.o ... 

Tak więc, gdy lista statyczna odwołuje kodu przy użyciu biblioteki, pełna „TypeBundle.o” obiekt dostanie połączony do otrzymanego binarnego, w tym type1.o, type2 .o i type3.o.

W tym miejscu sprawdź znaczenie "-Ur" w the manual.