Podział projektu na pliki a programowanie obiektowe

Cześć, próbuję zrobić mój pierwszy projekt używając programowania obiektowego. Dlaczego w menu.cpp mogę zdefiniować funkcję "adam" z pliku gra.cpp, a nie mogę w pliku menu.cpp stworzyć obiektu "gracz" klasy "adam" z pliku gra.cpp?

Funkcja:

//main.cpp
#include "menu.hpp"

int main()
{
    menu();
    return 0;
}

//menu.hpp
#ifndef MENU_HPP_INCLUDED
#define MENU_HPP_INCLUDED
#include "gra.hpp"

#include <iostream>
using namespace std;
void menu();

#endif // MENU_HPP_INCLUDED

// menu.cpp

#include "menu.hpp"
void menu(){
    adam(5);
}

//gra.hpp
#ifndef GRA_HPP_INCLUDED
#define GRA_HPP_INCLUDED

#include <iostream>
using namespace std;
void adam(short pkt);

#endif // GRA_HPP_INCLUDED

//gra.cpp
#include "gra.hpp"
void adam(short pkt){
    cout << "Adam ma " << pkt << " pkt";
}

Klasa:

//main.cpp
#include "menu.hpp"

int main()
{
    menu();
    return 0;
}

//menu.hpp
#ifndef MENU_HPP_INCLUDED
#define MENU_HPP_INCLUDED
#include "gra.hpp"

#include <iostream>
using namespace std;
void menu();

#endif // MENU_HPP_INCLUDED

// menu.cpp

#include "menu.hpp"
void menu(){
    adam gracz(5);
    cout << "Adam ma " << gracz.ilepkt();
}

//gra.hpp
#ifndef GRA_HPP_INCLUDED
#define GRA_HPP_INCLUDED

#include <iostream>
using namespace std;
class adam;

#endif // GRA_HPP_INCLUDED

//gra.cpp
#include "gra.hpp"

class adam{
private:
    short pkt;
public:
    adam(short p){
    pkt = p;
    }

    short ilepkt(){
        return pkt;
    }
};

Zwracany błąd:

E:\Moje Dokumenty\Programowanie\c++\gra\menu.cpp|5|error: variable 'adam gracz' has initializer but incomplete type|

Przedstawię ci inny model podziału na pliki. Jest o niebo lepszy, wszystko się ładnie łączy, standardowe nagłówki są użyte tylko raz i koniec.

Ok. Załóżmy że mamy plik main.cpp.
Następnie tworzymy plik Includes.h/hpp, oraz tworzymy plik nagłówkowy i plik źródłowy dla klasy.
Niech to będzie klasa CSamochod.

I teraz robimy tak: W includes.h zawieramy biblioteki standardowe oraz plik nagłówkowy klasy.
W kodzie źródłowym klasy zawieramy plik includes.h, w mainie zawieramy includes.h, a w pliku nagłówkowym klasy nie zawieramy niczego. Kompilator sam poskłada pliki tak, że w Includes znajdą się wszystkie definicje klas + na początku będą domyślne nagłówki, przez co daje to swobodny dostęp.

No i przykład:
Main.cpp:

#include "Includes.h"

int main(int, char**)
{
	CSamochod * pSamochod = new CSamochod();
	pSamochod->Method();
	delete pSamochod;
	
	return 0;
}
 

Includes.h:

#pragma once // dla zawarcia pliku tylko raz! można użyć ifndef..itd.
#include <cstdio>
#include <Windows.h>
#include <cstdlib>
#include <cmath>
// inne

#include "Samochod.h"
 

Samochod.h:

#pragma once
class CSamochod
{
public:
	CSamochod();
	~CSamochod();

	void Method();
};

Samochod.cpp:

 
#include "Includes.h"

CSamochod::CSamochod()
{
}

CSamochod::~CSamochod()
{
}

void CSamochod::Method()
{
	printf("CSamochod::Method()");
}

W ten sposób, możesz dołączać kolejno następne pliki nagłówkowe z klasami do includes.h, dodawać nowe kody źródłowe do projektu includujące includes.h, w których są metody.
Sam używam takiego czegoś, i jestem w sumie zadowolony.

ten pomysł z includes nie jest zbyt dobry,

w plikach cpp powinniśmy includować tylko to co nam potrzebne

a w nagłówkach wprowadzać forward deklarację, gdzie tylko się da

gośćabc napisał(a):

ten pomysł z includes nie jest zbyt dobry,

w plikach cpp powinniśmy includować tylko to co nam potrzebne

a w nagłówkach wprowadzać forward deklarację, gdzie tylko się da

Mówisz o pomyśle mwl4? W takim razie jak rozwiązać mój problem?

klasy definiujemy w plikach nagłówkowych, czyli na bank nie w gra.cpp, przenieś definicję​ do gra.h

i zaincluduj gra.h w plikach cpp, w których używasz klasy Adam czyli w menu.cpp

miej świadomość, że tworzysz tam Adama lokanie więc po wykonaniu menu() Adam zniknie

@mwl4 Dla mnie też nie wydaje się to do końca najlepsze rozwiązanie - chciałbym mieć w danych plikach dołączane tylko to co w tych plikach wykorzystuje i to powinno być według mnie jasno zaznaczone.

W sumie można by zapytać czy wszystkie niezbędne rzeczy można by zaincludować w pliku .h? Teoretycznie tak a praktycznie są przeciwwskazania?

"Napisałem, że można użyć #ifndef, #define. A to, że nie jest w standardzie no to cóż.. czysty idiotyzm. Jedynie panowie z msu pomyśleli że coś takiego jest przydatne."

"Widocznie niewiele masz wspólnego z programowaniem w większych projektach, bo sposób który pokazałem dominuje. A poza tym nie zapominaj, że jest tam pragma once."

styl oraz treść obu tych wypowiedzi świadczy jakim niedoświadczonym młokosem jesteś, waż swoje słowa bardzo uważnie następnym razem

mimo, że jest to internet pamiętaj, że takimi wypowiedziami "siłowymi" nic nie zyskasz, a tylko stracisz

Twoje rozwiązanie zajeżdża jakimś kursem visual studio 2005/2008, gdzie forsowano WINAPI i MFC., stąd ta pragma i niedorzeczne includowanie wszystkiego we wszystkim

a teraz lekcja: zmiana w pliku "Samochod.h" spowoduje rekompilację wszystkich plików cpp, które includują Twój nagłówek, ogólnie wszystko co jest niepotrzebne w danym pliku cpp a jest includowane spowoduje spowolnienie kompilacji

pewnie tego na kursach z 2005 roku nie było

"Jeśli choć troszkę popatrzyłeś na output w visualu to mogłeś zauważyć: "Skipping... (no relevant changes detected)" Poza tym, includowanie wszystkiego we wszystkim: I tak wszystko się pojawi tylko raz podczas kompilacji, więc mamy pełen dostęp do całego kodu/wszystkich klas, bez żadnych większych problemów, standardowe biblioteki są zawierane tylko raz więc sposób który przedstawiłem jest jednak chyba dobry. Poza tym, widziałeś gdzieś moje siłowe wypowiedzi? Ja sobie nie przypominam, ale ty może tak interpretujesz zwykłe wypowiadanie się."

dawno nie patrzyłem w output w visualu, bo moje maluteńkie projekty mają implementowane wszystko w c++11, które jest słabo wspierane przez visual compiler, ale ostatni post nie był o nagłówkach standardowych tylko o nagłówku samochod.h, który jest znany w całym programie. Podpowiadacz podczas pisania kodu będzie Ci wyświetlał listę wszystkich obiektów w programie, bo będziesz miał do nich swobodny dostęp w każdym pliku cpp; sam dostęp do wszystkiego jest już głupim rozwiązaniem;

"A co myślisz o włączeniu wszystkich niezbędnych rzeczy w pliku .h a w pliku .cpp już tylko samego pliku nagłówkowego?"

pytasz o dowolny plik h, czy o ten wspólny?

jak napisałem wspólny plik jest średnim rozwiązaniem, nie pisałem, że nie zadziała;

rzecz w tym, aby nie includować​ niepotrzebnych rzeczy i tyle, po co Ci include mapy w cpp, jeżeli jej nie używasz

zasada jest prosta, includujesz tylko to co potrzebne;

jeżeli chodzi o pliki nagłówkowe klas, to stosuję forward deklarację typów, których definicji nie muszę jeszcze znać, dopiero w pliku cpp gdzie już bez pośrednio pracuję na obiekcie, includuję pliki h definiujące te obiekty, ot cała filozofia

mwl4

napisałem, że Twoje rozwiązanie jest średnie wg. mnie i zaproponowałem alternatywę; podoba Ci się to je stosuj;

Nie chce mi się brać udziału w kolejnej bezproduktywnej dyskusji;

"c++11 jest wspierane w msvc, ale w visualu od 2011(a przypuszczam, że dla Ciebie visual się zakończył na 2008), więc nie wiem o co Ci w tej chwili chodzi. Może o czymś nie wiem, ale nie przypominam sobie, żebym miał jakieś drastyczne problemy z nim jeśli chodzi o standard 0x. Poza tym, czytanie ze zrozumieniem się kłania. "Skipping... (no relevant changes detected)" było właśnie odnośnie zmian w takim samochod.h. A poza tym (jak ty to nazwałeś?)"podpowiadacz", dobrze że sugeruje nam listę wszystkich struktur, obiektów itd., robi to i tak szybko i wszystko mamy pod ręką"

nudzisz. Nie będę wymieniał mnóstwa rzeczy nie wspieranych przez vc 11.0

koniec dyskusji

"@emacs najlepiej includowac tylko to co jest potrzebne w danym pliku, wiec... wiecej powinno byc tego w *.cpp niz w *.h. A jak potrzebujesz symbolu jakiegos w *.h, np. klasy Kotek, to pisze sobie nad moja klase class Kotek;"

dokładnie, to jest forward deklaracja

gośćabc napisał(a):

klasy definiujemy w plikach nagłówkowych, czyli na bank nie w gra.cpp, przenieś definicję​ do gra.h

i zaincluduj gra.h w plikach cpp, w których używasz klasy Adam czyli w menu.cpp

miej świadomość, że tworzysz tam Adama lokanie więc po wykonaniu menu() Adam zniknie

Super, dzięki działa ;) ale skoro jest to Twoje "ale", to jak polecałbyś to zrobić w inny sposób?

adamowski10 napisał(a):

gośćabc napisał(a):

klasy definiujemy w plikach nagłówkowych, czyli na bank nie w gra.cpp, przenieś definicję​ do gra.h

i zaincluduj gra.h w plikach cpp, w których używasz klasy Adam czyli w menu.cpp

miej świadomość, że tworzysz tam Adama lokanie więc po wykonaniu menu() Adam zniknie

Super, dzięki działa ;) ale skoro jest to Twoje "ale", to jak polecałbyś to zrobić w inny sposób?

w Twoim przypadku nic nie agregujesz, masz 1 typ Adam, który używasz tylko w cpp, to chyba wszystko