C Hassen...

[THX 1138]

GPC schrieb:

1310-Logik schrieb:

GPC schrieb:

...
Okay, aber das ales ändert auch nichts an der Situation, die wir jetzt haben: Jedes Toolkit verwendet ne eigene String-Klasse. Dieser Fakt macht std::string praktisch nutzlos.
...

Das ist aber ein Problem der Toolkit Hersteller, nicht des Standards.

Hehe, das sehe ich anders. Daher, dass mir z.B. in gtkmm gar keine andere Möglichkeit bleibt, als Glib::ustring zu nutzen, fällt std::string automatisch aus der Wahl raus. Damit wird es zu einem Problem des Standards.

Was hätten die Toolkit Hersteller machen sollen? So lange mit der Weiterentwicklung der Toolkits warten, bis die Kerle beim Standardisierungskomitee endlich mal den Standard fertig kriegen?

MfG

GPC

Inzwischen hätten sie anständige castings bereitstellen können.
Was sollte das Standardkomitee tun? Alle die verschiedenen Stringklassen in den Standard aufnehmen?

[net 0]

ich wisst doch: c++ ist ein 'hund mit angenagelten beinen' und durch jede erweiterung, egal was da kommen mag, wird es nur noch schlimmer. das problem ist ja, dass altes zeug nicht abgeschafft wird und viel neues dazukommt. das bedeutet, dass in zukunft noch mehr kauderwelsch-codes das licht der welt erblicken werden. weniger erfahrene coder werden noch mehr verschiedene konzepte durcheinandermixen. aber naja, für foren wie dieses ist sowas ja nur gut

[Artchi]

GPC schrieb:

Na ja, ne String-Klasse ist ja jetzt nicht gerade das Mörderprojekt. Das hätten sie auch ohne freme Hilfe kurz selber bauen können.

Wer ist "sie"? Das ISO-Komitee? Das ISO-Komitee ist nur eine Entscheidungsinstanz und segnet nur Vorschläge ab. Alles was im Standard und TRs rein kommt, bedarf der Arbeit von draussen.

Wenn eine UTF-8-Stringklasse (wie ustring von gtkmm) nicht soooo aufwändig ist und nach 1998 entwickelt wurde, warum hat das gtkmm-Team nicht dem Aufruf des ISO-Komitees gefolgt, und netterweise aus selbstlosen Zweck diese Klasse für den nächsten Standard bereit gestellt? Das ist jetzt kein Vorwurf, da es sich um eine freiwillige Sache handelt, aber gtkmm hätte autom. eine Vormachtstellung, weil es bereits diesen String im Toolkit drin hätte.

Hehe, das sehe ich anders. Daher, dass mir z.B. in gtkmm gar keine andere Möglichkeit bleibt, als Glib::ustring zu nutzen, fällt std::string automatisch aus der Wahl raus. Damit wird es zu einem Problem des Standards.

Was hätten die Toolkit Hersteller machen sollen?

Ich denke gtkmm kam nach dem Standard raus? Dann hat also gtkmm hier gepatzt? Sie hätten ja auch für einen großen Zeichensatz std::wstring nehmen können. Intern hätten sie es autom. von und nach UTF-8 konvertieren können, wenn es um die Anzeige in Linux geht (Windows arbeitet intern sowieso mit 16bit breiten Zeichen, also wstring kompatibel).

Gibt es denn in gtkmm keinen ustring nach wstring-Konverter? Wenn nicht, müssten sie nur sowas anbieten, und das Problem wäre gelöst.

SmartWin++ hat es z.B. richtig gemacht: diese Lib ist recht neu, und sie benutzen einfach std::basic_string für ihre Zwecke. Und dann gibts halt Hilfsfunktionen, wie Unicode2Ascii. Das macht auch die Adobe Source Lib auch so:
http://opensource.adobe.com/group__asl__unicode.html

[Gast]

1310-Logik schrieb:

GPC schrieb:

...
Okay, aber das ales ändert auch nichts an der Situation, die wir jetzt haben: Jedes Toolkit verwendet ne eigene String-Klasse. Dieser Fakt macht std::string praktisch nutzlos.
...

Das ist aber ein Problem der Toolkit Hersteller, nicht des Standards.

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

[GCP]

Optimizer schrieb:

1310-Logik schrieb:

GPC schrieb:

...
Okay, aber das ales ändert auch nichts an der Situation, die wir jetzt haben: Jedes Toolkit verwendet ne eigene String-Klasse. Dieser Fakt macht std::string praktisch nutzlos.
...

Das ist aber ein Problem der Toolkit Hersteller, nicht des Standards.

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

Falsch, es ist eine extrem gute Stringklasse.

[Artchi]

GPC schrieb:

Mag schon sein, aber dann kann man sich natürlich fragen: Warum dauerte das so lange?

Warum C++ so lange brauchte, ums ISO zu werden? Das liegt nicht mal an C++ oder dem C++ Komitee selbst. ISO selbst (also die Organisation) hat strenge Regeln und Auflagen, damit etwas überhaupt ein ISO-Prozess wird. Du kannst nicht heute sagen: "so, ich will C++ zum ISO machen und morgen 16 Uhr hat das Ding dann eine ISO-Nummer." Da wird schon alleine ISO dir Auflagen machen, damit du überhaupt den Prozess der Standardisierung starten darfst. Und dann kommt erst der eigentliche Prozess der diesen Regeln unterliegt. Was meinst du, warum z.B. Sun Microsystems es 1998 aufgegeben hat Java zum ISO-Standard zu machen nachdem sie bei erscheinen von Java versuchten? Wohlgemerkt: sie haben es schon mal versucht und haben es nach ein paar Jahren aufgegeben! Auch an ECMA sind sie im Jahr 2000 gescheitert bzw. waren nach einem ersten ausgerarbeiteten Vorschlag ausgestiegen, obwohl ECMA viel liberaler als ISO ist.

Was meinst du, warum C#, .NET, Javascript (ECMAscript), C++/CLI u.a. erst und nur bei ECMA standardisiert wurden? Weil ISO viel strenger ist.

Wenn man das alles bedenkt, dann sollte man sich hochachtungsvoll vor den ganzen Leuten die sich bei ISO-C++ 1998 zusammen gerauft haben verbeugen! Das Vorhaben "ISO-C++" hätte auch politisch in die Hose gehen können, so wie bei ISO-Java. Denn im ISO-C++-Komitee sitzen Firmen wie MS, HP, IBM, Dinkumware usw. Eigentlich ein Wunder das die an C++0x noch abstimmen.

Und wir dürfen auf ISO C++ 0x gespannt sein, vieles ist schon geschafft, einiges muß noch veranschiedet werden. Die Thread-Lib hats bis heute nicht geschafft, im Oktober 2006 muß es endgültig klappen.

[Gast]

C# 1.0 ist schon ISO-standardisiert. Das unterstreicht eigentlich sehr gut, was du sagst. Bald ist C# 3.0 endgültig ECMA-Standard, und C# 2.0 hat's noch nicht mal geschafft, ISO-Standard zu werden.

[Artchi]

Das C# 1.0 schon ISO-Standard ist, hab ich nicht gewusst. Gibts ne Nummer/Link dafür? Würde mich schon interessieren.

[Gast]

Laut Wikipedia: ISO/IEC 23270
Beim Compiler gibt's auch den Schalter ISO-1, wenn man die alte Sprachversion will.

[Erhard Henkes]

Für Einsteiger muss C++ in gewisser Weise ein Horror sein. Die Einarbeitung dauert ewig, und überall lauern Fehlermöglichkeiten und Alternativen. Zusätzlich existiert keine breit akzeptierte Plattform-übergreifende GUI. Als wesentliche Alternativen locken dann java und c#. Kein guter Zustand.

[THX 1138]

Ich wär dafür, das die Improved Console in den Standard kommt

[Artchi]

Erhard Henkes schrieb:

Für Einsteiger muss C++ in gewisser Weise ein Horror sein. Die Einarbeitung dauert ewig, und überall lauern Fehlermöglichkeiten und Alternativen. Zusätzlich existiert keine breit akzeptierte Plattform-übergreifende GUI. Als wesentliche Alternativen locken dann java und c#. Kein guter Zustand.

Wenn nicht andauernd irgendwelche Idioten sagen würden "Ich will keine externe Lib, weil sonst kein Standard!" wäre schon einiges einfacher. Wie oft liest man im C++-Forum, das jemand kein Boost einsetzen will, weil er sich "abhängig" macht. Da frage ich mich, wie kommt man überhaupt mit der Standard-Lib aus? Das geht doch überhaupt nicht.

So, zum Thema GUI: welche ISO- oder ECMA-Sprache hat denn eine GUI? Mir ist keine bekannt! Selbst Sun wollte damals ihr Java OHNE GUI standardisieren, und sind selbst daran gescheitert. WIndowsFOrms sind auch nicht im ECMA-Standard drin.

Warum muß eine GUI auch in den ISO rein? Swing, AWT und SWT sind auch kein ISO, so rum muß man das auch mal sehen. Übrigens, für Java gibts komischerweise auch mehrere GUI-Libs und stört auch niemanden.

Und selbst wenn man versuchen sollte in den Standard eine GUI reinzubringen: welche sollte es denn sein? Qt? gtkmm? fltk? Oder eine noch nicht implementierte? Das wäre nicht nur eine politische Entscheidung, sondern auch noch eine Kostenentscheidung! Wer das letzte C++-Komitee-Meeting in Berlin verfolgt hat, weiss das viele Mitglieder z.B. die Special-Math-Functions aus dem TR1-Vorschlag endgültig abgelehnt haben. Warum? Wegen Kostengründen, die die Library- und Compiler-Hersteller nicht auf sich nehmen wollten! Und im KOmitee sitzen nunmal Compiler- und Lib-Hersteller wie MS, HP, IBM, Dinkumware u.a. Firmen, die den ISO-Standard absegnen.

Jeder hier aus dem Forum kann gerne einen Proposal für den nächsten TR3 (den es sicherlich geben wird) schreiben, in dem er eine GUI-Lib dokumentiert und vorschlägt (die muß nicht mal implementiert sein!). Aber er kann sich sicher sein, das die LWG (Library Working Group des ISO-Komitees, zu dieser gerhört unter anderem Dinkumware) diesen Vorchlag aus Kostengründen ablehnen wird.

Weil keiner der Hersteller die Kosten auf sich nehmen will. Wir wissen ja, wie lange es gedauert hat, bis 99%ige ISO-konforme Compiler bekommen habn. "export" ist praktisch fast wieder aus dem Standard rausgeflgen, weil kein Hersteller es auf sich nehmen wollte. Dieser Cameou-Compiler (wie wid der geschrieben?) hat das zwar drin, aber der Hersteller hat was vom 6 Mannjahren Entwicklung oder so nur für die Implementierung von export gesagt.

Also, eine GUI werden wir im ISO-STandard nicht sehen, außer es gibt einen Geldgeber, der selbstlos ist und allen Compilerherstellern diese Lib kostenlos schenkt oder für einen symbolischen Preis verkauft.

[.filmor]

Optimizer schrieb:

1310-Logik schrieb:

GPC schrieb:

...
Okay, aber das ales ändert auch nichts an der Situation, die wir jetzt haben: Jedes Toolkit verwendet ne eigene String-Klasse. Dieser Fakt macht std::string praktisch nutzlos.
...

Das ist aber ein Problem der Toolkit Hersteller, nicht des Standards.

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).

[Artchi]

Achja, ein Tip für Leute die gerne am C++ Standard mit abstimmen wollen: jeder darf sich ein Stimmrecht für die Komitee-Meetings kaufen. Das geht indirekt über eine ISO-Mitgliedschaft (ich glaub es geht auch über eine DIN-Mitgliedschaft) für jährlich ca. 300 US$. Also, theoretisch müssen nur genug Pro-GUI-Fans sich eine Mitgliedschaft kaufen und bei einem eingereichten GUI-Proposal bei der Abstimmung mit einem "Ja" stimmen. Und schon hätte man die bisherigen Mitglieder ausgestochen und eine GUI im C++ Standard.

Nur eine Idee.

[GPC]

Artchi schrieb:

GPC schrieb:

Na ja, ne String-Klasse ist ja jetzt nicht gerade das Mörderprojekt. Das hätten sie auch ohne freme Hilfe kurz selber bauen können.

Wer ist "sie"? Das ISO-Komitee? Das ISO-Komitee ist nur eine Entscheidungsinstanz und segnet nur Vorschläge ab. Alles was im Standard und TRs rein kommt, bedarf der Arbeit von draussen.

HP z.B.? Die haben große Teile der STL entworfen.

Artchi schrieb:

Hehe, das sehe ich anders. Daher, dass mir z.B. in gtkmm gar keine andere Möglichkeit bleibt, als Glib::ustring zu nutzen, fällt std::string automatisch aus der Wahl raus. Damit wird es zu einem Problem des Standards.

Was hätten die Toolkit Hersteller machen sollen?

Ich denke gtkmm kam nach dem Standard raus? Dann hat also gtkmm hier gepatzt?

Ansichtssache, aber tendentiell ja. Problem: gtk+ verwendet intern schon die strings aus der glib, gtkmm wrappt gtk+. Daher fällt die Wahl nicht schwer.

Gibt es denn in gtkmm keinen ustring nach wstring-Konverter? Wenn nicht, müssten sie nur sowas anbieten, und das Problem wäre gelöst.

Du kannst mittels locate_to_utf8 und umgekehrt konvertieren.

Artchi schrieb:

Was meinst du, warum C#, .NET, Javascript (ECMAscript), C++/CLI u.a. erst und nur bei ECMA standardisiert wurden? Weil ISO viel strenger ist.

Die ISO ist ein riesen Haufen voll Bürokratie und Regelreitern. Ein Standard ist schön, weil dann hat man ein Dokument, auf das man sich verlassen kann, jedoch macht das die Geschichte ungefähr so flexibel wie die Pyramiden in Ägypten. Die bringt auch keiner so schnell von A nach B.

Und wir dürfen auf ISO C++ 0x gespannt sein, vieles ist schon geschafft, einiges muß noch veranschiedet werden. Die Thread-Lib hats bis heute nicht geschafft, im Oktober 2006 muß es endgültig klappen.

Okay, also wenn ich das hier alles richtig verstehe, sind wir froh, dass C++ im Jahre 2006 Funktionen zur stdlib hinzukriegt, die andere Sprachen schon seit mehreren Jahren drin haben (C# von Anfang an, Java auch, Python, Ruby...) ? Klar, da kann man sich natürlich freuen, aber ich finde eher man sollte sich Gedanken machen, wie man diesen Vorgang endlich mal beschleunigen kann, damit's nicht noch mal 10 Jahre dauert, bis das nächste sinnvolle Feature in den Standard reinkommt.

Erhard Henkes schrieb:

Für Einsteiger muss C++ in gewisser Weise ein Horror sein. Die Einarbeitung dauert ewig, und überall lauern Fehlermöglichkeiten und Alternativen. Zusätzlich existiert keine breit akzeptierte Plattform-übergreifende GUI. Als wesentliche Alternativen locken dann java und c#. Kein guter Zustand.

FULL ACK.

Artchi schrieb:

Wenn nicht andauernd irgendwelche Idioten sagen würden "Ich will keine externe Lib, weil sonst kein Standard!" wäre schon einiges einfacher. Wie oft liest man im C++-Forum, das jemand kein Boost einsetzen will, weil er sich "abhängig" macht. Da frage ich mich, wie kommt man überhaupt mit der Standard-Lib aus? Das geht doch überhaupt nicht.

Das Problem ist doch simpel: Viele verschiedene Libs auf vielen verschiedenen Plattformen schaffen unnötig inhomogene Umgebungen und Aufwand, sollte eine Lib auf Plattform X doch nicht so super funktionieren. Boost deckt schon viel ab und man muss echt dankbar für diese wirklich tolle Lib sein. Aber das zeigt doch deutlich, dass die C++ stdlib einfach zu schmal ist.

Artchi schrieb:

Warum muß eine GUI auch in den ISO rein? Swing, AWT und SWT sind auch kein ISO, so rum muß man das auch mal sehen. Übrigens, für Java gibts komischerweise auch mehrere GUI-Libs und stört auch niemanden.

Richtig. Nur gibt's für C++ ungefähr 10x so viele GUI Toolkits wie für Java. V.a. sind viele von einem modernen C++ Standpunkt einfach nicht zu gebrauchen.

Versteht mich nicht falsch: Ich mag C++ als Sprache. Die stdlib reißt aber echt keinen um. Kein Wunder dass C++ so n mieses Image hat.

MfG

GPC

[Artchi]

GPC schrieb:

Die ISO ist ein riesen Haufen voll Bürokratie und Regelreitern. Ein Standard ist schön, weil dann hat man ein Dokument, auf das man sich verlassen kann, jedoch macht das die Geschichte ungefähr so flexibel wie die Pyramiden in Ägypten. Die bringt auch keiner so schnell von A nach B.

...

Okay, also wenn ich das hier alles richtig verstehe, sind wir froh, dass C++ im Jahre 2006 Funktionen zur stdlib hinzukriegt, die andere Sprachen schon seit mehreren Jahren drin haben (C# von Anfang an, Java auch, Python, Ruby...) ? Klar, da kann man sich natürlich freuen, aber ich finde eher man sollte sich Gedanken machen, wie man diesen Vorgang endlich mal beschleunigen kann, damit's nicht noch mal 10 Jahre dauert, bis das nächste sinnvolle Feature in den Standard reinkommt.

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. 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!"

Gut, jetzt müssen noch die Compilerhersteller nachziehen, aber MS hatte auf einer MSDN-Konferrenz angekündigt, TR1 mit VC++ auszuliefern.

So, wegen den ellen langen Zeiten: der Einsendeschluss für den TR2 (aha!) ist im Oktober 2006. Da wird zwar noch nicht verabschiedet, aber zumindest wird sich ab dann das Komitee mit TR2 beschäftigen und die Vorschläge werden im Oktober von ihren jeweiligen Vorschlags-Inhabern dem Komitee präsentiert.

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. WIchtig ist es halt, das die C++ Community (bisher eigentlich nur die Boost Community) Vorschläge einreicht. Z.b. hat das Komitee einen XML-Lib-Vorschlag gewünscht. Ich glaub, da ist leider bisher nichts passier. Aber das Komitee will C++ mit den nötigen Basics ausstatten, aber es muß von der Comminity kommen.

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

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.

[Gast]

.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.