C/C++ vs. Java/dotNet/Eiffel/Ada/Modula3/etc.

[Matthias]

hallo matthias,
nun gut dann gebe ich Dir mal ein Beispiel:
Es gibt C++-Programmierer, die wegen der gezeigten Sonderlichkeiten von den integrierten C-Feldern abraten und einem die C++-Template-Klasse vector empfehlen. Ich möchte durchaus unterstellen, dass durch geeignete Code-Optimierung die Vektorklasse genauso speicher- und zeiteffizient sein kann, wie die originalen C-Felder, aber man wird mit dieser Implementierung niemals statische Fehler sofort aufdecken können. Wenn man beispielweise
int a[10];
a[20] = 34;
mit der Vektor-Klasse implementiert, etwa so:
vector <int> a(10);
a[20] = 34;

Hier zeigt sich wieder einmal, daß Du _überhaupt nicht_ zwischen C++ und C differenzierst. Richtig sähe dieser Code nämlich folgendermaßen aus:
vector<int> a(10);
a.at(20)=34;
Lässt man das Programm dann laufen passiert genau das, was passieren sollte:
terminate called after throwing an instance of 'std::out_of_range'
what(): vector::_M_range_check
Aborted
Es wird eine Exception geworfen und das Programm terminiert, weil diese nicht gefangen wird. Also alles in Butter.

dann wird sie den Fehler bestenfalls entdecken, wenn dieser Programmteil ausgeführt wird, obwohl der Fehler schon beim Übersetzen offensichtlich ist.

Zeig mir mal den Compiler, der das zur Compile-zeit erkennt!
Schonmal ein Tipp: der javac kann's nicht:
int[] foo=new int[10];
foo[20]=34;
wird ohne Warnungen übersetzt und führt zu
Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 20
at VektorTest.main(VektorTest.java:4)
Mit anderen Worten ist das Ergebnis exakt dasselbe wie bei C++, und ich habe ersthafte Zweifel daß das bei Ada anders ist.

Außerdem zählt einmal mehr der Vorwurf, dass Sprachfehler nicht durch Hinzufügen weiterer Lösungsansätze aus der Welt zu schaffen sind. Die C-Felder gibt es weiterhin in C++, dürfen benutzt werden und werden auch fleißig genutzt.

Im Rahmen der C-Kompatibilität ist das leider unumgänglich, auch wenn C++ dadurch wahrscheinlich nicht gerade besser wird

C++ bietet unter dem Strich zwei Varianten von Feldern an: Eine unzulängliche und eine völlig unzulängliche. Der Programmierer muss sich jedesmal neu für das jeweils kleinere Übel entscheiden.

Naja, daß das Quatsch ist dürfte der Codeschnipsel oben gezeigt haben.

Gerade Zeiger beinhalten ein Risikio, denke da brauchen wir uns nicht zu streiten.

Dank der Autopointer und Referenzen in C++ kann man sich heute zum Glück oft um Zeiger herumdrücken. Und wenn man gut aufpasst kann man sogar mit Zeigern halbwegs sicher programmieren, dazu gehört dann aber schon einiges Können, aber wie gesagt kann man in C++ oftmals darauf verzichten

[RudBoy]

Hier zeigt sich wieder einmal, daß Du _überhaupt nicht_ zwischen C++ und C differenzierst. Richtig sähe dieser Code nämlich folgendermaßen aus:
vector<int> a(10);
a.at(20)=34;
Lässt man das Programm dann laufen passiert genau das, was passieren sollte:
terminate called after throwing an instance of 'std::out_of_range'
what(): vector::_M_range_check
Aborted
Es wird eine Exception geworfen und das Programm terminiert, weil diesenicht gefangen wird. Also alles in Butter.

Vollkommen richtig erkannt Matthias

Zeig mir mal den Compiler, der das zur Compile-zeit erkennt!
Schonmal ein Tipp: der javac kann's nicht:
int[] foo=new int[10];
foo[20]=34;
wird ohne Warnungen übersetzt und führt zu
Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 20
at VektorTest.main(VektorTest.java:4)
Mit anderen Worten ist das Ergebnis exakt dasselbe wie bei C++, und ich habe ersthafte Zweifel daß das bei Ada anders ist.

Hier der Link schau selber http://de.wikipedia.org/wiki/Ada_%28Pro ... sprache%29

Im Rahmen der C-Kompatibilität ist das leider unumgänglich, auch wenn C++ dadurch wahrscheinlich nicht gerade besser wird

Vollkommen richtig,aber warum ist das so,verstehste nun meine Beweggründe zu Ada zu wechseln

Gerade Zeiger beinhalten ein Risikio, denke da brauchen wir uns nicht zu streiten.

Dank der Autopointer und Referenzen in C++ kann man sich heute zum Glück oft um Zeiger herumdrücken. Und wenn man gut aufpasst kann man sogar mit Zeigern halbwegs sicher programmieren, dazu gehört dann aber schon einiges Können, aber wie gesagt kann man in C++ oftmals darauf verzichten

Du sagst es schon selber und eigentlich ist es auch die Antwort, man muss sich darum nehr oder weniger herumdrücken,darauf habe ich keine Lust mehr.
Es gibt wirklich Sprachen in denen Du Dich nicht mit derart unnötigen Problemen belasten musst. Insofern sind mir dieses Sprachen auch viel lieber, da sie mir die Arbeit sehr erleichtern und sauberen Code ermöglichen.
Unter anderen hat dieses Dokument massgeblich zu meiner Entscheidung beigetragen:
http://atlas.web.cern.ch/Atlas/GROUPS/S ... eOfC++.pdf

Noch eine Info zu Ada, der Compiler stellt ein Novum in der Programmierung da, jeder Ada compiler muss vallidiert sprich den höchsten Sicherheitsüberprüfungen standhalten, das ist einzigartig.

Aber lies selbst in dem von mir angeführten Wikipedia link.
http://de.wikipedia.org/wiki/Ada_%28Pro ... sprache%29

Ada war übrigens die erste standardisierte Hochsprache überhaupt und unterliegt einer stetigen Innovation:
siehe hierzu Zeitafel der Programmiersprachen:
http://de.wikipedia.org/wiki/Zeittafel_ ... ersprachen

Zur Zeit ist die Version 2005 aktuell natürlich dem Standard entsprechend,
Ada 0Y wird auch bald fertig sein und dann standardisisiert und die Compiler vallidiert.

viele Grüsse RudBoy

[ThePhysicist]

Hey RudBoy, ich muss dir zustimmen.

Früher hab ich Pascal programmiert und war sehr zufrieden damit. Hab auch einiges in ASM programmiert, der Geschwindigkeit wegen. Ne Menge Leute (hauptsächlich Komilitonen, besonders Linux-Benutzer ) haben dann gesagt: "Wenn Du vernünftig programmieren willst, kommst Du um C++ nicht herum!" Ich hab das nie so recht verstehen wollen, hab dann aber mal gedacht, versuch ichs mal zu lernen mit "C++ in 21 Tagen". Hab nach 3 Tagen aufgegeben, weil ich es sooo sehr gehasst habe, dass ich am liebsten jemanden erschossen hätte. Und das war wohlgemerkt ein C++-Tutorial, nicht der "C hassen in 10 Tagen"- Kurs
An der Uni hab ich dann Java gelernt, schon wieder diese hässliche Syntax, aber wenigstens keine gotos.

Ich hab erst wieder mit C angefangen, als ich ReactOS entdeckt habe. Und bin nun in der Lage das eine oder andere in C zu schreiben. Hab auch schon einige kleine Patches gebastelt. Die Syntax hasse ich immer noch.

Die Vorteile von C sind: es ist sehr schnell und es ist sehr vielseitig einsetzbar, was man jedoch mit einer deutlich besseren Syntax (Pascal, Ada, Modula, ...) auch hinbekommen würde.
Diese Vorteile sind bei anderen auf der selben Syntax basierenden Sprachen (C++, C#, Java, ...) nicht mehr so sehr gegeben.

Allen C-Verteidigern, lege ich ans Herz, sich doch mal die von RudBoy verlinkten Seiten durchzulesen. Ich muss gestehen, ich war kurz davor das C-Hassen aufzugeben (ja ich habe tatsächlich 2 C-Compiler gleichzeitig installiert), aber der C-Hassen Kurs hat es nochmal verhindert

Ada als aktuelle Programmiersprache??? Gibt es da überhaupt noch Compiler die weiterentwickelt werden für?

Ada wird auch heute noch immer dort eingesetzt, wo es auf Sicherheit ankommt (NASA, Banken, Flugsicherung, Kernkraftwerke etc.) Und der GNAT wird sehr wohl weiterentwickelt GNAT News 2006-03-12 08:34

Zeig mir mal den Compiler, der das zur Compile-zeit erkennt!

Wie wärs mit FreePascal.

Code: Select all

program range;

var
  arr:array[1..10] of integer;

begin
  arr[21]:=2;
end.

Beim übersetzen:

Code: Select all

Target OS: Win32 for i386
Compiling range.pas
189 Kb Free
range.pas(7,6) Error: range check error while evaluating constants
range.pas(9) Fatal: There were 1 errors compiling module, stopping

C mag einige Vorteile haben aber wirklich überzeugend ist die Sprache wirklich nicht. Auch die Pascal-ähnlichen Sprachen haben vielleicht den einen oder anderen Nachteil, aber syntaktisch sind sie einfach viel konsistenter, sicherer und logischer.

[Matthias]

Vollkommen richtig erkannt Matthias

Das ist ja wohl der Gipfel! Du hast nichtmal ansatzweise verstanden was ein C++-vector ist und willst _mir_ erzählen was ich deiner Meinung nach richtig erkannt habe?

Hier der Link schau selber http://de.wikipedia.org/wiki/Ada_%28Pro ... sprache%29

Tja, wer lesen kann ist im Vorteil:

Ada unterstützt Laufzeittests, um Speicherüberläufe, Zugriff auf nicht zugewiesenen Speicher, off-by-one-Fehler und andere, ähnlich geartete Fehler frühzeitig zu erkennen und zu vermeiden.

Mit anderen Worten: Ob der Programmierer aus einem Array herausläuft wird, wie in jeder anderen Sprache auch, zur Laufzeit bestimmt - geht ja auch gar nicht anders.

Vollkommen richtig, aber warum ist das so,verstehste nun meine Beweggründe zu Ada zu wechseln

Das ist so weil es ermöglicht, einen _Arsch voll_ vorhandenen C-Code in C++-Programmen zu verwenden. Außerdem musst du ja keine C-Arrays verwenden, jetzt wo ich dir die Klasse vector erklärt habe.

Du sagst es schon selber und eigentlich ist es auch die Antwort, man muss sich darum nehr oder weniger herumdrücken,darauf habe ich keine Lust mehr.

Mansch, das war doch nur so dahingesagt, mit "herumdrücken" hat das in dem Sinne eigentlich gar nichts zu tun, eigentlich sind Autopointer und Referenzen ziemlich Idiotensicher.

Es gibt wirklich Sprachen in denen Du Dich nicht mit derart unnötigen Problemen belasten musst. Insofern sind mir dieses Sprachen auch viel lieber, da sie mir die Arbeit sehr erleichtern und sauberen Code ermöglichen.

Java bis 1.4 wo man ohne einen Arsch voll unsicherer C-Style-Typecasts (in Ermangelung von Generics) nicht auskam? Nicht gerade sauber, IMO. Und Ada nimmt einem die Speicherverwaltung auch nicht ab - das wäre im embedded- und Hochsicherheitsbereich, wo nunmal oft Echtzeiteigenschaften gefordert werden, auch ziemlich gefährlich. Also, welche Arbeit nimmt mir Ada konkret ab?

Noch eine Info zu Ada, der Compiler stellt ein Novum in der Programmierung da, jeder Ada compiler muss vallidiert sprich den höchsten Sicherheitsüberprüfungen standhalten, das ist einzigartig.

Na und? In 99,9% der Fälle ist nicht der Compiler, sondern der Programmierer schuld, wenn was schief geht, daher zählt das für mich nicht.

Ada war übrigens die erste standardisierte Hochsprache überhaupt und unterliegt einer stetigen Innovation:
siehe hierzu Zeitafel der Programmiersprachen:

C++ wird auch ständig weiterentwickelt und ist standardisiert.[/quote]

An der Uni hab ich dann Java gelernt, schon wieder diese hässliche Syntax, aber wenigstens keine gotos.

Auch in Java gibt's goto. verwenden tut's natürlich, wie in C++, heuzutage keiner mehr.
Ich gebe zu, der asketische Charme der C-Syntax ist etwas gewöhnungsbedürftig, aber wenn man sich einmal daran gewöhnt hat ist's OK und vor allem kompakt und schnell zu schreiben.

Ich hab erst wieder mit C angefangen, als ich ReactOS entdeckt habe.

Wie jetzt, C oder C++? Das ist ein _grundsätzlicher_ Unterschied! C ist Müll, C++ rockt!

Die Vorteile von C sind: es ist sehr schnell und es ist sehr vielseitig einsetzbar, was man jedoch mit einer deutlich besseren Syntax (Pascal, Ada, Modula, ...) auch hinbekommen würde.

Naja, ob die Ada-Syntax jetzt besser ist...
Fakt ist, daß die Performancevorteile von C gegenüber C++ heutzutage recht vernachlässigbar sind, wenn man sich die Performance heutiger Rechner anschaut. Leider sind alle vorhanderen Betriebssysteme nunmal in C geschrieben und daran wird sich so bald nichts ändern...

Allen C-Verteidigern, lege ich ans Herz, sich doch mal die von RudBoy verlinkten Seiten durchzulesen. Ich muss gestehen, ich war kurz davor das C-Hassen aufzugeben (ja ich habe tatsächlich 2 C-Compiler gleichzeitig installiert), aber der C-Hassen Kurs hat es nochmal verhindert

C ist auch wirklich eine recht dreckige Sprache, aber C++ hat wie gesagt so ziemlich alle Nachteile von C erfolgreich ausgebügelt.

Wie wärs mit FreePascal.

Code: Select all

program range;
var
  arr:array[1..10] of integer;
begin
  arr[21]:=2;
end.

Beim übersetzen:

Code: Select all

Target OS: Win32 for i386
Compiling range.pas
189 Kb Free
range.pas(7,6) Error: range check error while evaluating constants
range.pas(9) Fatal: There were 1 errors compiling module, stopping

Hm, hätte nicht gedacht, daß Compilerbauer ihre Zeit mit solchem Zeug verschwenden
Aber mal im Ernst: In so einem einfachen Fall mag das gehen, weil der Array-Index ein Literal ist und damit zur Compile-Zeit feststeht. Interessant wird's aber erst wenn das nicht der Fall ist, und ich wette, daß auch FreePascal dann versagt

C mag einige Vorteile haben aber wirklich überzeugend ist die Sprache wirklich nicht. Auch die Pascal-ähnlichen Sprachen haben vielleicht den einen oder anderen Nachteil, aber syntaktisch sind sie einfach viel konsistenter, sicherer und logischer.

Naja, ein wirklicher Vorteil von C fällt mir jetzt nicht ein. Gut, es ist vielleicht etwas portabler als C++, aber in den meisten Fällen ist C++ einfach die bessere Alternative =)

[RudBoy]

Hallo Matthias,

also ich würde Dir mal raten als Lektüre das von mir verlinkte PDF Dokument aufmerksam ganz durchzulesen. Vielleicht denkst Du dann etwas anders, und argumentierst nicht ganz so dogmatisch.

Dieses Dokument wurde von anerkannten Grössen in der Softwareentwicklung erstellt die einen sehr grossen Erfahrungschatz besitzen. Dann verweisse ich Dich mal zu Projekten die sich Tag für Tag mit Sicherheitsaspekten auseinandersetzen wie zum Beispiel das Projekt Trusted BSD in der Unix Welt das sind ausgewiesener Masen keine bekannten C oder C++ Hasser.
Es gibt ein Unzahl von Projekten die sich genau mit dieser Problemathik auseinandersetzen.
Genauso gibt es aber auch Projekte die jeden Tag aufs Neue beweisen wie fehlerträchtig doch C artige Programme sind, meinetwegen kannst Du das ganz asketisch C++ nennen trifft aber die offiziele Definition der Sprache nicht.

"Während Stroustrup „C mit Klassen“ („C with Classes“) entwickelte (woraus später C++ wurde)"

siehe hierzu:
http://de.wikipedia.org/wiki/C%2B%2B

mfg RudBoy

[Matthias]

also ich würde Dir mal raten als Lektüre das von mir verlinkte PDF Dokument aufmerksam ganz durchzulesen. Vielleicht denkst Du dann etwas anders, und argumentierst nicht ganz so dogmatisch.

Wo argumentiere ich bitte dogmatisch? Im Gegensatz zu Dir habe ich mich ein bißchen mit C++ beschäftigt und konnte damit beweisen, daß das von Dir gebrachte Beispiel völliger Quark ist, aber trotzdem reitest Du weiter auf der angeblich so schlimmen Pointerprogrammierung und manuellen Speicherverwaltung herum, die dank Autopointern und Referenzen in C++ einen nicht geringen Teil ihres Risikos verloren hat!
Irgendwie wird mir das gerade zu dumm hier...

[RudBoy]

also ich würde Dir mal raten als Lektüre das von mir verlinkte PDF Dokument aufmerksam ganz durchzulesen. Vielleicht denkst Du dann etwas anders, und argumentierst nicht ganz so dogmatisch.

Wo argumentiere ich bitte dogmatisch? Im Gegensatz zu Dir habe ich mich ein bißchen mit C++ beschäftigt und konnte damit beweisen, daß das von Dir gebrachte Beispiel völliger Quark ist, aber trotzdem reitest Du weiter auf der angeblich so schlimmen Pointerprogrammierung und manuellen Speicherverwaltung herum, die dank Autopointern und Referenzen in C++ einen nicht geringen Teil ihres Risikos verloren hat!
Irgendwie wird mir das gerade zu dumm hier...

Guten Morgen Matthias,

also der Eindruck kann schon endstehen, und Du unterstellst einfach mal wieder was.
Fakt ist C und C++ Compiler führen auch fehlerhaften C++ sowie C Code aus, da kommt man einfach nicht drum herum.

Selbst C und C++ Compiler sind auch nicht unbedingt kompatibel zu anderen C++ oder C Compilern, das zu dem Thema Standard, wer das nicht wahrhaben will der kann sich davon auf dem von mir verlinkten Wikipedia Dokument nachschauen und sich selbst davon überzeugen:

http://de.wikipedia.org/wiki/C%2B%2B

In letzter Zeit tauchen immer mehr Rootkits auf, die überwiegend nicht mehr in Assembler geschrieben werden sondern explizit C++ nutzen, man bemühe nur die Seiten des MS Bullentin.

Was mich nun wieder zur NET Plattform bringt, dort gibt es den sogenannten managed Code der Sicherheitskriterien explizit entsprechen muss, vereinfacht ausgedrückt.
Anmerkung:
vollkommen richtiger Ansatz.
Sowie den unmanaged Code der eben diesem Kriterien nicht entsprechen muss.

Anmerkung:
Andres Hellsberg der Architekt von NET kritisiert das, man bemühe nur entsprechende Seiten.

Von allen aber wird der unmamaged Code von Sicherheitsexperten auf das schärftste angegriffen, das sind zum überwiegenden Teil (eigentlich nur) C++ Programme da diese den Sicherheitskriterien nicht entsprechen müssen. Dieser unmanaged Code wird dann vom Compiler akzeptiert und ausgeführt.

Quasi eine Notlösung von MS aus Kompatibilitätsgründen zu C++ öffnet aber wieder Hintertüren und eigentlich ein Widerspruch zu NET.

mfg RudBoy

[frik85]

In letzter Zeit tauchen immer mehr Rootkits auf, die überwiegend nicht mehr in Assembler geschrieben werden sondern explizit C++ nutzen, man bemühe nur die Seiten des MS Bullentin.

Und weiter?

"Ein Rootkit (engl., etwa "Administratorenausrüstung") ist eine Sammlung von Softwarewerkzeugen, die nach dem Einbruch in ein Computersystem auf dem kompromittierten System installiert werden, um zukünftige Logins des Eindringlings zu verbergen, Prozesse und Dateien zu verstecken."
http://de.wikipedia.org/wiki/Rootkit

* Kernel Rootkits:
Kernel Rootkits ersetzen Teile des Betriebssystem-Kerns durch eigenen Code

* Userland Rootkits
keinen Zugriff auf der Kernel-Ebene; in einer normalen Library.

Das was du wahrscheinlich meinst sind Userland Rootkits.

Was das ganze mit Programmiersprache zu tun haben soll ist mir ehrlich gesagt schleierhaft. Man kann nämlich sogar mit Visual Basic ein Userland Rootkit erstellen. Praktisch mit allem das interaktion mit dem Betriebssystem bietet.

Das C++ mehr verwendet wird lässt sich darauf zurückführen das man wesentlich schneller fertig ist, als mit ASM.

Und das soll ein Nachteil von C/C++ sein?

[RudBoy]

In letzter Zeit tauchen immer mehr Rootkits auf, die überwiegend nicht mehr in Assembler geschrieben werden sondern explizit C++ nutzen, man bemühe nur die Seiten des MS Bullentin.

Und weiter?

"Ein Rootkit (engl., etwa "Administratorenausrüstung") ist eine Sammlung von Softwarewerkzeugen, die nach dem Einbruch in ein Computersystem auf dem kompromittierten System installiert werden, um zukünftige Logins des Eindringlings zu verbergen, Prozesse und Dateien zu verstecken."
http://de.wikipedia.org/wiki/Rootkit

* Kernel Rootkits:
Kernel Rootkits ersetzen Teile des Betriebssystem-Kerns durch eigenen Code

* Userland Rootkits
keinen Zugriff auf der Kernel-Ebene; in einer normalen Library.

Das was du wahrscheinlich meinst sind Userland Rootkits.

Was das ganze mit Programmiersprache zu tun haben soll ist mir ehrlich gesagt schleierhaft. Man kann nämlich sogar mit Visual Basic ein Userland Rootkit erstellen. Praktisch mit allem das interaktion mit dem Betriebssystem bietet.

Das C++ mehr verwendet wird lässt sich darauf zurückführen das man wesentlich schneller fertig ist, als mit ASM.

Und das soll ein Nachteil von C/C++ sein?

Hallo frk,

gerade wollte ich mich auslogen
na ja das kommt auf den Blickwinkel an

Was ich nur mit meiner Argumentationskette rüberbringen will ist das man nicht nur bei einer Sprache bleiben sollte. Sondern man sollte auch versuchen andere Konzepte zu verstehen, das erweitert den Horizont.
Jeder wählt ja seinen Weg und den sollte man verstehen, bei mir das halt Ada, bei einem anderen vielleicht Oberon um mal ne andere Sprache ins Spiel zu bringen.

Ausserdem kann man durch diese Herangehensweise seinen Werkzeugkasten vergrössern und das für sich beste Werkzeug einsetzen.

Ich erinnere mich noch ganz genau wie Basic Programmierer unter Linux diskriminiert wurden, möchte hier nur ganz bewusst das Kbasic Projekt anführen und die Reaktion des KDE Projekts das bis zur Abspaltung führte der Rest ist Geschichte. Mittlerweile gibt es noch Gambas und das hatt jetzt zu Recht ne sehr hohe Akzeptanz in der Comnunitie Gott sei Dank.

Auch an die Anfeindungen gegen Manuel Icaza kann ich mich noch sehr gut erinnern.
Anmerkung
Wer nicht weiss GNOME Mitbegründer unseglich viele Tools geschrieben, eine Bereicherung in der Softwareentwicklung Ximian usw.. usf...
Jetzt Gründer des Mono Projektes, was ich für eine richtige Innovation halte.
Denke man sollte nie geringschätzig über eine Programmiersprache urteilen, aber andererseits auch nicht deren Nachteile verschweigen.
Man sollte das mal alles im grösseren Kontext sehen.

Und es ist immer von Vorteil mehrere Obtionen zu haben.

Viele Grüsse RudBoy