C++ für C-Programmierer



  • manni66 schrieb:

    Lymogry schrieb:

    Kennst du dieses \1: http://www.rrzn.uni-hannover.de/buecher.html?no_cache=1&tx_rrznbuecher_pi1[showUid]=69

    Ganz am Ende drei Seten STL, wobei das Meiste über string ist. In der Beschreibung wird vom vorläufigen ANSI Standard geredet. Das scheint doch ein wenig angestaubt zu sein.

    Nicht nur das, es redet sehr merkwürdig:

    Viele Fehler in der Syntax, wie zum Beispiel das Vergessen eines Kommas als Abschlussmarkierung einer Zeile

    ?

    Ein Kompilierungsfehler wird angezeigt, wenn eine Prozedur nicht aufgerufen werden kann.

    Ebenfalls irritierend.

    In C++ können diese Fehler [hier: Laufzeitfhler] mit Hilfe von Exceptions abgefangen werden.

    Pauschal falsch. Nicht jeder Laufzeitfehler kann durch eine Exception abgefangen werden.

    Anschließend rät das Buch, eine Enumeration zu definieren, und die Enumeratoren zu werfen. Nicht nur, dass die Möglichkeit, einen Enumerator zu werfen, ein Designfehler von C++ ist... ich hätte nicht erwartet, dass das jemals verwendet werden würde.

    Hier ein richtiges Beispiel zur Verwendung von bad_alloc von mir:

    Fenster *objPtr = 0;
    try {
        objPtr = new Fenster(0,200);
    }
    catch(int fehler){
        cout << "Das Fenster ist zu klein gewählt.";
        delete(objPtr);
    }
    catch(bad_alloc &ex){
        cout << ex.what() << endl;
    }
    delete(objPtr);
    objPtr = 0;
    

    Ihr habt richtig erkannt, dass es nicht von mir ist. Dabei wird auto_ptr ja auch noch angesprochen... 👎



  • Jetzt kommt mal alle wieder runter. Das Skript ist heute nicht mehr zu gebrauchen, klar, aber das kann man seinem Autor wirklich nicht vorwerfen -- es muss so aus der Zeit um 1994/1995 stammen. Zu dieser Zeit war es stumpf noch nicht möglich, das zu schreiben, was wir heute unter sauberem C++ verstehen, weil die Compiler es einem mit ICEs um die Ohren gehauen hätten. Selbst Dinge, die wir heute (wenn wir nur ein bisschen Ahnung haben) für grundsätzlich nehmen -- RAII zum Beispiel -- waren zu der Zeit bleeding edge und mussten sich erst beweisen. Die Standardbibliothek war keine Standardbibliothek, weil es keinen Standard gab, und die Macht von Templates war nicht ansatzweise erforscht (oder erforschbar -- ICEs ohne Ende hat es bei den ersten Versuchen gehagelt). Bis zu dem, was heute C++-Grundlagen sind, so weit hatte damals noch niemand gedacht, und Dinge wie Boost.MPL hätten sich damals allenfalls Wahnsinnige vorstellen können.

    Das Compilerchaos, das Mitte der Neunziger geherrscht hat, ist heute schwer vorstellbar und nicht vergleichbar mit den milden Turbulenzen, die die Umstellung auf C++11 mit sich bringt. Portabilität war mehr oder weniger Glückssache. RTTI vermied man nicht, weil es objektorientierte Grundsätze verletzt, sondern weil wenige Compiler es beherrschten. Exceptions als Mittel zur Fehlerbehandlung waren mit großer Vorsicht zu genießen -- über den Problemkomplex Exceptionsicherheit war man schon gestolpert, aber die Lösung war alles andere als allgegenwärtig, und Compilersupport war auch hier zunächst mäßig. Es ist kein Zufall, dass in den wxWidgets-Coding-Guidelines steht, dass Exceptions vermieden werden sollen. MSVC 6 war mal ein richtig guter C++-Compiler!

    Von einem Skript aus dieser Zeit zu erwarten, dass es modernes C++ lehrt, ist abwegig, von C++11 ganz zu schweigen. Ich weiß nicht einmal, ob zu der Zeit, als es geschrieben wurde, Design Patterns schon erschienen war -- ggf. musste die Druckerschwärze wohl noch trocknen. Lernen und lehren will man damit heute sicher nicht mehr, aber darauf herumzuhacken ist aus meiner Sicht nicht zielführend. Man kann stattdessen ganz ruhig erklären, warum es in eine Vitrine statt in den Lehrsaal gehört.



  • Das ist eben der Sonestil, bei jedem zweiten Posting ins Fettnäpfchen treten. Wie kann man bei soviel Inkompetenz so auf die Kacke hauen?



  • Sone schrieb:

    Hier ein richtiges Beispiel zur Verwendung von bad_alloc von mir:

    Fenster *objPtr = 0;
    try {
        objPtr = new Fenster(0,200);
    }
    catch(int fehler){
        cout << "Das Fenster ist zu klein gewählt.";
        delete(objPtr);
    }
    catch(bad_alloc &ex){
        cout << ex.what() << endl;
    }
    delete(objPtr);
    objPtr = 0;
    

    Ihr habt richtig erkannt, dass es nicht von mir ist. Dabei wird auto_ptr ja auch noch angesprochen... 👎

    Wozu wird der Zeiger danach auf 0 gesetzt?
    Dicher, daß man den Speicher deleten muss, wenn der Konstruktor per Exceptien ausstieg?



  • Dicher, daß man den Speicher deleten muss, wenn der Konstruktor per Exceptien ausstieg?

    Muss/darf man nicht, allerdings "schadet" es hier nicht, da der Pointer eh noch immer 0 ist.



  • Ich bin ja nicht beratungsresitent, 🕶 also bin ich heute morgen in die Bibliothek und hab mir Stroustrups "C++ Programming Language" geholt und finde es ganz großartig.
    Ich kann dadrin die ersten Kapitel schön querlesen und verstehe die Hinweise und Ratschläge, die es mir gibt. Allerdings ist das Buch ein harter Brocken und ohne Einsteigerlektüre gar nicht nachvollziehbar. Ich programmiere nun schon seit 5 Jahre mit C und liebäugelte schon länger, auf eine objektorientierte Sprache umzusteigen, weil ich langsam an die Grenzen von C komme, wo es nicht mehr schön wird.
    Natürlich hab ich hier und da schon in ein C++ Buch reingeschaut. Mein Problem war immer, dass die erstmal Kapitelweise auf Schleifen und Abfragen eingehen, auf basalste Programmierung, was ich ja nun wirklich nicht brauche. Den dicken Brocken dann durchzuarbeiten, um doch keine relevanten Informationen zu verpassen, das fand ich ermüdend und langweilig ....

    Das erwähnte Script hat 130 Seiten und erleichtert einem den Umstieg.
    Es hegt an sich weder den Anspruch der Vollständigkeit, noch will es aktuell sein. Es ist zum Verständnis da!! Für den Anfang ist das SUPER!
    Damit hab ich die abstrakten Konstruktionen bekommen, ich habe sie verstanden! Das ist mir viel viel wert, damit ich kann - soviel ich will - mich weiter einarbeiten.
    Stroustrup sagt passend dazu "Das Verständnis von Programmier- und Designtechniken ist weit wichtiger als die Aneignung von Detailkenntnissen. Die erwirbt man sich im Laufe der Zeit durch Praxis". Ganz meiner Meinung!

    PS (wenn es der Freundlichkeit dient) 😃 : Ich bin weiblich, Mathematikerin und Tänzerin! 😃



  • Lymogry schrieb:

    PS (wenn es der Freundlichkeit dient) 😃 : Ich bin weiblich, Mathematikerin und Tänzerin! 😃

    cool story bro



  • Ich bin weiblich, Mathematikerin und Tänzerin!

    Inwiefern lockert das die Spannung?

    also bin ich heute morgen in die Bibliothek und hab mir Stroustrups "C++ Programming Language" geholt und finde es ganz großartig.

    Nun, das ist doch nicht schlecht, ein Lob von mir! 🙂



  • Sone schrieb:

    Ich bin weiblich, Mathematikerin und Tänzerin!

    Inwiefern lockert das die Spannung?

    kommt auf den Hormongehalt an, meine Vorurteile sagen, dass er hier sehr hoch ist 😃

    also bin ich heute morgen in die Bibliothek und hab mir Stroustrups "C++ Programming Language" geholt und finde es ganz großartig.

    Nun, das ist doch nicht schlecht, ein Lob von mir! 🙂

    siehst du, schon gelockert 🕶



  • Sone schrieb:

    Ich bin weiblich, Mathematikerin und Tänzerin!

    Inwiefern lockert das die Spannung?

    also bin ich heute morgen in die Bibliothek und hab mir Stroustrups "C++ Programming Language" geholt und finde es ganz großartig.

    Nun, das ist doch nicht schlecht, ein Lob von mir! 🙂

    Als wenn man gerade von DIR ein Lob will *kicher



  • Lymogry schrieb:

    ...
    (wenn es der Freundlichkeit dient) 😃 : Ich bin weiblich, Mathematikerin und Tänzerin! 😃

    Pics or... 😃



  • Ich habe jetzt nur das Inhaltsverzeichnis des Skriptes lesen können, behalte aber meine Zweifel, dass es gerade zum Einstieg gut geeignet ist. Oder zum Umstieg von C.

    Man muss dazu sagen, dass der Umstieg von C zu C++ besonders viele Fallstricke mit sich bringt, weil es einfach ist, dem Trugschluss aufzusitzen, C++ sei eine Art erweitertes C (und weil viele Buchautoren dies getan haben -- in wenig anderen Feldern gibt es so viel schlechte Lektüre). Guter C-Code hat mit gutem C++-Code wenig gemein, umd wenn man C++ wie C schreibt, bringt man sich in Teufels Küche.

    Es gibt dafür viele Gründe, von denen die meisten darauf hinauslaufen, dass es in C++ besser geht. Der größte Elefant im Raum aber, der dafür sorgt, dass Code, der in C vollkommen in Ordnung wäre, in C++ vollkommen kaputt ist, sind Exceptions. Etwa sieht Code der Form

    {
      void *db_handle = open_database("some_server", 5432, "user", "password");
    
      do_stuff_with_database(db_handle);
    
      close_database(db_handle);
    }
    

    für einen C-Programmierer völlig in Ordnung aus (und ist es auch), während ein C++-Programmierer die Hände über dem Kopf zusammenschlagen muss. Was, wenn do_stuff_with_database eine Exception wirft? Schon leakt man Connections. Und selbst, wenn do_stuff_with_database im Moment keine Exceptions wirft -- sich darauf verlassen zu wollen, dass jemand, der den Code in zwei Jahren mal anfasst, damit rechnet, dass die Funktion keine Exceptions werfen darf, ist weltfremd.

    Vor diesem Hintergrund ist das Lernen mit alten Skripten, in denen diese grundlegenden Entwurfsmuster nicht auftauchen, besonders für C-Umsteiger gefährlich. Du wirst dir viel angewöhnen, was man absolut vermeiden sollte, und es mühsam wieder verlernen müssen. Ich habe diesen Weg hinter mir. Er ist nicht angenehm.

    Ansonsten: Jungs, hört auf zu pubertieren.



  • volkard schrieb:

    Wozu wird der Zeiger danach auf 0 gesetzt?

    Keine Ahnung.

    Aber gut, das Skript darf man tatsächlich nicht runtermachen - es aber zum Umsteigen nutzen definitiv auch nicht. Es ist sogar noch von vor 98.

    Jungs, hört auf zu pubertieren.

    Was habe ich denn getan, dass du mich so abstempelst?


  • Mod

    Sone schrieb:

    Jungs, hört auf zu pubertieren.

    Was habe ich denn getan, dass du mich so abstempelst?

    Ich glaube, hier bist ausnahmsweise mal nicht du gemeint.

    @Lymogry: Wir hatten hier vor ein paar Monaten mal eine Riesendiskussion, deren recht einstimmiges Ergebnis es war, dass es eine schlechte Idee ist, die Hormone für Hilfe anzufachen. Denn weißt du, wer solche Tricks sofort durchschaut und sich angesichts solch billiger Fangtricks angeekelt abwendet? Männer die nicht mehr in der Pubertät sind. Kurz: Erfahrene Leute.
    Daher ist es allgemein besser, möglichst anonym zu bleiben. Bei anonymer Kommunikation ist der Ton in Internetforen trocken sachlich (was oft als grob empfunden wird, aber nicht so gemeint ist). Wenn du dich als Mitglied einer bestimmten Gruppe ausgibst, wirst du nicht das erreichen, was du im wirklichen Leben davon erhoffst (egal, um welche Gruppe es sich handelt. Auch männlich, weiß, deutsch, Single, 25-40 Jahre, Hochschulabschluss, erfolgreich.). Denn erstens ist es nicht nachprüfbar, wodurch ein großer Teil der Leute davon ausgeht, dass es eine ganz bewusste Taktik ist, um bestimmte Gefühle auszulösen, was in einer Trotzreaktion resultiert. Und der andere Teil der Leute (Überschneidungen möglich) benutzt die eigene Anonymität, um mal so richtig die Sau raus zu lassen und über die offenbarte Gruppe zu sagen, was man sich in echt nie trauen würde.

    Du siehst, es ist in diesem Thread ziemlich genau dies eingetreten. Dumme Sprüche. Trotzige Sprüche. Allgemein geringe Hilfsbereitschaft.



  • @SeppJ:
    Danke für den gutgemeinten Rat, aber vielleicht siehst du hier, dass ich weder Hilfe suche, noch irgendwelche Gefühle wecken will. 😉 Es diente lediglich der allgemeinen Lockerung (nachdem sich Sone etwas im Ton vergriffen hatte) und das ist auch gelungen.
    Dumme Sprüche sehe ich auch sehr locker, hab da kein Problem mit!

    Somit verabschiede ich mich nun auch aus der Runde. High Five, Bro! 🕶



  • nachdem sich Sone etwas im Ton vergriffen hatte

    Ich sehe rückblickend kein Problem. Wir sind in einem Programmierforum, keiner Party.

    Es diente lediglich der allgemeinen Lockerung und das ist auch gelungen.

    Bitte? Wieso genau hast du nun hier gepostet?


Anmelden zum Antworten