C Hassen...



  • passend zum aktuellen C++ vs. Java Thread 😃

    http://www.bildschirmarbeiter.com/output_8483.html

    Am besten find ich die ausgewählten Programmbeispiele

    'A' + ' ' == 'a'
    


  • C-Hasser kann man wirklich schnell werden. Besonders wenn ich mir die Standard-Lib angucke, kommt es mir jedes mal hoch.

    Aber die Webseite ist ja auch nicht gerade gut. Kann weder zwischen C noch C++ unterscheiden. Nimmt dann Modula(!) als Vergleichssprache. Naja ich weiß nicht.



  • Das ist doch Satire, oder? Hoffe ich zumindest für den Autor.



  • kingruedi schrieb:

    C-Hasser kann man wirklich schnell werden. Besonders wenn ich mir die Standard-Lib angucke, kommt es mir jedes mal hoch.

    👍



  • Ich bekenne mich auch als C Hasser, vor allem weil mir die STL fehlt.



  • kingruedi schrieb:

    C-Hasser kann man wirklich schnell werden. Besonders wenn ich mir die Standard-Lib angucke, kommt es mir jedes mal hoch.

    Aber Du programmierst dann nicht ernsthaft C++, oder? Die Standardbibliothek ist da auch ziemlich daneben (iostreams, die Integration der verschiedenen Teile usw.). Man merkt den Sprachen den Entwicklungsprozeß eben an, wobei man C zugute halten kann, daß es Kulturgut ist und C++ einfach Murks 😉



  • @Daniel E.
    Die C++ Standardbibliothek ist ja in vielen Bereichen noch schlimmer 🙂

    Aber als kompletten Murks würde ich C++ nicht bezeichnen wollen.



  • Erst wollte ich nur die C++-Standard-Bibliothek beschimpfen, aber das wäre zu einfach gewesen, also hab ich die ganze Sprache beschimpft 🙂



  • 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


Anmelden zum Antworten