Operator << überladen

[Knuddlbaer]

Hi!

Entweder die Funtkion in eine cpp auslagern oder ein inline davor schreiben.

[Online]

Knuddlbaer schrieb:

Hi!

Entweder die Funtkion in eine cpp auslagern oder ein inline davor schreiben.

ja, hab ich jetzt auch gemerkt das das in der cpp funktioniert, aber warum nicht im Header?

Cocaine schrieb:

Warum friend und nicht als Member?

wie meinst du das?

[HumeSikkins]

Cocaine schrieb:

Warum friend und nicht als Member?

Weil
str << cout so dämlich aussieht.

Das erklärt natürlich nur den "warum nicht als Member"-Teil. friend wahrscheinlich, da viele Anfängerbücher immer so tun, als *müsse* der op<< als friend implementiert werden. Das ist natürlich käse.

@online
Was du da machst ist nicht fein.
1. Niemals sollte man einen Namespace in einem Header öffnen.
2. Das Inkludieren von <iostream> ist überflüssig, wenn du den op<< nicht inline machst.
3. Namen wie _STRING_H sind nichts für dich und mich.

#ifndef STRING_H 
#define STRING_H 
#include <iosfwd> 

class String     
{ 
... 
public: 
}; 
std::ostream& operator<<(std::ostream &os, const String &s);

// String.cpp
#include <iostream>
using namespace std; // kein Problem hier
ostream& operator<<(ostream &os, const String &s)
{
    os << s.str();
    return os;
}

[HumeSikkins]

ja, hab ich jetzt auch gemerkt das das in der cpp funktioniert, aber warum nicht im Header?

Jede nicht inline-Funktion muss *genau eine* Definition besitzen.

Packst du eine solche nun aber in einen Header, hast du ganz schnell mehrere:

// String.h
class String {...};
ostream &operator<<(ostream &ostr, const String &s) 
{ 
    if(s.len)  
        ostr << s.string; 
    return(ostr); 
}

// String.cpp
#include "String.h" // -> String.cpp enthält Definition von op<<
String::String() {...}

// main.cpp
#include "String.h" // -> main.cpp enthält Definition von op<<
int main()
{
String s;
...
}

[Online]

HumeSikkins schrieb:

ja, hab ich jetzt auch gemerkt das das in der cpp funktioniert, aber warum nicht im Header?

Jede nicht inline-Funktion muss *genau eine* Definition besitzen.

Packst du eine solche nun aber in einen Header, hast du ganz schnell mehrere:

alles klar, das hab ich verstanden.

HumeSikkins schrieb:

Cocaine schrieb:

Warum friend und nicht als Member?

Weil
str << cout so dämlich aussieht.

Das erklärt natürlich nur den "warum nicht als Member"-Teil. friend wahrscheinlich, da viele Anfängerbücher immer so tun, als *müsse* der op<< als friend implementiert werden. Das ist natürlich käse.

@online
Was du da machst ist nicht fein.
1. Niemals sollte man einen Namespace in einem Header öffnen.
2. Das Inkludieren von <iostream> ist überflüssig, wenn du den op<< nicht inline machst.
3. Namen wie _STRING_H sind nichts für dich und mich.

ich mach das noch nicht solange, hab grade erst ein Semester hinter mir. Hab das meiste aus Büchern...
zu 3. : also den ersten Strich weglassen? hab das so aus Büchern übernommen

str << cout so dämlich aussieht.

das versteh ich net ganz. In der main schreib ich dann ganz normal cout << myStringClassUnit;

[Helium]

Jup den führenden Unterstrich weg. Führende Unterstriche sowie mehr als ein Unterstrich hintereinander innerhalb eines Bezeichners sollten nicht verwendet werden.

In der main schreib ich dann ganz normal cout << myStringClassUnit;

Nein, bestimmt nicht, weil es diesen Operator nicht gibt, wenn du als Member implementierst.

[Cocaine]

HumeSikkins schrieb:

Weil str << cout so dämlich aussieht.

Ja, vorm Schreiben Hirn einschalten, wär mal ne Idee gewesen...

[Online]

HumeSikkins schrieb:

#ifndef STRING_H 
#define STRING_H 
#include <iosfwd> 
 
class String     
{ 
... 
public: 
}; 
std::ostream& operator<<(std::ostream &os, const String &s);

// String.cpp
#include <iostream>
using namespace std; // kein Problem hier
ostream& operator<<(ostream &os, const String &s)
{
    os << s.str();
    return os;
}

wenn ich das aber so mache, wie du das hier hast dann kann ich nicht mehr auf die privaten Elemente zugreifen.

[desert pinguin]

Noch was dazu. Vielliecht offtopic aber trotzdem...
Eine gute Loesung, besonders wenn die Klasse für Vererbung entworfen ist, ist eine virtuelle Methode, zum Beispiel print(), zu entwerfen. Die Methode wird von dem Opeartor aufgerufen.

[Helium]

@Online:
Richtig.