Ist es sinnvoll heute noch C++ anzufangen?



  • rolfroller schrieb:

    Mit etwas Abstand betrachtet wirkt ihr alle etwas lächerlich.

    Hehe - macht das 'was ? 🙂



  • ~john schrieb:

    +fricky schrieb:

    ~john schrieb:

    [*]Makros

    sind doch gut und brauchbar in C.

    Du verwechselst mal wieder ein Grundkonzept mit einer Implementation.
    Makros sind totaler Schrott, da sie nicht typsicher sind.

    für typsicherheit sorgt der compiler nach der textersetzung. makros werden zu unrecht verteufelt. wenn man sich an ein paar einfache regeln hält, sind makros wirklich eine gute sache.

    ~john schrieb:

    +fricky schrieb:

    ~john schrieb:

    [*]Trigraphs

    hab' ich noch nie verwendet.

    Was ist das für ein Argument?...Meiner Meinung nach gehört der Mist rausgeschmissen. Und die Tatsache, daß Du noch nicht einmal kennst, spricht Bände.

    ich schätze 99.9% aller C-programmierer haben sie noch nie verwendet und 98% wissen nicht, was das ist. wenn's trigraphs rausgeschmissen werden, würde sie keiner vermissen. du hast zwar recht, dass trigraphs überflüssiger bullshit sind, aber sie sind nichts, was die sprache C in irgendeiner form beeinträchtigt oder sonst irgendjemanden stören könnte, aus einem einfachen grund: fast niemand muss damit jemals was zu tun kriegen. und wenn er sein ganzes leben lang 24 stunden am tag C programmieren würde.

    ~john schrieb:

    +fricky schrieb:

    ~john schrieb:

    [*]Zeigerarithmetik

    ist in C, weil C ziemlich maschinennah ist, sehr sinnvoll. was würdest du als ersatz vorschlagen?

    Zeigerarithmetik ist in einer Hochsprache überflüssig, man braucht sie grundsätzlich nicht.

    C ist eigentlich keine 'richtige' hochsprache, sondern eher eine art portabler assembler. du kannst ziemlich maschinennah programmieren, ohne dich auf eine bestimmte prozessorarchiktur festlegen zu müssen. die meisten CPUs kennen irgendeine form von direkter speicheradressierung, irgendwelche rechnereien mit adressen, i/o-register die wie speicherzellen angesprochen werden, usw. deshalb sind pointer in C unverzichtbar. man könnte ähnliches vielleicht mit einer art array-syntax machen, aber damit würde man die sache nur unnötig abstrahieren, ohne was zu gewinnen.

    Ada wird ebenfalls für LowLevel Aufgaben verwendet, da hat noch niemand Zeigerarithmetik vermißt.

    wie geht das da eigentlich? aber ich kann mir vorstellen, dass ADA mehr auf sicherheit achtet und dadurch das ganze nicht so flexibel ist, wie pointer in C.
    🙂



  • +fricky schrieb:

    ~john schrieb:

    Was ist das für ein Argument?...Meiner Meinung nach gehört der Mist rausgeschmissen. Und die Tatsache, daß Du noch nicht einmal kennst, spricht Bände.

    ich schätze 99.9% aller C-programmierer haben sie noch nie verwendet und 98% wissen nicht, was das ist. wenn's trigraphs rausgeschmissen werden, würde sie keiner vermissen. du hast zwar recht, dass trigraphs überflüssiger bullshit sind, aber sie sind nichts, was die sprache C in irgendeiner form beeinträchtigt oder sonst irgendjemanden stören könnte, aus einem einfachen grund: fast niemand muss damit jemals was zu tun kriegen. und wenn er sein ganzes leben lang 24 stunden am tag C programmieren würde.

    Wo wir wieder beim operator<<(volatile void*) sind. Aber du bist ja resistent.



  • Also in der Softwareschmiede, für die ich arbeite, werden neue Projekte grundsätzlich nicht mehr in C++ umgesetzt, sondern nun nur noch in C# oder ggf. in Java, wobei dies eher selten. Früher war mal alles C++, jetzt beinahe alles C#.



  • Michael E. schrieb:

    +fricky schrieb:

    ~john schrieb:

    Was ist das für ein Argument?...Meiner Meinung nach gehört der Mist rausgeschmissen. Und die Tatsache, daß Du noch nicht einmal kennst, spricht Bände.

    ich schätze 99.9% aller C-programmierer haben sie noch nie verwendet und 98% wissen nicht, was das ist. wenn's trigraphs rausgeschmissen werden, würde sie keiner vermissen. du hast zwar recht, dass trigraphs überflüssiger bullshit sind, aber sie sind nichts, was die sprache C in irgendeiner form beeinträchtigt oder sonst irgendjemanden stören könnte, aus einem einfachen grund: fast niemand muss damit jemals was zu tun kriegen. und wenn er sein ganzes leben lang 24 stunden am tag C programmieren würde.

    Wo wir wieder beim operator<<(volatile void*) sind. Aber du bist ja resistent.

    nö, der unterschied ist: trigraphs sind einfach nur entbehrlich, aber aus (volatile) void* pauschal einen bool zu machen, ist extremer mist. zugegeben, diese macke kann man nicht C++ selbst ankreiden(*), sondern den codern der c++ standard-lib. aber als spektakuläres vorführobjekt, um zu zeigen, wie sich C++ schon bei banalsten dingen seltsam verhält, taugt es hervorragend.

    (*)
    vielleicht schon, weil c++ volatile und nicht-volatile als argument in überladungen unterscheidet. vielleicht kann mich einer aufklären, warum das so ist. wenn man sich den sinn von 'volatile' vor augen führt, müsste das doch garnicht sein, oder doch?
    🙂



  • Wie gesagt, resistent. Deshalb hab ich auch schon keine Lust mehr zu diskutieren.



  • Trigraphs ... Parsen von Code unnötig verkompliziert

    Ja und? Nach dem Parsen hat der Compiler den Syntaxtree und kann damit machen, was er will.

    Zeigerarithmetik ist in einer Hochsprache überflüssig

    Ich wuenschte, ich haette manchmal Zeiger in Sprachen wie Java (nicht unbedingt die Arithmetik).

    Hochsprache

    Wenn es danach geht, muessten wir alle in Lisp programmieren. Kaum eine andere Sprache erlaubt mir Zugang zum Syntaxtree.

    operator<<(volatile void*) ... wie sich C++ schon bei banalsten dingen seltsam verhält, taugt es hervorragend.

    Dieses Beispiel ist sowas von irrelevant fuer den taeglichen Programmieralltag ... Hat irgendwer ein relevantes Beispiel, welches einem das Leben schwer macht, wenn man C++ idiomatisch benutzt? More C++ Idioms

    Also in der Softwareschmiede, für die ich arbeite, werden neue Projekte grundsätzlich nicht mehr in C++ umgesetzt, sondern nun nur noch in C# oder ggf. in Java, wobei dies eher selten. Früher war mal alles C++, jetzt beinahe alles C#.

    Jaja, Industriestandard ... Revenge of the Nerds Beating the Averages



  • knivil schrieb:

    operator<<(volatile void*) ... wie sich C++ schon bei banalsten dingen seltsam verhält, taugt es hervorragend.

    Dieses Beispiel ist sowas von irrelevant fuer den taeglichen Programmieralltag ...

    der effekt ist aber witzig. hier noch was lustiges:

    string a("c++ get off my ass");   // konstruktoraufruf mit parameter  
      string b();               // konstruktoraufruf ohne parameter (oder doch nicht?)
    

    🙂



  • +fricky schrieb:

    der effekt ist aber witzig. hier noch was lustiges:

    string a("c++ get off my ass");   // konstruktoraufruf mit parameter  
      string b();               // konstruktoraufruf ohne parameter (oder doch nicht?)
    

    🙂

    Wieder der beweis, über etwas zu urteilen, obwohl man es nicht kennt. Und es zeigt, das du nicht mal C kannst obwohl du dich C-Fanboy nennst, sonnst wäre dir aufgefallen, das string b(); ein Funktions-Prototyp ist (was auch der Compiler mit einem ERROR anmeckert). Das ist nun wirklich Basiswissen, oder?

    Es muß, wenn dann heißen:

    string b;
    

    Du bist echt peinlich. 🙄



  • Artchi schrieb:

    Und es zeigt, das du nicht mal C kannst obwohl du dich C-Fanboy nennst...

    in C gibts keine konstruktoraufrufe. da passieren solche verwechslungen garnicht erst.

    Artchi schrieb:

    ...sonnst wäre dir aufgefallen, das string b(); ein Funktions-Prototyp ist (was auch der Compiler mit einem ERROR anmeckert).

    bei mir meckert nix (vc 2005).

    Das ist nun wirklich Basiswissen, oder?

    nö, das ist die inkonsistente C++ syntax.
    🙂



  • Also auf die Idee bin ich selbst noch nie gekommen, aber wenn man es mal ausprobiert, kriegt man keinen Fehler, sondern eine vorzügliche Warnung (VS2008):

    1>c:\develop\testcenter v9\acquit\dlgtichawashadingcorrection.cpp(146) : warning C4930: 'std::string b(void)': Funktion mit Prototyp wurde nicht aufgerufen (war eine Variablendefinition gemeint?)



  • fricky, du bist echt gut.
    Kein anderer Troll hat es bisher geschafft trotz offensichtlichen Nicht-Wissens so viel Aufmerksamkeit zu erlangen und auch mich immer wieder dazuzu treiben dir zu antworten

    In C gibt es Pointer als Typen, aber dennoch kommt der * an den Namen und nicht zum Rest des Datentypes. Inkonsistente C-Syntax? Wayne? Ja richtig, wayne.. genauso wie das was du uns bisher vorgelegt hast. Vielleicht bringst du mal ein Beispiel was C so toll kann, was C++ nicht kann? Oder was Java kann, was C++ nicht kann? Und ich rede nicht von Workarounds.



  • JustAnotherNoob schrieb:

    In C gibt es Pointer als Typen, aber dennoch kommt der * an den Namen und nicht zum Rest des Datentypes.

    Wer sagt das?



  • JustAnotherNoob schrieb:

    In C gibt es Pointer als Typen, aber dennoch kommt der * an den Namen und nicht zum Rest des Datentypes.

    Aber ja doch:

    char  *p, buf[256];
    

    Oder willst Du den kompletten Quellcode vollmüllen ?



  • Abgesehen davon, dass es optisch m.E. schöner ist, wenn der '*' am Bezeichner und nicht am Typ pappt, ist es jedem natürlich selbst überlassen. So eine Konvention existiert nicht. Scheppertreibers Beispiel demonstriert, warum es so auch sinnvoller sein kann.

    P.S.: Meine Kristallkugel hat mir grad geflüstert, dass die Diskussion sich nun in die Richtung bewegen wird, ob man mehrere Variablen in einer Zeile deklarieren darf oder nicht... 🤡



  • _matze schrieb:

    Also auf die Idee bin ich selbst noch nie gekommen, aber wenn man es mal ausprobiert, kriegt man keinen Fehler, sondern eine vorzügliche Warnung (VS2008)

    die warnung kriegste bestimmt weg, wenn du oben eine funktion hinschreibst: string b{return"hello";}

    JustAnotherNoob schrieb:

    In C gibt es Pointer als Typen, aber dennoch kommt der * an den Namen und nicht zum Rest des Datentypes.

    beim dereferenzieren, oder wo?

    JustAnotherNoob schrieb:

    Vielleicht bringst du mal ein Beispiel was C so toll kann, was C++ nicht kann?

    kommt drauf an, was du mit können meinst. C ist viel leichter lesbar. z.b. ist in C ein ausdruck der form: a = b->c(d); relativ eindeutig. in C++ gibt es dagegen viele möglichkeiten, was es bedeuten könnte.
    🙂



  • Immer diese praxisnahen Beispiele. Wenn ich b im gesamten Programm nicht benutze, ist es mir doch egal, ob b jetzt eine Funktion oder ein Objekt ist. Aber sobald ich es benutze, fliegen mir die Fehler nur so um die Ohren, wenn ich mich bei der Deklaration vertan hab.



  • _matze schrieb:

    Abgesehen davon, dass es optisch m.E. schöner ist, wenn der '*' am Bezeichner und nicht am Typ pappt, ist es jedem natürlich selbst überlassen. So eine Konvention existiert nicht.

    Es geht nicht um eine Konvention. Der Stern gehört zum Bezeichner, nicht zum Typ. Egal, wo dabei die Leerschritte sind, wären anderenfalls hier a und b Zeiger. Insofern ist das gesagte schon richtig.

    char * a, b;
    


  • Ich denke ja. Zumindest war das mit ein Grund für mich, Pascal ab- und C
    anzuschaffen. 10 Seite Pascal ca. 10 Zeilen C 😉



  • Oh man nun werdet doch nicht immer gleich persönlich, wenn fricky~ euch mal die Fehler von C++ vor Augen führt. Diesen Konstruktoraufruf, der in Wirklichkeit eine Funktionsdeklaration darstellt finde ich auch besonders tückisch. Darüber sind damals in meinem C++ Uni Kurs sehr viele Kommilitonen gestolpert und wunderten sich dann, warum sie eine seltsame und für sie völlig unverständliche Fehlermeldung vom Compiler bekamen.

    Ihr Leute müsst mal bedenken, daß solche Tücken für Jemanden, der noch nicht seit 5 Jahren C++ programmiert und in jeder freien Minute den C++ Standard auswendig lernt, durchaus ein ernsthaftes Problem darstellen.

    Noch fataler ist natürlich das altbekannte virtual Problem, was dutzende meiner Kommilitonen völlig hat an die Wand fahren lassen.

    class abstract {
    public:
    	void init() { print(); }
    	virtual void print() = 0;
    	abstract() { init(); }
    };
    
    class abc : public abstract {
    public:
    	virtual void print() { cout << "Ich bin abc" << endl; }
    };
    
    int main(int argc, char* argv[]) {
    	abc test;
    	return 0;
    }
    

    Da soll der unerfahrene Neuling erstmal verstehen, was er hier falschgemacht hat und warum er mit einem obskuren runtime error R6025 abgestraft wird.

    Und von solchen Falltüren gibt es in C++ noch einige mehr.


Anmelden zum Antworten