[kasper93]

#programowanie #cpp

Mam pytanie, może trochę nietypowe, ale jak są dobre praktyki includowania plików?

Mam na myśli przypadek.

#include "1.h"

#include "2.h"

#include "3.h"

Ale tak się składa, że 3.h ma w sobie 1 oraz 2. I teraz pytanie includować tak, żeby się kompilowało możliwie najkrótszą listę. Czy includować więcej małych plików na wypadek, gdyby na przykład z tego większego coś usunięto?

Ja wiem, że preprocesor wszystko zaincluduje tylko raz, ale pytam się jak to się robi w dużych projektach?

[S.....h]

@kasper93: raczej wsystko w jednym jesli różnią się tematyką bardzo to się rozbija na kilka.

[blisher]

@kasper93: mnie uczono ze includujemy tak jakby wg drzewa, jezeli 1.h includuje 2.h to w main inludujemy tylko 1.h

[O.....i]

Ja wiem, że preprocesor wszystko zaincluduje tylko raz

@kasper93: Z tym to naprawdę różnie bywa. Ogólnie wypada dawać guardy w postaci

#ifndef 1_H

#define

[Hauleth]

@kasper93: Inkludujesz "publicznie" te nagłówki, które zawierają funkcje, których używasz. Nie obchodzi Cię, że jakiś inny nagłówek też go inkluduje, bo osoba czytająca kod po Tobie może tego nie wiedzieć (albo mogą się zmienić zależności danej biblioteki).

[kasper93]

mnie uczono ze includujemy tak jakby wg drzewa, jezeli 1.h includuje 2.h to w main inludujemy tylko 1.h

to pomimo iż string załącza iostream, to Ciebie to nie obchodzi - używasz cout oraz string więc załączasz:

No i zgadzam się z wami oboma, ale nie wiem co lepsze.

Z

[WolverinePL]

@kasper93: Powinno się zmniejszać zależności i to jest ogólna zasada, ktoś używa mojej klasy np, i ja sobie jakiegoś includa wywalę bo refaktoring robie i muszę teraz jego plik poprawić bo się wysypało wszystko, w dużych projektach tych plików jest N.

Poza tym w większych rzeczach na ogół używa się interfejsów które mają mniej zaimportowanych rzeczy niż deklaracja implementacji a te z kolei powinny mieć ich mniej niż plik z