Seltsames vorgehen bei Eingabe von String KLASSEN

Guten Morgen und frohes neues :3
Ich spiele gerade mit Klassen und Strings rum und da ist mir echt etwas negatives aufgefallen.

Wenn ich bei der ersten Eingabe bei nem String eine Leertaste eingebe z.B
"Earl Grey"

Denkt sich mein Programm das Grey wäre für die zweite Eingabe
Und handelt dementsprechend auch xD

main.cpp

#include <iostream>
#include "tee.h"
#include <string>
using namespace std;

int main()
{
    string eingabe;
    tee schwarztee;
    cout << "bitte gib die sorte ein ";
    cin >> eingabe;
    schwarztee.write_sorte(eingabe);
    cout << endl << "und jetzt gib bitte die herkunft ein";
    cin >> eingabe;
    schwarztee.write_herkunft(eingabe);
    cout << endl << "kommt aus " << schwarztee.get_herkunft() << " und die Sorte ist " << schwarztee.get_sorte();

    return 0;
}

tee.h

#ifndef TEE_H_INCLUDED
#define TEE_H_INCLUDED
#include <string>
using namespace std;
class tee{
    string sorte;
    string herkunft;
    public:
    tee();
  string  get_sorte() const {return sorte;}  ;
   string get_herkunft() const {return herkunft;}  ;
   void write_sorte(string &s);
   void write_herkunft(string &h);

};

#endif // TEE_H_INCLUDED

tee.cpp

#include <string>
#include "tee.h"
using namespace std;

tee::tee(){
    herkunft = "";
    sorte = "";
}

void tee::write_sorte(string &s){
    herkunft = s;
}

void tee::write_herkunft(string &h){
    sorte = h;
}

hustbaer

Das ist bei C++ so.
Nimm getline.

volkard

Nee, im Ernst, '\n' ist dere Zeilenumbruch, nur den willste hier ausdrücken. endl hingegen haut noch ein flush dazu, das willste hier nicht ausdrücken.

Der Operator << liest bis zum nächsten White-Space (Zeilenumbruch, Tabulator, Leerzeichen) und macht das sonst auch immer so, bei bool, int, short, float, ..., auch bei string. Alles andere wäre verwirrend. Darum nusst Du auf eine andere EInlese-Funktion zurückgreifen, wenn Du Dir mit dem Benutzer einig werden konntest, daß NUR der Zeilenumbruch (und gegebenenfalls End-Of-File) die Eingabe abschließt.

Den Standard-Konstruktor willste im Normalfall nicht haben: Es ist nicht so, daß Du neben den drei Teesorten "Earl Grey" und natürlich "JLP Spezial" und "Mütterle" und auch noch weitere sieben Sorten des Namens "" im Regal hast, sondern Du hast nur drei Sorten im Regal.

volkard schrieb:

Der Operator << liest bis zum nächsten White-Space (Zeilenumbruch, Tabulator, Leerzeichen) und macht das sonst auch immer so, bei bool, int, short, float, ..., auch bei string. Alles andere wäre verwirrend.

Warum? Bei der Ausgabe >> ist es auch nicht verwirrend, dass ein String mit Leerzeichen ausgegeben wird. Ich glaube das aktuelle verhalten von << verwirt mehr Leute.

Columbo

Ich glaube das aktuelle verhalten von << verwirt mehr Leute.

Der Punkt ist aber, dass dem Extraktions-Operator keinerlei weitere Information über die Art der Extraktion übergeben werden kann, anders als bei getline (welche noch den Delimitter nimmt). Daher muss eine "Standard-Einlese-Methode" festgelegt werden. Welche wäre wohl besser als das Lesen bis zum nächsten Whitespace?

Bei der Ausgabe gibt es auch ein definiertes Ende: Das vom String.

volkard

o90o90o90o schrieb:

volkard schrieb:

Der Operator << liest bis zum nächsten White-Space (Zeilenumbruch, Tabulator, Leerzeichen) und macht das sonst auch immer so, bei bool, int, short, float, ..., auch bei string. Alles andere wäre verwirrend.

Warum? Bei der Ausgabe >> ist es auch nicht verwirrend, dass ein String mit Leerzeichen ausgegeben wird. Ich glaube das aktuelle verhalten von << verwirt mehr Leute.

Und was, wenn der auszugebende String einen Zeilenumbruch enthält???
Klar werden dann zwei Zeilen augegeben.

Dann erwartest Du viewlleicht, daß ein einlesender String fortlaufend alle Zeilen einliest, bis ein doppelter Zeilenumbruch gelesen wurde? Geht, aber wenn Datein auch Leerzeilen haben können dürfen sollen, wirds da ganz schwierig zu durchschauen.

Man könnte es klären, wenn string allenfalls eine ganze Datei lesen würde und jedes Verhackstückeln von Tokenizern, Splittern und Parsern zu geschehen hätte. Ich fürchte, dann hätten wir deswegen mehr Anfragen in diesem Forum.

Ich glaube es gibt keinen der mit einer einfachen Console (nicht Editor) arbeitet und erwartet, dass bei einer String Eingabe nicht genau beim drücken von Enter diese fertig ist, außer, wenn er mit C++ arbeitet.

volkard

o90o90o90o schrieb:

Ich glaube es gibt keinen der mit einer einfachen Console (nicht Editor) arbeitet und erwartet, dass bei einer String Eingabe nicht genau beim drücken von Enter diese fertig ist, außer, wenn er mit C++ arbeitet.

Wenn ist Deinem Buch stand, daß ein String eine Textzeile (insbesondere Eingabezeile) ist, und Du das immer noch glaubst, wurdest Du leider gewolft. :p

In deinem Buch stand wohl, dass ein String beim Leerzeichen endet. Hast schon überzeugende Argumente.

Wie vorgeschlagen hab ich es mit getline gelößt

#include <iostream>
#include "tee.h"
#include <string>
using namespace std;

int main()
{
    string eingabe;
    tee schwarztee;
    cout << "bitte gib die sorte ein ";
    getline(cin,eingabe);
    schwarztee.write_sorte(eingabe);
    cout << endl << "und jetzt gib bitte die herkunft ein";
    getline(cin,eingabe);
    schwarztee.write_herkunft(eingabe);
    cout << endl << "kommt aus " << schwarztee.get_herkunft() << " und die Sorte ist " << schwarztee.get_sorte();

    return 0;
}

Wenn ich ehrlich bin hab ich den Grund glaube ich nicht zu 100% verstanden.
Ich versuchs mal zu erklären und ihr sagt mir dann bitte ob ich es richtig verstanden habe :p

Also bei cin >> scheinbar wegen dem '>>' wird der Text nur eingelesen bis zur nächsten Leertaste, weil Magie halt.

Plattfuss schrieb:

Also bei cin >> scheinbar wegen dem '>>' wird der Text nur eingelesen bis zur nächsten Leertaste, weil Magie halt.

operator>> ließt solange ein, bis er auf ein Whitespace (Leerzeichen, Tab, Enter, usw) stößt, weil genau das der Sinn von >> ist.

hustbaer

o90o90o90o schrieb:

volkard schrieb:

Der Operator << liest bis zum nächsten White-Space (Zeilenumbruch, Tabulator, Leerzeichen) und macht das sonst auch immer so, bei bool, int, short, float, ..., auch bei string. Alles andere wäre verwirrend.

Warum? Bei der Ausgabe >> ist es auch nicht verwirrend, dass ein String mit Leerzeichen ausgegeben wird. Ich glaube das aktuelle verhalten von << verwirt mehr Leute.

Nach der Logik müsste der extraction Operator bei Strings alles bis "EOF" lesen. Da man mit dem insertion Operator auch wunderbar Newlines mit ausgeben kann.
Das wäre aber reichlich beknackt.

hustbaer schrieb:

o90o90o90o schrieb:

volkard schrieb:

Der Operator << liest bis zum nächsten White-Space (Zeilenumbruch, Tabulator, Leerzeichen) und macht das sonst auch immer so, bei bool, int, short, float, ..., auch bei string. Alles andere wäre verwirrend.

Warum? Bei der Ausgabe >> ist es auch nicht verwirrend, dass ein String mit Leerzeichen ausgegeben wird. Ich glaube das aktuelle verhalten von << verwirt mehr Leute.

Nach der Logik müsste der extraction Operator bei Strings alles bis "EOF" lesen. Da man mit dem insertion Operator auch wunderbar Newlines mit ausgeben kann.
Das wäre aber reichlich beknackt.

o90o90o90o schrieb:

Ich glaube es gibt keinen der mit einer einfachen Console (nicht Editor) arbeitet und erwartet, dass bei einer String Eingabe nicht genau beim drücken von Enter diese fertig ist, außer, wenn er mit C++ arbeitet.

hustbaer

Ich meine nur dein Argument "<< gibt ja auch Whitespaces aus, also sollte >> sie auch mit einlesen" ist etwas komisch.
Dann dann auch "<< gibt ja auch Newlines aus, also sollte >> sie auch mit einlesen" gelten müsste.

Du kannst nicht eines dieser beiden Argumente bringen und das andere ablehnen, die Logik beider ist exakt die selbe.

o90o90o90o schrieb:

Ich glaube es gibt keinen der mit einer einfachen Console (nicht Editor) arbeitet und erwartet, dass bei einer String Eingabe nicht genau beim drücken von Enter diese fertig ist, außer, wenn er mit C++ arbeitet.

Das mag wohl sein, hat aber wie gesagt mit deinem "<< gibt auch Whitespaces aus" Argument nichts zu tun.

Und nicht alles was sich Anfänger im ersten Moment erwarten ist auch die optimale Lösung.

Die "Whitespace = Stop" Variante hat z.B. den Vorteil dass bei ">>" alle vordefinierten Operator gleich arbeiten, unabhängig vom Datentyp. Für alle gilt "Whitespace = Stop".

Würde ">>" bei Strings dagegen bis zum Zeilenende lesen wäre diese Symmetrie/Gemeinsamkeit zerstört. Und es gäbe keine andere Symmetrie/Gemeinsamkeit die man dadurch gewinnt. Weil sich ja wie gesagt ">>" mit Strings dadurch immer noch nicht gleich verhält wie "<<" mit Strings.

Eigentlich macht "Whitespace = Stop" auf der Console auch bei den anderen Datentypen keinen Sinn. Consoleneingabe endet einfach bei Enter und nicht bei Space. Das Problem dürfte wohl sein, dass man so tut, also ob die Console eine Datei wäre.

hustbaer

Und es würde noch weniger Sinn machen es auf der Konsole anders zu handhaben als in Files.
Überleg dir mal wie verwirrend DAS wäre.

Aber ich vermute dass es dir gar nicht mehr um die Sache geht, sondern einfach nur darum Recht zu haben.

Th69

@o90o90o90o: Es ist ja gerade der Sinn, daß sich Tastatureingaben genauso verhalten wie Dateien, damit man einfach in der Konsole die Ein- und Ausgabe umleiten kann, z.B.

program <input.txt >output.txt 2>error.txt

o90o90o90o schrieb:

Eigentlich macht "Whitespace = Stop" auf der Console auch bei den anderen Datentypen keinen Sinn. Consoleneingabe endet einfach bei Enter und nicht bei Space.

double x, y, z;
std::cout << "Geben Sie drei Zahlen ein: " << std::flush;
std::cin >> x >> y >> z;

...und jetzt versuchen wir das mal, wenn wir nur Zeilen einlesen können. Vor allem, wenn du jetzt nicht völlig Amok laufen und std::istringstream ein anderes Verhalten als std::istream geben willst.

o90o90o90o schrieb:

Das Problem dürfte wohl sein, dass man so tut, also ob die Console eine Datei wäre.

Das wird damit zusammenhängen, dass die Konsole eine Datei ist.

Das Problem hier besteht allein darin, dass dir nicht klar ist, dass operator>> keine rohe, sondern eine formatierte Einlesefunktion ist -- ein Konzept, das in den meisten Sprachen gleich oder ähnlich existiert. Wenn du eine Zeile haben willst, gibt es std::getline.

seldon schrieb:

double x, y, z;
std::cout << "Geben Sie drei Zahlen ein: " << std::flush;
std::cin >> x >> y >> z;
...und jetzt versuchen wir das mal, wenn wir nur Zeilen einlesen können. Vor allem, wenn du jetzt nicht völlig Amok laufen und std::istringstream ein anderes Verhalten als std::istream geben willst.

Nein, ich will für consolen Eingabe einen vernünftigen stream der nichts mit std::istream zu tun hat.

Funktioniert ja sowieso nicht wie ein file stream (siehe seek).

int main()
{
	int x;
	std::cout << "Verkaufspreis ihres Autos in Euro: " << std::flush;
	std::cin >> x;
	if ( !std::cin.fail() )
		std::cout << "Ihr Auto wurde fuer " << x << " Euro verkauft. Glueckwunsch.\n";

	std::cin.seekg(0, std::cin.beg);
	int xNochmal = 0;
	std::cin >> xNochmal;
	std::cout << "Nochmal x: " << xNochmal;
}

Verkaufspreis ihres Autos in Euro: 12 000
Ihr Auto wurde fuer 12 Euro verkauft. Glueckwunsch.
Nochmal x: 0

Und vonwegen string und int verwenden die gleichen Trennzeichen.

Verkaufspreis ihres Autos in Euro: 123sowasDerVerwendetJaNichtMalEinheitlichSpac
e...
Ihr Auto wurde fuer 123 Euro verkauft. Glueckwunsch.
Nochmal x: 0

Damit ist volkards Argument ja noch schlechter als gewolftes Zeugs.