Ist C++ wirklich so schlecht?

Gregor

Original erstellt von Matt:
**
ich hab in meinem beitrag kein wort über java verloren. da java genau so wie c/c++ zu den hochsprachen zählt meinte ich das auch nicht mit quick und dirty. viel eher meinte ich so teile wie FoxPro oder VB und der gleichen. die zeit die ich beim programmieren gewinne verliere ich wieder bei der fehlerbehebung beim kunden. ausserdem sind diese sprachen ja wohl um welten langsamer als c/c++ und java. wer gut c++ programmieren kann schaft in der gleichen zeit viel schnellere und stabielere programme.
**

OK! Da habe ich dich wohl falsch verstanden! Ich sage dann einfach mal: Sorry! Ich kenne FoxPro und VB eigentlich garnicht, deshalb kann ich dazu nichts sagen!

kartoffelsack

Du hast glaub den falschen Beruf gewählt ... Als Metzger wärs besser aufgehoben da wärs egal ob du nen billiges oder nen teures messer benutzt ...

Ich könnt mich jetzt ärgern und fragen, ob Du vielleicht die falsche Grammatik für Deinen Beitrag gewählt hast. Aber lassen wir das...

Tatsache ist nunmal dass ich Entwickler kenne - und ich kenne ein paar Leute aus ein paar recht erfolgreichen kleinen Software-Firmen - die einfach nicht die krassen c++-Gurus sind, und die haben gewisse Probleme mit c++. Damit meine ich nicht, dass die Programme nicht laufen, sondern damit meine ich, dass eine z.T. unansehliche Mischung aus C, C++ aus Vorstandard-Zeiten, iso-C++ und c++-Erweiterungen des jeweiligen Compilerherstellers ist. Und ehrlich gesagt glaube ich, dass das in vielen Firmen so ist.
Und was mich angeht: mir gefällt c++ und deswegen verbringe ich manchmal viel Zeit auszuprobieren, wie man etwas elegant lösen kann anstatt es schnell so zu machen, dass es funktioniert. Die Erfahrung, die ich damit sammle bringt mir in diesem Projekt aber oft nichts, vielleicht im nächsten. Tatsache ist aber, dass ich dieses Projekt ohne die Rumprobiererei evtl. schneller hätte machen können. Manchmal mache ich aber auch Sachen nicht elegant sondern so, dass sie schnell laufen und wenn ich mir den Code dann drei Wochen später wieder angucke, stehn mir die Haare zu berge. Und wer als Entwickler nach Fertigstellung seines unter Zeitdruck entstandenen Projekts sagt, dass die Architektur seinen Programms perfekt und er rundherum zufrieden damit ist, ist imho entweder ein Genie, ein Guru mit einigen Jährchen mehr Erfahrung als ich, nicht ehrlich zu sich selber oder er hat wirklich keine Ahnung vom Software-Design und nichts dazugelern.

Aber Selbst da wärs wichtig wie man nen Steak schneidet und nicht wie schnell ...

Du musst tolle Projektleiter haben. Meinen ist es nämlich überhaupt nicht unwichtig, wie schnell das Steak geschnitten ist bzw. wie schnell das Projekt fertig ist.

in welcher firma arbeitest du nicht das ich ausversehen mal software von euch kaufe. *grinz*

Was sagst Du jetzt, wenn ich MS sage?

Is gelogen, aber keine Sorge, die Wahrscheinlichkeit, dass Du etwas von uns kaufst geht gegen Null

[ Dieser Beitrag wurde am 20.01.2003 um 16:01 Uhr von kartoffelsack editiert. ]

Daniel E.

Original erstellt von Bashar:
**Über Korrektheit ging es in dem Thread noch nicht, und ich fürchte, da scheidet C++ ganz mieserabel ab (natürlich noch unterboten von C).
**

C++ ist hier schlechter als C, weil es viel zu komplex und undurchsichtig ist. Man kann quasi die Korrektheit eines C++-Programmes nicht beweisen.
Es gibt eine Norm (IEC 1508) zum Thema sicherheitskritische Software und da wird C 'sicherer' als C++ eingestuft. Natürlich sind beide Sprachen im Endeffekt für diesen Anwendungsbereich untauglich. Im Zweifel darf man SPARK nutzen.

Gregor

Original erstellt von champus:
**welche sprache ist besser? c c++, java, perl ...
das ist doch alles unsinn. die aufgabenstellung und das wissen des devs legt die sprache fest. einen hw treiber wuerde ich nicht unbedingt versuchen, in java zu realisieren. ich bin eigentlich c fanatiker, nutze aber manchmal auch andere sprachen, weil es einfach schneller geht.
**

Hat hier einer etwas von generell besser oder so gesagt? Ich glaube nicht. Wenn man Sprachen vergleicht, dann geht es doch genau darum, herauszufinden, was wofür warum besser geeignet ist. Es geht nicht um eine generelle Entscheidung für oder gegen eine Sprache.

Ich habe den Eindruck, dass C/C++ sehr gut ist, wenn es um systemnahe Programmierung geht, oder wenn es wirklich auf die Performance ankommt. VB wird zum Beispiel gut sein (nachdem, was man so hört), wenn man auf die Schnelle eine GUI braucht, aber nicht viel dahinter. Java sehe ich bei anderen Dingen im Vorteil und für C# sehe ich kein Anwendungsgebiet, in dem es sich deutlich von allen anderen Sprachen zum Positiven hin abhebt.

Matt

Original erstellt von kartoffelsack:
**Was sagst Du jetzt, wenn ich MS sage?

Is gelogen, aber keine Sorge, die Wahrscheinlichkeit, dass Du etwas von uns kaufst geht gegen Null

[ Dieser Beitrag wurde am 20.01.2003 um 16:01 Uhr von [qb]kartoffelsack** editiert. ][/QB]

gottseidank verwende ich linux.
nein mal im ernst das sollte nur en kleiner scherz sein.
es hörte sich in deinem beitrag nur so an als seien deine kolegen nicht so qualifiziert, aber da ihr ja nich MS seit kann man ja noch hoffen. *war wieder en scherz*

[ Dieser Beitrag wurde am 20.01.2003 um 16:21 Uhr von Matt editiert. ]

Lars

Original erstellt von Gregor:
C# sehe ich kein Anwendungsgebiet, in dem es sich deutlich von allen anderen Sprachen zum Positiven hin abhebt.

ich sehe bei C# kein Anwendungsgebiet, wo es vor dem Erscheinungsdatum von C# keine geeignete Sprache gab die das schon konnte.

Bashar

Original erstellt von Daniel E.:
C++ ist hier schlechter als C, weil es viel zu komplex und undurchsichtig ist. Man kann quasi die Korrektheit eines C++-Programmes nicht beweisen.
Es gibt eine Norm (IEC 1508) zum Thema sicherheitskritische Software und da wird C 'sicherer' als C++ eingestuft. Natürlich sind beide Sprachen im Endeffekt für diesen Anwendungsbereich untauglich. Im Zweifel darf man SPARK nutzen.

C an sich ist weder komplex noch undurchsichtig: Die damit geschriebenen Programme sind es. Zumindest wenn sie eine gewisse Komplexität haben.

Diese Norm scheint von Software auszugehen, die streng nach Schema F, erst detaillierte Spezifikation auf Papier bevor der Rechner angeschaltet wird, geschrieben wird, auszugehen. Mag im sicherheitskritischen Bereich OK sein. Da nützt einem dann auch die ganze Abstraktionsfähigkeit einer Sprache nicht mehr viel, da die Denkarbeit bereits erledigt wurde. Also ist C so gut wie alles andere.

HumeSikkins

Hallo,
also ich halte es für ein riesen Grücht (oder einen Marketing-Trick), dass Java Programme per se leichter zu warten sind oder das Java leicht zu erlenen ist.

Wer einmal so richtig miese Java-Programme gesehen hat, wird sicher zugeben, dass auch Java erlernt werden muss und das auch dies nicht über Nacht geschieht.

Das C++ noch schwerer ist würde ich allerdings niemals bezweifeln. Allerdings wundere ich mich schon ein bischen. Wenn C++ wirklich so scheiße wäre, wie ihr teilweise behauptet, dann frage ich mich warum es immer noch für *neue* Projekte eingesetzt wird. Hinter C++ steckt keine Riesenfirma die irgendwas pusht und ich habe auch noch nie einen "C++ Werbespot" gesehen.

Zum Thema Produktivität. Was soll das eigentlich sein? Was genau will man messen?
C. Jones hat mal ausführlich begründet (als Antwort auf den Artikel "No silver bullet" von F.P. Brooks), warum Qualität letztlich ein viel besserer Maß als Produktivität ist.

Und im Punkto Qualität steht C++ in meinen Augen Java keinesfalls nach (auch wenn das vielleicht nur für C++ Experten gilt). Nur wenige Sprachen bieten soviele und so reichhaltige Ausdrucksmittel. Man muss halt nur wissen, wie man diese richtig einsetzt.

Gregor

also ich halte es für ein riesen Grücht (oder einen Marketing-Trick), dass Java Programme per se leichter zu warten sind oder das Java leicht zu erlenen ist.

1. Keiner hat gesagt, dass Java leicht zu erlernen ist. Es wurde nur gesagt, dass es deutlich leichter als C++ zu erlernen ist.

2. Ich halte es nicht für ein Gerücht. Ich denke, dass das die geringere Komplexität impliziert.

Wer einmal so richtig miese Java-Programme gesehen hat, wird sicher zugeben, dass auch Java erlernt werden muss und das auch dies nicht über Nacht geschieht.

Ich habe noch kein richtig mieses Java-Programm gesehen (auch kein wirklich tolles), trotzdem gebe ich dir Recht, dass jemand, der nicht gelernt hat, zu programmieren, wohl nicht programmieren kann. Java hat (so hört man) sehr viel stärker mit Leuten zu kämpfen, die denken, sie könnten gut programmieren, als C++. Da Java leichter zu lernen ist, als C++, wird es stärker von Programmierern genutzt, die nicht gut programmieren können.

dann frage ich mich warum es immer noch für *neue* Projekte eingesetzt wird.

Das frage ich mich allerdings bei vielen Projekten auch. Es wundert mich etwas, dass du dir die Frage stellst und nicht die Antwort präsentierst. Ich denke, du gehörst hier zu den Leuten, die am meisten Ahnung von C++ haben. Da solltest du doch die Vorteile von C++ am ehesten kennen und begründen können, oder?

Zum Thema Produktivität. Was soll das eigentlich sein? Was genau will man messen?
C. Jones hat mal ausführlich begründet (als Antwort auf den Artikel "No silver bullet" von F.P. Brooks), warum Qualität letztlich ein viel besserer Maß als Produktivität ist.

Ich sehe eher ein Problem, Qualität zu messen. Was soll das eigentlich sein und wie soll man das messen. In der Studie oben wird Produktivität in Codezeilen gemessen. Wenn C++-Programme deutlich kürzer als Java-Programme wären, dann würde es diw ganze Studie relativieren. Allerdings zweifele ich das doch ganz stark an und behaupte eher das Gegenteil. Da es sich bei der Studie nur um einen Programmierer gehandelt hat, ist anzunehmen, dass bei beiden Projekten eine ähnliche Qualität herauskam.

Und im Punkto Qualität steht C++ in meinen Augen Java keinesfalls nach (auch wenn das vielleicht nur für C++ Experten gilt). Nur wenige Sprachen bieten soviele und so reichhaltige Ausdrucksmittel. Man muss halt nur wissen, wie man diese richtig einsetzt.

1. Wer ist schon C++-Experte? Davon gibt es doch eher wenige, oder? Insofern deute ich deine Aussage als ein "Man kann auch mit C++ Qualität produzieren, auch wenn die meisten es wohl nicht schaffen!".

2. Viele und reichhaltige Ausdrucksmittel implizieren IMHO viele verschiedene Fehler, die alle sehr unterschiedlich sein können. Keine Frage: Sie erlauben auch elegante Lösungen, die ohne diese Ausdrucksmöglichkeiten nicht zu Stande kommen würden.

HumeSikkins

Es wundert mich etwas, dass du dir die Frage stellst und nicht die Antwort präsentierst. Ich denke, du gehörst hier zu den Leuten, die am meisten Ahnung von C++ haben. Da solltest du doch die Vorteile von C++ am ehesten kennen und begründen können, oder?

Falsch gedacht. Ich bin Informatik-Student kein Projektleiter, Software-Techniker, Programmierer oder sonste was. Meine Ahnung von C++ beschränkt sich auf ein klein wenig theoretische Kentnisse. Diese beschränken sich aber auch *Standard*-C++. Ich habe keine Ahnung von der realen Welt.
Das ist auch der Grund, warum ich selten bei solchen Diskussionen mitrede. 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.

Ich habe noch kein richtig mieses Java-Programm gesehen

Das wundert mich aber doch sehr. Java *zwingt* einen zur OOP und nur ganz wenige haben OOP wirklich verstanden. Die meisten besitzen ein hundsgemeines und gefährliches Halbwissen. Einige haben schlicht weg überhaupt keinen Plan. Und daraus resultieren dann (in meinen Augen) die miesesten Programme. Unwartbar, riesen Abhängigkeiten, scheiß Performance und was es sonst noch schönes gibt. In der Uni hatte ich z.B. letztens ein Beispielprogramm in dem ein High-Level-Package von *allen* Low-Level-Packages abhing. Ich wiederhole: Von allen!
Der Programmierer kannte zwar die Syntax von Java, nur wie man die Sprache effektiv einsetzt, dass wusste er scheinbar nicht.

Wenn C++-Programme deutlich kürzer als Java-Programme wären

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. Aber ACHTUNG: Wie oben bereits erwähnt, ich bin Student kein Programmierer. Es kann also gut sein, dass meine Programme nicht repräsentativ sind.

Wer ist schon C++-Experte? Davon gibt es doch eher wenige, oder?

Och ich denke da gibt's ne ganze Menge. Nur wahrscheinlich nicht halbsoviele wie selbsternannte oder Möchtegernexperten.

Man kann auch mit C++ Qualität produzieren, auch wenn die meisten es wohl nicht schaffen!".

Wäre nicht meine Aussage. Ich bin nur der Meinung, dass Qualität nicht vom Himmel fällt. Du (allgemein. Nicht Gregor) kannst den Leuten nicht dauernd verklickern, dass Programmierern was für Doofe ist und echte Könner (im Sinne von Informatikstars) niemals programmieren und dann erwarten, dass die Doofen tolle Qualität hervorbringen. So nach dem Motto: Ich mache das Modell und den Rest macht der Bleistift. Und wenn das nicht klappt, dann ist die verwendete Sprache scheiße. So läuft das in meinen Augen nicht.

Gregor

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.

kartoffelsack

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. ]

Matt

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++.

Shade Of Mine

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?

Gerard

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,

Shade Of Mine

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.

Bashar

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. ]

Daniel E.

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.

Bashar

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. ]

Gerard

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