Header oder nicht Header?

pumuckl

asc schrieb:

2. Vorwärtsdeklarationen funktionieren ausschließlich mit Referenzen und Zeigern, sofern auf diese noch nicht in der Datei zugegriffen wird

Und mit Funktionsrückgabetypen und -argumenten in Funktionsdeklarationen sowie mit templates, soweit in der Datei nicht (explizit oder implizit) auf Funktionen des Templates zugegriffen wird, die eine Definition der Klasse benötigen.

RHBaum

namespace std
{class string;}

da sollte eigentlich kaum nen compiler mitspielen oder ...
std::string ist nen typedef auf std::basic_string<char> und keine eigenständige klasse.

wenn <map> schon einbindest, und die eh <string> ebenfalls incudiert, dann machts eh kein unnerschied das <string> selber noch mal includierst. Im Gegenteil es ist sicher fuer STL-Impls, und funktioniert auch wo <map> nicht <string> includiert.

Wenn da dranrumschrauben willst dann bitte so das <map> und <string> rausbekommst.
Aber nen std::basic_string und ne std::map forwarden ist ned lustig besser ne eigene klasse die nur map und string verwendet, und diese Pimpl'n (SIehe PIMPL Idom).

Ciao ...

Wurstinator

Es ging mir nur um die Unterschiede zwischen den Codes.

Wie sieht es aus, wenn es sich nicht um Templates handelt?

// Einkaufswagen.h
class Supermarkt_Ware;

class Einkaufswagen
{
public:
    Einkaufswagen() {}
    Supermarkt_Ware& ware_im_wagen(int index);
  // ...
};

// Einkaufswagen.cpp
#include <einkaufswagen.h>
#include <supermarkt_ware.h>

Supermarkt_Ware& Einkaufswagen::ware_im_wagen(int index)
{
 // ...
}

Oder sollte ich "supermarkt_ware.h" lieber im Einkaufswagen-Header inkludieren?

pumuckl

Wurstinator schrieb:

Oder sollte ich "supermarkt_ware.h" lieber im Einkaufswagen-Header inkludieren?

Gegenfrage: musst du ihn includieren?

Siehe auch hier: http://gotw.ca/gotw/007.htm

Wurstinator

So, wie der Code jetzt da steht, nicht, darum frage ich ja

Mir wurde auch schon gesagt, man sollte immer alles in Header inkludieren wenn möglich.

pumuckl

Wurstinator schrieb:

Mir wurde auch schon gesagt, man sollte immer alles in Header inkludieren wenn möglich.

Dann zeig demjenigen mal einen gehörigen Vogel. Je weniger includes du in einem Header hast, desto besser. Wenn eine forward declaration reicht, dann nimm die. Binde den Header in der .cpp ein. Sonst kriegst du unnötige Abhängigkeiten in deinen Code, siehe der Link den ich oben gepostet hab.

volkard

pumuckl schrieb:

Wurstinator schrieb:

Mir wurde auch schon gesagt, man sollte immer alles in Header inkludieren wenn möglich.

Dann zeig demjenigen mal einen gehörigen Vogel. Je weniger includes du in einem Header hast, desto besser. Wenn eine forward declaration reicht, dann nimm die. Binde den Header in der .cpp ein. Sonst kriegst du unnötige Abhängigkeiten in deinen Code, siehe der Link den ich oben gepostet hab.

Ich nehme forward-Deklarationen nur, um zyklische Abhängigkeiten zu vermeiden. Ansonsten werden alle benötigten Typen immer inkludiert. Aber auch nicht mehr.

Außer, um so schwere Brocken wie die <windows.h> loszuwerden, gegen die wende ich schonmal Tricks an.

pumuckl

volkard schrieb:

Ich nehme forward-Deklarationen nur, um zyklische Abhängigkeiten zu vermeiden. Ansonsten werden alle benötigten Typen immer inkludiert. Aber auch nicht mehr.

So hab ichs früher auch gemacht. Bis ich in einem unserer Module in der Firma mal durch einen simplen Header mit Forward-Deklarationen die Buildzeit um 60% reduziert hab. Ab einem bestimmten Punkt lohnt sich das dann eben doch merklich...

volkard

pumuckl schrieb:

volkard schrieb:

Ich nehme forward-Deklarationen nur, um zyklische Abhängigkeiten zu vermeiden. Ansonsten werden alle benötigten Typen immer inkludiert. Aber auch nicht mehr.

So hab ichs früher auch gemacht. Bis ich in einem unserer Module in der Firma mal durch einen simplen Header mit Forward-Deklarationen die Buildzeit um 60% reduziert hab. Ab einem bestimmten Punkt lohnt sich das dann eben doch merklich...

Dann lag das eigentliche Problem aber woanders. Wie im <map> von msvc, der <stdexept> inkludiert, der wiederum <string> braucht. WObei msvc das wieder recht gut mit precompiled headers bekämpfen kann.
Aufräumen hat bei mir aber immer *viel* mehr gebracht, als gelegentliches Pimpeln, Forwarden und Precompilen. Wenn Du natürlich dicke Oschis inkludieren mußt, die Du nicht beeinflussen kannst, dann trickse.

Wurstinator schrieb:

Mir wurde auch schon gesagt, man sollte immer alles in Header inkludieren wenn möglich.

Dann zeig demjenigen mal einen gehörigen Vogel. Je weniger includes du in einem Header hast, desto besser.

Naja, er hat nicht ganz unrecht wenn man es nicht falsch versteht. Man sollte alle header inkludieren, die man braucht. Aber auch nicht mehr.

Man soll halt nicht

#include <map>

schreiben, und das

#include <string>

weglassen weils halt beim verwendeten compiler geht - da dann lieber beides rein. Was man aber nicht braucht, included man wenns geht auch nicht.

Auch bei einem eigenen Projekt sollte man sich meiner Meinung nach nicht darauf verlassen, das ein header b.h auch noch den header c.h mitbringt - das kann sich nämlich ändern.

Konktret:
b.h:

#include "c.h"

a.cpp:

#include "b.h"
#include "c.h" //selbst wenn es momentan unnötig ist! 
//So muss ich mich nicht drum kümmern, das wenn ich denn header c.h in b.h nicht mehr brauche, ich plötzlich compilerfehler in a.cpp bekomme