Anfängerfehler
-
Dann bist du in einem der unglücklichen Fälle wo zur Laufzeit alles wunderbar läuft und erst beim Beenden des Programms gibts Salat weil du irgendwo was böses angestellt hast. Wenns bei der Freigabe von strings knallt versuch mal stückweise einzelne Programmteile auszuschließen um die Fehlerursache etwas einzugrenzen, und dann im fehlerhaften programmteil die Behandlung deiner Strings rauskommentieren - vermutlich stößt du schon auf dem Weg dahin irgendwo über den Fehler. Das wichtigste ist: immer hinterfragen was du gemacht hast, ob die Annahmen die du in einem Stück Code hast auch wirklich zutreffen.
-
Na endlich nachdem ich nun die komplette main.cpp auskommentiert habe, hab ich nun auch angefangen die Dateien die mit dem Projekt verknüpft waren aus dem Projekt zu entfernen. Und siehe da es läuft durch ohne Fehler...
Welche Dateien muss ich dem Projekt als Headerdateien/Quelldateien hinzufügen?
Reicht es nicht wenn ich die Dateien bzw. ihre Header in der main.cpp mittels #include einfüge?MfG
Scarabol
-
Grundsätzlich reicht es, wenn einfach der Fehlerhafte Code nicht ausgeführt wird. Also wenn du mal alles auskommentiert hast, dann kommentier den Code wieder rein bis der Fehler wieder passiert. Dann kannst du die Schranke recht gut eingrenzen.
-
Ich hab hier grad ein ganz merkwürdiges Verhalten das ich mir nicht erklären kann:
1. Ich habe alle Codes vom Projekt gelöst nur noch die main.cpp ohne #includes
=> Alles läuft ohne Fehler...
2. Ich füge die Codes dem Projekt wieder hinzu
=> Alles läuft ohne Fehler...
3. Ich füge die Includes in der main.cpp wieder dazu
=> ERROR
4. Und hier passiert das merkwürdige mach ich den 3. Schritt rückgängig bleibt der Fehler trotzdem bestehen???Wie kommt das? Wenn ich den 3. Schritt rückgängig mache sollte das Projekt doch wieder bei der lauffähigen 2. Variante sein? Oder nicht?
Was macht VC++ mit den Code, die zum Projekt hinzugefügt werden eigentlicht???EDIT
ARGH! Jetzt funzt das auch nicht mehr (ohne Includes und das Projekt hat nur eine Datei main.cpp)EDIT
ARG! Nochmal kompiliert und jetzt läufts wieder ?????EDIT3
Jetzt läuft es ich versteh die Welt nicht mehr??? - Drehen wir uns noch um die Sonne?MfG
Scarabol
-
Im Moment funktioniert es, daher mal ne kleine Zwischenfrage:
Ich habe eine Funktion connect aus der WinSock.h und eine Klasse network die selber eine Funktion connect hat aber gleichzeitig die Funktion connect der Winsock.h benutzt:
bool connect() { connect(...); // hier soll der die connect aus der Winsock nehmen }Wie kann ich entscheiden welche Funktion der Compiler benutzt?
Muss ich einen Namespace benutzen? Geht es auch ohne?MfG
Scarabol
-
Scarabol schrieb:
Im Moment funktioniert es, daher mal ne kleine Zwischenfrage:
Ich habe eine Funktion connect aus der WinSock.h und eine Klasse network die selber eine Funktion connect hat aber gleichzeitig die Funktion connect der Winsock.h benutzt:
bool connect() { connect(...); // hier soll der die connect aus der Winsock nehmen }Wie kann ich entscheiden welche Funktion der Compiler benutzt?
Muss ich einen Namespace benutzen? Geht es auch ohne?MfG
ScarabolIch denke, mit ::connect() müsstest du die Funktion aus dem globalen Namespace, also in dem Fall aus winsock.h nutzen können.
-
Danke, funktioniert.
MfG
Scarabol
-
Falscher Alarm funktioniert leider doch nicht er bentutz trotzdem die Funktion der Klasse nur das jetzt keine Fehlermeldung mehr kommt...
MfG
Scarabol
-
char buffer[1024]; sizeof(buffer); // liefert das gewünschte Ergebnis 1024 funktion(char *buffer) { sizeof(buffer); // liefert das "richtige" Ergebnis von 4 sizeof(*buffer); // liefert 1 - Woher??? // Wie kann ich jetzt hier in der Funktion das gewünschte Ergebnis von oben erzielen, also 1024? }MfG
Scarabol
-
Scarabol schrieb:
char buffer[1024]; sizeof(buffer); // liefert das gewünschte Ergebnis 1024 funktion(char *buffer) { sizeof(buffer); // liefert das "richtige" Ergebnis von 4 sizeof(*buffer); // liefert 1 - Woher??? // Wie kann ich jetzt hier in der Funktion das gewünschte Ergebnis von oben erzielen, also 1024? }MfG
ScarabolDie Größe kannst du so gar nicht herausfinden, da die Funktion ja lediglich einen Zeiger auf ein Array bekommt, kein Array. Du musst die Größe als weiteren Parameter der Funktion mitgeben. Das ist auch der übliche Weg.
-
ok, danke.
MfG
Scarabol
-
Hallo,
ich hab nochmal ne Frage zu Headern (.h) und deren Code anhängseln (.cpp)
Also ich hab einen Header math.h und eine Datei math.cpp beide sind mit dem Projekt verknüpft. math.h als Headerdatei und math.cpp als Quelldatei.
1. Wozu bzw. wann muss ich die Dateien im Projektmappen Explorer verknüpfen? Ich füge die Header ja z.B. mit #include math.h bereits in den Quellcode ein???Das führt mich zu Frage 2:
Wenn ich in math.cpp die Klasse aus sin.h benötige muss ich dann:
math.h#include sin.h bla blaa)
math.cpp#include math.h #include sin.h bla blaoder b)
math.cpp#include sin.h #include math.h bla blaoder c)
#include math.h // weil #include sin.h steht ja schon in math.hIn der sin.h steht
#ifndef inc_sin_h #define inc_sin_h bla bla #endifDas verhindert ja das die Klasse oder Function ect. in sin.h mehrmals definiert wird, aber muss man das grundsätzlich machen? Kann das zu Problemen führen?
Währe toll wenn mir da einer weiterhelfen könnte, danke.
MfG
Scarabol
-
Um zu verhindern, dass du Header mehrmals inkludierst, kannst du folgende Präprozessorstruktur verwenden:
// math.h #ifndef MATH_H #define MATH_H // Klassendefinition, etc. hier #endifDas wird quasi in jeder Headerdatei gemacht und ist sicher.
EDIT: Hätte den Post wohl bis zu Ende lesen sollen.

Mach das was du schon in sin.h gemacht hast einfach für jede Headerdatei.MfG,
ScRaT
-
Scarabol schrieb:
ich hab nochmal ne Frage zu Headern (.h) und deren Code anhängseln (.cpp)
Da hättest du ruhig einen neuen Thread aufmachen können, aber na ja...
Scarabol schrieb:
1. Wozu bzw. wann muss ich die Dateien im Projektmappen Explorer verknüpfen? Ich füge die Header ja z.B. mit #include math.h bereits in den Quellcode ein???
Stimmt, entscheidend ist das include-Statement. Header-Dateien werden nicht kompiliert, sondern Übersetzungseinheiten (.c, .cpp). Per include sorgst du dann dafür, dass der Inhalt eines Headers im Code eingefügt wird (es wird ganz einfach der ganze Text der Datei vor dem Übersetzen dorthin kopiert). Ein Eintrag im Projektmappenexplorer ist eigentlich unnötig, ist aber natürlich eine komfortable Möglichkeit, zum Projekt zugehörige Header-Dateien im Überblick zu behalten und sie schnell öffnen zu können (und daher sehr empfehlenswert).
Scarabol schrieb:
Das führt mich zu Frage 2:
Wenn ich in math.cpp die Klasse aus sin.h benötige muss ich dann...Jede Variante wird wohl funktionieren, solange die Header mit include-guards abgesichert sind. Ich würde sogar Variante a oder b bevorzugen.
Scarabol schrieb:
Das verhindert ja das die Klasse oder Function ect. in sin.h mehrmals definiert wird, aber muss man das grundsätzlich machen? Kann das zu Problemen führen?
Ganz im Gegenteil: wenn du die guards weglässt, kann das schnell zu Problemen führen.
Btw, ist dir klar, dass es schon eine Datei math.h gibt? Einen eigenen Header des gleichen Namens zu erzeugen, ist gar keine gute Idee. Den solltest du umbenennen (myMath.h oder sowas).
-
Morgen,
Btw, ist dir klar, dass es schon eine Datei math.h gibt? Einen eigenen Header des gleichen Namens zu erzeugen, ist gar keine gute Idee. Den solltest du umbenennen (myMath.h oder sowas).
Vielen dank für den Hinweis ich muss euch leider sagen das meine Headerdateien nicht sin.h und math.h heißen aber sonst ist das so schwer zu erklären und keiner kann sich was vorstellen, also sorry

MfG
Scarabol
-
Scarabol schrieb:
Vielen dank für den Hinweis ich muss euch leider sagen das meine Headerdateien nicht sin.h und math.h heißen aber sonst ist das so schwer zu erklären und keiner kann sich was vorstellen, also sorry

Du unterschätzt die Inelligenz und Vorstellugnskraft der Leute hier im Forum
Poste Code und Namen so wie sie bei dir stehen, am Besten per Copy&Paste, dann wirst du nur auf die wirklichen Tippfehler und Namensfehler hingewiesen, nicht auf die Fehler, die du beim Umbenennen gemacht hast. Das spart Zeit für alle.