Warum lassen C/C++ Compiler soviel Müll zu?
-
knivil schrieb:
Ich wuerde sagen, diesen Fehler ruehren daher, das C++ nicht ideomatisch verwendet wurde. Hier ein kleiner Auszug: http://en.wikibooks.org/wiki/More_C%2B%2B_Idioms .
oh ja, das buch sieht verdammt nach pflichtlektüre für jeden c++ coder aus.
knivil schrieb:
logischen fehlern kann einen C++ auch nicht bewahren
Doch, ein gutes Beispiel ist die ist boost::mpl.
ach nö, logische fehler sind denkfehler, hervorgerufen durch schlamperei, unwissenheit, falsche annahmen, usw. keine library kann 'menschliches versagen' dieser art ausgleichen.
u-ser_l schrieb:
"Schlichtheit" ist nicht gleich "Schlichtheit" ...
Ob "Schlichtheit" als Kriterium für Fehlerarmut taugt, hängt davon ab, was genau am betrachteten Formalismus "schlicht" sein soll.
"Schlichtheit" im Sinne von "niedriger Abstraktionsgrad/'dummer' Formalismus" kann idR zu mehr Fehlern führen. Siehe BF oder Maschinencode in Binärdarstellung.
"Schlichtheit" im Sinne von "der Formalismus ist auf wenigen, aber mächtigen Abstraktionen aufgebaut/ 'kluger' Formalismus" kann im Ggteil aber zu weniger Fehlern führen. Siehe OOP.^^stimmt im prinzip, aber um mal wieder auf C und C++ zurückzukommen: der C-formalismus ist im verhältnis zu seiner (relativ) geringen komplexität sehr leistungsstark (in früheren threads sagte ich: c hat einen hohen 'wirkungsgrad'). verglichen mit C++, dessen komplexität um ein vielfaches grösser ist, leistet es nur wenig mehr. d.h. C++ hat einen schlechteren 'wirkungsgrad' als C.
Tachyon schrieb:
Basher schrieb:
Ada ist noch deutlich komplizierter als C++. Trotzdem macht man darin komischerweise meist weniger Fehler.
vielleicht kommt's dir nur so vor, weil du mit C++ mehr vertraut bist.
Ulkig, und das, wo ich beruflich doch fast nur Ada programmiere.
Ada kann ich nicht, nur VHDL, was ja von Ada abstammt. ich hab' dabei nie irgendwas als unangemessen komplex empfunden. was findest du denn an Ada so viel komplizierter als an C++?
pointercrash() schrieb:
Leider hat sich die Welt nicht mehr drum geschert, seit die PCs und dann die µC relativ ressourcenstark geworden sind und die FORTH- Gemeinde nicht dem eigenen Standard folgt, es demnach tausende zueinander inkompatible FORTH- Dialekte gibt, die meist nichtmal gut ans Target adaptiert sind. Dem C/C++/Java- Rush konnte man so nichts entgegensetzen.
du kannst ja mal 'nen forth-interpreter für deine µC portieren. das soll angeblich garnicht so schwierig sein. und dann machste deine kundenspezifischen anwendungen in forth. vielleicht biste damit effizienter als mit der C-hackerei. wir machen sowas (auch auf embedded systemen) mit 'nem BASIC-dialekt. BASIC aus dem grund, weils jeder leicht versteht und als anwender schnell eigene programme schreiben kann.
DStefan schrieb:
Und wenn man das bedenkt, ist es schon fast egal, welche Programmiersprache in einem Projekt verwendet wird. Naja - fast. Objektorientiert sollte sie schon sein
wie sagt man so schön: to a hammer, everything looks like a nail --> http://www.iwriteiam.nl/AoP_OOCH.html
-
Basher schrieb:
du kannst ja mal 'nen forth-interpreter für deine µC portieren. das soll angeblich garnicht so schwierig sein. und dann machste deine kundenspezifischen anwendungen in forth. vielleicht biste damit effizienter als mit der C-hackerei. wir machen sowas (auch auf embedded systemen) mit 'nem BASIC-dialekt. BASIC aus dem grund, weils jeder leicht versteht und als anwender schnell eigene programme schreiben kann.
Ja, so'n FIG- Port ist in drei, vier Tagen halbwegs lebensfähig, hab' ich ja oft genug gemacht.
Das Problem beginnt beim Kunden. Der will C oder C++, wegen der Portabilität - auch in der Wahl des Entwicklers. 'Ne Bindung an einen Port und dessen Entwickler scheuen die wie der Teufel das Weihwasser.
Das Argument kann ich nicht wirklich entkräften, außerdem soll man mit Kunden nicht debattieren außer übern Preis ...
-
Basher schrieb:
der C-formalismus ist im verhältnis zu seiner (relativ) geringen komplexität sehr leistungsstark (in früheren threads sagte ich: c hat einen hohen 'wirkungsgrad').
Eben. Und warum? Weil C die passenden Abstraktionen für portable hardwarenahe Programmierung hat, für die es eigentlich auch gedacht ist.
Basher schrieb:
verglichen mit C++, dessen komplexität um ein vielfaches grösser ist, leistet es nur wenig mehr. d.h. C++ hat einen schlechteren 'wirkungsgrad' als C.
das kann sich aber drastisch ändern, wenn die Projektgröße eine kritische Grenze von, sagen wir mal, 100000 Zeilen übersteigt. Dann werden die Vorteile der OOP durchschlagen, wahrscheinlich unabhängig von der Sprache, und je "wackeliger" die Spezifikation ist, umso mehr.
-
u-ser_l schrieb:
Basher schrieb:
der C-formalismus ist im verhältnis zu seiner (relativ) geringen komplexität sehr leistungsstark (in früheren threads sagte ich: c hat einen hohen 'wirkungsgrad').
Eben. Und warum? Weil C die passenden Abstraktionen für portable hardwarenahe Programmierung hat, für die es eigentlich auch gedacht ist.
richtig, dafür wird C ja auch hauptsächlich verwendet. und für alles was schnell, klein, effizient und direkt auf der CPU laufen soll. alle 3 punkte sind nur noch durch assembler zu schlagen, aber mit asm hat man so gut wie keine abstraktionmöglichkeiten mehr (so wie mit brainfuck z.b.), was den wirkungsgrad (ergebnis/(zeitaufwand+gehirnschmalz)) geringer macht.
u-ser_l schrieb:
Basher schrieb:
verglichen mit C++, dessen komplexität um ein vielfaches grösser ist, leistet es nur wenig mehr. d.h. C++ hat einen schlechteren 'wirkungsgrad' als C.
das kann sich aber drastisch ändern, wenn die Projektgröße eine kritische Grenze von, sagen wir mal, 100000 Zeilen übersteigt. Dann werden die Vorteile der OOP durchschlagen, wahrscheinlich unabhängig von der Sprache, und je "wackeliger" die Spezifikation ist, umso mehr.
kommt drauf an. oop ist kein allheilmittel, obwohl grosse systeme sicherlich davon profitieren. ich glaube aber nicht, dass man's an der zukünftigen zeilenzahl des quelltexts festmachen kann. manche aufgaben schreien nach OOP, andere musst du gewaltsam in ein OO-korsett pressen. wahrscheinlich sollte die erste frage sein, die sich ein softwaredesigner stellt: ist hier oo angebracht oder wäre ein anderes konzept vorteilhafter?
-
ist hier oo angebracht oder wäre ein anderes konzept vorteilhafter?
Deswegen bietet z.B. C++ mehr als nur OOP.
100000 Zeilen übersteigt
In welcher Sprache?
schnell, klein, effizient
Was ist klein, schnell und effizient? Haskell compiliert auch direkt zu Maschinencode oder falls eine Plattform nicht unterstuetzt wird nach C Code. Auch halte ich es fuer sinnfrei, Begriffe aus anderen Zusammenhaengen zu entlehnen und mit deren Bedeutung zu argumentieren z.B. Wirkungsgrad. Dann muessten wir sowieso alle in Lisp programmieren: An Experiment in Software Prototyping Productivity. Schade das auf Java nicht eingegangen wurde und die Loesung in C++ von einem Manager geschrieben wurde. Auch ist das Paper von 1994, also lange bevor echtem C++.
-
knivil schrieb:
Deswegen bietet z.B. C++ mehr als nur OOP.
was denn noch außer OOP und dem Erbgut von C ?
knivil schrieb:
100000 Zeilen übersteigt
In welcher Sprache?
egal - 100000 Zeilen sind in jeder Sprache ein Grund, über einen Umstieg auf OOP zumindest nachzudenken.
Was ist klein, schnell und effizient?
hängt ja bekanntlich von der Aufgabenstellung ab - für numerische Simulationen mit 10 mio. Variablen könnte Fortran klein, schnell und effizient sein, für eine Schach-KI oder einen OS-Kern wohl eher nicht.
-
knivil schrieb:
ist hier oo angebracht oder wäre ein anderes konzept vorteilhafter?
Deswegen bietet z.B. C++ mehr als nur OOP.
deswegen wird dieses barocke ja C++ überhaupt verwendet, weil man meint, in dieser sprache alles nur denkbare zur verfügung zu haben. irgendwie stimmt es ja auch, nur ist es viel schwieriger, umständlicher und fehleranfälliger als in den meisten anderen sprachen.
knivil schrieb:
Auch halte ich es fuer sinnfrei, Begriffe aus anderen Zusammenhaengen zu entlehnen und mit deren Bedeutung zu argumentieren z.B. Wirkungsgrad.
deshalb hab' ichs auch ständig in anführungsstriche gesetzt. mir fiel nix besserers als bezeichnung ein, für das verhältnis nutzen/aufwand o.ä.
-
egal - 100000 Zeilen sind in jeder Sprache ein Grund, über einen Umstieg auf OOP zumindest nachzudenken.
Wieviel Zeilen C oder C++ Code entsprechen wohl 100'000 Zeilen Lispcode ... Auch gibt es weitaus groessere Systeme (nicht nur der Linuxkernel), die ohne OOP zuverlaessig arbeiten.
weil man meint, in dieser sprache alles nur denkbare zur verfügung zu haben ... nur ist es viel schwieriger, umständlicher und fehleranfälliger als in den meisten anderen sprachen.
Nein, das stimmt nicht. Weder denkt man das, noch ist es ein Nachteil. Aber solch pauschale Antworten helfen nicht bei einer Analyse.
-
knivil schrieb:
Wieviel Zeilen C oder C++ Code entsprechen wohl 100'000 Zeilen Lispcode ... Auch gibt es weitaus groessere Systeme (nicht nur der Linuxkernel), die ohne OOP zuverlaessig arbeiten.
wahrscheinlich millionen ... daß es möglich ist, auch größere Systeme ohne OOP zuverlässig zu handhaben, bezweifle ich nicht, behaupt aber, daß OOP eine große Hilfe dabei ist.
Beim l*n*x-Kernel liegt insofern ein Sonderfall vor, als
1. OS-Kerne seit Jahrzehnten eine gut verstandene Problemstellung sind,
2. eine naheliegende Modularstruktur (Kernelmodule) vorliegt,
3. die Funktionseinheiten meist ähnlichen Zwecken dienen (Treiber)
4. über 1000 Entwickler zur Verfügung stehen
5. kein Zeitlimit existiert
6. Budgetdruck ? Da muß man wohl zwischen Freizeitprogrammierern und bezahlten unterscheiden.- all das ist bei einem durchschnittlichen Softwaredesign aber nicht immer gegeben.
ich weiß jetzt immer noch nicht, was C++ außer OOP und dem C-Erbgut sonst noch bieten soll
-
u_ser-l schrieb:
Beim l*n*x-Kernel liegt insofern ein Sonderfall vor, als [...]
Was ist beim Linux Kernel den der Sonderfall? Da ist OOP auch ganz normal. Man kombiniert eben die Hardwarenaehe von C mit OO-Design.
u_ser-l schrieb:
ich weiß jetzt immer noch nicht, was C++ außer OOP und dem C-Erbgut sonst noch bieten soll
Templates vllt? Soll ja der grosse Vorteil von C++ sein.
-
Destruktoren.
-
DEvent schrieb:
Was ist beim Linux Kernel den der Sonderfall? Da ist OOP auch ganz normal. Man kombiniert eben die Hardwarenaehe von C mit OO-Design.
ich meinte, der l*n*x Kern ist ein Sonderfall, wegen der Randbedingungen
1. OS-Kerne seit Jahrzehnten eine gut verstandene Problemstellung sind,
2. eine naheliegende Modularstruktur (Kernelmodule) vorliegt,
3. die Funktionseinheiten meist ähnlichen Zwecken dienen (Treiber)
4. über 1000 Entwickler zur Verfügung stehen
5. kein Zeitlimit existiert
6. Budgetdruck ? Da muß man wohl zwischen Freizeitprogrammierern und bezahlten unterscheiden.- in einem normalen, durchschnittlichen kommerziellen Softwareprojekt sind kaum alle diese Punkte erfüllt, manchmal kein einziger.
Und je schlechter die Problemstellung verstanden, je unpräziser oder variabler die Spezifikation und je höher der Kosten- und Zeitdruck ist, umso mehr können die Implementierer von OOP profitieren, z.B. weil dank Datenkapselung und dank Interfaces spätere Änderungen einfacher werden, ohne alles wieder einzureißen, wenn sich die Spezifikation als nachbesserungsbedürftig erweist - und das kommt nicht selten vor, denn Spezifikationen sind normalerweise in natürlicher Sprache verfaßt.