C schneller als C++ ?

Helium

natürlich kann man OOP mit C nachbilden, aber das kann ich mit Assembelr auch

OK, dann hätte ich ein möglichst kurzes Beispiel in Assembler bitte.

@Mr.N: Ich glaube dir schon, da ich der selben Ansicht bin.

Daniel E.

Original erstellt von junix:
Das Probelm bei C-Programmierern die nen C++-Compiler haben ist schlicht das völlig andere Denken das durch C eingeimpft wurde.

Du hast mich nicht verstanden. C++-Programme enthalten mehr Fehler als C-Programme, von Leuten die X Jahre die Sprache kennen, und das ist unabhängig davon, ob ein Programmierer vorher C, Ada, Scheme oder Spanisch gelernt hat weil es so schwer durchschaubar ist und viel Erfahrung sowie ein gutes Händchen im Raten benötigt. Das wurde hier schon mehrfach gesagt.

Original erstellt von TriPhoenix:
IMHO sind alle Sprachen gleich unsicher, sofern man nicht korrekt damit umgeht.

Man kann es einem Programmierer schwerer machen inkorrekt mit der Sprache umzugehen. Das macht dem Programmierer meistens aber keinen Spaß, darum programmiert auch kaum jemand in Spark.

volkard

Ansonsten: bevor mich jemand zum dritten mal falsch versteht

ich versuche mal, da was draus zu lesen.

Nur imho sind die Fehler, die man machen kann in C meistens sichtbarer, wenngelich man da auch fatalere machen kann, während in C++ sich ab und zu was verstecken kann. Für mich persönlich sind mehr sichtbare Fehler "sicherer" als weniger aber dafür versteckte.

aha. also darf ich dein argument dochj übertragen von c nach basic oder gar asm.
die komplizierten konstrukte wie

do
 befehl
while(bedingung);

verbergen ja in wirklichkeit ein schlichtes

marke:
befehl
if(bedingung) goto marke;

natürlich ist unteres viel klarer. nicht zuletzt, weil mit if-goto außer do auch die verwirrenden sprachmittel wile, for, else und switch unnötig werden.
und wer mag behaupten, er habe sich nicht schon mal bei schleifen vertan? schleifen sind einfach gefährlich und kompliziert. und wenn noch switch und continue vorkommen! continue springt in der forschleife aufs semikolon zwischen der laufbedingung und dem weiterschaltungsausdruck! wie verwirrend!

die fehler sind in asm oder besser basicv2 einfach "sichtbarer".

und jetzt nochmal deinen satz:

Für mich persönlich sind mehr sichtbare Fehler "sicherer" als weniger aber dafür versteckte.

und ich kann deine meinung einfach nicht so ganz nachvollziehen.

übrigens verlagern sich die fehler mit der zeit.
anfangs ist ne falsche laufbedingung ein interessanter fehler. über tippfehler redet man nicht, die passieren immer mal und sind in null komma nix weg.
später ist ne schlechte funktionale zerlegung ein fehler, der es einem unmöglich macht, die gewünschte komplexität aufzubauen. über falsche laufbedingungen redet man nicht mehr. die passieren immer mal und sind in null komma nix weg.
so mag es sein, daß man auch mal ne zeit hat, wo man in c keine schlimmen fehler machen würde, aber in c++ viele. das vergeht aber. wenn man vorwiegend über die design-fehler nachdenkt, die einem erst in drei monaten das knie brechen, dann ist meines erachtes nach c++ eine der ungefährlichsten sprachen (man strirbt nämlich bereits nach 2 monaten und hat nen monat gespart).

volkard

C++-Programme enthalten mehr Fehler als C-Programme, von Leuten die X Jahre die Sprache kennen, und das ist unabhängig davon, ob ein Programmierer

das halte ich für quatsch.
fertige c++-programme sind wesentlich wesentlich fehlerfreuer, nicht zuletzt weils typsicherheit mit templates und einfache fehlerbehandlung mit exceptions gibt.

TriPhoenix

Original erstellt von volkard:
aha. also darf ich dein argument dochj übertragen von c nach basic oder gar asm.
die komplizierten konstrukte wie
do
 befehl
while(bedingung);
verbergen ja in wirklichkeit ein schlichtes
marke:
befehl
if(bedingung) goto marke;
natürlich ist unteres viel klarer. nicht zuletzt, weil mit if-goto außer do auch die verwirrenden sprachmittel wile, for, else und switch unnötig werden.
und wer mag behaupten, er habe sich nicht schon mal bei schleifen vertan? schleifen sind einfach gefährlich und kompliziert. und wenn noch switch und continue vorkommen! continue springt in der forschleife aufs semikolon zwischen der laufbedingung und dem weiterschaltungsausdruck! wie verwirrend!

nein, so kann man das nicht ansehen. Was ich meine sind dinge wie z.B. Implizite Destruktorenaufrufe. Sowas ist versteckt, denn sie haben kein Äquivalent im Programmtext ( } zählt hier nun wirklich nicht). Destruktoren sind definitiv eine praktische Sache, man muss sich nur seines Schrittes bewusst sein und an solche Sachen denken. Eine Übersetzung von deinem C-Beispiel in Basic oder Assembler ändert nur die Schreibweise der Instruktionen, da ist nichst dran versteckt.

übrigens verlagern sich die fehler mit der zeit.
anfangs ist ne falsche laufbedingung ein interessanter fehler. über tippfehler redet man nicht, die passieren immer mal und sind in null komma nix weg.
später ist ne schlechte funktionale zerlegung ein fehler, der es einem unmöglich macht, die gewünschte komplexität aufzubauen. über falsche laufbedingungen redet man nicht mehr. die passieren immer mal und sind in null komma nix weg.
so mag es sein, daß man auch mal ne zeit hat, wo man in c keine schlimmen fehler machen würde, aber in c++ viele. das vergeht aber. wenn man vorwiegend über die design-fehler nachdenkt, die einem erst in drei monaten das knie brechen, dann ist meines erachtes nach c++ eine der ungefährlichsten sprachen (man strirbt nämlich bereits nach 2 monaten und hat nen monat gespart).

Hm, da istd ie Frage ob Designfehler noch mit Sicherheit zu tun haben. Denn Designfehler sieht man wenigstens, meistens rennt man früher oder später mitm Kopf dagegen
Aber Anyway, ich denke man kann sowohl in C, als auch in C++ genauso gut "versteckte" Designfehler aufbauen. Ich programmiere zwar größeres in Java aber man nutzt in beiden (Java/C++) ja mehr oder weniger das OOP-Prinzip und man kann genauso gut in OOP einen Designfehler machen. Den schleppt man dann genauso wie einen C-Designfehler durch und durch und biegt immer mehr hier und da zurecht bis es ienfach nicht mehr geht. Aber ich denke das macht in C keinen Unterschied, solange man dort ebenso strukturiert bleibt wie in C++ (sprich: Funktionen nach Funktionalität in Dateien gruppieren z.B.). Wenn man natürlich alles kunterbunt durcheinander wirft, ists klar, aber wenn man es Strukturiert macht, sehe ich da keinen Unterschied.

[ Dieser Beitrag wurde am 24.05.2003 um 16:28 Uhr von TriPhoenix editiert. ]

[ Dieser Beitrag wurde am 24.05.2003 um 16:29 Uhr von TriPhoenix editiert. ]