Das ist das Ende von C++!

Artchi schrieb:

Optimizer schrieb:

Während es für C++ zahllose String-Klassen gibt und keine so richtig in der Praxis Standard ist, hast du in D die Situation, dass jeder die eine String-Klasse benutzt, schon allein indem er ein Literal hinschreibt.

Gerade du, der hier nun ein alter Hase im Forum ist, hätte ich eher zugetraut, das ihm bewusst ist, warum es soviele String-Klassen gibt. Schade.

Die vielen String-Klassen von Qt, MFC, wx usw. sind doch vor 1998 entstanden. Deshalb hat doch jeder seinen eigenen String gebastelt, weil es keine C++-Norm gab und man nicht davon ausgehen konnte, das es eine String-Klasse beim Compiler gab.

Na und, das ändert nichts daran, dass das unheimlich nervt. Außerdem sind die std::(w)strings schon sehr mager, wenn man sie mit dem Java String vergleicht.

Die smilies weg, nicht die BBCodes

Artchi

Was nervt dich? Die Standard-Strings? Oder die vielen Strings aus anderen Libs? Benutze dann halt eine Lib, die Standard-Strings verwendet. Dann nervt es nicht mehr. Wenn mich an einem Auto was grundlägend nervt, kauf ich das Auto nicht.

Die Boost-Leute schaffen es komischerweise in ihrer gesamtheit die Standard-Strings zu benutzen. Wenn Qt, WX u.a. es nicht schaffen auf Standard-Strings zu switchen, kann ISO-C++ nichts dafür. Beschwert euch doch bei den Urhebern von Qt, WX usw. Sollen sie halt endlich umbauen. Aber natürlich macht Qt das nicht, weil dann würden sie einen Abhängigkeitsgrund weniger haben.

MS hat ihre gesamte Win32-API auf const wchar_t* umgebaut. Kann ich problemlos std::wstring benutzen und wenn ich mal einen Parameter an Win32 übergebe, mache ich einfach c_str(), fertig. Es geht, wenn der API-Urheber es nur will.

Artchi schrieb:

Was nervt dich? Die Standard-Strings? Oder die vielen Strings aus anderen Libs?

Eigentlich beides.

Benutze dann halt eine Lib, die Standard-Strings verwendet. Dann nervt es nicht mehr. Wenn mich an einem Auto was grundlägend nervt, kauf ich das Auto nicht.

Manche Arbeitgeber woll nicht, dass man dauernd neue Libs einschleppt.

MS hat ihre gesamte Win32-API auf const wchar_t* umgebaut. Kann ich problemlos std::wstring benutzen und wenn ich mal einen Parameter an Win32 übergebe, mache ich einfach c_str(), fertig. Es geht, wenn der API-Urheber es nur will.

Das finde ich ja auch so toll, das man den "guten" std::string wieder zum "bösen" char* macht.
Sogar die STL ist so inkonsequent

basic_fstream (const char *__s, ios_base::openmode __mode=ios_base::in|ios_base::out)

TOLL!!!

Gregor

Artchi schrieb:

Wenn Qt, WX u.a. es nicht schaffen auf Standard-Strings zu switchen, kann ISO-C++ nichts dafür.

Ich denke nicht, dass man die Infrastruktur rund um eine Sprache bei der Betrachtung der Sprache ignorieren sollte. Das geht an der Realität vorbei. Es ist eine bewusste Entscheidung, bei C++ nur eine relativ kleine Standardbibliothek zu haben und das ist ein zentrales Problem von C++. Genau das führt dazu, dass derartige Inhomogenitäten bei der Verwendung üblicher Werkzeuge entstehen.

Du meinst, ISO-C++ ist nicht an solchen Inhomogenitäten schuld? Ok, so kann man das natürlich sehen. Wenn man den eigenen Verantwortungsbereich derart stark einschränkt, dass man sich für fast gar nichts zuständig fühlt, kann man auch an fast gar nichts schuld sein. Ich sehe eine umfassende Standardbibliothek aber durchaus als etwas an, für das der Standard verantwortlich sein sollte.

BTW: Genau aus dem gleichen Grund wird D nie irgendeine Relevanz bekommen: Da fehlt einfach eine umfassende Standardbibliothek.

Artchi

KennerDesProblems schrieb:

Manche Arbeitgeber woll nicht, dass man dauernd neue Libs einschleppt.

Ja, und? Was kann die C++ Norm dafür? Die anderen sind immer schuld? Wir können auch kein Java 1.5 oder 1.6 benutzen, weil unser Kunde leider IBM Java WebSpehere mit 1.4 vorschreibt. Weil IBM leider noch keinen WebSphere mit Java 1.5 rausgebracht hat. So, und nun? Ist jetzt Java EE inkonsistent? Nein, unser Kunde und IBM ist schuld das wir immer noch auf Java 1.4 rumkurken müssen. Ich gebe aber nicht SUN oder Java die Schuld! Weil ich sehr wohl zwischen Java-Spec und Implementierung/Produkt unterscheiden kann.

KennerDesProblems schrieb:

MS hat ihre gesamte Win32-API auf const wchar_t* umgebaut. Kann ich problemlos std::wstring benutzen und wenn ich mal einen Parameter an Win32 übergebe, mache ich einfach c_str(), fertig. Es geht, wenn der API-Urheber es nur will.

Das finde ich ja auch so toll, das man den "guten" std::string wieder zum "bösen" char* macht.
Sogar die STL ist so inkonsequent

Das kannst du vielleicht nicht wissen, aber die Win32-API ist eine C-API, nichts C++. Deshalb kann da schlecht eine String-Klasse benutzt werden. Aber ist ok. Das Beispiel habe ich nur aufgeführt, um zu zeigen, das eine API sehr wohl von einem Typ (in dem Fall char) auf einen aktuelleren/sinnvolleren Typ (in dem Fall wchar_t) umgestellt werden kann. Das C keine Klassen kennt, hat ja nichts mit C++ zu tun.

KennerDesProblems schrieb:

basic_fstream (const char *__s, ios_base::openmode __mode=ios_base::in|ios_base::out)

TOLL!!!

Ja, das stimmt allerdings. Das ist ein Defizit im noch aktuellen C++ Standard. Es sagt keiner, das C++ die perfekte Sprache ist.

Um dich aber zu beruhigen, in der C++2009-Norm werden solche Sachen auf die String-Klassen wahrscheinlich umgebaut (ein Proposal liegt dem Komitee vor). In der ISO-C++-TR2 wird es wahrscheinlich sogar eine path-Klasse geben. Leider ist das Thema TR2 erstmal auf 2009 verschoben, da sich das Komitee bis 2009 voll auf die neue ISO-C++-Norm konzentrieren will. Also, es wird an der C++-Spec weiter gearbeitet um diese zu verbessern.

Wenn C++-Benutzer diese Features nicht nutzen, ist das nicht die Schuld der Norm. Siehe auch IBM WebSphere.

Simon2

Hi,

also wenn ich sehe, dass bei uns immer noch Cobol-Programmierer eingestellt werden, wage ich zu bezweifeln, dass es überhaupt das "Ende einer Sprache" gibt.
Die Frage ist eher, welche Nische(n) eine neue Sprache besetzen (und ggf. einer anderen Sprache abknöpfen) wird.

Gruß,

Simon2.

Artchi

Gregor schrieb:

Artchi schrieb:

Wenn Qt, WX u.a. es nicht schaffen auf Standard-Strings zu switchen, kann ISO-C++ nichts dafür.

Ich denke nicht, dass man die Infrastruktur rund um eine Sprache bei der Betrachtung der Sprache ignorieren sollte. Das geht an der Realität vorbei. Es ist eine bewusste Entscheidung, bei C++ nur eine relativ kleine Standardbibliothek zu haben und das ist ein zentrales Problem von C++. Genau das führt dazu, dass derartige Inhomogenitäten bei der Verwendung üblicher Werkzeuge entstehen.

Du meinst, ISO-C++ ist nicht an solchen Inhomogenitäten schuld? Ok, so kann man das natürlich sehen. Wenn man den eigenen Verantwortungsbereich derart stark einschränkt, dass man sich für fast gar nichts zuständig fühlt, kann man auch an fast gar nichts schuld sein. Ich sehe eine umfassende Standardbibliothek aber durchaus als etwas an, für das der Standard verantwortlich sein sollte.

Ja, richtig. Ich sage, das es eine Norm gibt, und diese umgesetzt werden kann. Wenn ein C++ Compiler-Hersteller mir als Kunden keinen guten Compiler liefert (dazu gehört auch eine gewisse Einhaltung der Norm), kann ich mich gegen dieses Produkt entscheiden und ein besseres wählen. Genau das gleiche sehe ich bei Libraries, wie Qt. Wer Qt einsetzt und dafür auch bezahlt, hat bewusst die QString-Klasse in Kauf genommen. Ergo hat er sich gegen ein Produkt entschieden, welches wahrscheinlich Standard-Strings benutzt.

Nehmen wir SmartWin++, eine moderne C++-GUI-Lib für Windows. Diese benutzt konsequent std::basic_string. Warum? Weil diese Library erst nach der ISO-C++-Norm entwickelt wurde. Man hat die verfügbare Standardlib-Klassen genutzt. Finde ich gut! Ich sehe auch andere neue Libraries, die immer mehr Standard-Klassen einsetzen und z.B. auf eigene Strings verzichten. Die Infrastruktur ist ja da.

Ich muß hier auf Arbeit z.B. mit Java 1.4 arbeiten, weil leider IBM noch keinen WebSphere mit Java 1.5 rausgebracht hat. Aber weißt du auf wen wir fluchen? Nicht Java oder Sun. Nein, sondern auf IBM und unseren Kunden der IBM-Produkte einsetzt.

Nach deiner C++-Vorstellung, wäre also Java schuld, das einige Java-Enterprise-Hersteller nicht den kompletten aktuellen Java-Spec unterstützen??? Ich kann hier viele Sachen nicht umsetzen und einsetzen, wie ich es in Java 1.5 oder gar 1.6 machen könnte/wollte. Ich muß mich immer mit externen Lösungen (Libs) bedienen. Das gleiche kann man auch auf Firmen wie Trolltech übertragen. Sie gehen nicht mit der aktuellen C++-Spec.

Was die Mini-Standardlib angeht. Wer sagt dir denn, das das C++-Komitee eine Mini-Lib haben will? Im ernst, ich habe dergleichen noch nie offiziell gehört/gelesen. Ganz im Gegenteil, das Komitee sucht vergeblich Leute, die Library-Vorschläge einreichen! Es wurde vor zwei Jahren offiziell nochmal vom Komitee ein Aufruf gestartet, das die Community bitte Vorschläge für XML, Netzwerk, Unicode und andere Libraries einreicht. Das einzige was bisher nicht eingereicht wurde, sind XML-Lib-Vorschläge.

Das was man als C++-Nutzer nicht erwarten kann, ist eine GUI-Lib, obwohl Bjarne Stroustrup offiziell sich sowas wünscht. Aber er sagt, das es hier keine Lösung geben kann, die die C++-Community befriedigen könnte. Mein Meinung: Javas Swing zeigt es ebenfalls, da es auch dort mehrere GUI-Libs (SWT z.B.) gibt. Weil Swing nicht jedem Anspruch/Vorstellungen gerecht werden kann (obwohl mir pers. Swing seeehr gut gefällt).

Clw

Bevor jetzt irgendwelche Spekulationen aufkommen: In D gibt es auch keine string-Klasse wie in Java oder C# (zumindest keine standardisierte). String Literale sind vom Typ char[] ("..."c), wchar[] ("..."w), dchar[] ("..."d). Diese sind als dynamische Arrays implementiert und lassen sich genauso behandeln, wie alle dynamischen Arrays. Ein String-Literal muss nicht unbedingt ein c, w oder d als Typmarker haben, sondern sein Typ wird automatisch hergeleitet, wenn möglich

nep

Du hast schon recht mit dem was du sagst Artchi. Das ändert aber nix daran, dass es in der Praxis eben nun mal häufig nervig ist z.B. verschiedene Strings benutzen zu müssen. Und gerade du müsstest doch wissen, dass es gerade in der Praxis eben nicht so einfach ist, einfach mal zu sagen "Ne Lib xyz benutzt keinen std::string, also benutz ich die auch nicht". Oft hat man doch gar keine Wahl und ist an irgendwelche Vorgaben gebunden. Oder was bringt mir z.B. eine Lib die sich meinetwegen an den Standard hält, aber nicht alles kann was ich benötige?
Das ist in Java/C# eben nun mal einfach besser gelöst (oder anders ausgedrückt: produktiver). Da muss ich mich z.B. nicht um die verschiedensten String-Klassen kümmern.

Artchi

@nep! Ja, natürlich weiß ich selber das es nicht so einfach ist. Ich arbeite täglich 8 Std. beruflich nicht mit dem was ich gerne hätte (z.B. immer das aktuellste Java). Wenn jemand Qt oder WX benutzt ist er natürlich in einer Zwickmühle. Und natürlich ist das die Realität. Nur frage ich mich, ob es das besser macht, wenn man auf die C++-Norm meckert? Es bringt nichts!

Genauso bringt es nichts, wenn ich in ein Java-Forum gehe, und dort über Java herziehe, weil ich IBMs WebSphere einsetzen muß. Dann sagen mir die Java-Forums-Members: "Wechsel doch den ApplikationServer, z.B. auf JBoss." Oder "Beschwer dich bei IBM!" Keiner Würde sagen "Ja, das ist leider die Realität. Java ist schlecht." Aber ich als C++-User soll von Java- und D-Fans mir anhören, das C++ schuld ist? Da wird doch mit zweierlei Maß gemessen. Das ist eigentlich das, was mich auf die Palme bringt. Fakten bringen mich nicht auf die Palme, nur Falschaussagen und vermischung von Fakten.

nep

Ich finde dein Beispiel mit dem WebSphere hat aber eine ganz andere Dimension. Das ist etwas spezielles was so mit Java ja erst mal wenig zu tun hat, ausser dass es eben mit Java geschrieben wurde. Mit Strings im Gegenzug wirst du eigentlich immer konfrontiert werden, egal was du machst. Es geht hierbei eben um viel grundlegendere Dinge, als z.B. ein Application Server.
Versteh mich nicht falsch, ich will jetzt auch nicht sagen "C++ ist scheisse", das ist es an sich ja auch nicht. Nur bringt einem das auch nicht viel, wenn man dann in der alltäglichen Praxis doch meistens eben mit genau solchen Problemen konfrontiert wird

Artchi

nep schrieb:

Das ist in Java/C# eben nun mal einfach besser gelöst (oder anders ausgedrückt: produktiver). Da muss ich mich z.B. nicht um die verschiedensten String-Klassen kümmern.

Man sollte aber nicht verheimlichen, das es auch in Java mittlerweile drei String-Klassen gibt, weil nicht eine einzige alle Anforderungen auf einmal abdeckt. Mittlerweile sind drei dabei:

String
StringBuilder
StringBuffer

Je nachdem, was ich gerade braucht, muß ich mir eine Aussuchen. Das einzige was in Java wirklich kosistenter ist, ist das die parameter bei Methoden String erwarten. Aber wie gesagt, hier könnten Qt usw. durch Überladung sich bessern. Beispiel ist der QPushButton. Warum gibts keine Überladung, z.B. so:

QPushButton::QPushButton ( const QString & text, QWidget * parent = 0 );
QPushButton::QPushButton ( const std::wstring & text, QWidget * parent = 0 );

Die Implementierung des 2. Ctors könnte dann eine Konvertierung nach QString machen. Mir als Benutzer der QPushButton-Klasse wäre es egal, was intern passiert. Ich könnte aber direkt meinen wstring übergeben.

MS hat das in Windows ähnlich gelöst (Pseudo-Code!):

void MessageBox (const char *text,    const char *title, ...);    // ASCII-Variante
void MessageBoxW(const wchar_t *text, const wchar_t *title, ...); // Unicode-Variante

Der Clou ist, das die MessageBox-Implementierung eigentlich MessageBoxW aufruft, und für den ASCII-User die Konvertierung nach Unicode übernimmt. Aber MS hat sich zumindest die Mühe gemacht, beide User zu bedienen. Sie nutzen also die C-Norm aus.

Das erwarte ich von den großen C++-Frameworks auch. Leider machen die das nicht, um die User abhängig von ihren Klassen zu machen. (so kommt es mir zumindest vor)

nep

Artchi schrieb:

nep schrieb:

Das ist in Java/C# eben nun mal einfach besser gelöst (oder anders ausgedrückt: produktiver). Da muss ich mich z.B. nicht um die verschiedensten String-Klassen kümmern.

Man sollte aber nicht verheimlichen, das es auch in Java mittlerweile drei String-Klassen gibt, weil nicht eine einzige alle Anforderungen auf einmal abdeckt. Mittlerweile sind drei dabei:

String
StringBuilder
StringBuffer

Je nachdem, was ich gerade braucht, muß ich mir eine Aussuchen. Das einzige was in Java wirklich kosistenter ist, ist das die parameter bei Methoden String erwarten

Naja das ist aber kein Vergleich zu C++. Es wird letztendlich ja trotzdem immer String benutzt. Nur wenn du halt nen großen String aus vielen Verkettungen zusammenbaust, dann benutzt du halt z.B. StringBuffer da das performanter ist als String(da dieser Immutable ist). Und daraus kannst ja dann sofort wieder einen String kriegen. Also das ist schon schön flüssig und einfach zu benutzen. Naja vielleicht ist das auch Ansichtssache.

Artchi schrieb:

Das erwarte ich von den großen C++-Frameworks auch. Leider machen die das nicht, um die User abhängig von ihren Klassen zu machen.

Ja, eben und das ist ja das Problem. Das bringt mir ja in der Praxis trotzdem nichts, wenn zwar C++ an sich dafür nichts kann, aber die Lib-Hersteller trotzdem alle ihr eigenes Süppchen kochen. Davon kann ich mir auch nichts kaufen.

rüdiger schrieb:

Optimizer schrieb:

Darum geht es doch nicht. Der Unterschied zu D ist, dass in C++ die Standard C++-String Klasse nicht als Sprachmittel zur Verfügung steht. Wenn du schreibst "Blubb", dann ist das ein char*.

Im Vergleich dazu ist in D, Java, C# und anderen Sprachen, die Strings auf Sprachebene integrieren, ein String-Literal wirklich vom Typ String. Zum Beispiel ist dadurch sowas wie "blubblubb".ToUpper() möglich. Klar, kann man darüber streiten, wie gigantisch der Vorteil ist. Auf Sprachebene erreicht man halt eine bessere Integration. Während es für C++ zahllose String-Klassen gibt und keine so richtig in der Praxis Standard ist, hast du in D die Situation, dass jeder die eine String-Klasse benutzt, schon allein indem er ein Literal hinschreibt.

Wenn man "foo" zu einem Objekt einer Klasse String macht, dann muss man aber einige "besondere" Klassen einführen. Das Widerspricht eben dem C++-Ansatz und würde die Sprache verkomplizieren. Ich meine eine Freestanding-Implementierung, die kein std::basic_string anbietet, macht dies ja aus einem gewissen Grund. Da macht es natürlich kein Sinn, das man sagt "Nö, eine Freestanding-Implementierung" darf das nicht.

Außerdem gibt es ja unterschiedliche String-Klassen, weil es eben nicht so leicht ist eine String-Klasse zu entwerfen. Die std::basic_string-Klasse ist ja alles andere als perfekt. Warum glauben gerade die D-Leute, die perfekte String-Klasse entworfen zu haben? (Wobei ich dazu sagen muss, das viele Probleme einer String-Klasse wohl für US-Amerikaner eh ziemlich abstrakt wirken dürften, mit denen sich jemand in Deutschland oder gar China rumprökeln muss.)

Der gleiche Grund ist es ja auch, warum man in C++ kein foreach hat, weil man damit eben die Trennung zwischen Sprache und Bibliothek aufheben müsste und ich halte viele Verbesserungen an C++ für sinnvoll. Aber sicher keine, die die Bibliothek mit der Sprache verwurschteln.

Ich denke mal nicht, dass die Entwickler von D denken, die perfekte String-Klasse entworfen zu haben. Ich würde mal vermuten, dass sie besser als std::string ist, aber den eigentlichen Vorteil sehe ich darin, dass dafür ein Sprachmittel zur Verfügung steht.

Ich verstehe den Ansatz von C++, möglichst viel auf Bibliotheksebene zu machen um die Sprache davon unabhängig zu haben. C++ soll irgendwie alles geil können, man soll damit Programme schreiben können oder sich auch selber mit Makros, umfangreicher Operator-Überladung und eben nicht fertigem foreach und Strings in der Sprache unglaublich erweitern und anpassen können. Ich denke wir beide haben da eine grundverschiedene Meinung. Ich denke, auf Sprachebene sind viele Dinge besser realisierbar, du befürchtest anscheinend, dass darunter die Vielseitigkeit einer Sprache leidet. Ich halte extrem vielseitige Sprachen aber für schlecht.

Skriptsprachen existieren auch oft nur aus dem simplen Grund, weil auf Sprachebene alles besser integrierbar ist. Nimm als Beispiel JSP. Es ist halt nicht toll, wenn man eine Webseite machen will und dann von irgendwelchen Servlet-Klassen ständig ableitet und Code schreibt -> man entwickelt für diesen Zweck ne eigene Sprache. Sinnvoll. Du dagegen argumentierst, die Sprache solle möglichst wenig eingebaut haben, damit sie vielseitig ist. Was ich nicht für sinnvoll halte, da sie dann zwar alles kann, aber nichts gescheit. C++ kann kein gescheites foreach und keine gescheiten Strings.

Wenn du verschiedene Bibliotheken nutzt, die ihre eigenen String-Klassen mitbringen bist du immer irgendwie dabei, über char[] hin und her zu konvertieren. Oder bastel doch mal ein foreach. Es wird niemals genau so geil sein wie

foreach( int myInt in myIntList )
    sum += myInt;

Und mit foreach ist es das selbe wie mit String. Jeder bastelt sich sein eigenes...

... und würde die Sprache verkomplizieren.

Nein, die Grammatik der Sprache wäre gleich kompliziert und der Umgang mit der Sprache wäre ganz erheblich einfacher. Wie man wirklich gut an Sprachen sehen kann, die eingebaute Strings und foreach haben.

Artchi schrieb:

Man sollte aber nicht verheimlichen, das es auch in Java mittlerweile drei String-Klassen gibt, weil nicht eine einzige alle Anforderungen auf einmal abdeckt. Mittlerweile sind drei dabei:

String
StringBuilder
StringBuffer

Der Unterschied ist: Diese drei Klassen sind für einen jeweils eigenen Verwendungszweck geschaffen. Der Grund, warum es diese verschiedene Klassen gibt ist also, weil mal die eine geeigneter ist, mal die andere.

Der Grund, warum es für C++ dreihundert verschiedene String-Klassen gibt ist nicht so toll. Und das Ergebnis ist auch, dass es hundert Klassen gibt, die sich für den einen Zweck gut eignen, hundert, die sich für den anderen Zweck gut eignen.

Artchi

Optimizer schrieb:

Der Unterschied ist: Diese drei Klassen sind für einen jeweils eigenen Verwendungszweck geschaffen. Der Grund, warum es diese verschiedene Klassen gibt ist also, weil mal die eine geeigneter ist, mal die andere.

Ehm, und wo ist der Unterschied zu dem hier:

Optimizer schrieb:

Der Grund, warum es für C++ dreihundert verschiedene String-Klassen gibt ist nicht so toll. Und das Ergebnis ist auch, dass es hundert Klassen gibt, die sich für den einen Zweck gut eignen, hundert, die sich für den anderen Zweck gut eignen.

Du sagst es selber! Es gibt jeweils mehrere String-Klassen weil jede einen anderen Zweck erfüllt. Nur bei C++ ist das schlechter bei Java ist das i.O.? Oder sind nur 3 vs. 10 ein Unterschied? (hunderte sind es kaum, es gibt gerade mal eine Hand voll bedeutender String-Klassen im C++-Umfeld).

Ich liebe diesen C++-Flamewar.

Jester

Hast Du das jetzt ernsthaft nicht verstanden?

In C++ gibt es dermaßen viele Stringklassen, nicht weil die alle unterschiedliche Vorzüge bieten, sondern weil es lange keine gab und daher jede beschissene Library ihre eigene string-Klasse mitgebracht hat.

Artchi

Jester schrieb:

Hast Du das jetzt ernsthaft nicht verstanden?

In C++ gibt es dermaßen viele Stringklassen, nicht weil die alle unterschiedliche Vorzüge bieten, sondern weil es lange keine gab und daher jede beschissene Library ihre eigene string-Klasse mitgebracht hat.

Ist mir schon klar. NUr habe ich schon mal gesagt, das wir C++ler eine std::basic_string haben. Und? Kommen mir die Leute immer noch mit QString, wxString und CString an. Und wer sagt das es hunderte gibt? Es gibt nur eine Hand voll nennenswerter String-Klassen. Ich kann dir auch gerne viele XML-Libs im Java-Umfeld nennen. Warum sind die denn alle entstanden? Weil es erst ab Java 1.4 XML-Support gab? Ach, schau her! Das kann ich mit jeder Klasse/Lib aus dem Java-Umfeld machen, die erst später in den Java-Specs rein kamen, aber vorher schon von vielen anderen Leuten entworfen und implementiert wurden. In Java 1.4 gab es sogar einen Unicode-Bug in der XML-Lib. Wurde in Java 1.5 geändert, wodurch unsere damals ertellten XML-Dateien in Java 1.5 nicht mehr lesbar waren.

Was wäre das denn für eine Diskussionsgrundlage, wenn ich jetzt jedes Java-Defizit aufführe?

Artchi schrieb:

Das kannst du vielleicht nicht wissen, aber die Win32-API ist eine C-API, nichts C++. Deshalb kann da schlecht eine String-Klasse benutzt werden. Aber ist ok. Das Beispiel habe ich nur aufgeführt, um zu zeigen, das eine API sehr wohl von einem Typ (in dem Fall char) auf einen aktuelleren/sinnvolleren Typ (in dem Fall wchar_t) umgestellt werden kann. Das C keine Klassen kennt, hat ja nichts mit C++ zu tun.

ich weiß

Langsam wird es lächerlich. Gibts doch endlich zu, dass C++ in Sachen standard library viel schlechter ist als Java.

Was hat den C++ für ne XML Unterstützung?

Artchi

KennerDesProblems schrieb:

Langsam wird es lächerlich. Gibts doch endlich zu, dass C++ in Sachen standard library viel schlechter ist als Java.

Ja, ich gebe hoch und heilig zu, das C++ in Sachen Standardlibrary der letzte Schrott in der Geschichte der Programmiersprachen ist.

Artchi

PS: endlich kann ich mich hier ausklinken.