C ist wieder die beliebteste Programmiersprache

[krypt0n]

[..]jetzt darf jeder mal FF oder AdobeAcrobat Reader ausführen und den Speicherverbrauch messen

Du vergleichst ernsthaft total verschiedene Programme und ihren Speicherverbrauch? Ich stimme dir zu, dass der VM Overhead bei grösseren Applikationen praktisch keine Rolle mehr spielt, nur garantieren auch die heutigen Garbage-Collectors nicht, dass es keine Speicherlecks mehr gibt.

BufferOverflows und GarbageCollectoren (bzw. das Fehlen dieser) haben nicht so viel mit einenader zu tun . Stichworte wären Ada (optional), Delphi/Pascal. Ein Bof dafür zu finden ist viel schwerer, als für C Erzeugnisse.

/agree

Fehlende Arraybereichprüfungen, Pointerspielereien und die beliebten bereichlosen Kopierfunktionen von C sind die Hauptursache. Der Perfomanceverlust gegenüber einer Version mit Runtimeprüfung ist übrigens minimal. Auf einem heutigen Rechner würde man diesen wahrscheinlich nicht messen können. Aber lieber 0.0001% angebliche Performance und dafür eben Bof riskieren . Der Witz ist ja dass die modernen Anti-Bof Maßnahmen (canaries, stackquards, Radnomizations) der C/C++ Compiler mehr Performance kosten, als eine vergleichbare Runtimeprüfung wie z.B in Delphi (die man aber auch noch bei Bedarf abschalten kann).

Gebe ich dir auch Recht

Jeder Collector funktioniert besser als "zu Fuß". Vor allem weil es für C++ mehrere Ansätze und Hybride gibt, wo man den Speicher auch manuell freigeben kann.

Meine Erfahrung sieht da anders aus. Memoryleaks lassen sich wirklich nur sehr schwer verhinderen (besonders bei grösseren Projekten), die heutigen Garbage Collectors garantieren aber auf keinen Fall, dass es mit ihnen keine Leaks gibt und fressen gleichzeitig noch ziemlich Performance.

Vor 12 Jahren hätte ich dir noch beigepflichtet. Da hatte man seine 64MB RAM und ärgerte sich über 30MB Speicherfresser. Heutzutage sich über paar MB mehr (5x mehr frisst NET/Java auch nicht ) aufregen aber nebenbei FF mit 400MB Verbrauch laufen lassen ist lachhaft ). Java/NET Speicherverbrauch ist vergleichsweise nur am Anfang hoch (beziehungsweise für wirklich "kleine" Anwendungen). Dann amortisiert sich das Ganze.

Da stimme ich dir aber nicht zu - es ist meiner Ansicht nach der falsche Weg sich auf den Fortschritt in der Hardwareentwicklung zu verlassen und einfach zu sagen, dass Optimierungen unnötig sind, weil die Hardware sowieso nur noch besser wird.

C/C++ "as is" sind nicht mehr zeitgemäß.

ACK!

Das gute an C/C++ ist halt, dass es sehr gute Compiler und sehr viele Bibliotheken dafür gibt. Das heißt aber noch lange nicht, dass die Sprache an sich "stark" ist .

Stimme ich dir vollkommen zu - nur ist C(++) meiner Ansicht nach in vielen Bereichen den restlichen Sprachen (deutlich) überlegen.

Zitat: "Wer glaubt gut zu sein, hat aufgehört besser zu werden". Gilt vor allem im IT Bereich - auch für Sprachen.

Weise Worte!

[EBFE]

nur ist C(++) meiner Ansicht nach in vielen Bereichen den restlichen Sprachen (deutlich) überlegen

Da lässt sich eher nur drüber streiten (nicht umsonst DAS Flame Thema Nr1). Ich kenne auch einige Bereiche (Bioinformatik, vor allem Prototyping der verschiedenen Algorithmen, Prototyping allgmein, automatische Verifizierer für Software) wo C total ungeeignet ist.
Oder LowLevel Programmierung (im Sinne RealMode/Hardwarezugriff - hier geht nichts ohne Inline-ASM :| ) - wo man sieht, dass C auch hier subobtimal ist (ok - die einzige Alternative ist meistens Assembly, was Entwicklungtechnisch noch deutlich schlechter ist)

Da stimme ich dir aber nicht zu - es ist meiner Ansicht nach der falsche Weg sich auf den Fortschritt in der Hardwareentwicklung zu verlassen und einfach zu sagen, dass Optimierungen unnötig sind, weil die Hardware sowieso nur noch besser wird.

Nee, ich bin keineswegs gegen Optimierungen (auch wenn Entwicklungstechnisch was anderes propagiert wird). Aber man muss halt realistisch bleiben. Und wenn ich die Wahl habe zwischen "weniger Verbrauch und dafür mehr potentielle Fehler" und "mehr Verbrauch, weniger Fehler" tendiere ich erstmal zu dem kleineren Übel, solange es sich in Grenzen hält.
Bei der Größe und Anforderungen an moderne Software (1000+1 Feature sind quasi Pflicht ) wäre es auch zu viel verlangt. Es gilt ja immer noch: je optimierter etwas sein muss, desto mehr Zeit verschlingt die Optimierung + Pflege selbst und desto weniger Zeit bleibt für die Weiterentwicklung der eigentlichen Software.


Btw/PS:
Eine IDE mit Syntaxhighligning, Projektverwaltung, Autoergänzung, Codefolding und gerade ein mittelgroßes Projekt offen:

C:\WINDOWS>tasklist |find /I "Radasm"
RadASM.exe                 3064                           0         2.732 K

damit die Javaner/NETler und auch C(++)-ler mal vor Neid erblassen dürfen *scnr*

[GregorSamsa]

Womit wir wieder beim Thema "Welche Sprache ist besser" wären =)

Ich persönlich favorisiere C, da ich diese Sprache am einfachsten für eine Low-Level-Programmierung halte, die sich zwar nicht mit Assembler messen kann, aber deutlich "tiefer" liegt als z.B. Java.

Desweiteren (vllt. durch meinen "Lernweg" durch die Programmierung) habe ich die Angewohnheit, Code nur zu vertrauen, den ich selber geschrieben habe, da ich jede Zeile kennen will.

Daher nutze ich auch äußerst selten Frameworks. Ich mag es nicht, wenn ich auf etwas zugreife, was ich nicht in- und außwendig Begreife...

Naja - Zeitgemäß ist das nicht mehr, aber ich finde, C(++) hat noch definitiv eine Daseinsberechtigung - nicht mehr aktuell, aber doch in meinen Augen die Sprache, mit der besten Kontrolle über den Ablauf.