Uczono mnie, aby zachować definicje klas i kod oddzielne.C++: Kiedy dopuszczalne jest posiadanie kodu w pliku nagłówkowym?
Jednak widziałem sytuacje, w których ludzie często zawierają fragmenty kodu w nagłówku, np. proste metody dostępu, które zwracają odwołanie do zmiennej.
Gdzie narysujesz linię?
Ogólnie rzecz biorąc, rzeczy, które kompilator ma wstawiać lub kod szablonowy. W obu przypadkach kod musi być dostępny dla kompilatora wszędzie, gdzie jest używany, więc nie masz wyboru.
Należy jednak zauważyć, że im więcej kodu umieścisz w pliku nagłówkowym, tym dłużej będzie trzeba go kompilować - i tym częściej będziesz musiał dotykać plików nagłówkowych, powodując reakcję łańcuchową powolnych kompilacji :)
To zależy od Ciebie. Boost umieszcza prawie cały kod w nagłówku ... i jest to szanowana biblioteka.
Jednym z powodów, aby zminimalizować ilość kodu w nagłówkach, jest zminimalizowanie ilości kodu, który ma zostać przekompilowany po zmianie implementacji. Jeśli nie dbasz o to, możesz mieć dowolną ilość kodu w nagłówkach.
Czasami posiadanie kodu tylko w nagłówkach odbywa się celowo w celu odsłonięcia kodu - ATL robi to dla eaxmple.
Będę trzymać się kodu w plikach .c i .cpp oraz nagłówkach w plikach .h, .hpp. Powodem jest to, że gdy ściągam plik .tar.gz lub zip z kodu źródłowego, zawsze szukam plików .h dla plików nagłówkowych i plików .cpp dla źródła. Wiele osób przywykło do tego, więc myślę, że powinieneś zachować ten styl.
Gdy masz kod w pliku nagłówkowym dla prostych metod pobierających/ustawiających, jest on mniej lub bardziej w porządku, ponieważ albo chcesz zaoszczędzić trochę czasu pracy z powodu konserwacji kodu (wpisanie tej samej metody w nagłówku i pliku implementacji), albo ponieważ tak naprawdę chcesz, aby metoda była wbudowana z powodu obciążania wywołanego przez funkcję w krytycznych miejscach czasowych.
Będziesz nie tylko poddawany wolniejszym kompilacjom, ale czas łączenia może być ogromny, jeśli masz dużo klas widocznych mniej więcej wszędzie.
Kolejną wadą z kodem mieszania między plikami nagłówkowymi i implementacyjnymi jest czytelność. Jeśli w sposób ciągły deklarujesz w pliku nagłówkowym i konsekwentnie przechowujesz kod w pliku implementacyjnym, łatwiej jest zachować ten sam porządek między metodami. Nie ma brakujących luk, jeśli wiesz o co mi chodzi.
Pozdrawiam!
Zauważ, że możesz skończyć z dziwnymi efektami ubocznymi, jeśli umieścisz kod w pliku nagłówkowym i nie będziesz ostrożny z plikiem Makefile. Miałem kiedyś błąd z powodu kodu, który zmieniłem w nagłówku, który został przekompilowany do niektórych plików, ale nie innych, ponieważ zależności nie były poprawne w Makefile. To nie jest wielka sprawa, jeśli automatycznie wygenerujesz plik Makefile.
Podczas opracowywania dużego projektu C++ należy zachować czujność, aby każdy plik .CPP zawierał możliwie jak najmniej plików nagłówkowych.
Więc mam proste reguły dla „rysowanie linii”:
Jeżeli przez inline realizacji, plik nagłówka musi teraz zawierać dodatkowy plik nagłówka, należy przesunąć realizację z nagłówka i do pliku .CPP.
Oczywiście nie jest to jedyny powód, dla którego nie należy wstawiać, ale jest to określony przykład linii, której nie należy przekraczać.
Będziesz potrzebował kodu w nagłówku, jeśli chcesz "wstawić" kod. W przeciwnym razie, istnieje więcej zalet, aby trzymać implementację w ciele.
Ale gdy nagłówek rośnie w rozmiarze, to zajmie więcej i więcej czasu kompilacji, więc jest przydatny do wykorzystania prekompilowane nagłówki.
Wzmocnienie jest także dużym użytkownikiem szablonów i metaprogramowania szablonów - co oznacza DUŻĄ ilość kodu, który musi być dostępny w witrynie tworzenia szablonów. Więc są tu szczególnym przypadkiem ... – bdonlan