Klasse in neuer Klasse nutzen

Hallo,

kann mir jemand sagen, wie ich eine Klasse, wie zum Beispiel "fstream" in einer von mir erstellten Klasse nutzen kann, die ich in einer Header erstellt habe?
Also zum Beispiel:

///////////////////CLASS.h//////////////////////////
.
.
.
class NEUE_KLASSE
{
     public:
        void Test()
        {
           string Zeile;
           fstream f;
           f.open("blabla",ios::in);
           getline(f,Zeile);
           f.close();
        }
};
/////////////////main.cpp/////////////////////////////
   .
   .
   .
   NEUE_KLASSE Neu;
   Neu.Test();

Würd mich freuen, wenn mir da jemand helfen kann

Firefighter

Ja.
Includier einfach die fstream in deiner headerdatei, ungefähr so:

///////////////////CLASS.h//////////////////////////
#include<fstream>
#include<string>
class NEUE_KLASSE
{
     public:
        void Test()
        {
           std::string Zeile;
           std::fstream f;
           f.open("blabla",ios::in);
           std::getline(f,Zeile);
           f.close();
        }
};

Noch als Tip, wenn du eine Datei lesen willst, nutze dafür einfach std::ifstream

Xebov

Also ich halte es für keine gute Idee Header in header einzubidnen, da bekomm ich immer Bauchschmerzen, vor allem wenn man später eigene header mit Guards hat gibt das doch probleme ohne Ende, ich würde ja diese Lösung vorschlagen:

///////////////////CLASS.h//////////////////////////
class NEUE_KLASSE
{
     public:
        void Test();
}; 
///////////////////CLASS.cpp////////////////////////
#include<fstream>
#include<string>
using namespace std;

void NEUE_KLASSE::Test()
{
   string Zeile;
   fstream f;
   f.open("blabla",ios::in);
   getline(f,Zeile);
   f.close();
}

Xebov schrieb:

Also ich halte es für keine gute Idee Header in header einzubidnen, da bekomm ich immer Bauchschmerzen, vor allem wenn man später eigene header mit Guards hat gibt das doch probleme ohne Ende

kannst du das mal näher ausführen?

ich würde ja diese Lösung vorschlagen:

und was machst du, wenn NEUE_KLASSE ein template als member hat?

Oh man, danke. Ich hatte es so wie Firefighter gemacht aber vergessen, dass das alles ja im namespace std steht. Deswegen ging des bei mir. Und auch danke für den Tipp mit dem ifstream^^

Xebov

megan00b schrieb:

Xebov schrieb:

Also ich halte es für keine gute Idee Header in header einzubidnen, da bekomm ich immer Bauchschmerzen, vor allem wenn man später eigene header mit Guards hat gibt das doch probleme ohne Ende

kannst du das mal näher ausführen?

Naja ich bins ehr vorsichtig mit Header includes in Headern, man kann da schonmal über die headerguards stolpern wenn man nicht aufpasst und zum Beispiel wechselseitig Includiert, deswegen nutze ich sowas auch nur da wo mir nichts anderes einfällt, es ist vor allem vond er übersicht her günstiger wenn man nicht überall in den headern noch andere Header includes drin hat.

megan00b schrieb:

ich würde ja diese Lösung vorschlagen:

und was machst du, wenn NEUE_KLASSE ein template als member hat?

Ja das ist sone Ausnahme von demw as ich oben egschrieben habe, man solte es aber wirklich nur dann machen wenn es nicht anders geht, finde ich.

Nexus

Xebov schrieb:

Also ich halte es für keine gute Idee Header in header einzubidnen, da bekomm ich immer Bauchschmerzen, vor allem wenn man später eigene header mit Guards hat gibt das doch probleme ohne Ende

Es ist dir aber bewusst, dass es sehr viele Fälle gibt, in denen es nicht nur sinnvoll, sondern notwendig ist, in Headerdateien andere Header einzubinden? Templates sind da eher die Ausnahme. Jedes Mal, wenn du in einer Klassendefinition Member vom Typ einer anderen Klasse hast, brauchst du entsprechende Header.

Xebov schrieb:

Naja ich bins ehr vorsichtig mit Header includes in Headern, man kann da schonmal über die headerguards stolpern wenn man nicht aufpasst und zum Beispiel wechselseitig Includiert, deswegen nutze ich sowas auch nur da wo mir nichts anderes einfällt, es ist vor allem vond er übersicht her günstiger wenn man nicht überall in den headern noch andere Header includes drin hat.

Wo liegt das Problem bei Headerguards? Wenn man die konsequent durchzieht, funktionieren sie für alle Header. Und Fehler aufgrund zirkulärer Inkludierung passieren sowieso selten und sind in solchen Fällen auch schnell behoben.

Und findest du es übersichtlicher, wenn die #include s in den .cpp-Dateien stehen als in den Headern?

Xebov

Nexus schrieb:

Es ist dir aber bewusst, dass es sehr viele Fälle gibt, in denen es nicht nur sinnvoll, sondern notwendig ist, in Headerdateien andere Header einzubinden? Templates sind da eher die Ausnahme. Jedes Mal, wenn du in einer Klassendefinition Member vom Typ einer anderen Klasse hast, brauchst du entsprechende Header.

Wo liegt das Problem bei Headerguards? Wenn man die konsequent durchzieht, funktionieren sie für alle Header. Und Fehler aufgrund zirkulärer Inkludierung passieren sowieso selten und sind in solchen Fällen auch schnell behoben.

Und findest du es übersichtlicher, wenn die #include s in den .cpp-Dateien stehen als in den Headern?

Nein finde ich nicht, ich fidne es aber auch nicht übersichtlich wenn alle möglichen header alle möglichen anderen includen. Oft reichen ja auch forward Deklarationen und da finde ich es bedeutend übersichtlicher ne Forward Deklaration reinzuschreiben und dann alle header Zentral in einen einzubinden, so hab ich nur einen header den ich in die cpps einbinden muß und sehe Zentral was fehlt, bzw muß nicht irgendwelchen Includewegen folgen um zu sehen welche dateien über 5Ecken evtl mit eingebunden werden. Wenn es wirklich Nötig ist spricht ja nichts gegen direktes einbinden. Findeste sowas nicht auch übersichtlicher?

Nexus

Das Problem ist, dass man bei zentralen "Include-Headern" einzelne Dateien jeweils zu oft einbindet, was natürlich die Kompilierzeit erhöht. Ich habe bei mir eigentlich nur einen solchen Header (StdAfx.h), bei dem Headerdateien, die fast überall gebraucht werden (z.B. <vector> oder <boost/foreach.hpp> ), drin sind.

Und so schlimm finde ich es nicht, in die Dateien mehrere Header zu inkludieren. So sieht man jeweils auch gerade, was benötigt wird.

Edit: Formulierung

Xebov

Nexus schrieb:

Das Problem ist, dass man bei zentralen "Include-Headern" einzelne Dateien jeweils zu oft einbindet, was natürlich die Kompilierzeit erhöht.

Was verstehst du unter zu oft einbinden? Meinst du das einzellne Header mehrfach eingebunden werden oder meinst du das in die cpp Dateien Header eingebunden werden die man eigentlich gerade nicht braucht?

Nexus schrieb:

Und so schlimm finde ich es nicht, in die Dateien mehrere Header zu inkludieren. So sieht man jeweils auch gerade, was benötigt wird.

Gut sieht man mit Forward Deklaration auch.

Nexus

Xebov schrieb:

Was verstehst du unter zu oft einbinden? Meinst du das einzellne Header mehrfach eingebunden werden oder meinst du das in die cpp Dateien Header eingebunden werden die man eigentlich gerade nicht braucht?

Ja, jeweils Header, die man nicht braucht.

// Zentralheader.h
#include "A.h"
#include "B.h"
#include "C.h"
#include "D.h"
...

// AnwenderVonA.cpp
#include "Zentralheader.h"

Ohne vorkompilierte Header kann sich das massiv auf die Kompilierzeit auswirken, besonders wenn die einzelnen Header ihrererseits #include -Direktiven haben. Von daher finde ich, sollte man eher nur einbinden, was nötig ist. Meines Erachtens machen mehrere #include s eine Datei auch nicht hässlich.

Nexus schrieb:

Gut sieht man mit Forward Deklaration auch.

Ja - ob Forward Declaration möglich und sinnvoll ist, hängt vom gegebenen Kontext ab. Für die Übersichtlichkeit macht es meiner Ansicht nach keinen grossen Unterschied.

Xebov

Nexus schrieb:

Ja, jeweils Header, die man nicht braucht.
// Zentralheader.h
#include "A.h"
#include "B.h"
#include "C.h"
#include "D.h"
...

// AnwenderVonA.cpp
#include "Zentralheader.h"
Ohne vorkompilierte Header kann sich das massiv auf die Kompilierzeit auswirken, besonders wenn die einzelnen Header ihrererseits #include -Direktiven haben. Von daher finde ich, sollte man eher nur einbinden, was nötig ist. Meines Erachtens machen mehrere #include s eine Datei auch nicht hässlich.

Ja so sieht meins zzt aus, ca 20 Header, die aber selbst keine Direktiven haben, includiert in Reihenfolge in einen Zentral Header der dann in jede cpp Datei includiert ist. Damit komme ich auf um die 2min+ für einen kompletten durchgang wäre evtl mal ganz interessant es mal abzuändern und zu sehen was da rauskommen würde.

Xebov schrieb:

Nexus schrieb:
Ja, jeweils Header, die man nicht braucht.
// Zentralheader.h
#include "A.h"
#include "B.h"
#include "C.h"
#include "D.h"
...

// AnwenderVonA.cpp
#include "Zentralheader.h"
Ohne vorkompilierte Header kann sich das massiv auf die Kompilierzeit auswirken, besonders wenn die einzelnen Header ihrererseits #include -Direktiven haben. Von daher finde ich, sollte man eher nur einbinden, was nötig ist. Meines Erachtens machen mehrere #include s eine Datei auch nicht hässlich.
Ja so sieht meins zzt aus, ca 20 Header, die aber selbst keine Direktiven haben, includiert in Reihenfolge in einen Zentral Header der dann in jede cpp Datei includiert ist. Damit komme ich auf um die 2min+ für einen kompletten durchgang wäre evtl mal ganz interessant es mal abzuändern und zu sehen was da rauskommen würde.

für sowas gibts ja (zumindest im msvc) den vorkompilierten header...
aber da würde ich eigtl nur die std-header (und vll noch paar libs, die man benutzt) includen - auf jeden fall nur dinge, die sich eher eher nich ändern - sonst muss der ja auch jedes ma neu compiliert werden und verliert seinen vorteil...

bb

pumuckl

Xebov schrieb:

Ja so sieht meins zzt aus, ca 20 Header, die aber selbst keine Direktiven haben, includiert in Reihenfolge in einen Zentral Header der dann in jede cpp Datei includiert ist. Damit komme ich auf um die 2min+ für einen kompletten durchgang wäre evtl mal ganz interessant es mal abzuändern und zu sehen was da rauskommen würde.

Die reinste Abhängigkeitshölle also. Du änderst einen klitzekleinen Teil in einem der Header, z.B. weil du in irgendeiner Klasse für die interne Verwendung noch ein boolsches Flag haben möchtest, und musst deswegen das ganze Projekt neu kompilieren, weil indirekt ALLE Übersetzungseinheiten diesen einen Header einbinden *schauder*. Bei dir sind das lächerliche 20 Header - stell dir mal vor wie sich das auswirkt wenn du bei einigen hundert oder gar tausend Headern bist und ein Komplett-build deines Programms mal eben eine halbe Stunde oder mehr benötigt.

Sowas tut man nicht. Man bindet jeden Header einzig und allein dort ein wo er gebraucht wird. Und selbstverständlich verzichtet man auf #includes wenn es eine forward-Deklaration auch tut.

Schau dir mal folgendes an:
http://www.gotw.ca/gotw/007.htm
Ist zwar von 1997, aber immernoch aktuell.

Nexus

unskilled @logged-off schrieb:

für sowas gibts ja (zumindest im msvc) den vorkompilierten header...
aber da würde ich eigtl nur die std-header (und vll noch paar libs, die man benutzt) includen - auf jeden fall nur dinge, die sich eher eher nich ändern - sonst muss der ja auch jedes ma neu compiliert werden und verliert seinen vorteil...

Ja, eben. Für Xebovs Fall wären vorkompilierte Header nicht unbedingt angebracht, da man durch die ständigen Änderungen keine Vorteile des Vorkompilierens hat.

Ansonsten kann ich nur pumuckl zustimmen, das Wort "Hölle" triffts gut...

Xebov

Ich habs mir mal durchgelesen, ich fidne nicht alels aus dem text so gut, aber der Grundgedanke is schon nicht schlecht. Werd mich mal über die Umsetzung machen.

Shade Of Mine

Xebov schrieb:

Naja ich bins ehr vorsichtig mit Header includes in Headern, man kann da schonmal über die headerguards stolpern wenn man nicht aufpasst und zum Beispiel wechselseitig Includiert, deswegen nutze ich sowas auch nur da wo mir nichts anderes einfällt, es ist vor allem vond er übersicht her günstiger wenn man nicht überall in den headern noch andere Header includes drin hat.

Ne ne. Jeder Header muss autark sein. Sonst kennt sich ja niemand mehr aus.

Jeder header muss alles inkludieren was er braucht - nicht mehr, aber auch nicht weniger.