Etwas verwirrt mit Headerdateien und weiterreichen von Variablen/Strings
-
Noch eine Frage: Warum cmath statt math.h?
-
Edith: ich hatte eh cmath - oder meintest du es andersrum? Lieber math.h?
-
conqueror24 schrieb:
Edith: ich hatte eh cmath - oder meintest du es andersrum? Lieber math.h?
Lieber cmath weil Standard.
-
Kann ich das getrost vergessen (Kein Fehler, ein Warning)?
Warnung 1 warning C4101: 'ex': Unreferenzierte lokale Variable c:\users\ra\desktop\vigenere\vigenere\v3\Form1.h 185
Das kommt von der Zeile:
catch(Exception^ ex) {MessageBox::Show("Datei unlesbar"); }
Oder gibt es einen guten Grund, warum ich die Warnung nicht einfach übergehen sollte
-
Noch eine Frage zu dem Punkt von vorher:
calc.h
namespace ns1 { std::string irgendeinstring2(const std::string& irgendeinstring1); }
calc.cpp:
namespace ns1 { irgendeinevariable = 0; std::string funktionsname(const std::string& Inhalt_rTB1) { ns1::irgendeinevariable1 = ... return irgendeinevariable1}; }
und alternativ:
calc.cpp:
namespace ns1 { irgendeinevariable = 0; }; std::string funktionsname(const std::string& Inhalt_rTB1) { using namespace ns1; irgendeinevariable1 = 5; return irgendeinevariable1};
Ich finde es irgendwie komisch immer in einem Namespace zu arbeiten? Oder soll das so sein und mein Gefühl betrügt mich? Warum muss ich, obwohl ich innerhalb der {} des Namespaces bin ihn dann noch immer mit namespacenamen:: vor die Variablen setzen?
-
conqueror24 schrieb:
Kann ich das getrost vergessen (Kein Fehler, ein Warning)?
Warnung 1 warning C4101: 'ex': Unreferenzierte lokale Variable c:\users\ra\desktop\vigenere\vigenere\v3\Form1.h 185
Das kommt von der Zeile:
catch(Exception^ ex) {MessageBox::Show("Datei unlesbar"); }
Ja, kannst Du. Oder noch besser Du behebst sie, z.B. so:
catch(Exception^) {MessageBox::Show("Datei unlesbar"); }
Irgendwie scheint mir in deinem Bsp. der Funktionsname irgendeinstring2 schlecht gewählt. Hältst Du irgendeinstring2 für eine Variable? Das ist es nicht, es ist eine Funktion!
Ich finde es irgendwie komisch immer in einem Namespace zu arbeiten
Dann lass es. Namespaces sind wie gesagt ein Mechanismus um zu strukturieren und um Nameskonflikte zu vermeiden. In kleinen Programmen spielt das nicht so eine Rolle.
Warum muss ich, obwohl ich innerhalb der {} des Namespaces bin ihn dann noch immer mit namespacenamen:: vor die Variablen setzen?
Das musst Du nicht. Wenn doch, machst Du was falsch.
Lass endlich die globalen Variablen weg - Du brauchst sie nicht! Übergib alles nötige als Parameter und gib falls nötig einen Wert zurück. Die Funktionen sollen möglichst keine Seiteneffekte haben (wie z.B. eine globale Variable ändern).
-
Ja du hast (natürlich) recht, da habe ich mich ein wenig verlesen (oder so halb, weil ich noch einen zweiten Namespace verwendet hatte im ersten). Und ja, das war ein dumm getaufter Funktionsname.
Du meinst also (dein Beispiel hier nochmal, weil ich es so verwendet habe)
private: System::Void mach_was_Click(System::Object^ sender, System::EventArgs^ e) { std::string Inhalt_richTextBox1 = marshal_as<std::string>(richTextBox1->Text); std::string resultat = namespacename::Funktionsname(Inhalt_richTextBox1); richTextBox1->Text = gcnew String(resultat.c_str()); }
Wenn ich nun aber nicht
namespacename::Funktionsname(Inhalt_richTextBox1)
mache, wie bekomme ich dann den Inhalt von meiner TextBox dahin, wo ich damit herumrechnen/arbeiten kann? Also sprich in die calc.cpp Datei?
-
conqueror24 schrieb:
Wenn ich nun aber nicht
namespacename::Funktionsname(Inhalt_richTextBox1)
mache, wie bekomme ich dann den Inhalt von meiner TextBox dahin, wo ich damit herumrechnen/arbeiten kann? Also sprich in die calc.cpp Datei?
Auch als Argumente von Funktionen - die argumente können auch weitergereicht werden.
-
Darf ich das dann so machen?
form1.h
std::string Inhalt_rTB1 = marshal_as<std::string>(richTextBox1->Text); richTextBox2->Text = gcnew String(funktionsname(Inhalt_rTB1).c_str());
-
conqueror24 schrieb:
Darf ich das dann so machen?
form1.h
std::string Inhalt_rTB1 = marshal_as<std::string>(richTextBox1->Text); richTextBox2->Text = gcnew String(funktionsname(Inhalt_rTB1).c_str());
Ja.