Kod C++ w plikach nagłówkowych

W dniu, w którym programiści C++ uzgodnią drogę, jagnięta będą leżeć z lwami, Palestyńczycy obejmą Izraelczyków, a koty i psy będą mogły się żenić.

Separacja między .h i .pliki cpp są w większości arbitralne w tym momencie, pozostałość optymalizacji kompilatora dawno temu. Moim zdaniem deklaracje należą do nagłówka, a definicje do pliku implementacji. Ale to tylko nawyk, nie religia.

Kod w nagłówkach jest ogólnie złym pomysłem, ponieważ wymusza rekompilację wszystkich plików zawierających nagłówek, gdy zmienisz rzeczywisty kod, a nie deklaracje. Spowolni to również kompilację, ponieważ będziesz musiał przeanalizować kod w każdym pliku zawierającym nagłówek.

Powodem posiadania kodu w plikach nagłówkowych jest to, że zwykle jest on potrzebny do poprawnego działania słowa kluczowego inline oraz podczas korzystania z szablonów, które są instancjonowane w innych plikach cpp.

To, co może Cię poinformować, to przekonanie, że większość kodu C++ powinna być templowana, aby umożliwić maksymalną użyteczność. A jeśli jest szablonem, to wszystko będzie musiało znajdować się w pliku nagłówkowym, aby kod klienta mógł go zobaczyć i utworzyć instancję. Jeśli jest wystarczająco dobre dla Boost i STL, to jest wystarczająco dobre dla nas.

Nie zgadzam się z tym punktem widzenia, ale może być tam, skąd pochodzi.

Myślę, że twój współpracownik jest mądry i masz również rację.

Przydatne rzeczy, które odkryłem, że umieszczanie wszystkiego w nagłówkach jest takie, że:

1. Nie ma potrzeby pisania i synchronizacji nagłówków i źródeł.

2. Struktura jest prosta i żadne koliste zależności nie zmuszają kodera do stworzenia "lepszej" struktury.

3. Przenośny, łatwy do osadzenia w nowym projekcie.

Zgadzam się z problemem czasu kompilacji, ale myślę, że powinniśmy zauważ, że:

1. Zmiana pliku źródłowego jest bardzo prawdopodobna, aby zmienić pliki nagłówkowe, co prowadzi do ponownego skompilowania całego projektu.

2. Szybkość kompilacji jest znacznie szybsza niż wcześniej. A jeśli masz projekt do zbudowania z długim czasem i wysoką częstotliwością, może to oznaczać, że twój projekt ma wady. Rozdzielenie zadań na różne projekty i moduł może uniknąć tego problemu.

Na koniec chcę tylko wspierać twojego współpracownika, tylko moim osobistym zdaniem.

Często umieszczam trywialne funkcje członkowskie w pliku nagłówkowym, aby umożliwić ich inlinowanie. Ale żeby umieścić tam cały kod, żeby był zgodny z szablonami? To zwykłe szaleństwo.

Pamiętaj: głupia konsystencja jest hobgoblinem małych umysłów .

Ogólnie rzecz biorąc, pisząc nową klasę, umieszczę cały kod w klasie, więc nie muszę szukać go w innym pliku.. Gdy wszystko działa, rozkładam ciało metod do pliku cpp, pozostawiając prototypy w pliku hpp.

Jak powiedział Tuomas, Twój nagłówek powinien być minimalny. Aby być kompletnym, poszerzę trochę.

Osobiście używam 4 typów plików w moich projektach C++:

• Public:
• nagłówek przekierowujący: w przypadku szablonów itp., plik ten otrzymuje deklaracje przekierowujące, które pojawią się w nagłówku.
• Header: ten plik zawiera nagłówek przekierowania, jeśli istnieje, i deklaruje wszystko, co chcę być publiczne (i definiuje klasy...)
• prywatne:
• Private header: ten plik jest nagłówkiem zarezerwowanym dla implementacji, zawiera nagłówek i deklaruje funkcje / struktury pomocnicze (na przykład dla pimpl lub predykatów). Pomiń, jeśli jest to niepotrzebne.
• plik źródłowy: zawiera nagłówek prywatny (lub nagłówek, jeśli nie ma nagłówka prywatnego) i definiuje wszystko (nie-szablon...)

Ponadto łączę to z inną zasadą: nie Definiuj tego, co możesz zadeklarować dalej. Choć oczywiście jestem tam rozsądny (używanie pimpl wszędzie jest dość kłopotliwe).

Oznacza to, że wolę deklarację forward niż dyrektywę #include w nagłówkach, kiedy tylko mogę z nimi uciec.

Na koniec używam również reguły widoczności: ograniczam zakresy moich symboli tak bardzo, jak to możliwe, aby nie zanieczyszczały zewnętrznych zakresów.

Ujmując to w całości:

// example_fwd.hpp
// Here necessary to forward declare the template class,
// you don't want people to declare them in case you wish to add
// another template symbol (with a default) later on
class MyClass;
template <class T> class MyClassT;

// example.hpp
#include "project/example_fwd.hpp"

// Those can't really be skipped
#include <string>
#include <vector>

#include "project/pimpl.hpp"

// Those can be forward declared easily
#include "project/foo_fwd.hpp"

namespace project { class Bar; }

namespace project
{
  class MyClass
  {
  public:
    struct Color // Limiting scope of enum
    {
      enum type { Red, Orange, Green };
    };
    typedef Color::type Color_t;

  public:
    MyClass(); // because of pimpl, I need to define the constructor

  private:
    struct Impl;
    pimpl<Impl> mImpl; // I won't describe pimpl here :p
  };

  template <class T> class MyClassT: public MyClass {};
} // namespace project

// example_impl.hpp (not visible to clients)
#include "project/example.hpp"
#include "project/bar.hpp"

template <class T> void check(MyClass<T> const& c) { }

// example.cpp
#include "example_impl.hpp"

// MyClass definition

Ratunkiem jest to, że w większości przypadków nagłówek forward jest bezużyteczny: konieczne jest tylko w przypadku typedef lub template i tak jest nagłówek implementacji;)

Jeśli ta nowa droga jest naprawdę drogą , w naszych projektach mogliśmy podążać w innym kierunku.

Ponieważ staramy się unikać wszystkich niepotrzebnych rzeczy w nagłówkach. Obejmuje to unikanie kaskady nagłówka. Kod w nagłówkach prawdopodobnie będzie potrzebował innego nagłówka, który będzie potrzebował innego nagłówka i tak dalej. Jeśli jesteśmy zmuszeni do używania szablonów, staramy się unikać zaśmiecania nagłówków zbyt dużą ilością szablonów.

Używamy również "nieprzezroczysty wskaźnik" - wzorzec w stosownych przypadkach.

Dzięki tym praktykom możemy tworzyć szybciej niż większość naszych rówieśników. I tak... zmiana kodu lub członków klasy nie spowoduje ogromnych przebudów.

Aby dodać więcej zabawy można dodać .ipp pliki, które zawierają implementację szablonu( który jest zawarty w .hpp), natomiast .hpp zawiera interfejs.

Jako że oprócz kodu templatowanego (w zależności od projektu może to być Większość lub mniejszość plików) istnieje zwykły kod i tutaj lepiej jest oddzielić deklaracje i definicje. W razie potrzeby należy podać również deklaracje typu forward - może to mieć wpływ na czas kompilacji.

Ja osobiście robię to w moich plikach nagłówkowych:

// class-declaration

// inline-method-declarations

Nie lubię mieszać kodu metod z klasą, ponieważ uważam, że szybkie szukanie rzeczy jest bolesne.

Nie umieszczałbym wszystkich metod w pliku nagłówkowym. Kompilator (normalnie) nie będzie w stanie wstawiać wirtualnych metod i będzie (prawdopodobnie) tylko małe metody bez pętli (całkowicie zależy od kompilatora).

Wykonywanie metod w klasie jest poprawne... ale z czytelnego punktu widzenia ja nie podoba mi się to. Umieszczenie metod w nagłówku oznacza, że jeśli to możliwe, zostaną one zainlinowane.

IMHO, ma zasługi tylko wtedy, gdy robi szablony i / lub metaprogramowanie. Jest już wiele powodów, dla których ograniczasz pliki nagłówkowe tylko do deklaracji. Po prostu... nagłówki. Jeśli chcesz dołączyć kod, skompiluj go jako bibliotekę i połącz.

Usunąłem całą implementację z definicji klasy. Chcę mieć komentarze doxygen z definicji klasy.

Czy to naprawdę nie zależy od złożoności systemu i wewnętrznych konwencji?

W tej chwili pracuję nad symulatorem sieci neuronowej, który jest niezwykle złożony, a przyjęty styl, którego mam używać, to:

Definicje klas w nazwach klas.h
Kod klasy w classnameCode.h
kod wykonywalny w nazwie klasy.cpp

To dzieli symulacje zbudowane przez Użytkownika od klas bazowych zbudowanych przez deweloperów i działa najlepiej w sytuacja.

Zdziwiłbym się jednak widząc, że ludzie robią to np. w aplikacji graficznej, czy jakiejkolwiek innej aplikacji, której celem nie jest dostarczenie użytkownikom bazy kodu.