C ist wieder die beliebteste Programmiersprache

[EBFE]

JDiskReport: (und ja, mit GUI und so , nach einem Suchvorgang und mit 10 verschiedenen interaktiven Diagrammen als Darstellung)

C:\WINDOWS>tasklist | find /I "javaw"
jjavaw.exe                   204                           0        46.796 K

eine kleine Anwendung, die Daten aus Txt Dateien in eine Remote-DB schaufelt:

C:\WINDOWS>tasklist | find /I "jav"
java.exe                   3048                           0         7.280 K

ArgoUML mit einem größeren Projekt

C:\WINDOWS>tasklist | find /I "java"
javaw.exe                  3288                           0        61.572 K

frisch gestarteter Thunderbird:

thunderbird.exe            3756                           0        50.564 K

FoxIt PDF Reader

FOXITR~1.EXE               3216                           0        36.820 K

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

Lieber einige Buffer Overflows als strunzdumme Garbage Collectors, die nur Performance fressen und schlussendlich doch nicht ganz so funktionieren wie man eigentlich möchte.

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

Nenne mir einen wirklich guten Garbage Collector!)

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

C/C++ "as is" sind nicht mehr zeitgemäß. Vorlieben hin oder her - zumindest die StdLibs müssen überarbeitet werden. Ich habe nämlich viele C/C++ Compilate "von innen" im Debugger gesehen - da sind z.T Sachen wo man sich an den Kopf fassen kann (C++ Stringfunktionen wie []-Arrayzugriffüberladung (wer glaubt, dass der Zugriff "a=mystr[i]" da in 3-4 Anweisungen erfolgt, irrt sich gewaltig - allerlei hin und her gecalle sowohl bei GCC wie MS Produkten - aber eine kleine Bereichsprüfung bei dem Zugriff war trotzdem zu "kostspielieg" ).
Übrigens: die beliebten Pointer sind der Kopfschmerz des Compileroptimierers. Btw: Großteil der angeblichen Performancevorteile durch wirklich sprachspezifische Features von C sind heutzutage entweder nicht messbar (oder <0.1% ) oder gleich ein Mythos .

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