Ist es sinnvoll heute noch C++ anzufangen?



  • supertux schrieb:

    ich bin auch ein C-Fanboy! nur, ich kenne mich nicht mit C++ aus, deshalb kann ich da nicht mitreden 😡

    Keine Scheu, Sachkenntnis ist bei sowas auch eher hinderlich.



  • Bashar schrieb:

    supertux schrieb:

    ich bin auch ein C-Fanboy! nur, ich kenne mich nicht mit C++ aus, deshalb kann ich da nicht mitreden 😡

    Keine Scheu, Sachkenntnis ist bei sowas auch eher hinderlich.

    👍



  • Einige hier werden offensichtlich nervös, wie man an ihren zunehmend gereizten Reaktionen auf frickys sachliche Beiträge sehen kann.

    Ich verstehe aber auch nicht, warum manche Leute solche Evangelisten sind und sich sofort persönlich angegriffen fühlen, wenn man feststellt, daß C++ Mängel hat und seine besten Zeiten vorüber sind.



  • Als weiter so - ich mag dieses leicht abgeklärte saloppe Programmiersprachenbashing 😉

    OOP könnten wir noch mal rannehmen ...



  • JustAnotherNoob schrieb:

    grrrrr...
    (mal kein grinse-smiley, weil zwei andere schon da sind)

    Vielleicht fällt dir dann mal auf, dass deine Argumentation für C und deine Argumentation für Java total widersprüchlich sind.

    würde ich nicht sagen. C und Java, samt ihrer anwendungsbereiche, sind einfach 'anders', deshalb gelten viele argumente für Java nicht für C und umgekehrt auch nicht.

    JustAnotherNoob schrieb:

    Bei C gegen C++ sagst du "C hat keine Unzulänglichkeiten, man kann mit jedem Feature Mist bauen, wenn man es falsch benutzt, aber als guter Programmierer passiert das nicht"

    die frage ist, wann jemand ein 'guter programmierer' ist, um mit einer sprache sicher umgehen zu können. vergleich' es mit brettspielen wie schach und mühle. in mühle wird man sehr schnell sehr gut, bei schach dauert es viel, viel länger. die macken von C sind dermassen minimal, dass man schnell lernt, was (situationsbedingt) falsch und was richtig ist. mit Java verhält es sich ähnlich, allerdings auf einer anderen ebene.

    JustAnotherNoob schrieb:

    Bei Java gegen C++ sagst du "doch, das passiert, aber auf jeden Fall, egal was ist. C++ Features sind gefährlich, man kann mit Javatools auf keinen Fall Mist bauen etc. pp. blahblah.".

    es ist zumindest viel schwerer in Java mist zu bauen, weil das ganze lowlevel-niveau wie manuelle speicherverwaltung, pointer, nackte arrays, alles-in-alles casten zu können, usw. praktisch nicht existiert. solche dinge sind alle für eine lowlevel-sprache wie C unverzichtbar, haben aber in einer highlevel-sprache nichts verloren.
    🙂



  • Bashar schrieb:

    supertux schrieb:

    ich bin auch ein C-Fanboy! nur, ich kenne mich nicht mit C++ aus, deshalb kann ich da nicht mitreden 😡

    Keine Scheu, Sachkenntnis ist bei sowas auch eher hinderlich.

    genau, als wären C++ Fanboys per Definition sachlich. Danke für die Schublade, ein sehr sachliches Argument von dir.



  • supertux schrieb:

    genau, als wären C++ Fanboys per Definition sachlich. Danke für die Schublade, ein sehr sachliches Argument von dir.

    Das hast du falsch verstanden. Die meisten die gegen C++ anstänkern, und sich HIER tummeln, haben ebend keine C++-Sachkenntnis. Und dann ist dieses Schubladendenken berechtigt.

    Es ist ja nicht so, das die C++-Fanboys sich jede Woche in Java-Foren rumtummeln und gegen Java stänkern. Denk mal darüber nach, wer hier von beiden Seiten Minderwertigkeitskomplexe hat? 🙄



  • Es ist ja nicht so, das die C++-Fanboys sich jede Woche in Java-Foren rumtummeln und gegen Java stänkern. Denk mal darüber nach, wer hier von beiden Seiten Minderwertigkeitskomplexe hat?

    So etwas gibt es ? "Foren stürmen" ??? Oha !



  • Artchi schrieb:

    Es ist ja nicht so, das die C++-Fanboys sich jede Woche in Java-Foren rumtummeln und gegen Java stänkern.

    ich hab' letztens mal 'nen dummen spruch über Java gelassen. gregor hats gleich gelöscht.
    🙂



  • +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. Generics und Inline Funktions bieten die gleiche Funktionalität, bei deutlich höherer Sicherheit. Aber die gibt es nun einmal nicht in C.

    +fricky schrieb:

    ~john schrieb:

    [*]Trigraphs

    hab' ich noch nie verwendet.

    Was ist das für ein Argument? Du selbst bashst auf anderen Sprache herum, wenn man dort Probleme per Konvetion vermeiden kann, und für C soll das auf einmal nicht gelten? Entscheidend ist die Tatsache, daß der Schrott Teil der Sprache ist und das Parsen von Code unnötig verkompliziert. Meiner Meinung nach gehört der Mist rausgeschmissen. Und die Tatsache, daß Du noch nicht einmal kennst, spricht Bände.

    +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. Offsets berechnen ist Aufgabe des Compilers und nicht des Programmierers. Weil es in C Zeigerarithmetik gibt, kann man leider kein Bounds Checking implementieren, und Buffer Over-/Underflows sind so leidiges Dauerthema in C. Ada wird ebenfalls für LowLevel Aufgaben verwendet, da hat noch niemand Zeigerarithmetik vermißt.



  • Artchi schrieb:

    Es ist ja nicht so, das die C++-Fanboys sich jede Woche in Java-Foren rumtummeln und gegen Java stänkern. Denk mal darüber nach, wer hier von beiden Seiten Minderwertigkeitskomplexe hat? 🙄

    Sind es:

    a) die C-Fanboys die mit C ihr Geld verdienen?

    oder:

    b) die C++-Fanboys die mit Java ihr Geld verdienen?



  • Hi ~john,

    was das Programm zu tun hat entscheide ich und nicht ein Compiler. Wenn man
    nicht einmal mit Zeigern etc umgehen kann sollte man es lassen. Die ganzen
    "Typ"- und sonstwas-Prüfungen ? Wozu denn ? Weil man nicht mehr durchblickt ?
    Für BWLer ???



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



  • 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


Anmelden zum Antworten