5

W tej chwili jestem nieco zdezorientowany, ponieważ planuję dołączyć wiele plików źródłowych i nagłówkowych po raz pierwszy w jednym z moich projektów.
Więc zastanawiam się, czy to byłoby właściwe podejście?
Czy muszę umieścić nagłówek łańcucha w każdym pliku źródłowym, który używa go bezpośrednio?
A co z nagłówkiem "stdafx.hpp", który powinien zawierać program Visual C++?C++ Czy muszę dołączyć standardowe biblioteki dla każdego pliku źródłowego?

Czy to byłaby droga?

main.cpp

#include "stdafx.hpp" 
#include <string> //? 
#include <stringLib1.h> 
#include <stringLib2.h> 
using std::string; 

//use a windows.h function here 
//use a stringLib1 function here 
//use a stringLib2 function here 

stringLib1.h

#include "stdafx.hpp" 
#include <string> 
using std::string; 

class uselessClass1 
{ 
public: 
    string GetStringBack1(string myString); 
}; 

stringLib1.cpp

#include "stdafx.hpp" 

string uselessClass1::GetStringBack1(string myString) { 
    return myString; 
} 

stringLib2.h

#include "stdafx.hpp" 
#include <string> 
using std::string; 

class uselessClass2 
{ 
public: 
    string GetStringBack2(string myString); 
}; 

stringLib2.cpp

#include "stdafx.hpp" 

string uselessClass2::GetStringBack2(string myString) { 
    return myString; 
} 
+7

Tak, musisz uwzględnić pliki nagłówkowe w każdym pliku, którego chcesz użyć. Jednak nie powinieneś używać słowa kluczowego 'using' w nagłówku. To nie jest dobry styl. –

+0

@ user2572585 Kto mówi o stylu? – nbro

+2

@ Komórkę Mam nadzieję, że to był sarkastyczny komentarz i nie byłeś poważny. – CoryKramer

Odpowiedz

0

stdafx to powinno być na górze każdego pliku .cpp i nie powinno być w plikach .h. Możesz wstawić #include < ciąg> w stdafx.h, jeśli nie chcesz umieszczać go w każdym innym pliku.

+0

Możesz * polegać * na stdafx, aby dać ci wspólne nagłówki i na pewno wielu deweloperów, ale żałuję, że tego nie zrobiliby (i żałuję, że nie było przełącznika VS, aby uznać to za błąd). Problem polega na tym, że utrudnia ponowne wykorzystanie plików pomiędzy różnymi projektami, ponieważ każdy będzie miał inny stdafx. – dlf

+0

To prawda, ale możesz łatwo dodać brakujące nagłówki, gdy napotkasz błąd, nieprawdaż? – XTF

+0

Tak, ale jeśli jest to inna osoba w innym dziale pracującym nad innym projektem, który dzieli kod z twoimi, którzy dokonują odkrycia, sytuacja staje się polityczna! :) – dlf

-1

Przypuszczam, że musisz mieć własne pliki nagłówkowe, które mogą być wymagane w innych plikach cpp i plikach nagłówkowych. Jak ten, który dał

#include <stringLib1.h> 
#include <stringLib2.h> 

W mojej opinii, że lepiej, aby utworzyć jeden wspólny nagłówek pliku, w którym uwzględniono wszystkie wspólne biblioteki i pliki nagłówkowe plik nagłówka projektu. Plik ten można następnie dołączyć do wszystkich innych plików cpp i pliku nagłówkowego. I lepiej będzie też użyć osłon nagłówka.

Biorąc pod uwagę wspólny plik nagłówkowy "includes.h".

#ifndef INCLUDES_H 
#define INCLUDES_H 

#include <string> 

#include <stringLib1.h> 
#include <stringLib2.h> 

/***Header files***/  

#endif //INCLUDES_H 

To jest teraz twój wspólny plik nagłówkowy. Można to uwzględnić we wszystkich plikach projektu.

+2

Co za okropny pomysł. Jeśli nie prekompilujesz tego nagłówka, dlaczego na ziemi niepotrzebnie uwzględnisz wszystkie nagłówki w każdej jednostce tłumaczeniowej ?! –

+0

Przypuszczam, że nigdy nie pracowałeś nad dużym projektem C++. Pomysł ten wkrótce okazał się piekłem na Ziemi. –

+0

W rzeczywistości w moim przedsiębiorstwie takie podejście jest przestrzegane. A ponieważ zauważyliście, że to nie jest dobre podejście, zagłębię się w to jeszcze bardziej. Dzięki. – Arpit

3
  1. Dobrą praktyką jest zazwyczaj uwzględnianie tylko tego, co używa twój kod w każdym pliku. Która zmniejsza zależność od innych nagłówków, a na dużych projektach, skrócenia czasu kompilacji (a także pomaga dowiedzieć się, co zależy od tego)

  2. Zastosowanie include guards w plikach nagłówkowych

  3. nie przywozili na wszystko przez polluting globalna przestrzeń nazw, np

    using namespace std; 
    

    ale raczej zakwalifikować, co masz zamiar używać, gdy trzeba to

  4. Nie trzeba stdafx.h w projekcie unless you're using precompiled headers. Można kontrolować to zachowanie we właściwościach projektu VS (C/C++ -> Prekompilowane Nagłówki -> prekompilowanego Header)

3

Nagłówek stdafx.h jest potrzebna jeśli prekompilowana nagłówek jest włączony VS. (Read this one) Wystarczy dołączyć stdafx.h w swoich plikach .cpp jako pierwsze dołączenie.

Odnośnie plików nagłówkowych i plików cpp (które są w parze), należy dołączyć elementy niezbędne do deklaracji w nagłówku i uwzględnić w cpp wszystko inne (niezbędne do definicji). Uwzględnij także odpowiedni nagłówek w parze cpp. I użyj include guards.

myclass.h

#ifndef MYCLASS_H // This is the include guard macro 
#define MYCLASS_H 

#include <string> 
using namespace std; 

class MyClass { 
    private: 
     string myString; 
    public: 
    MyClass(string s) {myString = s;} 
    string getString(void) {return myString;} 
    void generate(); 
} 

myclass.cpp

#include <stdafx.h> // VS: Precompiled Header 
// Include the header pair 
#include "myclass.h" // With this one <string> gets included too 
// Other stuff used internally 
#include <vector> 
#include <iostream> 

void MyClass::generate() { 
    vector<string> myRandomStrings; 
    ... 
    cout << "Done\n"; 
} 

#endif 

Następnie w main(...), można po prostu zadzwonić i obejmują myclass.hgenerate() funkcję.

Powiązane problemy