Jakie są konsekwencje wykorzystania /Zi vs / Z7 dla projektów Visual Studio C++?

Jedną z zalet starego formatu C7 jest to, że jest on all-in-one, przechowywany w EXE, zamiast oddzielnego PDB i EXE. Oznacza to, że nigdy nie można mieć niedopasowania. Narzędzia VS dev upewnią się, że PDB pasuje do swojego EXE, zanim go użyje, ale zdecydowanie łatwiej jest mieć pojedynczy EXE ze wszystkim, czego potrzebujesz.

Dodaje to nowe problemy z koniecznością usunięcia informacji o debugowaniu po wydaniu, oraz gigantycznego pliku EXE, nie wspominając o starożytnym formacie i braku wsparcia dla inne nowoczesne funkcje, takie jak minrebuild, ale nadal mogą być pomocne, gdy próbujesz utrzymać rzeczy tak proste, jak to możliwe. Jeden plik jest łatwiejszy niż dwa.

Nie żebym kiedykolwiek korzystał z formatu C7, po prostu umieszczam to tam jako możliwą zaletę, skoro pytasz.

Nawiasem mówiąc, tak GCC robi rzeczy na kilku platformach, których używam. Format DWARF2 zakopany w wyjściowym ELFIE. ludzie Uniksa myślą, że są tacy komiczni. :)

BTW format PDB można parsować za pomocą DIA SDK .

Jest jeszcze jedna wada dla /Z7: Nie jest kompatybilny z przyrostowym linkowaniem, co może być powodem, aby go uniknąć. Link: http://msdn.microsoft.com/en-us/library/4khtbfyf%28v=vs.100%29.aspx

Przy okazji: nawet jeśli Microsoft mówi, że pełne łącze (zamiast przyrostowego) jest wykonywane, gdy "obiekt skompilowany z opcją /Yu /Z7 jest zmieniony.", wydaje się, że dotyczy to tylko bibliotek statycznych zbudowanych z /Z7, a nie plików obiektowych.

Kolejną wadą /Z7 jest duży rozmiar plików obiektowych. Zostało to już tutaj wspomniane, jednak może to nasilić się do punktu, w którym linker nie jest w stanie połączyć pliku wykonywalnego, ponieważ łamie limit rozmiaru linkera lub formatu PE (daje błąd linkera LNK1248). Wydaje się, że Visual Studio lub format PE ma twardy limit 2GB (również na maszynach x64). Podczas tworzenia wersji debugowania możesz uruchomić ten limit. Wydaje się, że wpływa to nie tylko na wielkość ostateczny skompilowany plik wykonywalny, ale także dane tymczasowe. Tylko Microsoft wie o wewnętrznych linkerach, ale natknęliśmy się na ten problem tutaj (choć plik wykonywalny nie był oczywiście duży o 2gigs, nawet w debugowaniu). Problem w cudowny sposób zniknął i nigdy nie wrócił, gdy zmieniliśmy projekt na /ZI.