Po uruchomieniu gcov foo.cpp generuje on nie tylko raport dotyczący pokrycia kodu dla foo.cpp, ale także dla wszystkich nagłówków STL używanych przez foo.cpp.Dlaczego gcov tworzy dane pokrycia kodu dla nagłówków STL?
Czy istnieje sposób, aby temu zapobiec? Wydaje się ignorować standardowe nagłówki bibliotek, takie jak <ctime>.
Edit
Wystarczy biegł tym poście na gcc listy:
plików Wszelkie C++ nagłówek z kodem inline dostaną oprzyrządowanie pokrycia podczas kompilacji, a wyniki będą widoczne z gcov. Jedną z przydatnych flag jest "gcov -long-file-names" (lub po prostu -l), który tworzy unikalny plik wyjściowy .gcov dla każdego nagłówka zawartego w danym pliku. Pliki mają nazwy takie jak "foo.cpp ## bar.h.gcov". Ułatwiłoby to później ich usunięcie za pomocą "rm * \ # \ # *. Gcov" (ostrożnie z tymi ukośnikami odwrotnymi!)
Innym sposobem wykrywania tych plików jest szukanie linii o numerach 0 w wyjście gcov. Oznaczono te informacje, w tym "Źródło:" pełną ścieżką do oryginalnego pliku źródłowego.
Może masz starą wersję, nie widzę żadnego pliku z podwójnym znakiem w moich wynikach. Istnieją jednak pliki binarne z rozszerzeniem .gcno, a te pasują do tych nazw plików (możesz je zobaczyć, używając łańcuchów przeciwko tym plikom binarnym). –
Świetnie! Opcja "-l" rozwiązała wiele problemów z funkcjami wbudowanymi i szablonami. –
-r --relative tylko
Tylko wyjście informacji o plikach źródłowych o względnej ścieżki (po źródło przedrostka elizji). Ścieżki bezwzględne są zwykle plikami nagłówkowymi systemu, a zasięg jakichkolwiek wbudowanych funkcji w nich jest zwykle nieinteresujący.
dzięki. w zasadzie to zignorowałoby rzeczy zawarte w '#include
Tak, osiągnięcie 100% pokrycia stl wydaje się kolosalnym zadaniem, wątpię nawet, że programiści STL mają zestaw testów ze 100% pokrycia ^^. To pytanie jest rzeczywiście bardzo przydatne. – GameDeveloper