C Hassen...

.filmor schrieb:

Optimizer schrieb:

Das ist ein Problem der schlechtesten String-Klasse aller Zeiten. Sieh's halt endlich ein.

Wie zum Henker kommst du darauf? Die einzigen Probleme (die man aber ausmerzen sollte) sind, dass dir von der Implementierung vorgeschrieben wird, wie der String gespeichert wird (s. flex_string) und dass dir von der Plattform vorgeschrieben wird, wie die Zeichen kodiert sind. Beides ist nicht besonders praktisch, besonders bei plattformübergreifenden Anwendungen und Bibliotheken.
Gegen das Interface ist IMHO nichts einzuwenden (und das ist schließlich das, was den Programmierer dazu bringt zu sagen, die Klasse sei schlecht).

Das interface ist doch gerade das schlimmste. length() und size() ist hirnrissig und es gibt keine fertigen Operationen, um eine Zahl als String-Repräsentation (vorzugsweise in beliebiger Formatierung und Zahlenbasis) an einen String anzuhängen. Entschuldige mal, aber das sind die Basics. Sag nicht, dass Streams das können, das ist nämlich genau das Problem, dass beispielsweise eine GUI-Lib halt eben gerne einen String für die Button-Beschriftung hätte und es ist viel zu fricklig, erst in nen stringstream zu schreiben und wieder nen String rauszugetten - äh zu fricklig, für Leute, die mehr Komfort gewohnt sind.

Dann fehlt sowas:

string myString = string.Format("Der Wert ist {0}, das ist {1} mehr, als ich brauche!", wert1, wert2)

natürlich typsicher und ohne explizite Typangabe wie %d.

Dann ist string unfähig, zwischen Zeichencode und Zeichen zu differenzieren, damit sind alle Zeichensätze, die eine variable Anzahl bytes pro Zeichen verwenden, umständlich zu handhaben.

Das ganze Konzept erzeugt viel zu viel temporäre variablen, wenn du Dinge schreibst wie myString1 + myString2 + "slöiehdf" + myString3, schwitzt der Compiler richtig krass, um alles noch wegzuoptimieren. Um ihn zu helfen, gibt es extra nen operator+(char*), soviel zu schönem Interface. Ein schönes Interface wäre, wenn der String in die Sprache integriert wäre, dass "shdlif" kein char* sondern ein std::string ist.

Und da sowieso jeder Compiler-Hersteller den String anders implementieren kann, hat sich das mit den Libs schon weitestgehend erübrigt. Ein char* kann man immer übergeben, das macht zwischen verschiedenen Compilern und Libs keinen Unterschied, beim std::string brauchst du erstmal ein gemeinsames Modell wie das im Speicher auszusehen hat und das ist nicht standardisiert.

.filmor

Optimizer schrieb:

Das interface ist doch gerade das schlimmste. length() und size() ist hirnrissig

Ist es nicht. Sobald du einen Multibytestring implementierst ist das sinnvoll.

Optimizer schrieb:

und es gibt keine fertigen Operationen, um eine Zahl als String-Repräsentation (vorzugsweise in beliebiger Formatierung und Zahlenbasis) an einen String anzuhängen. Entschuldige mal, aber das sind die Basics. Sag nicht, dass Streams das können, das ist nämlich genau das Problem, dass beispielsweise eine GUI-Lib halt eben gerne einen String für die Button-Beschriftung hätte und es ist viel zu fricklig, erst in nen stringstream zu schreiben und wieder nen String rauszugetten - äh zu fricklig, für Leute, die mehr Komfort gewohnt sind.

Stimmt, aber das ist nicht Aufgabe der Stringklasse. boost::lexical_cast macht das.

Optimizer schrieb:

Dann fehlt sowas:
string myString = string.Format("Der Wert ist {0}, das ist {1} mehr, als ich brauche!", wert1, wert2)
natürlich typsicher und ohne explizite Typangabe wie %d.

Gibts auch in Boost (Boost.Format). Wiederum nicht die Aufgabe der Stringklasse.

Optimizer schrieb:

Dann ist string unfähig, zwischen Zeichencode und Zeichen zu differenzieren, damit sind alle Zeichensätze, die eine variable Anzahl bytes pro Zeichen verwenden, umständlich zu handhaben.

Stimmt. Aber das sagte ich (2. Schwachpunkt).

Optimizer schrieb:

Das ganze Konzept erzeugt viel zu viel temporäre variablen, wenn du Dinge schreibst wie myString1 + myString2 + "slöiehdf" + myString3, schwitzt der Compiler richtig krass, um alles noch wegzuoptimieren. Um ihn zu helfen, gibt es extra nen operator+(char*), soviel zu schönem Interface. Ein schönes Interface wäre, wenn der String in die Sprache integriert wäre, dass "shdlif" kein char* sondern ein std::string ist.

Unsinn. Wenn du wirklich performante Strings brauchst, musst du nunmal leider char* nehmen. Übrigens ist das auch kein Problem der Klasse. Zum Thema der temporären Variablen: wie sollte es deiner Meinung nach aussehen?! Erst verlangst du mehr Komfort und dann so was ...

Optimizer schrieb:

Und da sowieso jeder Compiler-Hersteller den String anders implementieren kann, hat sich das mit den Libs schon weitestgehend erübrigt. Ein char* kann man immer übergeben, das macht zwischen verschiedenen Compilern und Libs keinen Unterschied, beim std::string brauchst du erstmal ein gemeinsames Modell wie das im Speicher auszusehen hat und das ist nicht standardisiert.

Und? So lange die Schnittstelle gleich ist, ist das egal. Übrigens ist das der andere angesprochene Kritikpunkt (diesmal Nr. 1).

Hast du nun noch was Neues, was gegen std::string spricht? :p

GPC

Artchi schrieb:

Hier kann man dem C++ Komitee aber (wenn auch leider etwas spät) ein Umdenken und Einsicht nachsagen. TR (ISO Technical Reports) sind ja hier schon mehr mals gefallen. Mit den TRs will das Komitee schneller den Standard voranbringen, weil TRs für Compilerhersteller optional sind.

Optional im Sinne von: Beim VC++ ist es dabei, der Borland hat's halt nicht? Bad luck?

Es gibt einmal den ISO-C++ Sprachstandard, in dem auch die bisher bekannte Standardlib angehört. Jetzt gibts aber zus. die TRs. TR1 ist ja jetzt schon im April 2006 verabschiedet und er ist _gesetzt_! So, d.h. seit April 2006 haben wir _offiziell_ für ISO-C++ die Boost Smartpointer, Hashs, Regex u.a. in C++. Wer heute also sagt: "Warum gibts verdammt nochmal kein Regex in C++?" dem kann man sagen: "schau in den Namespace std::tr1 rein! Da hast du es drin!"

Also gut, das ist ja schon mal was. Ein Fortschritt. Da will ich auch nichts gegen sagen.

Ich schätze mal in ein oder zwei Jahren wird dann TR2 endgültig verabschiedet und dann können wir sagen: "Wenn du Funktionen für Filesystem, Threads, Netzwerk brauchst, schau in den Namespace std::tr2 rein!"

Also, zukünftig werden wir nicht mehr 10 und mehr Jahre warten müssen. Es wird sich wohl auf 2 bis 3 Jahre einpendeln.

Uh, nicht berauschend, aber wenigstens überblickbar.

Am ISO-C++ Sprachstandard soll in Zukunft (weil es da wirklich 10 Jahre braucht!) nur noch wenig gemacht werden.

D.h. es wird alles über TRs geregelt werden, was die Sprache nicht im Kern über den Haufen werfen würde?

Achja, noch etwas was auch erstaunlich ist: im C++0x Standard wurde ja dieses Templateproblem behoben:
std::vector<std::vector<int>>
                           ^^
Wer VC++ 2005 benutzt, findet diesen C++0x-Bugfix schon vor. ALso MS hat hier sogar schon vorarbeit geleistet und schon mal ein C++0x-Spec in die Praxis umgesetzt.

Ah, deshalb lief das bei nem User erst kürzlich, hab mich noch gewundert. Auch nett ist das Feature:

std::string fileName("file.txt");

std::ifstream ifs(fileName);
//...

Das wollten sie doch auch implementieren, ist das nun schon beim TR1 oder TR2 dabei?

MfG

GPC

Artchi

um eine Zahl als String-Repräsentation (vorzugsweise in beliebiger Formatierung und Zahlenbasis) an einen String anzuhängen. Entschuldige mal, aber das sind die Basics.

boost::lexical_cast wurde von der LWG vorläufig für den TR2 akzeptiert.

Dann ist string unfähig, zwischen Zeichencode und Zeichen zu differenzieren, damit sind alle Zeichensätze, die eine variable Anzahl bytes pro Zeichen verwenden, umständlich zu handhaben.

std::string ist auch nicht dafür gedacht. Du benutzt also diese Klasse falsch. Du mußt (wie vorgesehen) std::wstring benutzen, wenn du mehr als 256 verschiedene Zeichen haben willst. Einiziges Manko bisher (und das ist wirklich doof) ist die fehlende "wstring nach utf-8 und umgekehrt"-Konvertierung.

Du hast mit string und wstring zwei Klassen, die erstmal ihre Zwecke erfüllen. An dem einen Manko bzgl. UTF-8 wird aktuell gearbeitet und es liegen auch erste Vorschläge beim Komitee vor. Es ist aber noch nichts verabschiedet.

wenn du Dinge schreibst wie myString1 + myString2 + "slöiehdf" + myString3, schwitzt der Compiler richtig krass

Ist in Java auch nicht besser, da passiert das gleiche mit String, vermeiden kann ich das nur mit der Klasse StringBuffer.

Und da sowieso jeder Compiler-Hersteller den String anders implementieren kann, hat sich das mit den Libs schon weitestgehend erübrigt. Ein char* kann man immer übergeben, das macht zwischen verschiedenen Compilern und Libs keinen Unterschied, beim std::string brauchst du erstmal ein gemeinsames Modell wie das im Speicher auszusehen hat und das ist nicht standardisiert.

Die Implementierung ist mir aber persönlich egal. Wichtig ist nur, das das Interface von std::basic_string das macht, was auch im Standard drin steht.

Artchi

Optional im Sinne von: Beim VC++ ist es dabei, der Borland hat's halt nicht? Bad luck?

Da es sich nur um Libraries und nicht um Sprachfeatures handelt, kann man die TR-Konformität nachrüsten. Boost selbst arbeitet z.B. an einer TR1-Implementierung. Wenn also jemandem in seinem Compiler der TR1 fehlt, einfach bei Boost downloaden. Ich denke mal, solche Gruppen wie STLport werden das auch machen. Dinkumware arbeitet auch daran, und somit wird wohl jeder Compilerhersteller, der bisher auf Dinkumware setzt, TR1 auch gleich mit einkaufen.

Das wollten sie doch auch implementieren, ist das nun schon beim TR1 oder TR2 dabei?

Wurde erst im April 2006 eingereicht, durchgängig in der Standardlib string zu verwenden:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1981.html

Muß man noch abwarten, was jetzt auf den nächsten Meetings damit passiert. Notfalls wird sich boost::filesystem durchsetzen, wo man Dateistreams auch über die Klassen string und path öffnen kann.

.filmor schrieb:

Optimizer schrieb:

Das interface ist doch gerade das schlimmste. length() und size() ist hirnrissig

Ist es nicht. Sobald du einen Multibytestring implementierst ist das sinnvoll.

Red nicht: http://cppreference.com/cppstring/length.html
Das ist einfach nur doppelt gemoppelt, weil length() schöner klingt und size() gibt es, damit das Container-Interface erfüllt ist. Das ist halt gutes Design. size() darf nichts anderes als length() zurückgeben.

Optimizer schrieb:

und es gibt keine fertigen Operationen, um eine Zahl als String-Repräsentation (vorzugsweise in beliebiger Formatierung und Zahlenbasis) an einen String anzuhängen. Entschuldige mal, aber das sind die Basics. Sag nicht, dass Streams das können, das ist nämlich genau das Problem, dass beispielsweise eine GUI-Lib halt eben gerne einen String für die Button-Beschriftung hätte und es ist viel zu fricklig, erst in nen stringstream zu schreiben und wieder nen String rauszugetten - äh zu fricklig, für Leute, die mehr Komfort gewohnt sind.

Stimmt, aber das ist nicht Aufgabe der Stringklasse. boost::lexical_cast macht das.

boost::lexical_cast macht genau das fricklige, was ich beschrieben habe. Überhaupt nicht geil und überhaupt nicht performant. Aber gut, dass wir kurzzeitig mal nicht über die Standardbibliothek gesprochen haben. Lass uns zum Thema zurückkehren, schließlich hat hier keiner bezweifelt, dass es möglich ist, für C++ gute Libs zu schreiben.

Optimizer schrieb:
Dann fehlt sowas:
string myString = string.Format("Der Wert ist {0}, das ist {1} mehr, als ich brauche!", wert1, wert2)
natürlich typsicher und ohne explizite Typangabe wie %d.
Gibts auch in Boost (Boost.Format). Wiederum nicht die Aufgabe der Stringklasse.

Mit welcher Begründung ist das alles nicht Aufgabe der Stringklasse? Wie ist zu erklären, dass substring, find, compare alles Aufgabe der String-Klasse ist, etwas anderes aber, was im Standard dämlicherweise nicht existiert dann plötzlich überhaupt gar nicht mehr Aufgabe des Strings ist? Führe doch mal bitte genau aus, wie man so etwas bewerten kann (vor allem, wenn ich es jeden Tag 20mal verwende). Du scheinst ja einfach anzunehmen, wenn etwas wichtiges fehlt, wird es wohl auch nicht da hin passen, aber das hätte ich schon gerne gut begründet, wird nämlich überall anders gehandhabt.

Optimizer schrieb:

Das ganze Konzept erzeugt viel zu viel temporäre variablen, wenn du Dinge schreibst wie myString1 + myString2 + "slöiehdf" + myString3, schwitzt der Compiler richtig krass, um alles noch wegzuoptimieren. Um ihn zu helfen, gibt es extra nen operator+(char*), soviel zu schönem Interface. Ein schönes Interface wäre, wenn der String in die Sprache integriert wäre, dass "shdlif" kein char* sondern ein std::string ist.

Unsinn. Wenn du wirklich performante Strings brauchst, musst du nunmal leider char* nehmen. Übrigens ist das auch kein Problem der Klasse. Zum Thema der temporären Variablen: wie sollte es deiner Meinung nach aussehen?! Erst verlangst du mehr Komfort und dann so was ...

Das geht mit einem so vermurkstem Konzept natürlich nicht, schon klar. Wie es meiner Meinung nach aussehen soll? Strings integriert man am besten auf Sprachebene wie in C# und Java. Da kannst du hundert + hinschreiben und der Compiler macht einen StringBuilder variabler Länge mit append() für jedes + draus und am Ende holt er den String, macht immer 2 Objekte.

Stimmt. Aber das sagte ich (2. Schwachpunkt).

Übrigens ist das der andere angesprochene Kritikpunkt (diesmal Nr. 1).

Na perfekt, jetzt haben wir beide nur Kritikpunkte aufgezählt und noch nichts positives an std::string erwähnt.

Hast du nun noch was Neues, was gegen std::string spricht? :p

Aber trotzdem findest du die Klasse wohl toll designed. Naja, man kann ja auch einfach die Augen vor der Wahrheit verschließen, aber andere überzeugt du damit noch nicht.

Erhard Henkes

Das Problem bezüglich std::string besteht darin, dass es zu spät gekommen ist. Wie mit Hase und Igel. Überall ist char* bereits vor Ort. Das fängt mit konstanten Strings wie "hello, world" an. Klar man könnte so einen Schauerkram wie

std::cout << std::string("hello, world") << std::endl;

schreiben, aber welches Lehrbuch macht denn so etwas freiwillig?

Zusätzlich fehlen für viele Dinge echte Alternativen in C++. Dann greift man eben auf die alten C-Bibliotheken zurück, und schon hat man es schon wieder mit char* zu schaffen und braucht vielleicht ein buffer char[256] als Member-Variable in einer Klasse.

Nehmen wir z.B. an, man soll die Systemzeit abfragen, wie macht ihr das mit C++ ohne die C-Bibliothek <ctime>, die selbstverständlich noch mit char* arbeitet?

.filmor

Optimizer schrieb:

.filmor schrieb:

Optimizer schrieb:

Das interface ist doch gerade das schlimmste. length() und size() ist hirnrissig

Ist es nicht. Sobald du einen Multibytestring implementierst ist das sinnvoll.

Red nicht: http://cppreference.com/cppstring/length.html
Das ist einfach nur doppelt gemoppelt, weil length() schöner klingt und size() gibt es, damit das Container-Interface erfüllt ist. Das ist halt gutes Design. size() darf nichts anderes als length() zurückgeben.

Für den hypothetischen Fall, dass jemand einen Multibytestring implementiert (und std::string ist definitiv keiner) kann er length für die Anzahl der Zeichen und size für die Anzahl an gespeicherten chars oder ints oder was auch immer nehmen.

Optimizer schrieb:

boost::lexical_cast macht genau das fricklige, was ich beschrieben habe. Überhaupt nicht geil und überhaupt nicht performant. Aber gut, dass wir kurzzeitig mal nicht über die Standardbibliothek gesprochen haben. Lass uns zum Thema zurückkehren, schließlich hat hier keiner bezweifelt, dass es möglich ist, für C++ gute Libs zu schreiben.

Wenn du es performant haben willst, dann nimm halt C. Hast du überhaupt Belege dafür, das die stringstreams so unglaublich lahm sind? Ich hatte bisher noch keine Probleme damit. Außerdem ist das wiederum stark implementierungsabhängig.

Optimizer schrieb:

Mit welcher Begründung ist das alles nicht Aufgabe der Stringklasse? Wie ist zu erklären, dass substring, find, compare alles Aufgabe der String-Klasse ist, etwas anderes aber, was im Standard dämlicherweise nicht existiert dann plötzlich überhaupt gar nicht mehr Aufgabe des Strings ist? Führe doch mal bitte genau aus, wie man so etwas bewerten kann (vor allem, wenn ich es jeden Tag 20mal verwende). Du scheinst ja einfach anzunehmen, wenn etwas wichtiges fehlt, wird es wohl auch nicht da hin passen, aber das hätte ich schon gerne gut begründet, wird nämlich überall anders gehandhabt.

Was zum Henker hat denn Formatierung mit strings zu tun?! Im Prinzip ist das sogar nur Aufgabe der Ausgabeoperationen (wo es ja auch drin ist, eben die Streams). substr ist (so wie es jetzt ist) tatsächlich ziemlich unnötig, ein Einzug einer ordentlichen Range-Bibliothek in den Standard muss dem Abhilfe schaffen. Eigentlich sollte das meiste, was keine Iteratoren sondern Indizes nutzt, aus der Stringklasse verschwinden (solange es einen adäquaten Ersatz gibt und es performancetechnisch vertretbar ist).
Okay, nach reiflicher Überlegung (;)) bin ich doch nicht ganz mit der Stringklasse zufrieden. Aber wirklich fehlen IMHO nur slices (wie auch in den anderen Containern).

Optimizer schrieb:

Das geht mit einem so vermurkstem Konzept natürlich nicht, schon klar. Wie es meiner Meinung nach aussehen soll? Strings integriert man am besten auf Sprachebene wie in C# und Java. Da kannst du hundert + hinschreiben und der Compiler macht einen StringBuilder variabler Länge mit append() für jedes + draus und am Ende holt er den String, macht immer 2 Objekte.

Wenn Strings fest in der Sprache eingebaut sind, dann sind sie doch noch unflexibler, als wenn sie als Klasse implementiert sind?! BTW, das hat nichts mit std::string sondern mit C++ zu tun.

Optimizer schrieb:

Hast du nun noch was Neues, was gegen std::string spricht? :p

Aber trotzdem findest du die Klasse wohl toll designed. Naja, man kann ja auch einfach die Augen vor der Wahrheit verschließen, aber andere überzeugt du damit noch nicht.

s.o.

Ich mach mich direkt dran, eine bessere zu schreiben :p

Artchi

Nehmen wir z.B. an, man soll die Systemzeit abfragen, wie macht ihr das mit C++ ohne die C-Bibliothek <ctime>, die selbstverständlich noch mit char* arbeitet?

Verstehe das Problem nicht so recht?

time_t t = time(NULL);
string str(ctime(&t));
cout << str << endl;

Im TR2 wird aber hoffentlich boost::date_time rein kommen.

Swordfish

.filmor schrieb:

Ich mach mich direkt dran, eine bessere zu schreiben

Ich bin schon richtig gespannt

Greetz, Swordfish

.filmor schrieb:

Optimizer schrieb:

.filmor schrieb:

Optimizer schrieb:

Das interface ist doch gerade das schlimmste. length() und size() ist hirnrissig

Ist es nicht. Sobald du einen Multibytestring implementierst ist das sinnvoll.

Red nicht: http://cppreference.com/cppstring/length.html
Das ist einfach nur doppelt gemoppelt, weil length() schöner klingt und size() gibt es, damit das Container-Interface erfüllt ist. Das ist halt gutes Design. size() darf nichts anderes als length() zurückgeben.

Für den hypothetischen Fall, dass jemand einen Multibytestring implementiert (und std::string ist definitiv keiner) kann er length für die Anzahl der Zeichen und size für die Anzahl an gespeicherten chars oder ints oder was auch immer nehmen.

Das darfst du aber nicht, wenn du dich an den Standard halten willst. So wie es definiert ist (size() == length()), ist es Teil eines unschönen Interface und daran kann man erstmal nichts ändern.

Optimizer schrieb:

boost::lexical_cast macht genau das fricklige, was ich beschrieben habe. Überhaupt nicht geil und überhaupt nicht performant. Aber gut, dass wir kurzzeitig mal nicht über die Standardbibliothek gesprochen haben. Lass uns zum Thema zurückkehren, schließlich hat hier keiner bezweifelt, dass es möglich ist, für C++ gute Libs zu schreiben.

Wenn du es performant haben willst, dann nimm halt C. Hast du überhaupt Belege dafür, das die stringstreams so unglaublich lahm sind? Ich hatte bisher noch keine Probleme damit. Außerdem ist das wiederum stark implementierungsabhängig.

Du instanzierst halt einen Stream und schmeißt ihn wieder weg, nimmst vorher den string raus und weist den Wert dem eigentlich Zielobjekt zu (wahrscheinlich eine Kopie, weil man könnte ja den extrahierten String auch noch verwenden wollen). Damit hast du
- einen temporären Stream
- einen temporären String
- eine Zuweisung von temp an myString, die wahrscheinlich ne Kopie des Inhalts ist
(das macht mindestens zwei buffer im Heap allokiert für nix und wieder nix)

Da ist das Konzept schon so ungünstig, dass der Compiler nicht mehr alles rausreißen kann. Vergleich mal, was wäre wenn der String das einfach anhängen könnte. Er würde seinen internen Buffer, falls nötig, vergrößeren und die chars für die Zahl reinschreiben.

Was zum Henker hat denn Formatierung mit strings zu tun?! Im Prinzip ist das sogar nur Aufgabe der Ausgabeoperationen (wo es ja auch drin ist, eben die Streams).

Das ist ein Trugschluss, Formatierung hat erstmal gar nichts mit I/O zu tun. Die Formatierung in die Streams zu setzen halte ich für einen Fehler, da die auch benutzt werden, um binär zu schreiben. Eine strikte Trennung dieser beiden Sachen ist ein besseres Design.

Dazu muss man mal sehen, dass man in einer echten Welt verschiedene Encodings braucht. Es ist reichlich bedenklich, das einfach so in das Stream I/O reinzupacken. Ein schönerer Ansatz ist, erstmal ne Stream I/O nur für bytes bereitzustellen und eine Lib für verschiedene Text-Sachen, dazu gehört dann String, meinetwegen eine Format-Klasse und ein TextWriter, der Strings unter Angabe eines bestimmten Encodings als bytes in einen bestimmten Stream schreibt. Und dann sieht man auch sofort, dass Formatierung eine Text-Sache ist und keine I/O-Sache. Ein Stream kann doch gar nicht wissen, welche Bytes er bei welchem Text jetzt schreiben soll, da muss vorher eine Umwandlung (Kodierung genannt) stattfinden und das genau das mit Standardmitteln nicht einstellbar ist, deckt den ganzen Design-Fehler auf.

EDIT: Davon abgesehen reicht dir doch die Ausgabe-Formatierung gar nicht. Wie willst du denn so formatierten Text in eine Excel-Tabelle bringen? Achja richtig... in nen stringstream schreiben und wieder nen string rausgetten...

Optimizer schrieb:

Das geht mit einem so vermurkstem Konzept natürlich nicht, schon klar. Wie es meiner Meinung nach aussehen soll? Strings integriert man am besten auf Sprachebene wie in C# und Java. Da kannst du hundert + hinschreiben und der Compiler macht einen StringBuilder variabler Länge mit append() für jedes + draus und am Ende holt er den String, macht immer 2 Objekte.

Wenn Strings fest in der Sprache eingebaut sind, dann sind sie doch noch unflexibler, als wenn sie als Klasse implementiert sind?!

Ja, man ist insofern unflexibler, als das alle die selbe String-Klasse fast verwenden müssen. Wo siehst du Nachteile? Du hast ja auch Strings in C++ eingebaut - aber C-Strings.

Artchi

size() von basic_string ist nur deshalb drin, falls man diesen als Container behandelt. Container haben nunmal size() als Funktion um die Elementanzahl abzufragen. Behandelt man basic_string nicht als Container, ist length() fachlich gesehen logischer.

Erhard Henkes

Verstehe das Problem nicht so recht?
time_t t = time(NULL);
string str(ctime(&t));
cout << str << endl;

Gute Idee, aber nicht so schnell!
... denn schon motzt MSVC++ 2005:

warning C4996: 'ctime' was declared deprecated
Consider using ctime_s instead.

Verwendet man ctime_s, das völlig anders aufgebaut ist, so hat man als ersten Parameter char* buffer.

Das gilt auch, wenn man es mit _strtime_s(...) versucht.

Von time_t und NULL will ich erst gar nicht anfangen.

Man ist selbst bei Neuerungen ständig umzingelt von char*. Daher benötigt C++ diesbezüglich unbedingt einen Neuanfang, oder man akzeptiert das char-Array und den Zeiger char* als die Repräsentation eines Strings auch in C++.

Artchi

Ja, MSVC8.0 meint es gut, aber ctime ist ISO-konform und ctime_s von MS im Alleingang eingeführt um C-Funktionen sicherer zu machen. Oder sind die Dinger mittlerweile ISO-C?

It should be noted that in this context, "deprecated" just means that a function's use is not recommended; it does not indicate that the function is scheduled to be removed from the CRT.

Du kannst die Deprecated Warnings ausschalten, mit _CRT_SECURE_NO_DEPRECATE .
http://msdn2.microsoft.com/en-us/library/8ef0s5kh.aspx

Man ist selbst bei Neuerungen ständig umzingelt von char*. Daher benötigt C++ diesbezüglich unbedingt einen Neuanfang, oder man akzeptiert das char-Array und den Zeiger char* als die Repräsentation eines Strings auch in C++.

Dann hast du meine letzten Postings nicht richtig gelesen... für dich nochmal:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1981.html

net 0

Erhard Henkes schrieb:

warning C4996: 'ctime' was declared deprecated
Consider using ctime_s instead.

ctime ist eigentlich harmlos, da braucht der m$ compiler nicht zu meckern. es ist nur nicht so richtig multithreading tauglich

Artchi schrieb:

Ja, MSVC8.0 meint es gut, aber ctime ist ISO-konform und ctime_s von MS im Alleingang eingeführt um C-Funktionen sicherer zu machen. Oder sind die Dinger mittlerweile ISO-C?

also mickrichweich hat die 'safer c library', oder wie das heisst, glaube ich, nicht erfunden. watcom z.b. hat die auch...

Erhard Henkes

Dann hast du meine letzten Postings nicht richtig gelesen...

Doch habe ich. Ich wollte nur zeigen, dass man sich drehen und wenden kann, wie man will, von irgendeiner Seite wird man immer "angemacht".

Dann hast du meine letzten Postings nicht richtig gelesen... für dich nochmal:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1981.html

Danke für den Link.

Erhard Henkes

... und ctime_s von MS im Alleingang eingeführt um C-Funktionen sicherer zu machen.

Diese Dinger geben dem immer noch üblichen C/C++-Mix jetzt wirklich den Rest.

net 0

Erhard Henkes schrieb:

Diese Dinger geben dem immer noch üblichen C/C++-Mix jetzt wirklich den Rest.

die sind ja eigentlich für 'c' gedacht. c++ user haben doch ihren stl/boost mischmasch und brauchen sowas nicht

Erhard Henkes

..

DrGreenthumb

Erhard Henkes schrieb:

Wie man mit Zeigern und C-casts Blödsinn treiben kann, zeigt dieses berühmte Beispiel:
// [ c++ objekt nach string gecastet ]
Mit std::string gelingt dies nicht.

Das Beispiel zeigt, wie man in C/++ direkten Zugriff auf den Speicher hat.
std::string schützt da überhaupt gar nicht.