2014-06-13 6 views
7

Nie wydają się być dwie ścieżki zawierające Microsoft Visual Studio uruchomieniowe pliki źródłowe:Dlaczego kod źródłowy biblioteki środowiska wykonawczego Visual Studio jest przechowywany w dwóch katalogach?

C: \ Program Files (x86) \ Microsoft Visual Studio 12.0 \ VC \ crt \ src

i

C: \ Program Files (x86) \ Microsoft Visual Studio 12.0 \ VC \ include

jakiś plik s pojawiają się w obu katalogach, ale mają różne rozmiary. Spojrzałem na jeden plik w szczególności i miał taką samą metodę zdefiniowaną w obu plikach.

Moje pytanie brzmi: jaka jest różnica w użyciu dwóch ścieżek? Chciałbym wiedzieć, kiedy debuguję (nie mam na myśli trybu debugowania) w Visual Studio, który plik jest kodem na ekranie?

+2

Myślę, że nie masz włączonych opcji "Pokaż rozszerzenia plików" w Eksploratorze, więc mylą pliki nagłówkowe i źródłowe. – Dai

+0

Pliki, na które patrzyłem, były plikami nagłówkowymi, ponieważ użycie szablonów oznacza, że ​​implementacja musi znajdować się w pliku nagłówkowym. Oba zawierały implementację dla tej samej metody. – mezamorphic

Odpowiedz

1

CRT znajduje się na dole stosu bibliotek Visual C++: pozostałe biblioteki zależą od niego i zależą od niego praktycznie wszystkie rodzime moduły. Zawiera dwa rodzaje rzeczy: [1] C Standard Library i różne rozszerzenia oraz [2] funkcje uruchomieniowe wymagane do takich rzeczy, jak uruchamianie procesu i obsługa wyjątków. Ponieważ CRT znajduje się na samym dole stosu, logiczne jest rozpoczęcie procesu stabilizacji bibliotek.


(1) Wysyłamy większość źródeł do CRT z Visual Studio; możesz je znaleźć w katalogu instalacyjnym Visual Studio w VC \ crt \ src.

(2) W programie Visual Studio 2013 istnieją 6,830 #if, #ifdef, #ifndef, #elif i #else dyrektyw w źródłach, które wysyłamy wraz z produktem; w CTP Visual Studio "14" jest 1,656. Liczby te nie zawierają dyrektyw w nagłówkach i zawierają pliki źródłowe STL, które są w dużej mierze nienaruszone przez ten wysiłek refaktoryzacji, więc nie jest to idealny pomiar, ale wskazuje na ilość wykonanych porządków.

EDIT 1: informacje

Artykuł:

napisane przez: James McNellis

data: 10 Jun 2014 9:00 AM

url: http://blogs.msdn.com/b/vcblog/archive/2014/06/10/the-great-crt-refactoring.aspx

+3

Wątpię, czy jesteś w przebraniu Jamesa McNellisa, więc powinieneś podać * właściwą nazwę * (przynajmniej jego nazwisko i link do [oryginalnego artykułu] (http://blogs.msdn.com/b/vcblog/ archiwum/2014/06/10/the-great-crt-refactoring.aspx), które cytujesz). Nie widzę też, jak to odpowiada na pytanie. –

+1

oczywiście, będę edytować mój post teraz ... dzięki – angel

+0

@angel Które z nich używa VS, gdy przechodzę przez kod? – mezamorphic

9

Katalog include posiada wszystkie publicznie on aders. Są to nagłówki, które można dołączyć do kodu, takie jak <stdio.h> i <type_traits>, a także nagłówki implementacji wymagane przez te nagłówki.

Katalog crt\src zawiera źródła CRT, w tym większość .asm, .c i .cpp plików używanych do budowy CRT. Ten katalog ma również kopię wielu nagłówków CRT, aw niektórych przypadkach nagłówki te różnią się od tych w katalogu include. Jest to wyłącznie artefakt dotyczący budowy CRT.

Podczas debugowania kodu śródtekstowego zdefiniowanego w nagłówkach CRT, debugger powinien zawsze wybrać właściwy nagłówek. Jeśli oba katalogi zawierają tę samą kopię nagłówka, debugger po prostu wybierze jedną kopię, a ponieważ nagłówki są takie same, nie ma znaczenia, który z nich wybierze. Jeśli nagłówki są różne, to który nagłówek wybiera debugger, zależy od obiektu, do którego została skompilowana funkcja inline. Jeśli obiekt jest częścią CRT, przejdziesz do nagłówka od crt\src; jeśli obiekt pochodzi z jednego z plików źródłowych, przejdziesz do nagłówka od include. Zasadniczo debugger powinien zawsze być w stanie znaleźć poprawną kopię nagłówka.

Uprościliśmy to znacznie w CTP Visual Studio "14". W katalogu crt\src nie ma już publicznych nagłówków, a nagłówki wysłane w katalogu include to te same, które zostały użyte do zbudowania CRT.

Powiązane problemy