3. find() Funktion funktioniert nicht

find() Funktion funktioniert nicht

  • N

    1. Ich wollte eine Gruppe strings die durch Leerzeichen getrennt waren in unterschiedliche Speicher tun. Dazu habe ich zuerst den .find(" ",0) Befehl benutzt. Dieser funktioniert bei mir jedoch nur wenn ich den string direkt im quelltext eingebe: string text="hier steht ein Text";
    Unter dieser Voraussetzung zeigt er mir die Position der Leerzeichen.
    Wenn ich jedoch folgendes mache:

    #include <iostream>
    #include <cstring>
    #include <cstdio>
    using namespace std;
    int main ()
    {
    string ausgabe;
    cin>>ausgabe;
    int pos;
    pos = ausgabe.find(" " ,0);
    cout<<pos<<endl;
    fflush(stdin);
    getchar();
    }

    also den Text über die Konsole eingeben lasse, passiert unterschiedliches:
    a) nach Leerzeichen suchen funktioniert gar nicht (ausgabe: -1)
    b) wenn ich nach z.B. ("hier") suchen lasse:
    wenn ich eingebe: "hier ist was los" :ausgabe 0(funktioniert)
    wenn ich eingebe: "isthierwaslos" :ausgabe 3(funktioniert)
    wenn ich eingebe: "ist hier was los" :ausgabe -1 (funkt. nicht)

    das heißt er gibt mir die Position nicht, wenn ich Leerzeichen verwende(außer das Wort steht an erster Stelle)
    Wer kann mir helfen ohne i-was kompliziertes zu versuchen (bin totaler Anfänger, also ohne z.B. char*)?

    2. kleine Frage: wie um Gottes willen kann man int's nach der Eingabe wenn sie nur durch Leerzeichen getrennt sind in unterschiedliche Speicher packen
    (also ohne nach jeder Zahl Enter zu drücken)?

    MfG,
    totaler n00b

    0
  • Mod

    Zu Punkt 1: guck dir mal an, was der istream Operator >> für std::string macht. Der stoppt nämlich beim ersten Whitespacezeichen das er findet. Dagegen könnten folgende Sachen helfen:

    1. getline
    2. Möglicherweise auch noskipws. Das habe ich aber selbst noch nie in Zusammenhang mit std::string verwendet. Wäre aber mal einen Versuch wert, ob das geht.

    Zu Punkt 2: Du machst einfach mehrere formatierte Eingaben (also mit Operator >>) nacheinander. Wie auch für string, nimmt der >> Operator für int Leerzeichen als Trennzeichen. Genauso verhält er sich übrigens bei allen eingebauten Datentypen, für die es diesen Operator gibt.

    0
  • D

    Das liegt daran, dass der >>-Operator bis zu dem ersten Leerzeichen einliest. 😉

    Versuchs mal so:

    #include <iostream>
#include <string> // benutze string!
using namespace std;
int main ()
{
string ausgabe;
getline(cin, ausgabe);
int pos;
pos = ausgabe.find(" " ,0);
cout<<pos<<endl;
fflush(stdin);
getchar();
}

    btw:
    cpp-Tags benutzen!

    Zu 2:

    #include <iostream>
int main ()
{
 int i = 0;
 int i2 = 0;

 std::cout << "2 Zahlen eingeben: ";
 std::cin >> i >> i2;
 std::cout << i << ", " << i2;

 fflush(stdin);
 getchar();
}
    0
  • K
     

    #include <iostream> 
//#include <cstring> C-String? oO
#include <string>

//using namespace std; 

int main () 
{ 
	std::string varStr("hier geht der bär ab");
	::size_t pos = varStr.find("geht");

	if(pos != std::string::npos)
		std::cout<< pos;

	std::cin.get();
}

    Warum integer? Steht doch direkt in der cpp-reference, dass ein ::size_t zurückgegeben wird...

    0
  • U

    ::size_t pos = varStr.find("geht");
    kannst du nicht auch mal mit weniger doppelpkt programmieren?
    noch dazu, wenn sie falsch sind...
    size_t liegt im namespace std , egal was dein compiler denkt... ich finds zwar auch sinnlos und doof, aber kann man nix machen, wenns so im standard steht - ist ja auch nicht das einzige, was im standard nich so doll ist ;o)
    noch dazu wäre std::string::size_type korrekt (das wird zwar immer ein size_t sein, aber der allocator kann eben auch nen anderen size type nutzen (vll kann er eh nur 2^16 byte adressieren und nimmt deshalb sinnvollerweise uint16 oder was auch immer...)

    bb

    0
  • N

    n00b42 schrieb:

    fflush(stdin);
getchar();

    fflush(stdin) solltest du nicht schreiben, das führt zu undefiniertem Verhalten. Auch getchar() empfehle ich nicht, weil du C- und C++-Eingabebehandlung mischst. Nimm std::cin.get() , wie von Kóyaánasqatsi vorgeschlagen.

    Kóyaánasqatsi schrieb:

    Warum integer? Steht doch direkt in der cpp-reference, dass ein ::size_t zurückgegeben wird...

    Gewöhn dir bitte ab, immer :: für den globalen Namensraum anzugeben, damit verwirrst du die Leute nur. 😉
    size_t wäre wenn schon in std ...

    0
  • K

    Nexus schrieb:

    size_t wäre wenn schon in std ...

    Bei mir nicht. 🙂

    0
  • U

    Kóyaánasqatsi schrieb:

    Nexus schrieb:

    size_t wäre wenn schon in std ...

    Bei mir nicht. 🙂

    sicher ist er das bei dir auch - nur vll nimmts dein compiler nicht so genau mit dem standard und bietet ihn zusätzlich auch im globalen scope an - aber selbst dann wär es noch nicht richtig 😛
    da kommt mir gerad nen interessanter gedanke:
    welchen size_type hat std::vector<bool> ? ^^ ich glaub auch size_t - dabei kann er doch (zumindest theoretisch) sizeof(char)*std::numeric_limits<allocator_type::size_type>::max() allokieren?!

    bb

    0
  • K

    Bei mir ist im std-Scope nichts von size_t zu finden.

    0
  • N

    Kóyaánasqatsi schrieb:

    Bei mir ist im std-Scope nichts von size_t zu finden.

    Wo hast du gesucht? Bei IntelliSense? Darauf solltest du dich nicht verlassen.

    size_t ist ein Typ der C-Standardbibliothek und wurde mit C++ in den Header <cstddef> verfrachtet und in std eingepackt.

    0
  • K

    Jo, IntelliSense war Schuld. Habe das Gefühl, dass das bei VS ziemlich verbuggt ist.

    0
  • N

    Danke für die schnellen Antworten. Hätte gar nicht gedacht, dass meine Frage gleich so ein breites Echo haben würde 👍 .

    0
  • U

    n00b42 schrieb:

    Danke für die schnellen Antworten. Hätte gar nicht gedacht, dass meine Frage gleich so ein breites Echo haben würde 👍 .

    Jopp - das lag aber eher an K. als an deiner Frage^^

    PS:

    Kóyaánasqatsi schrieb:

    Jo, IntelliSense war Schuld. Habe das Gefühl, dass das bei VS ziemlich verbuggt ist.

    so was guckt man ja auch im standard und nicht in der IDE nach... Intellisense zeigt zwar trotzdem vieles aus der standard-lib nicht an, aber die Fehler dort haben mich bisher nur extrem selten gestört...

    bb

    0
  • N

    unskilled schrieb:

    so was guckt man ja auch im standard und nicht in der IDE nach... Intellisense zeigt zwar trotzdem vieles aus der standard-lib nicht an, aber die Fehler dort haben mich bisher nur extrem selten gestört...

    Das Problem liegt darin, dass die Standardbibliothek des MSVC++ C-Typen wie size_t global definiert und per using in den std -Namensraum zieht. IntelliSense scheint using nicht zu berücksichtigen.

    Abgesehen von gelegentlichen Ausfällen gefällt mir IntelliSense nicht schlecht. Allerdings sollte man es nicht als Massstab für den C++-Standard nehmen.

    0
  • U

    Nexus schrieb:

    unskilled schrieb:

    so was guckt man ja auch im standard und nicht in der IDE nach... Intellisense zeigt zwar trotzdem vieles aus der standard-lib nicht an, aber die Fehler dort haben mich bisher nur extrem selten gestört...

    Das Problem liegt darin, dass die Standardbibliothek des MSVC++ C-Typen wie size_t global definiert und per using in den std -Namensraum zieht. IntelliSense scheint using nicht zu berücksichtigen.

    dein Intellisense kennt size_t? meins nicht - wird daran liegen, dass es auch nirgendwo definiert wird 😛
    aber ja, leider scheint intellisense using nicht verstehen zu können 😕

    Nexus schrieb:

    Abgesehen von gelegentlichen Ausfällen gefällt mir IntelliSense nicht schlecht. Allerdings sollte man es nicht als Massstab für den C++-Standard nehmen.

    wollt ich damit auch sagen.

    bb

    0
Anmelden zum Antworten