C Hassen...
-
Nur aus Interesse: Wo liegen konkret eure Kritikpunkte bezüglich der C++ Standardlib?
-
ich hab das ganze nur so ganz grob ueberflogen, aber doll ist der text nicht...
nur mal ein rausgepicktes beispiel:while(i<10) i--;und wundern uns, warum die Schleife nicht abbricht und bauen noch schnell eine Testausgabe ein
while(i<10) printf("%d\n", i); i--;also jeder der ein wenig ahnung von c hat, weiss doch dass man bei schleifen oder abfragen, auf die nur eine zeile code folgt, die geschweiften klammern weglassen kann...
und ebenso sollte jeder wissen dass man immer nur eine anweisung in eine zeile schreibt (schreiben sollte) und nicht alles zubombt... und schon kann man den fehler wunderbar finden und beheben...ich mag c und komme gut damit zurecht, sicher gibt es tage an denen man verzweifelt, aber meistens(wennn nicht sogar immer
) sitzt der fehler doch davor
-
scrontch schrieb:
Nur aus Interesse: Wo liegen konkret eure Kritikpunkte bezüglich der C++ Standardlib?
Die Vermengung der vielen unterschiedlichen Konzepte, die normalerweise nicht wirklich mit sich selbst zusammenpaßt. Valarrays vs. Vektoren, std::string mag nicht richtig mit den Iostreams ... Der standardisierte STL-Teil ist für sich ganz nett, paßt aber auch nicht so ganz rein. Die ganzen Zusicherungen, die einzelne Container und Funktionen über Exceptionsicherheit (nicht) machen, sind in keinem normalen Kopf unterzubringen
Das ist auch recht klar, die IOstreams sind im Wesentlichen von Jerry Schwarz, die STL von Hewlett-Packard und während des Normungsverfahrens hat man dann immer wieder am Standard rumgewerkelt (zB war nicht von Anfang an klar, daß Templates reinkommen, ob und wieviel von der STL in der Norm landet usw.).
-
Man stößt schnell bei der Standard Library an seine Grenzen. So ist nicht nur std::string nicht wirklich durchgesetzt. Es ist ja auch nicht möglich eigene String-Klassen, für variables Encoding (UTF-8 uä), einzuführen.
Wichtige Dinge fehlen einfach, so wie Funktionen um Typen in Strings umzuwandeln (den stringstream Ansatz halte ich für einen Versuch mit Kanonen auf Tauben zu schießen); Hashs fehlen (obwohl sie ja in der STL eigentlich drin sind). (Von Dingen wie Threads, Dateisystemen und co will ich ja gar nicht anfangen!).
Viele Sachen wirken einfach zusammen gewürfelt.
valarray soll zB kaum mit SIMD optimierbar sein (kenne mich mit valarray aber nicht aus), was ja eigentlich der Sinn so einer Klasse ist. Iteratoren für std::map macht auch wenig Sinn IMHO.
Die IOStreams sind übertrieben groß und in den heutigen Implementierungen auch noch erstaunlich langsam. Dabei sind die noch nicht einmal sonderflich flexibel, wenn man zB Filter für einen Stream einführen will, dann muss man tricksen.
-
kingruedi schrieb:
So ist nicht nur std::string nicht wirklich durchgesetzt.
Das liegt an den Programmierern, nicht der Sprache (mit Ausnahme der perversen iostream-Konstruktoren).
kingruedi schrieb:
Es ist ja auch nicht möglich eigene String-Klassen, für variables Encoding (UTF-8 uä), einzuführen.
Bitte? Natürlich geht das.
kingruedi schrieb:
den stringstream Ansatz halte ich für einen Versuch mit Kanonen auf Tauben zu schießen
Wieso?
kingruedi schrieb:
Hashs fehlen (obwohl sie ja in der STL eigentlich drin sind). (Von Dingen wie Threads, Dateisystemen und co will ich ja gar nicht anfangen!).
Stimmt, aber wenn man das möchte kann man Boost oder den TR1 nehmen. Für Dateisysteme gibts C++-Wrapper für FUSE :p
kingruedi schrieb:
Viele Sachen wirken einfach zusammen gewürfelt.
Welche?
kingruedi schrieb:
Iteratoren für std::map macht auch wenig Sinn IMHO.
Warum? So funktionieren die ganzen Algorithmen damit (auch wenn nicht Alle sinnvoll sind).
kingruedi schrieb:
Die IOStreams sind übertrieben groß und in den heutigen Implementierungen auch noch erstaunlich langsam. Dabei sind die noch nicht einmal sonderflich flexibel, wenn man zB Filter für einen Stream einführen will, dann muss man tricksen.
... oder wiederum Boost verwenden. Allerdings sind Filter auch grundsätzlich nicht so schwer zu schreiben, wenn man erstmal bei den Streambuffern durchblickt.
Die Geschwindigkeit hängt von der Implementierung ab und cout verwendest du in deinen Programmen sowieso nie ernsthaft, auf jeden Fall nicht in geschwindigkeitskritischem Kontext.
Das die Binarys so groß werden ist auch nicht unbedingt schuld der Sprache. Wir hatten hier schon einige Threads, in denen das sehr schön widerlegt wurde (müsste ich jetzt aber suchen).
An dem Konzept der Streams ist imho nichts auszusetzen.
-
Vieles was am aktuellen Standard von 1998 bemängelt wird, wird doch schon in TR1 und bald in TR2 gelöst. Deshalb kann ich das "Problem" nicht so Recht nachvollziehen. Klar, man hätte schon alles im ersten Standard drin haben können, aber dann wäre dieser immer noch nicht fertig.
std::string bzw. std::wstring hat sich deshalb noch nicht durchgesetzt, weil die ganzen Frameworks, wie wxWidgets, Qt, MFC usw., eigene String-Klassen haben. Und DAS auch nur deshalb, weil sie weit _vor_ dem C++-Standard das Licht der Welt erblickt haben. Das vergessen alle und geben der Standard-Lib die Schuld.
Threads, Filesystem, Netzwerk, UTF-8 u.a. kommen doch in TR2 rein. Klar, es dauert noch bis es abgesegnet und sicher ist. Aber TR1 wurde im April 2006 verabschiedet und wir haben doch dadurch schon mal Regex u.a. nette Sachen in C++, was ich persönlich super finde. Jetzt muß man noch TR2 abwarten, was auch nicht mehr lange auf sich warten lässt.
-
.filmor schrieb:
kingruedi schrieb:
So ist nicht nur std::string nicht wirklich durchgesetzt.
Das liegt an den Programmierern, nicht der Sprache (mit Ausnahme der perversen iostream-Konstruktoren).
kingruedi schrieb:
Es ist ja auch nicht möglich eigene String-Klassen, für variables Encoding (UTF-8 uä), einzuführen.
Bitte? Natürlich geht das.
Na ja, das rockt nicht wirklich. Oder warum glaubst du haben die meisten Toolkits ne eigene String-Klasse (AnsiString, CString, Glib::ustring, QString...)? Bestimmt nicht, weil sie nichts besseres zu tun haben. std::string ist nett, weil man dann als Anfänger ne string-Klasse hat und sieht, wie das denn so abläuft. Aber sonst kann man das Teil imho nicht wirklich gebrauchen.
kingruedi schrieb:
den stringstream Ansatz halte ich für einen Versuch mit Kanonen auf Tauben zu schießen
Wieso?
kingruedi schrieb:
Hashs fehlen (obwohl sie ja in der STL eigentlich drin sind). (Von Dingen wie Threads, Dateisystemen und co will ich ja gar nicht anfangen!).
Stimmt, aber wenn man das möchte kann man Boost oder den TR1 nehmen. Für Dateisysteme gibts C++-Wrapper für FUSE :p
Und warum muss ich ne extra Bibliothek dazunehmen, nur um ein bisschen im Dateisystem rumzugurken? Die C++ Standardlib ist atm nicht sehr umfangreich. Die Aufwertung durch TR1 und TR2 ist imho sehr wichtig. Hat ja auch lange genug gedauert
Klar, die C++ stdlib muss nicht ALLES anbieten, was es so an Libs auf dem Markt gibt, aber ich finde, der momentane Zustand ist unhaltbar. Wenn ich da nur an Python und sein "Batteries included" Konzept denke...Die Geschwindigkeit hängt von der Implementierung ab und cout verwendest du in deinen Programmen sowieso nie ernsthaft, auf jeden Fall nicht in geschwindigkeitskritischem Kontext.
Trotzdem könnten die Streams schneller sein als printf. Dem ist aber nicht der Fall. Blöd, oder?
Das die Binarys so groß werden ist auch nicht unbedingt schuld der Sprache. Wir hatten hier schon einige Threads, in denen das sehr schön widerlegt wurde (müsste ich jetzt aber suchen).
Geht ja auch nicht um C++ an sich, sondern um die Standardbibliothek. Und wie du richtig sagtest, die iostream ist einfach zu fett.
An dem Konzept der Streams ist imho nichts auszusetzen.
ACK.
MfG
GPC
-
vote boost into standard
*nur mein senf*
-
GPC schrieb:
Na ja, das rockt nicht wirklich. Oder warum glaubst du haben die meisten Toolkits ne eigene String-Klasse (AnsiString, CString, Glib::ustring, QString...)? Bestimmt nicht, weil sie nichts besseres zu tun haben. std::string ist nett, weil man dann als Anfänger ne string-Klasse hat und sieht, wie das denn so abläuft. Aber sonst kann man das Teil imho nicht wirklich gebrauchen.
Ja, weil std::string und std::wstring erst 1998 standard wurden, und Qt, MFC, wxWidgets usw. schon Steinzeit-Libs sind. wxWidgets ist jetzt mehr als 12 Jahre alt, MFC kam mit Windows 3.1 raus, und Qt ist meines Wissens 1995 entwickelt wurden.
Während einige Leute Libs zum Standard beisteuerten, kann man sich auch fragen, warum das Borland, Trolltech, MS, GTK u.a. nicht gemacht haben? Oder es heute immer noch nich gemacht haben obwohl das ISO-Komitee offiziell nach einer solchen Klasse/Lib gefragt hat. Aber diese Gruppen und Communities haben es bisher nicht getan. Bisher haben es nur Einzelpersonen getan. Genau das gleiche lief 1998 ab. Hätten wir nicht Boost, wäre an TR1 und TR2 kaum zu denken.
-
Artchi schrieb:
GPC schrieb:
Na ja, das rockt nicht wirklich. Oder warum glaubst du haben die meisten Toolkits ne eigene String-Klasse (AnsiString, CString, Glib::ustring, QString...)? Bestimmt nicht, weil sie nichts besseres zu tun haben. std::string ist nett, weil man dann als Anfänger ne string-Klasse hat und sieht, wie das denn so abläuft. Aber sonst kann man das Teil imho nicht wirklich gebrauchen.
Ja, weil std::string und std::wstring 1998 standard wurden, und Qt, MFC, wxWidgets usw. schon Steinzeit-Libs sind. wxWidgets ist jetzt mehr als 12 Jahre alt, MFC kam mit Windows 3.1 raus, und Qt ist meines Wissens 1995 entwickelt wurden.
Mag schon sein, aber dann kann man sich natürlich fragen: Warum dauerte das so lange?
gtkmm ist ja später als 1998 richtig in die Puschen gekommen, die hätten noch auf std::string umsteigen können. Aber sie haben es nicht getan. Ich denke, da steckt mehr dahinter, als die Idee, einfach den ustring aus der glib zu wrappen.
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.
Während einige Leute Libs zum Standard beisteuerten, kann man sich auch fragen, warum das Borland, Trolltech, MS, GTK u.a. nicht gemacht haben?
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.
MfG
GPC
-
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.
-
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
-
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?
-
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
-
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
-
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.
-
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.
-
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.
-
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.
-
Das C# 1.0 schon ISO-Standard ist, hab ich nicht gewusst. Gibts ne Nummer/Link dafür? Würde mich schon interessieren.
