Andy_m4
Well-Known Member
In der Tat. Wobei der Layer zwischen Assembler und Maschinencode extrem dünn ist. Nicht zu vergleichen mit C or whatever und Assembler.Auch Assembler braucht nen Compiler für die Umwandlung in Maschinencode.
War auch so nicht gemeint. Ich wollte damit nur klar stellen, dass es eben mehrere Optionen gibt und auch in der Praxis mindestens genauso (wenn nicht gar häufiger) zum tragen können als irgendwelche Handoptimierungen.Nicht jedes Performance-Problem lässt sich mit Hardware erschlagen
Während richtig geschriebenes C++ natürlich unendlich schnell ist. :-)ganz einfach weil keine unendliche schnelle Hardware existiert.
Das kommt ja meist noch hinzu. Bei C++ ist auch die Implementierung zeitaufwendiger.Wenn dein Problem sicher in 5min lösbar ist und unsicher in 20s, dann diskutiert man das nicht unbedingt einfach weg.
Ich brauch länger und hab auch dann noch potentiell unsicherebn Code. Sprich: C++ setze ich nur ein, wenn es wirklich nicht anders geht.
Ja. Nur das eben C++ ein Flickenteppich ist und Du an allen Ecken und enden solche Späße hast.Da ist das Vermeiden von [] in C++ jetzt auch nicht so das Mega-Problem.
Mit ich hab irgendwas von meinem Schwager gehört der irgendwo gesehen hat das lässt sich schwer diskutieren. Entweder Du hast ein konkretes Beispiel parat oder nicht. Alles andere ist unbrauchbar für eine Diskussion.Ich hab nur schon selbst Projekte gesehen, die in ziemlich große Performance-Probleme gerannt sind und letztendlich unsafe die einzige Lösung war.
Bullshit. Über Rust und D und sogar C# wird hier im Thread auch gesprochen. Aber Fortran ist plötzlich ein No-Go.Hat niemand behauptet. Das Thema ist halt C++.
Merkst selbst, ne?
Keine Ahnung.Du wirst auch vermutlich im Nachwuchs-Markt für Programmierer nur noch wenig Leute finden die Fortran können.
Wieviel gibt es denn am Nachwuchsmarkt, die C++ können?
Ich nehme nur auf, was DU sagst. Also beschwer Dich nicht bei mir.Huh? Darum gehts doch gar nicht.
Und auch ein C++ Compiler optimiert.
Nur alles sehr intransparent. Das geht wesentlich eleganter, wie schon erläutert.Ich erlaube dem Entwickler einen unsicheren Pfad für Performance-Kritische Stellen, oder ich knalle automatisch alles mit Sicherheits-Checks zu und hoffe, dass der Compiler schon selbst erkennt was ohne sowas auskommt. C++ ist im Standard eher unsicher, geht aber auch sicher
Versteh ich nicht.Java ist Im Standard sicher, der Compiler versucht was er kann. Und das Thema ist jetzt C++ quasi in die Richtung der Java-Arbeitsweise zu kriegen.
Wie gesagt. Du kriegst ja schon Probleme beim Wechsel des Compilers. Bei Wechsel der Hardware dürfte die Hürde entsprechend noch höher sein.Niemand hat behauptet, dass C++ (oder sogar C) ein Write-Once-Compile-Anywhere ist.
Hab ich auch so nie gesagt. Genau genommen hab ich zu Rust gar keine Stellung bezogen. Du wirfst mir Rust andauernd vor die Füße und anhand dessen zu belegen, wo C++ gut ist. Und wenn man dann doch mal ne andere Sprache in die Diskussion bringt heißt nur lapidar das ist ein C++ Thread.Das betrifft natürlich nicht alle Projekte und ich bin durchaus dafür neue Projekte in einer Sprache wie Rust zu schreiben, wenn es möglich ist. Es löst aber halt trotzdem nicht alle Probleme.
Unteranderem auch das wirkt so, als wolltest Du C++ schönreden. Und genau deshalb hab ich auch was in dem Thread geschrieben. Ich sehe keinen Grund Dinge schönzureden und benenne sie lieber klar wie sie sind. Das ich am Ende des Tages aus bestimmten Gründen trotzdem C++ schreibe steht auf einem anderen Blatt.