C++Strings und die C++ String Bibliothek
-
length() ist eine funktion von string und kein member. daher gehören da die klammern dran, dann sollte der code auch gehen.
-
Braunstein schrieb:
es heißt ja auch str.length**()**
Bei manchen Compilern zieht iostream eben string mit rein (MinGW, keine Vorwärtsdeklarartion).Oh ja, da habe ich mich ein wenig vertan. Okay, dann funktioniert das Aufrufen der Methoden wohl doch.
Nun ja, also ich verwenden MinGW g++. Habe schon in der iostream, istream, ostream und ios Headerdatei geschaut, aber nicht direkt das Schlüsselwort string entdeckt. Ich schau aber noch weiter.
Danke
-
freu dich doch, dass es geht...
Sinngemäßes Zitat aus Matrix 3 über Maschinen:
"Wir wissen nicht, wie sie funktioniert, aber dass sie funktioniert."
-
Quellcode schrieb:
freu dich doch, dass es geht...
nein. Wenn dieses Verhalten nicht dem Standard entspricht kann man nach einem Compilerwechsel diverse Probleme bekommen
-
dann mach standardmäßig folgendes:
#include <string.h>
bzw.
#include <string>
-
Quellcode schrieb:
#include <string.h>
bzw.
#include <string>Ersteres bitte unter keinen Umständen! (Ungültiger C++ Code)
cu André
-
hm... wirklich... unter Borland C++ Builder geth es ohne das .h gar nicht...
-
Squall schrieb:
Nun ja, also ich verwenden MinGW g++. Habe schon in der iostream, istream, ostream und ios Headerdatei geschaut, aber nicht direkt das Schlüsselwort string entdeckt. Ich schau aber noch weiter.
der ist auch ein bisschen versteckt. das ist jetzt mal die include-reihenfolge für den gcc 4.2.3 unter linux, aber das sollte bei dem mingw ähnlich aussehen:
<iostream> -> <ios> -> <bits/ios_base.h> -> <bits/locale_class.h> -> <string>ob das der standard so definiert, müsste ich jetzt erst nachlesen...
-
Quellcode schrieb:
hm... wirklich... unter Borland C++ Builder geth es ohne das .h gar nicht...
Dann solltest du aber schnell den Compiler wechseln (oder zumindest aktualisieren).
-
Quellcode schrieb:
hm... wirklich... unter Borland C++ Builder geth es ohne das .h gar nicht...
Sagen wir es so: Wenn du einen veralteten Compiler verwendest, ist das dein Problem, aber BITTE schlag keinen veralteten Code vor. Und tue dir selbst etwas Gutes und wechsel (es gibt genügend frei verfügbare Alternativen)
Der C++98 Standard kennt keine Bibliothek die mittels <string.h> inkludiert wird. Es mag ein Compiler zwar zulassen, dies ist aber nicht garantiert.
cu André
-
Quellcode schrieb:
hm... wirklich... unter Borland C++ Builder geth es ohne das .h gar nicht...
Welche BCB-Version hast du denn?
Meine derzeit älteste installierte Version,BCB5 , hat damit kein Problem.
-
Ok, danke für die Hinweise.
Werde in Zukunft auch MSVC 2008 verwenden.Bin nur leider Uni-technisch gezwungen den BCB zu benutzen.
Ich wusste bis eben gar nicht, dass das veralteter Code ist.Wieder etwas schlauer
-
Der aktuelle BCB2007 ist gar nicht so veraltet.
Es wird bei CodeGear (Embarcadero) auch fleissig weiter am Compiler gearbeitet um ihn standardkonformer zu machen. Ab der nächsten Release sollte z.Bsp. auch ein fertig kompiliertes boost mit dabei sein.
-
Quellcode schrieb:
Ich wusste bis eben gar nicht, dass das veralteter Code ist.
Du kannst dir merken, dass in C++ alle Standardheader ohne Dateiendung auskommen. Bei moderneren Compilern wird dir auch eine Warnung beim Benutzen veralteter Header ausgegeben.
-
asc schrieb:
Quellcode schrieb:
#include <string.h>
bzw.
#include <string>Ersteres bitte unter keinen Umständen! (Ungültiger C++ Code)
cu André
Ja, allerdings! ... Das wird bei uns in der Schule verwendet, weil die einen uralt Compiler von Borland verwenden, wo es noch nicht einmal Namespaces gab...
Vor allem ist string.h doch eigentlich die alte C-Headerdatei, oder? Mit Funktionen wie strcmp(), strcpy() usw...?
-
asc schrieb:
Der C++98 Standard kennt keine Bibliothek die mittels <string.h> inkludiert wird. Es mag ein Compiler zwar zulassen, dies ist aber nicht garantiert.
Klar kennt der Standard das. string.h ist zwar zugunsten von cstring überholt, ist aber trotzdem Teil des Standards und enthält die Deklarationen für den Stringteil der libc.
-
ghorst schrieb:
Squall schrieb:
Nun ja, also ich verwenden MinGW g++. Habe schon in der iostream, istream, ostream und ios Headerdatei geschaut, aber nicht direkt das Schlüsselwort string entdeckt. Ich schau aber noch weiter.
der ist auch ein bisschen versteckt. das ist jetzt mal die include-reihenfolge für den gcc 4.2.3 unter linux, aber das sollte bei dem mingw ähnlich aussehen:
<iostream> -> <ios> -> <bits/ios_base.h> -> <bits/locale_class.h> -> <string>ob das der standard so definiert, müsste ich jetzt erst nachlesen...
Habe deine Antwort ganz übersehen.
Was mich ja wundert, dass das da funktioniert. Mir ist aber auch aufgefallen, dass iostream -> ostream -> ios -> cstdio inkludiert. Theoretisch sollte man also printf() verwenden können, kann man aber nicht!
Wieso das denn?
Braunstein schrieb:
Meine derzeit älteste installierte Version,BCB5 , hat damit kein Problem.
In der Schule verwenden wir BCB5. Die soziemlich früheste Version davon und die unterstützt es nicht.
Danke,
Gruß
Squall
-
Wenn überhaupt, dann std::printf. Aber sowas braucht eigentlich nicht zu interessieren, es ist einfach ein Implementierungsdetail. Wenn du std::printf haben willst, dann holst du dir cstdio, wenn du std::string haben willst, dann holst du dir <string> etc.
-
Ich schreibe sowieso in jeden Quellcode von mir using namespace std;, von daher.^^
Nun ja, ich habe mir auch gedacht, für Zukunft immer schön string einbinden, wenn ich strings verwende. Es könnte ja sein, dass das kein Standard ist (habe nicht nachgeschaut) und deshalb woanders Probleme verursachen könnte. Mich wunderte es einfach ein wenig.
Danke für eure zahlreichen Antworten,
Gruß
Squall
-
Squall schrieb:
Ich schreibe sowieso in jeden Quellcode von mir using namespace std;, von daher.^^
Nun ja, ich habe mir auch gedacht, für Zukunft immer schön string einbinden, wenn ich strings verwende. Es könnte ja sein, dass das kein Standard ist (habe nicht nachgeschaut) und deshalb woanders Probleme verursachen könnte. Mich wunderte es einfach ein wenig.
Danke für eure zahlreichen Antworten,
Gruß
SquallEs ist definitiv kein Standard. Wenn Du std::string verwendest, musst Du <string> inkludieren. Dass die <string> indirekt über andere Header auch inkludiert wird, ist im C++ Standard allerdings nicht verboten. Man darf sich einfach nicht darauf verlassen.
Und noch so nebenbei: die <string.h> hat nichts mit der <string> zu tun. Die <string.h> ist nicht veraltet, sondern einfach nur ein C-Header. Was zu verwechlung führt ist, dass z. B. <iostream.h> veraltet ist und man <iostream> verwenden sollte. Aber das ist eine andere Geschichte.