Da schließe ich mich an =) C++ ftw <3Zitat:
Zitat von AlterHacker
Greetz Zer0Flag
Druckbare Version
Da schließe ich mich an =) C++ ftw <3Zitat:
Zitat von AlterHacker
Greetz Zer0Flag
basic ist natürlich die beste Programmiersprache
....nicht :D
C und C++ sind das einzig wahre <3 :D
C rockt schon, sonst würden buffer overflows ja echt bald komplett austerben!
achja, btw perl <3 ;) komisch das python mehr hat
Mist, das wollte ich gerade scrreiben :mad:Zitat:
Zitat von Cheese
Btw:
Ich kenne keine größere Anwendung in C/C++ die keine Memoryleaks enthält ;). Mein Rechner läuft teilweise bis zu 2 Monaten ohne Reboot (solange es keine zwingenden Kernelupdates gibt) - da merkt man Memleaks bei Thunderbird, Mozilladerivaten (nicht nur FF ;) ), Explorer und der restlichen Software - die muss man einmal die Woche neustarten.Zitat:
Garbage collectoren? quatsch ich pass schon auf meinen Speicher selber auf.
New/Delete sind eben nicht genau das Gleiche wie malloc etc. Nur schon alleine wegen Kon-/Destruktoren ...Zitat:
Zitat von AlterHacker
Java is des Teufels!!! Delphi und Baisc kann man rauchen, PHP noch mehr - PHP ist IMHO so in etwa die schlimmste Sprache die es gibt. Keine einheitliche Funktionsbenennung, langsam viele Bugs etc.Zitat:
Zitat von Steiger_mp
Lieber einige Buffer Overflows als strunzdumme Garbage Collectors, die nur Performance fressen und schlussendlich doch nicht ganz so funktionieren wie man eigentlich möchte.Zitat:
Zitat von Cheese
Ich habe bei meinem PC auch ähnliche Uptimes und gebe dir in der Beziehung Recht, dass es nur sehr wenige Programme gibt, die so lange laufen (mal abgesehen von einigen Daemons wie ALSA oder der SSHd...). Trotzdem bevorzuge ich es ein Programm von mir aus einmal am Tag neu starten zu müssen, anstatt dass es von Anfang an gleich 5 mal so viel Speicher frisst und sogar mit Garbage Collection noch Memory Leaks hat (Nenne mir einen wirklich guten Garbage Collector!).Zitat:
Zitat von EBFE
Kenn ich. Mein Windows hat nach ner Uptime von öh 5 Tagen schon merkbare einbüßen ^^.Zitat:
Zitat von EBFE
Ich programmier ja jetzt keine Firefox'ns usw, aber guck mal was son simples Java-Programm an Speicher verbraucht. Da hilft auch n Garbage-Collector nichts ^^
Fakt ist jedenfalls das nichts perfekt ist^^, C/C++ sind in Sachen Performance deutlich besser Java.
Außerdem muss man bei C++ drauf achten womit es kompiliert wurde,
wenn dies nämlich mit Visual Studio passiert ist, dann hat man diese .NET scheiße
und das zieht einiges von der C++ Performance.
JDiskReport: (und ja, mit GUI und so ;) , nach einem Suchvorgang und mit 10 verschiedenen interaktiven Diagrammen als Darstellung)
eine kleine Anwendung, die Daten aus Txt Dateien in eine Remote-DB schaufelt:Code:C:\WINDOWS>tasklist | find /I "javaw"
jjavaw.exe 204 0 46.796 K
ArgoUML mit einem größeren ProjektCode:C:\WINDOWS>tasklist | find /I "jav"
java.exe 3048 0 7.280 K
frisch gestarteter Thunderbird:Code:C:\WINDOWS>tasklist | find /I "java"
javaw.exe 3288 0 61.572 K
FoxIt PDF ReaderCode:thunderbird.exe 3756 0 50.564 K
jetzt darf jeder mal FF oder AdobeAcrobat Reader ausführen und den Speicherverbrauch messen ;)Code:FOXITR~1.EXE 3216 0 36.820 K
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.Zitat:
Lieber einige Buffer Overflows als strunzdumme Garbage Collectors, die nur Performance fressen und schlussendlich doch nicht ganz so funktionieren wie man eigentlich möchte.
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).
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.Zitat:
Nenne mir einen wirklich guten Garbage Collector!)
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" :rolleyes: ).
Ü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.
Bei FF der Speicherbedarf find ich irgendwie auch Astronomisch. Das geht teilweise echt nicht mehr.
Zu dem Rest kann ich dir nur zustimmen, außer es gibt halt noch eine weitere Anti-BoF-Methode: Sauber coden ;-)
Immer schön Ränder überprüfen usw, wenn man sich das einmal angewöhnt, sollte da eigentlich ja nichts mehr passieren.
Gefährliches Halbwissen hast du. Erstmal muss man das .NET-Framework bei jedem Projekt selber aktivieren. Von Haus aus erzeugen alle Visual-Studio-Projekte ganz normale native Anwendungen.Zitat:
Zitat von cookie-exploit
Außerdem wird die Perfomance nicht schlechter, wenn du .NET gar nicht benutzt..