3. Ist C++ wirklich so schlecht?

Ist C++ wirklich so schlecht?

  • G

    Ich stimme dir in jedem Fall zu, dass Programmieren keine Beschäftigung für dumme Leute ist. Wer gut programmieren will muss ne ganze Menge wissen und muss dieses Wissen auch anwenden können. Es ist also nicht nur Intelligenz notwendig, sondern auch Wissen.

    Also meine C++ Programme sind immer deutlich kürzer als die entsprechenden Java-Programme. Allein schon weil ich nicht andauernd 752 try-catch-Blöcke aufschreiben muss.

    Naja! Die Exceptions beschränken sich bei Java größtenteils auf die schon vorgegebenen Exceptions aus der Standardbibliothek. IMHO treten bei größeren Projekten in Java garnichtmal so viele try-catch-Blöcke auf. In meinem Projekt ist glaube ich eine von 148 Klassen eine Exception und die ist eigentlich auch unnötig und wird wohl irgendwann beseitigt. Außerdem haben, bei mir zumindest, die wenigsten Klassen viel mit der Standardbibliothek zu tun.

    ...genauso, wie du bei C++ kein try-catch brauchst, brauchst du bei Java kein delete. Um zu sehen, welcher Code größer ist, müßte man wohl ein nicht ganz kleines Prohekt in C++ und in Java schreiben und dann vergleichen. Fänd ich eigentlich ganz interessant.

    0
  • K

    delete brauchts Du in gutem c++ auch nicht - oder zumindest nicht direkt bzw. selten. 😉

    Aber wie machst Du ein Java-Programm exception-sicher ohne try-catch-finally

    Normalerweise dürften c++-Programme aber ne ganze Menge mehr Code haben. Wegen der Header.

    [ Dieser Beitrag wurde am 21.01.2003 um 10:12 Uhr von kartoffelsack editiert. ]

    0
  • M

    ich glaube wir sollten den thread umbennen in C++ vs. Java

    ich denke jeder sollte das verwenden mit dem er am beste klar kommmt. c++ is halt nunmal nicht für jeden geeignet, aber als richtiger programmierer sollte man wenigstens eine hochsprache beherschen sei es nun java oder c++.

    0
  • S

    Original erstellt von Gregor:
    **
    Naja! Die Exceptions beschränken sich bei Java größtenteils auf die schon vorgegebenen Exceptions aus der Standardbibliothek. IMHO treten bei größeren Projekten in Java garnichtmal so viele try-catch-Blöcke auf. In meinem Projekt ist glaube ich eine von 148 Klassen eine Exception und die ist eigentlich auch unnötig und wird wohl irgendwann beseitigt. Außerdem haben, bei mir zumindest, die wenigsten Klassen viel mit der Standardbibliothek zu tun.

    ...genauso, wie du bei C++ kein try-catch brauchst, brauchst du bei Java kein delete. Um zu sehen, welcher Code größer ist, müßte man wohl ein nicht ganz kleines Prohekt in C++ und in Java schreiben und dann vergleichen. Fänd ich eigentlich ganz interessant.**

    delete p;
    ist eine Zeile lang
    ausserdem kann man sich mit smart pointer das delete auch sparen :p

    try
    catch
    finally
    schon 3 zeilen. und man braucht zum catchen und zum finallyien auch noch code.

    naja, aber ich kenn Java nicht besonders gut, wenn der aufbau aber ähnlich wie C# ist (wovon ich ausgehe), dann gibt es doch massenweise try catch finally blocks oder?

    in meinen C++ Programmen habe ich EINEN try block mit 2-3 catch hinten dran...
    in C# habe ich an jeder ecke und ende diese blöcke - OK, kann daran liegen dass ich C# nicht gut kann...

    also, wieviele try-blöcke kommen bei dir so vor?

    0
  • G

    ob

    if(!func_call())
    // fehler behandlung

    oder

    try
{
    func_call();
}
catch(const efunc_call & e)
{
   // fehler behandlung
}

    gewöhnungs sache? das try & catch kann man sogar besser lesen, weil man sieht sofort es ist eine fehler behandlung und man sieht genau was behandlet wird

    bei den if müss es nicht fehler behandlung sein und man muss auch in die docu kucken um zu erfahren um welchen fehler es sich handelt

    was ich aber schlecht finde, den lib schreiben wird es zu leicht gemacht, oh hier gibts ein problem, throwen wir mal was, soll sich der user um das problem kümmern
    und der user erstickt in try & catches,

    0
  • S

    Original erstellt von Dimah:
    **ob

    if(!func_call())
    // fehler behandlung

    oder

    try
{
    func_call();
}
catch(const efunc_call & e)
{
   // fehler behandlung
}

    gewöhnungs sache? das try & catch kann man sogar besser lesen, weil man sieht sofort es ist eine fehler behandlung und man sieht genau was behandlet wird
    **

    Eine Funktion liefert einen sinnvollen Wert zurück. Wenn die Funktion fehl schlägt fliegt ne Exception. dafür brauch ich aber kein try catch - da der caller erstmal garnix machen kann. erst viel später wird die exception gefangen, ausgewertet und uU darauf reagiert.

    wieviele try catches hast du denn in deinen Programmen? ich meistens EINS. ab und zu kommt ein 2. oder 3. an zentralen punkten dazu... das wars schon.

    auf welche lib spielst du an? nimm mal die STL - außer bei at() wirft die nie.

    0
  • B

    Original erstellt von Shade Of Mine:
    **erst viel später wird die exception gefangen, ausgewertet und uU darauf reagiert.
    **

    Funktioniert aber in Java nicht, weil es keine Destruktoren gibt, die beim Stack Unwinding aufgerufen werden. Also brauchst du doch zumindest try..finally. Und so gut kenn ich Java nun nicht, dass ich sagen könnte, ob catch (mit weiterwerfen der Exception) in dem Fall benötigt wird oder nicht.

    BTW: In Lisp wird der Handler *vor* dem Unwinding aufgerufen.

    Edit: Quote ausgebessert

    [ Dieser Beitrag wurde am 21.01.2003 um 15:22 Uhr von Bashar editiert. ]

    0
  • D

    Original erstellt von Bashar:
    Also ist C so gut wie alles andere.

    Kaum. Beim Umsetzten eines Verfahrens in eine Programmiersprache sollte man auch denken. 🙂

    C unterstützt nun mal einige Fehler sehr gut und direkt. Zum Beispiel Bufferoverflows. Es gibt AFAICS kein gutes Verfahren um diese aufzuspüren (zumal manchmal Pufferüberschreitungen auch [pseudo-]legal sind). Andere Sprachen schalten diese Fehlerklassen eben von vorneherein fast komplett aus.

    0
  • B

    Daniel E.:C++ mit den richtigen Techniken zum Beispiel.

    Es geht mir nicht um C vs. Ada oder SPARK oder was weiß ich, sondern um die Behauptung, C++ sei noch unsicherer als C.

    [ Dieser Beitrag wurde am 21.01.2003 um 16:28 Uhr von Bashar editiert. ]

    0
  • G

    Original erstellt von Shade Of Mine:
    Eine Funktion liefert einen sinnvollen Wert zurück. Wenn die Funktion fehl schlägt fliegt ne Exception. dafür brauch ich aber kein try catch - da der caller erstmal garnix machen kann. erst viel später wird die exception gefangen, ausgewertet und uU darauf reagiert..

    machen den java programmierer try & catches aus spass oder auch wenn sie nicht daruf reagieren können?

    Original erstellt von Shade Of Mine:
    **wieviele try catches hast du denn in deinen Programmen? ich meistens EINS. ab und zu kommt ein 2. oder 3. an zentralen punkten dazu... das wars schon.

    auf welche lib spielst du an? nimm mal die STL - außer bei at() wirft die nie.**

    meine programme sind aber etwas realitäts fremd und ignorieren oft mögliche fehler, aber ich kann mir vorstellen das mit wenigen try & catches es schwerer ist ein Programm nach einer Exception wieder zum laufen zu bringen (Nur zum Fehler melden sind Exception zu schade, IMHO)

    das mit der lib habe ich irgend wo aufgeschnapt

    0
  • M

    Original erstellt von Dimah:
    **meine programme sind aber etwas realitäts fremd und ignorieren oft mögliche fehler, aber ich kann mir vorstellen das mit wenigen try & catches es schwerer ist ein Programm nach einer Exception wieder zum laufen zu bringen (Nur zum Fehler melden sind Exception zu schade, IMHO)
    **

    du sollst auch wenn möglich so programmieren das keine exceptions entstehen, dann brauchst du auch keine try {} catches mehr.

    0
  • G

    Nur mal so als Info:

    Ich habe mir eben ein kleines Programm geschrieben, was alle "try", "catch" und "finally" in meinem Projekt zählt. Das Ergebnis ist:

    try : 17
    catch : 33
    finally : 0

    Das Projekt umfaßt mehr als 7000 Zeilen (ohne Leerzeilen und ohne Kommentare).

    Das macht somit nichtmal 1% des Codes aus.

    0
  • S

    kein finally?
    das haut meine ganze Theorie über den Haufen - also vergesst was ich gesagt habe.

    0
  • H

    kein finally?
    das haut meine ganze Theorie über den Haufen

    In dem Moment wo du kritische Resourcen angefordert hast (und auch wieder freigeben willst), brauchst du auch ein finally (wenn du nicht alles doppelt machen willst).

    So habe ich es zumindest an der Uni gelernt und so sehe ich es auch in Java-Büchern und Artikeln.

    0
  • G

    Ich gebe zu, dass ich in dem Projekt bisher so gut, wie keine ernsthafte Ausnahmebehandlung mache. 🙄 Es werden also früher oder später noch ein paar "finally" dazukommen. ...es werden auch noch ein paar "try" und "catch" dazukommen (zum Beispiel bei möglichen Plätzen für OutOfMemoryExceptions). Das ändert aber nichts daran, dass sich das im Großen und Ganzen nahezu garnicht auf die Codegröße auswirkt.

    0
  • D

    Original erstellt von Bashar:
    [Es geht] um die Behauptung, C++ sei noch unsicherer als C.

    Auf jeden Fall formal sehr viel schwieriger zu verifizieren, weil viel komplexer.

    Die 'richtigen Techniken' können auch mal das Falsche tun.

    0
  • P

    Java is also between 30% and 200% more productive, in terms of lines of code per minute.

    zu deutsch: "in java braucht man fuer alles 30 bis 200 prozent mehr zeilen"

    und "7 jahre c++ erfahrung" im verhaeltnis zu "paar wochen java" klingt imposanter als es ist. mit einer sprache lernt man programmieren, das dauert eine weile, fuer alle weiteren braucht man dann halt nur noch paar wochen. insbesonderen bei der aehnlichkeit von java und c++. also kann man sagen, der konnte beides gleich gut.
    und wie man bei einem experiment mit einer (1!) versuchsperson zu einer konfidenz von 95% kommen kann ist mir schleierhaft.

    c/c++ erreicht fast assembler nahe geschwindigkeit.
    😃

    4. C++-Programme werden in der Regel schneller als Assembler-Programme ausgeführt, weil die Compiler besser optimieren können, als es der Mensch kann.

    hm. dann wurden die compiler wohl von einem compiler entwickelt?

    ganze am anfang wurde gefragt, was man mit java klassen machen kann, was man mit c++ klassen nicht kann: einen anderen konstruktor der selben klasse aufrufen. und super ist auch manchmal nicht schlecht.

    meine meinung zu java: klobig, fuehlt sich fast an wie pascal. ich kann mir eine welt ohne templates nicht mehr vorstellen. damit kann man mit einer einzigen zeile quasi unendlich produktiv sein.

    0
  • G

    zu deutsch: "in java braucht man fuer alles 30 bis 200 prozent mehr zeilen"

    🙂 ...lern mal Englisch. Ich habe gehört, dass das ganz nützlich sein soll! 🙂

    hm. dann wurden die compiler wohl von einem compiler entwickelt?

    Hast du schonmal nen Menschen gesehen, der mp3s abspielen kann? mp3-Player wurden schließlich auch von Menschen entwickelt. 🙂

    meine meinung zu java: klobig, fuehlt sich fast an wie pascal. ich kann mir eine welt ohne templates nicht mehr vorstellen. damit kann man mit einer einzigen zeile quasi unendlich produktiv sein.

    Ich habe von dir mal ein paar Fragen im Java-Forum gesehen. Ich habe dich da mehrfach darauf hingewiesen, dass du offenbar versuchst, Java wie C++ zu verwenden. Es ist klar, dass das nicht gut geht und, dass einem Java dann absolut schlecht vorkommt. Wenn du Java so verwendet hättest, wie man Java verwenden sollte, dann wäre dir Java auch nicht klobig und so vorgekommen. Java ist IMHO eine sehr mächtige und sehr schöne Sprache. C++ ist noch mächtiger, dafür aus meiner Sicht aber absolut hässlich.

    Soo ähnlich sind sich Java und C++ nicht und es geht nicht so schnell, umzusteigen. Man findet vielleicht leicht in die andere Sprache hinein (da Syntax und Konzepte teilweise übereinstimmen), das heißt aber noch lange nicht, dass man bald gut in der anderen Sprache programmieren kann. Es dauert ja allein schon eine gewisse Zeit, bis man weiß, wo man was in der jeweils neuen Standardbibliothek finden kann und was überhaupt da ist.

    0
  • H

    meine meinung zu java: klobig, fuehlt sich fast an wie pascal

    Java ist IMHO eine sehr mächtige und sehr schöne Sprache. C++ ist noch mächtiger, dafür aus meiner Sicht aber absolut hässlich.

    Seht ihr. Das war der Grund warum ich folgende Aussage formuliert habe:

    Ich kann dazu keine *fachliche* Aussage treffen. Nur meine Meinung kundtun. Und diese ist dann eher auf Emotionen, denn auf Wissen begründet. Keine gute Ausganslage um sinvoll zu diskutieren.

    Scheinbar bin ich nicht der Einzige hier, der vor diesem Problem steht.

    Ich habe den Text zwar schon mal gebracht, als Konter gefällt er mir hier aber sehr sehr gut 🙂

    Java, the virtual success. Java improves on C++, adding some fundamental features such as
    garbage collection, tightly integrated thread support, and the ever popular
    "Write Once, Debug Everywhere" model. But while Java managed to get a few things right,
    or at least better, it hugely misses the boat in some very fundamental areas:
    there is just enough type checking to get in your way, but not enough to ensure your safety.
    There is no genericty (templates or similar), there is no support for invariant assertions
    (as in Eiffel), it's not as flexible as Objective C or Smalltalk, not as elegant as Eiffel,
    and not as fast as C++. This isn't meant to be a lengthy bash at Java, but as one pundit
    put it "Java has the blazing speed of Smalltalk and the elegant simplicity of C++."

    Die Punkte type checking, templates und invariant assertions (bzw. Pre-Postconditions: siehe Probleme mit Template Method und Interfaces) sehe ich wirklich als *fachliche* Kritikpunkte.

    0
  • M

    Original erstellt von Gregor:
    **...lern mal Englisch. Ich habe gehört, dass das ganz nützlich sein soll! 🙂
    **

    Nicht mit dem Finger zeigen, da weisen 4 Finger der gleichen Hand auf Dich!

    Lies seine Aussage noch mal _ganz_ _genau_ und Du wirst sehen, daß er sehr wohl Englisch kann, aber Probleme mit Aussagen von Werbetextern hat. 🙂

    0
Anmelden zum Antworten