3. Multiple definition of

Multiple definition of

  • L

    vielen dank.. ich lerne CPP gerade aus einem Buch, und da ist das ganze so beschrieben..

    ich bin mit der Klasse String in C++ nicht vertraut, weil ich bisher immer char strings verwendet hatte.. aber warum übergibst du die strings dann als Referenz?

    lg

    0
  • U

    aber warum übergibst du die strings dann als Referenz

    Weil sie so nicht kopiert werden müssen - und er übergibt sie als const Referenz, da sie auch nicht verändert werden... So wird (intern) nur ein Pointer übergeben und man spart sich das kopieren halt - als Faustregel gilt eigtl, dass man (auf 32bit Systemen) ab 4Byte großen Typen eine by-Referenz einer by-Value -Übergabe vorzieht...

    btw:
    #ifndef _MENSCH_H_ ich würde niemals meine eigenen Makros mit einem Understrich anfangen lassen, da solche Namen eigtl _IMMER_ für den Compiler reserviert sind... Klar ist das bei den meisten Namen ca. 100%ig, dass der Compiler sie nicht nimmt, aber wenn doch, ist der Fehler denke ich relativ schwer zu finden ^^ Daher gewöhn dich dran, den Unterstrich da wegzulassen...

    bb

    0
  • A

    lif schrieb:

    vielen dank.. ich lerne CPP gerade aus einem Buch, und da ist das ganze so beschrieben..

    Dann einen ganz großen Tip: Such die nächstbeste runde Papierablage (Auch Abfalleimer genannt), und tue dem Buch einen Gefallen => hinein damit.

    Jedes C++ Buch das mit char*/char-Arrays anfängt hat die Sprache C++ nicht verdient.

    0
  • L

    ist glaube ich keine gute Idee.. das buch hat 40€ gekostet.. Ausserdem sind andere Themen sehr gut beschrieben (Client-Server, GUI,...) ich glaube, dass auf std::string später noch eingegangen wird, aber es hätte ja keinen Sinn, die Klasse zu verwenden, wenn noch nicht darauf eingegangen wurde

    ich kenne zwar die Vor-/Nachteile von std::string nicht, aber ich versteh nicht ganz, was dich bei chars so stört.. natürlich ist es umständlich, aber soo schlimm find ichs auch wieder nicht..

    lg lif

    0
  • A

    lif schrieb:

    ist glaube ich keine gute Idee.. das buch hat 40€ gekostet...

    Was dennoch nichts über die Qualität aussagt...

    lif schrieb:

    Ausserdem sind andere Themen sehr gut beschrieben (Client-Server, GUI,...)...

    Dürfte ich mal fragen mit welchen Vorkenntnissen der Programmierung du hantierst (Cient-Server/GUI haben in einen Buch das erstmal die Sprache C++ vermittelt nämlich ebenso nichts zu tun. Als zweites Buch okay, nicht aber als erstes).

    lif schrieb:

    ich glaube, dass auf std::string später noch eingegangen wird, aber es hätte ja keinen Sinn, die Klasse zu verwenden, wenn noch nicht darauf eingegangen wurde

    Wenn man sich wirklich und ernsthaft mit C++ auseinander setzen will, sollte gerade sowas wie std::string bereits relativ am Anfang stehen. Ebenso wie z.B. std::vector statt den Arrays...

    lif schrieb:

    ich kenne zwar die Vor-/Nachteile von std::string nicht, aber ich versteh nicht ganz, was dich bei chars so stört.. natürlich ist es umständlich, aber soo schlimm find ichs auch wieder nicht..

    1. Relikt aus C (ebenso wie die Arrays)
    2. Fehleranfällig und Anfängerfeindlich (Alleine schon die Thematik mit dem Kopieren)
    3. Die C-String Methoden sind nicht typsicher
    4. Warum etwas erwähnen das man später in der Regel nicht mehr verwendet?

    cu André

    0
  • N

    lif schrieb:

    aber ich versteh nicht ganz, was dich bei chars so stört.. natürlich ist es umständlich, aber soo schlimm find ichs auch wieder nicht..

    Du hast auch noch nicht genug intensiv damit gearbeitet, um all die Nachteile erkennen zu können. Um einige zu nennen:

    • Eine einfache Zuweisung mit = funktioniert nicht. Du musst immer zuerst Speicher reservieren und dann strcpy() oder strncpy() benutzen.
    • Gleiches gilt für andere komfortable Operationen wie Aneinanderreihung mit +, alphabetischer Vergleich z.B. mit <, Überprüfung auf Gleichheit mit ==, etc.
    • Wenn ein char* als Rückgabewert einer Funktion benötigt wird, muss der Aufrufer immer dran denken, den Speicher wieder freizugeben.
    • Um bei Laufzeit den Speicher zu vergrössern (wenn man Zeichen anhängt), muss man jedes Mal entweder realloc() (unter C) oder delete[] und new[] (C++) einsetzen.
    • In Klassen müssen jeweils Destruktor, Zuweisung und Kopierkonstruktor speziell implementiert werden, um das gezielte Resultat zu erwünschen (alternative Smartpointer).
    • und so weiter...

    Übrigens: alle diese Probleme hat man mit std::string nicht.

    0
  • L

    ich will hier nicht als der retter von char auftreten, aber die Zuweisung mit = funktioniert serwohl

    //Deklaration mit Initiallisierung
char foo[] = { "Hallo" };

    mit dem rest hast du recht 😉

    0
  • N

    lif schrieb:

    ich will hier nicht als der retter von char auftreten, aber die Zuweisung mit = funktioniert serwohl

    //Deklaration mit Initiallisierung
char foo[] = { "Hallo" };

    Erstens mal ist das, wie du selber geschrieben hast, eine Initialisierung und keine Zuweisung (lassen wir mal die geschweiften Klammern...).

    Unter Zuweisung versteht man Folgendes:

    char Str1[] = "Hallo";
char* Str2;
Str2 = Str1;   // jetzt zeigt Str2 auf den gleichen Speicherbereich wie Str1, es wird also keine Kopie angelegt.
char Str3[10];
Str3 = Str1;  // geht sowieso nicht, da Arrays nicht zugewiesen werden können.

    Bei std::string hingegen:

    std::string Str1 = "Hallo";
std::string Str2;
Str2 = Str1;  // Geht: Str2 hat jetzt den gleichen Wert wie Str1, ist aber ein eigenes Objekt.

    Und eben, das ist nur einer von vielen Punkten...

    0
  • L

    ja, da hast du recht.. allerdings habe ich vorher schon C gelernt, und für mich ist es deutlich einfacher (zumindest momentan) eine Art (eben char) zu verwenden, die mir bekannt ist zu verwenden, als eine neue (std::string) zu verwenden, mit der ich nicht vertraut bin. Klar, werde ich mich mit der C++ Klasse String vertraut machen, aber alles zu seiner Zeit. Ich bin momentan bei C++ bei den Klassen, und ich glaube das ist deutlich wichtiger, als die Frage, ob nun char oder std::string..

    meine Meinung, hat ja schliesslich jeder seine 😉

    0
  • Administrator

    lif schrieb:

    meine Meinung, hat ja schliesslich jeder seine 😉

    Wenn ich auch noch eine Meinung hinzufügen darf:
    Erst recht wenn man von C kommt, sollte man früh lernen in C++ von C wegzukommen. Desto früher, desto besser. C und C++ haben andere Ideen und Konzepte, man sollte die Programmiersprachen nicht mischen. Wenn du nicht von Anfang an gut trennst, läufst du die Gefahr, dass du es am Ende nie richtig tun wirst und dann läufst du Gefahr, dass du C-Code in C++ schreiben willst.

    Grüssli

    0
  • P

    lif schrieb:

    ich lerne CPP gerade aus einem Buch, und da ist das ganze so beschrieben..

    Wenn das Buch mal abgesehen von den C-Strings solche Dinge wie person.erzeuge() an Stelle von ordentlichen Konstruktoren propagiert solltest du es wirklich in den Rundordner verfrachten. Auch wenns 40€ gekostet hat. (Eine Alternative wäre, es bei Amazon zu verkaufen um etwas von dem Geld wieder zu bekommen, aber das wäre verantwortungslos, dann sitzt nämlich bald der Nächste mit dem Mist da.) Das Buch scheint eins der leider sehr häufig auftauchenden Bücher nach dem Motto "von C nach C++" zu sein. Leider verführen diese Bücher viele (und vor allem Umsteiger mit C-Kenntnissen) dazu, Stückchen für Stückchen umzusteigen und auf halbem Weg halt zu machen, nachdem die nötigsten C++-Elemente gelernt wurden. Das Resultat ist eine Hybridsprache, eine Art C mit Klassen, die viele Stärken von C++ (wie z.B. string und vector) ignoriert und mit den schwächen Elementen von C (Arrays und Funktionen ohne Längenchecks auf diesen Arrays) weiterarbeitet.
    Leute die mit solchen Büchern lernen und auf diese Art "C/C++" programmieren tauchen ständig hier im Forum auf und haben immer die selben Probleme wie überlaufende Arrays, missverstandene char-pointer Kopien und diverse andere Dinge, die mit einem ordentlichen Einstieg in die Programmiersprache C++ nicht passiert wären. Deshalb: mach keinen Umstieg sondern einen Neuanfang, du ersparst dir viele Probleme. Wenn du ein Programm schreibst, entscheide dich zwischen C und C++ und gehe keine Kompromisse ein. Ein "C/C++" Programmierstil geht garnicht, vor allem wenn andere deinen Code warten oder erweitern sollen: C'ler verstehen die C++-Elemente nicht, und C++'ler kriegen das kalte Grausen wenn sie mit char-Arrays, "sprintf" & Co. konfrontiert werden.
    Ich selbst hab vor kurzem in einer "C++"-Sourcedatei nach einem Fehler gesucht - er lag in einer Funktion bestehend aus 3000 Zeilen C-Code, vielen sprintf's und einer davon hat die Rücksprungadresse überschrieben - allerdings nur wenn man nicht im Debug-Modus kompiliert hatte. Viel Spaß beim Suchen (2 Tage...)
    Also entscheid dich, bau keine Flügel an dein Auto und glaub dann du könntest damit fliegen 😉

    0
  • L

    du hast recht. ich bin auch kein fan von C/C++ - Hybrid..
    -> person.erzeuge(). Diese Funktion wurde im buch erklärt - !!bevor!! Konstruktoren behandelt wurden. Natürlich könnte man das ganze auch so schreiben:

    Mensch person1("Fritz", 20, Mensch::MANN);

    ->die Funktion kann getrost entfernt werden, da ja Konstruktoren ser wohl verfügbar sind.
    auch ich bin der Meinung, dass Bücher, die C mit Klassen ( 😋 ) lernen einfach nur mist sind. ich glaube aber, dass du mich missverstanden hast. Dieses Buch ist nicht so eines.. Aber da es ein Buch ist, das man von vorne nach hinten liest beginnt es natürlich nicht mit den fortgeschrittensten Themen.
    -> als erstes werden Klassen - / Methoden erklärt, und dann erst Konstruktoren und Destruktoren.
    dank der Methode Mensch::erzeuge() können auch leute, die gerne mit dem vorhandenen Wissen ein Programm schreiben, welche noch nicht das Kapitel ganz gelesen haben, ihr wissen in die Praxis umsetzen.
    Natürlich könnte man jetzt wieder sagen, das man mit halbvorhandenem Wissen nichts programmieren sollte, aber ich finde, das ein bisschen Praxis nicht schaden kann 😉

    0
  • P

    deswegen fangen gute Bücher mit trivialen Klassen an, die keine Initialisierung benötigen. Sofern die Klassen dann komplexer werden, werden Konstruktoren eingeführt. Solche Krücken wie diese Pseudo-Konstruktoren einzuführen ist ziemlicher Mist, was bringt das?

    1. Lernt der Leser etwas, was schlechter Stil ist.
    2. Wirds schon wenige Kapitel später nicht mehr gebraucht, ist also verschwendete Energie.
    3. Bleiben erfahrungsgemäß gerade solche provisorisch eingeführten Konstrukte gerne in den Köpfen der Leute hängen, und sie benutzen sie dann statt es richtig zu machen. Sieht man ja an deinem Beispiel, du benutzt einen sinnfreien Standard-Ctor und danach den pseudo-Konstruktor statt es gleich richtig zu machen, obwohl du weißt wie man einen ordentlichen Konstruktor schreibt...
    0
  • A

    lif schrieb:

    Diese Funktion wurde im buch erklärt - !!bevor!! Konstruktoren behandelt wurden.

    Andere (bessere) Bücher verwenden bereits im Vorfeld Klassen und Konstruktoren, ohne das sie gezwungen sind alles bis ins letzte zu erklären. Man kann std::string auch für die einfachen Verwendungen ohne große Erklärung verwenden (sogar deutlich besser als char*), und auch Klassen können - sofern man auf Details verzichtet - bereits am Anfang verwendet werden.

    Ich bezweifel das es irgendein Buch gibt das cin/cout im Detail durchkaut bevor es angewendet wird. Anfangs reicht es wenn man sagt wie man etwas ausgibt oder einliest, Details können immer noch später beschrieben werden.

    lif schrieb:

    auch ich bin der Meinung, dass Bücher, die C mit Klassen ( 😋 ) lernen einfach nur mist sind. ich glaube aber, dass du mich missverstanden hast. Dieses Buch ist nicht so eines.. Aber da es ein Buch ist, das man von vorne nach hinten liest beginnt es natürlich nicht mit den fortgeschrittensten Themen.

    Nein, es verwendet Themen die garkeine Relevanz in 99% der Fälle hat (Die wenigen Fälle die übrig bleiben sind Optimierungen, und auch die sollte man wenn überhaupt nach dem Hinzuziehen eines Profilers anpassen).

    lif schrieb:

    -> als erstes werden Klassen - / Methoden erklärt, und dann erst Konstruktoren und Destruktoren.

    Selbst dann ist eine Funktion "erzeuge" einfach nur Mist. Die hat wenn erst in Bereichen von Fabrikmethoden zu suchen (Thema: Entwurfsmuster), und wird dann garantiert eine andere Schnittstelle haben (static/virtual). Dann lieber Klassen ohne Zeiger verwenden, dann kann man anfangs Konstruktoren/Destruktor gänzlich außen vor lassen.

    lif schrieb:

    Natürlich könnte man jetzt wieder sagen, das man mit halbvorhandenem Wissen nichts programmieren sollte, aber ich finde, das ein bisschen Praxis nicht schaden kann 😉

    Falsche Praxis kann sehr wohl schaden.

    cu André

    0
Anmelden zum Antworten