initialized data in header
-
Ne. string wTitel=string(""). Aber das kann nicht so richtig sein. Du hast doch nicht etwa im header using namespace std; benutzt?
-
ness schrieb:
Ne. string wTitel=string(""). Aber das kann nicht so richtig sein. Du hast doch nicht etwa im header using namespace std; benutzt?
doch hab ich, da ich keine Ahnung hab wie man es sonst macht.
#include <string> #using namespace std;
sollte man es ohne machen? (bringt aber immernoch keinen Unterschied...)
// Test.h #include <string> class Test { public: int create1(int x, int y, int wTitel=0); // hier ist alles ok int create2(int x, int y, std::string wTitel); // hier ist auch alles ok int create3(int x, int y, std::string wTitel=""); // hier meldet er: // Warning: initialized data in header };
gibt es überhaubt ne Lösung???
-
Kannst du uns mal bitte sagen, welchen Compiiler du benutzt? Weil es ist richtig was du da gemacht hast.
using namespace sollte man tatsächlich in Headern vermeiden!
-
bcb6
-
ist es jetzt ein fehler oder eine warnung?
-
using ... in der header ist deshalb verpönt, weil man in der üe den namespace dann auch geüffnet hat und nicht wieder "schließen" kann.
So würde ich es machen:#include <string> class Test { private: static const std::string null_string; public: int create1(int x, int y, int wTitel=0); int create2(int x, int y, const std::string& wTitel); int create3(int x, int y, const std::string& wTitel=null_string); }; //test.cpp #include "test.h" const std::string Test::null_string("");
-
Shade Of Mine schrieb:
ist es jetzt ein fehler oder eine warnung?
warning
aber als perfektionist ... Fehler!!!
schließlich ist man bemüht perfekten code zu schreiben
ness schrieb:
using ... in der header ist deshalb verpönt, weil man in der üe den namespace dann auch geüffnet hat und nicht wieder "schließen" kann.
using allgemein oder "nur" using namespace?
ness schrieb:
So würde ich es machen:
#include <string> class Test { private: static const std::string null_string; public: int create1(int x, int y, int wTitel=0); int create2(int x, int y, const std::string& wTitel); int create3(int x, int y, const std::string& wTitel=null_string); }; //test.cpp #include "test.h" const std::string Test::null_string("");
hm, viel aufwand für wenig gewinn und zusätzlich sieht es nicht mehr so einfach aus und könnte zusätzliche fehler enthalten. bin am überlegen ob ich das warning einfach abschalte (wobei ich das sehr sehr ungern machen
)
-
bcb6? Von wann ist der? Aus dem letzten Jahrtausend? Würde mal auf nen aktuellen Compiler wechseln, dann gibts auch kein Warning.
-
Ne, allgemein jedes using. Die namespaces sind dazu da, um kollisionen zu vermeiden. using in einem neuen namespace sollte aber OK sein (using namespace besser auchnicht in einenm neuen namespace, wenn du nicht sehr genau weißt was drinsteht.)
-
ness schrieb:
using in einem neuen namespace sollte aber OK sein (using namespace besser auchnicht in einenm neuen namespace, wenn du nicht sehr genau weißt was drinsteht.)
Auch das nicht. Zwar sind in diesem Fall weniger die möglichen Kollisionen ein Problem. Dafür hast du aber ein anderes: using-Deklarationen sind (im Gegensatz zu using-Direktiven) reihenfolge-abhängig da nur solche Namen "geused" werden, für die bereits eine Deklaration sichtbar ist. Das heißt aber dann, dass ein Header der using-Deklarationen enthält unterschiedliche Bedeutungen haben kann, abhängig davon welche Header vor diesem Header inkludiert werden (darauf hast du keinen Einfluss, da du nicht wissen kannst, in welcher Reihenfolge ein Client seine Header inkludiert).
Im schlimmsten Fall hast du ein Programm, in dem der selbe Header an zwei Stellen zwei unterschiedliche Bedeutungen hat -> Verletzung der ODR -> undefiniertes Verhalten.Kurz: In Header gehören weder using-Direktiven noch using-Deklarationen (mal abgesehen von denen im Scope einer Klasse).
In einer cpp-Datei hingegen kannst du machen was du willst, solange die using-Deklarationen/Direktiven *nach* allen includes stehen.
Eine cpp-Datei ist ein abgeschlossenes Gebilde. Kollisionen betreffen nur diese eine Datei und können niemals die Bedeutung anderer Programmteile beeinflussen.