ich vermute mal äußerst simple Frage, aber warum ergibt folgender Code

string hallo = "ichbineinstring";
printf("%s",hallo);
printf("\n");
cout << hallo << endl;

bei Nutzung von printf (null)?

(null)
ichbineinstring

?

Es empfiehlt sich hier die C++ Funktionen für Ein- und Ausgabe zu verwenden:

std::string hallo = "ichbineinstring";
std::cout << hallo << std::endl;

Grüssli

printf() kommt aus C und kommt nur mit skalaren Typen zurecht. Ausserdem ist es durch die fehlende Typsicherheit recht fehleranfällig, wenn man nicht genau weiss, was man macht.

string hallo = "ichbineinstring";
char str[20] = "ichbinaucheinstring";
printf("%s",str);
printf("\n");
cout << hallo << endl;
getchar();

So ist besser

Ah, danke!

string hallo = "ichbineinstring";
char str[20] = "ichbinaucheinstring";
printf("%s",str);
printf("\n");
cout << hallo << endl;
getchar();

So ist besser

nicht wirklich...

using namespace std;

const char str[] = ".....";
cout << str << endl;

bb

ich behalts im Hinterkopf

aber behalts mit const char* und nicht char* im hinterkopf ^^
braucht man aber eigtl nur für C-APIs

bb

braucht man aber eigtl nur für C-APIs

Nö. Wie konstruierst du z.B. ein std::fstream-Objekt?
(In der Praxis benutzt man std::fstream natürlich nach Möglichkeit ohnehin nicht.)

...

hab ja extra "eigentlich" geschrieben - ist ja nicht so, dass ich nicht daran gedacht hätte danke ^^

bb

Nö. Wie konstruierst du z.B. ein std::fstream-Objekt?

Das sollte doch im kommenden Standard angepasst werden.

audacia schrieb:

(In der Praxis benutzt man std::fstream natürlich nach Möglichkeit ohnehin nicht.)

Wie?

audacia schrieb:

(In der Praxis benutzt man std::fstream natürlich nach Möglichkeit ohnehin nicht.)

Wie?

Na du solltest natürlich fprintf/fscanf benutzen! Wusstest du das etwa nicht?

audacia schrieb:

(In der Praxis benutzt man std::fstream natürlich nach Möglichkeit ohnehin nicht.)

Wie?

Nun, die Streams sind in allen mir bekannten Implementationen langsamer als C-Streams (teilweise um Größenordnungen), und außerdem sind sie nicht moduslos, was Fehler in der Anwendung begünstigt und den korrekten Umgang massiv erschwert. Gewöhnlich ist man mit einem kleinen RAII-Wrapper um die C-Funktionen viel besser dran.

Naja, ich hatte bisher eigentlich nicht viele Probleme mit std::fstream , für meine Anwendungen reicht es. Ich finde zum Beispiel auch die Operatoren >> und << sehr komfortabel und habe momentan nicht wirklich Lust, alle Überladungen nachzuprogrammieren.

Okay, das kann gut sein, ich kenne die C-Funktionen aber auch zu wenig, um das genau beurteilen zu können.

Man braucht die C-Funktionen nicht zu kennen, um zu sehen, daß es sich bei fstream um einen gewaltigen Designfehler handelt. Beispiele: die Existenz von fstream::good() und fstream::close().

Man braucht die C-Funktionen nicht zu kennen, um zu sehen, daß es sich bei fstream um einen gewaltigen Designfehler handelt. Beispiele: die Existenz von fstream::good() und fstream::close().

Ja, die Streams sind zum Teil etwas speziell. Allerdings habe ich die bisher nicht so kritisch betrachtet, was auch daran liegen könnte, dass ich kaum Alternativen kenne.

Aber weshalb erachtest du die beiden Methoden als Designfehler? Weil sie durch andere Memberfunktionen eigentlich bereits abgedeckt sind (z.B. Dtor bei close() )?

Nun, die Streams sind in allen mir bekannten Implementationen langsamer als C-Streams (teilweise um Größenordnungen), und außerdem sind sie nicht moduslos, was Fehler in der Anwendung begünstigt und den korrekten Umgang massiv erschwert.

1. Geschwindigkeit:
http://www.cplusplus.com/reference/iostream/streambuf/pubsetbuf/
Viele Implementationen haben standardmässig keinen Puffer gesetzt, weshalb sie als deutlich langsamer erscheinen. Der Puffer kann verdammt viel ausmachen.

2. Moduslos:
http://www.cplusplus.com/reference/iostream/ios/exceptions/
Man kann sich über Modusänderungen sehr schnell und explizit informieren lassen.

Grüssli

Aber weshalb erachtest du die beiden Methoden als Designfehler?

fstream::good(), weil es impliziert, daß ich stets manuell auf Fehler überprüfen muß. Wozu gibt es denn Exceptions?

fstream::close(), weil es das Objekt in einen Modus versetzt, in dem der Aufruf mancher Methoden nicht mehr gültig ist. Zudem steckt fstream noch in einer Vererbungshierarchie, in der es auf diese Weise das LSP verletzt.

Dravere schrieb:

2. Moduslos:
http://www.cplusplus.com/reference/iostream/ios/exceptions/
Man kann sich über Modusänderungen sehr schnell und explizit informieren lassen.

Das ist nicht, was ich mit "moduslos" meine; siehe meine Ausführungen zu fstream::close().

Und daß man das Verhalten im Fehlerfalle umstellen kann, macht die Sache IMHO nur noch schlimmer, weil man dadurch ein fstream-Objekt mit noch einem Zustand behaftet, der ihn eigentlich nichts angeht. Beispiel:

void tryRead (istream& stream, ...)
{
    stream.read (...);
    if (!stream.good ())
        ...; // set default value
}
void foo (void)
{
    std::fstream theFile ("someFile", ...);
    theFile.exceptions (>alles<);
    ...
    tryRead (stream, ...); // <--
}

Hier verursacht der Aufruf von tryRead() unerwartetes Verhalten, da tryRead() sich auf das Standardverhalten des Streams verläßt. Korrekt müßte man tryRead() also so implementieren:

class StreamExceptionStatePreserver
{
private:
    ios_base::iostate prevState;
public:
    StreamExceptionStatePreserver (ios& theStream, ios_base::iostate newState)
     : prevState (theStream.exceptions ())
    { theStream.exceptions (newState); }
    ~StreamExceptionStatePreserver (void)
    { theStream.exceptions (prevState); }
};    

void tryRead (istream& stream, ...)
{
    StreamExceptionStatePreserver esp (stream, >garnix<);
    stream.read (...);
    if (!stream.good ())
        ...; // set default value
}

Ich weiß nicht, wie es dir geht, aber spätestens da schreit sämtliche mir verbliebene Intuition laut "Designfehler".

Eine Klasse, die derartige Workarounds erfordert, wird von mir i.d.R. ohnehin erst von einem adäquaten Wrapper umgeben, der die Komplexität in der Anwendung reduziert. Und wenn wir ohnehin beim Wrappen sind, können wir auch gleich die C-Funktionen wrappen, weil sie viel weniger Ballast haben und in der Praxis schlicht schneller sind, Puffer hin oder her.

5. Gibt es eigentlich Vorschläge für Verbesserung der Streams? Bzw. gibt es einfachere/bessere Streambibliotheken? Wäre mal interessant sich mit dem Zeug auseinander zu setzen.

Grüssli

1. Wieso verletzt fstream das Liskovsches Substitutionsprinzip? Leuchtet mir gerade nicht ein.

Nun, std::fstream definiert einen Zustand, in dem der korrespondierende Stream überhaupt nicht existiert und deshalb der Aufruf aller auf dem Stream operierender Methoden fehlschlägt. Die Basisklasse std::iostream tut das nicht - für sie gibt es nur Streams in intaktem und nicht intaktem Zustand.

Dravere schrieb:

2. Bei den Exceptions setze ich immer den richtigen Status für das Programm oder Bibliothek gleich beim Anfang der Arbeit. Also wenn ein Stream übergeben wird, dann hole ich mir das streambuf Objekt raus und übergebe es einem eigenen Streamobjekt.

Es ist schön, daß du im eigenen Code vorsorgst, aber das hat nun aber doch nichts damit zu tun, daß das Design der Streams in diesem Punkt fragwürdig ist, zu tun, oder?

Dravere schrieb:

4. Wenn man wirklich etwas an den Streams ankreiden möchte, dann sollte man dies beim ganzen Locale und Facet Zeug machen. Dort ist meiner Meinung nach wirklich ein Designfehler passiert. Das Zeug ist viel zu komplex, es verstösst gegen Speicherzugehörigkeit (wer Speicher holt, gibt ihn frei), ist unübersichtlich und unverständlich, viel zu umfangreich für kleine Dinge, usw. usf.

Ja, da stimme ich uneingeschränkt zu. Aber falls du damit sagen willst, daß das Design der Streamklassen ansonsten in Ordnung ist, dann wäre es an der Zeit, daß du dich mal zu meinen Argumenten äußerst.

Nun, std::fstream definiert einen Zustand, in dem der korrespondierende Stream überhaupt nicht existiert und deshalb der Aufruf aller auf dem Stream operierender Methoden fehlschlägt. Die Basisklasse std::iostream tut das nicht - für sie gibt es nur Streams in intaktem und nicht intaktem Zustand.

Das ist aber kein Verstoss gegen das Liskovsche Substitutionsprinzip. LSP geht genau in die andere Richtung. Es müssen alle beweisbaren Eigenschaft der Basisklasse auch für die abgeleitete Klasse gelten. Das ist auch der Fall.

std::fstream erweitert nur die Eigenschaften und das ist auch der Sinn von Vererbung!

audacia schrieb:

Es ist schön, daß du im eigenen Code vorsorgst, aber das hat nun aber doch nichts damit zu tun, daß das Design der Streams in diesem Punkt fragwürdig ist, zu tun, oder?

Fragwürdig ist aber nicht gleich ein Designfehler. Ich finde es gar nicht so fragwürdig, für mich ergibt das zum Teil durchaus einen Sinn. Man hat verschiedene Möglichkeiten. Und die exceptionfreie Möglichkeit hat durchaus seine Vorteile. Ich verwende oft beide Möglichkeiten.

Man könnte vielleicht die Frage in den Raum stellen, wieso man nicht zwei Klassen gemacht hat. Eine mit Exception und eine ohne Exception. Das hätte vielleicht eine bessere Abgrenzung zwischen beiden Versionen geschaffen. Es hätte aber womöglich auch eine Menge an Codeduplizierung geschaffen.

Ich habe nichts dagegen, wenn man die Sache überdenkt. Allerdings sollte man zwei Dinge im Hinterkopf behalten:
1. Es können immer Fehler beim Design passieren. Das heisst aber nicht, dass die Klassen dann gleich nutzlos sind.
2. Nachher ist man immer klüger

Dravere schrieb:

Aber falls du damit sagen willst, daß das Design der Streamklassen ansonsten in Ordnung ist, dann wäre es an der Zeit, daß du dich mal zu meinen Argumenten äußerst.

Nein, ich halte die Streamklassen ansonsten nicht einfach für in Ordnung. Aber ich halte sie auch nicht für einen völligen Designfehler und finde auch nicht, dass man sie gleich wegwerfen soll. Alles ist immer verbesserungswürdig. Ich finde die Ideen der Streamklassen gar nicht so schlecht, die Umsetzung lässt höchstens zum Teil zu wünschen übrig. Aber es ist definitiv nicht so, dass man sie nicht verwenden könnte.

Ich persönlich habe ein wenig das Gefühl, dass du aus einer Mücke einen Elefanten machst und dich dann darüber beschwerst, dass du den Elefanten nicht hochheben kannst

Grüssli