Was ich halt nicht versteh ist, wieso das so langsam ist.
Man könnte doch die Adressen von den "Catch"-Blöcken einfach auf einem Stack ablegen und wenn dann eine Ausnahme auftritt wird nur noch überprüft welcher Catchblock greift.
Ich denke das sollte nichtmal 1000 CPU-Zyklen brauchen, wenn das erste Catch greift.

Wie das in C++ funktioniert, hab ich in einen der vorigen Beiträge verlinkt.
Exceptions sind nicht lokal, sondern laufen eventuell bis über die main Funktion raus.
Es gibt ein festen Exception Cache, der ist 1 KB groß.
Daher sind auch new und free so schnell, denn für jede Exception muss ja die Exception erstmal erstellt werden und dazu gehört auch ein Stacktrace und andere Exceptiontyp abhängige Daten.
Die Exception wandert solange den Callstack runter, bis ein try-catch es abfängt und verlässt es den thread scope(für hauptprozess ist es die main Funktion), dann greift ein vom Compiler angelegter code, welcher auch die App beendet.
Jedes try-catch, welches unterwegs vor kommt, wird geprüft werden, also je mehr catch blöcke, je langsamer.

In C++ sind Exceptions ja Ausnahmen, also treten eigentlich garnicht auf, wenn man alles richtig macht.
Wenn man genau hin schaut, dann haben fast alle STL Klassen/Funktionen keine Möglichkeit Exceptions zu werfen.
Es gibt nur zwei Ausnahmen new und delete, dort werden per default Exceptions geworfen, kann aber durch "new (nothrow) int" z.B. auch unterbunden werden.
Bei C# sind die Container und Basisklassen vollgestopft mit möglichen Exceptions und da sieht man auch, dass MS viel von Exceptions hält.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Weil die Leute es so wollen!!! Es gibt Sprachen die das sogar sofort ohne weitere Arbeit händeln (z.B. C und C++), aber frag dich mal warum TAK diese Zeiten dann hat.

_________________
Meine Homepage

Was hat denn bitte schön die Zeit für das Erzeugen, Auslösen und Verarbeiten einer Exception mit "die Leute wollen es ja nicht anders" zu tun? Was ist denn das für eine Ausage?

Warum wieder gleich so extrem? Wenn man nur Spiele betrachtet mag die Aussage wohl stimmen, dass man so gut wie keine Exceptions benötigt/verwenden sollte. Was Aufgrund des zeitlichen Aspektes auch vollkommen logisch ist. Nur sollten, auch bei Spielen, alle möglichen Codestellen Exceptions auslösen (dürfen). Eben dann wenn diese Rahmenbedingungen/Paramater vor finden mit denen sie nicht arbeiten können oder wollen. Nichts ist schlimmer als Code der im Zweifel einfach irgendwas ignoriert. Strenger Code kann helfen Fehler frühzeitig zu erkennen.

Und das finde ich ist bei C# mitunter der Fall. Klar die Sachen lösen mitunter Exceptions aus. Was aber höchstwahrscheinlich bedeutet, dass Rahmenbedingungen nicht richtig waren. Wenn ich in meinen Programmen Exceptions bekomme, dann aber auch nur an Stellen an denen ich das erwarten würde. Aber da sehe ich auch die Intention hinter der Sprache und dessen primäres Einsatzgebiet. In Desktopanwendungen sind Exceptions nun mal vollkommen normal. Sofern sie denn richtig eingesetzt werden. Speziell, wenn man recht viele Benutzereingaben verarbeitet und/oder auf externe Bibliotheken/Treiber zugreift muss man leider immer wieder mit so etwas rechnen. Eine Desktopanwendung darf sich da aber nicht so schnell auch dem Tritt bringen lassen.
Was ich aber auch schon erlebt habe waren Exceptions zur Statusübermittlung. Das ist dann aber natürlich der vollkommen falsche Weg.

Da hast du mich falsch verstanden, der Code kann Exceptions werfen aber wenn er sauber geschrieben ist, dann wird der Code keine werfen können und damit entsteht auch kein overhead(bei c++ zumindestens hab ich es gestern getestet).
Es geht nicht darum, dass man keine Exceptions im code wirft, wenn was stark im argen ist, sondern darum, dass man so programmieren sollte, dass diese nicht ausgelöst werden können. Eine klassische C# Exception ist NullReferenceException, welche durch ein if (obj!=null) myObj.doWhatEver(obj); else {fixProblem();} schon verhindert wird.
Der Vergleich kostet so wenig und ist eine konstante Belastung, also wunderschön aber try { myObj.doWhatEveer(obj) } catch (NullReferenceException e) { fixProblem();} greift nur in sehr wenigen Fällen, kostet dann aber wesentlich mehr.

Bzgl. Echtzeit Entwicklung
Wenn man Mobile Devices und Consolen Software entwickelt, dann hat man ein Timebudget von z.B. 33ms und man versucht soviel wie möglich Code konstant viel Zeit zu verbrauchen.
Sollte ich keine Prüfung auf null machen, sondern try-catch, dann muss ich bei einer möglichen Exception, im Code, mein übriges Timebudget auf 30,5ms reduzieren(weil die Exception 2.5ms braucht). Leider muss ja noch das Problem gelöst werden, die Zeit kommt bei beiden Fällen mit drauf. Kurz gesagt, das allerschlechteste Szenario, was möglich ist, darf nur 33ms benötigen.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Sicher hätte ich jetzt hier noch Seitenlang darüber Low-Level Technobabble ablassen können warum seine Idee so nicht mit moderner Objektorientierter Programmierung funktionieren kann (Stichwort Objectstatus etc.) und warum die Exceptions jetzt nun genau so langsam sind usw.. Letztenendes muss man aber im Hinterkopf behalten das sich über die Zeit halt diese langsamere Version der Fehlerbehebung und Analyse halt durchgesetzt hat und sich Microsoft beim Design an der Masse orientiert hat... man will halt einfach damit kein OS proggen können.

_________________
Meine Homepage

new und free sollen schnell sein in c++? das wär mir auch neu

Leider daneben getippt. MS hatte mit C# vor den C++ Nachfolger zu entwickeln aber die Entwicklung einer neuen Sprache in dem Umfang hat bisher nicht genug Zuwendung bei den C++ Entwicklern gefunden. D war auch so ein Versuch ein Nachfolger von C++ zu etablieren aber fruchtete ebenfalls nicht.

Was mir öfter auffällt ist, dass viele Entwickler über Sprachen reden aber eigentlich Bibliotheken meinen.
Man kann mit C# sehr wohl Grafiktreiber(ein Freund macht dies Beruflich) oder ganze Betriebssysteme schreiben, das geht auch mit so gut wie jeder anderen Sprache aber würde man für C# die .Net Bibliothek verwenden, sieht es eher düster aus.


delete definitiv, da es den Speicher nur unter bestimmten Bedingungen frei gibt und new braucht nur Zeit, wenn der angeforderte Speicher größer ist, als der aktuell reservierte. Das Problem kommt, wenn man genau diese Bedingungen hat, dann wird z.B. HeapAlloc und HeapFree aufgerufen und die sind halt nicht so schnell, diese Funktionen müssen alle Programmmiersprachen aufrufen also egal welche Sprache, keine wird in dem Fall schneller sein können als die Zeit, die für diese System-Calls benötigt wird.
Na klar geht immer mehr aber mir sind bis Dato noch keine Bottlenecks aufgrund von dem Memory-Allocator begegnet, wenn es um C++ ging(passiert auch eigentlich nur, wenn man nicht genug C++ Erfahrung hat).

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Es sagt ja niemand, dass du ellenlange Beiträge schreiben musst. Aber du musst selber zugeben, dass dein Beitrag nun wirklich nicht viele Fakten hatte. Und ich finde auf Antworten wie "weil es so ist" darf man durchaus kritisch nachfragen.


Man hätte das ein bisschen so auffassen können. Deswegen bin ich da noch mal drauf eingegangen. Wie man das macht muss jeder selber wissen. Ich persönlich mag es nur nicht so gern, wenn Aussagen da stehen die man als "das muss in jeden Fall so sein" verstehen kann.

Da muss ich dich enttäuschen. C# kann ohne ein Framework im Hintergrund das Programm nicht zu einer Addresse springen lassen. Unter .NET gibt es Klassen die das für dich machen können, ein einfaches Beispiel dafür wäre die Delegate Klasse. Du müsstest diese Funktionalität also in einer anderen Sprache bereitstellen damit dein Programm darauf zugreifen kann.

[edit]
oder du nutzt einfach die vorhandenen Bibliotheken und musst damit leben das deine Seele M$ dann gehört

_________________
Meine Homepage

... vielleicht meinte er ja "treiber" für das nicht weiter verfolgte os "Singularity" ... oder das komische ding von Carlo Kok

oder doch nur irgendeinen emulator für den gameboy

Die C# Compiler bieten per Sprachdefinitiion doch alles, was ich bräuchte, um sowas zu machen.
Man hat pointer(auch function pointer), unmanaged Code, reflection und kann zur Laufzeit den Code erweitern.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Hi,

sorry, das ich den Thread neu ausgrabe, aber das mit den Exception kann ich nicht auf C# sitzen lassen .
Zum Glück ist er auch erst 3 knappe Monate alt.

Ich habe das mal selbst ausprobiert, weil ich das ebenfalls nicht glauben konnte.
Und ich komme auf das Ergebnis, welches ihr zu Anfang auch erwartet habt.

Hier der Code:

C#:


C++:


C#: 54487Ticks = 14ms
C++: 2024598180Ticks bzw. nach dem 2. mal 1015241680Ticks = ca. 1/2 Sekunde.

Weshalb ihr auf andere Ergebnisse kommt, verstehe ich nicht.
Selbst auf meinem alten Laptop komme ich auf die selben Ergebnisse (natürlich nur im gleichem Verhältnis ).
C# mit dem .Net Framework 4, Optimierung an und Target CPU auf Any CPU. Gemessen mit System.Diangostics.StopWatch und auch einmal mit nativen QueryPerformanceCounter.
C++ nativer Code und x64. Gemessen mit QueryPerformanceCounter.

Korrigiert mich wenn ich daneben liege, denn ich bin kein Profi.

mfg

Beide Methoden sind schlecht zum testen, wenn man nicht vorher die Ausführung auf ein Thread forciert.
SetThreadAffinityMask erlaubt dir ein aktuellen Prozess auf ein Kern fest zu legen und mit Sleep kannst du dann den Prozess Sheduler(von Windows) zwingen die Ausführung zu unterbrechen. Sobald der Sheduler wieder zurück springt und den Code weiter ausführt, dann ist der Code auf den fest gelegten CPU-Kern.
Wenn man dies nicht macht, dann kommt völliger murks raus, denn jeder Kern hat ein eigenen Counter und die sind nur geringfügig unsynchron.
Ich habe mit DateTime.Now gemessen, weil ich die Ausführungszeit so hoch geschraubt hab, dass ich die Genauigkeit nicht mehr brauchte und dieser Counter hat dieses Problem nicht.

Hier mal c++ Code aus mein Framework.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Also ich muss jetzt auch mal was sagen zu diesem Thread, allerdings kommt hier noch vorher ein gutes Stück Programmiergeschichte dazu... sorry dafür...

Ich habe gut 4 Jahre mit .NET 2.0 beruflich gearbeitet und konnte mich damals schnell für die Sprache begeistern, gerade weil man damit so verdammt schnell UI Anwendungen/Services/Webanwendungen entwickeln kann. Mit meinen Kenntnissen von Delphi (> 10 Jahre Erfahrung) und OOP bin ich sehr schnell in die Sprache und in das .NET Framework eingestiegen und konnte schon nach wenigen tagen Einarbeitung Software damit entwickeln. Leider musste ich anfangs mit VB.NET arbeiten (würg), was aber zum glück nicht lange war. Habe mich sehr schnell mit C# angefreundet und war davon stark beeindruckt im vergleich zu Delphi/C++ etc.

Privat habe ich immer mit Delphi entwickelt und kam damit auch sehr gut klar und habe damit auch einiges gezaubert aber nachdem die IDE dafür immer schlechter und schlechter wurde (Delphi 2005 war die letzte version die ich gekauft habe) habe ich angefangen neue Anwendungen für mich Privat in C# und VC# Express zu Entwickeln. Und nachdem ich auch noch günstig an eine VS 2005 Lizenz gekommen bin, war es klar dass ich mich von Delphi verarbschiede und alles nur noch in C# und .NET mache.

Zwischendrin habe ich immer wieder "versucht" mich in C++ einzuarbeiten, aber meine ersten Anwendungen endeten natürlich in pointer chaos und memory leaks, da ich das nicht so gewohnt war. Klar in Delphi musste man auch auf den Speicher achten und hatte da ebenfalls schnell eine Zugriffsverletzung, aber unter C++ beginnt das ja schon bei string operationen. Vor allem das "include" / "lib" chaos war in C++ übel und ich hatte Tage/Wochen verbracht meine Anwendungen zum Kompilieren/Linken zu bekommen.
Klar, mittlerweile ist man auch schlauer und ich habe nun keine/kaum noch Probleme damit C++ Anwendungen zu schreiben und diese korrekt zu konfigurieren damit diese auch richtig kompilieren und verstehe auch wie das mit den includes/libs funktioniert.... Siehe Fluid Sandbox

Aber dennoch hatte ich viele Startschwierigkeiten mit C++, die ich mit Delphi oder C# nicht hatte.
Vor allem eine Sache die in C++ noch heute Entwickler die Haare raufen lässt ist der Horror damit GUI Anwendungen zu schreiben. Es gibt zwar, unzählige GUI libs, aber keinen wirklichen Designer dafür der ansatzweise konfortabel wie der UI Designer von VStudio ist, wo man mal schnell ne UI Applikation innerhalb sehr kurzer Zeit zusammenklicken kann. Das war ja auch damals die große stärke von der Delphi IDE meiner meinung nach.

Das soll jetzt nicht bedeuten C++ wäre schlecht, im gegenteil ich denke mittlerweile mag ich C++ weil man damit sehr Performante Anwendungen schreiben kann und es ähnlich wie C# ist und vorallem da ich weiß dass in der Spieleentwicklung bevorzugt C++ verwendet wird, habe mir ein teures Buch zugelegt (Game Engine Architecture) um zu verstehen wie Game Engines funktionieren und wie man diese schreibt weil ich eine gute Idee für ein MMO Spiel hatte.
Aber nachdem ich dieses Buch gelesen hatte bin ich zum dem entschluss gekommen, das ich erstens max. 20% davon verstehe was da drin steht und zweitens ich Lichtjahre davon entfernt bin sowas wie eine Game Engine zu schreiben, geschweige denn ein fertiges Spiel, daher auch kein MMO mal eben aus dem ärmel schütteln kann.

Das hat mich erstmal geschockt, aber das ist logisch... ich habe noch nie wirklich nie ein richtiges fertiges Spiel auf die Beine gestellt. Noch nichtmal nen fertigen Pong klon... aber dafür hunderte kleine 3D OpenGL Technologie Demos oder angefangene Spiele wie z.b. ein verbuggtes Breakout die noch heute auf meiner Entwicklungsplatte vor sich hin schimmeln. Dazu kommt noch das ich keine Lineare Algebra in der Schule hatte und mir somit auch die Grundkenntnisse für die Spielentwicklung fehlen und mir auch Mathematik dadurch sehr schwer fällt.

Dennoch kann ich behaupten das ich relativ gut Entwickeln kann, vor allem nun mit gut 20 Jahren Erfahrung ist es kein Problem mehr für mich aufwendige UI, Server -und oder Webanwendungen zu schreiben, fast egal mit welcher Sprache oder Framework. Aber nun zum eigentlichen Thema.

Ich hatte mal wieder angefangen mit C++ und OpenGL ein einfaches Jump & Run Spiel zu programmieren und kam eigentlich relativ gut zurecht bis ich dann auf ein nerviges Timing (Frametime berechnung hat durchgehend gesponnen) Problem gestoßen bin und ich partou nicht gelöst bekommen habe.

Aus Verzweiflung habe ich doch mal das XNA Framework ausprobiert dass mir ein sehr guter Kumpel vor Jahren empfohlen hat und was soll ich sagen. Man kann damit definitiv Spiele erstellen wenn man sich strikt an das Framework hält und nicht versucht "eigene" Wege zu gehen. Es werden nicht umsonst viele Spiele für die XBox 360 von Indie Entwickler damit erstellt und erfolgreich verkauft.

Mein einfaches 2D Platformer Game was ich aktuell mit dem XNA Framework schreibe läuft bisher sehr gut und ich kann keine Framerate einbrüche feststellen. Auch etwailige 3D Samples die ich ausprobiert habe, liefen durchgehend flüssig, aber das mag wohl auch an meiner Kiste liegen die recht gut ausgestattet ist.
Ebenfalls ist z.b. Trine ein 2.5D Grafisch recht aufwendiges Puzzle Jump&Run Spiel ebenfalls in XNA mit .NET geschrieben und das läuft erste Sahne.

Ich denke daher man kann Heute auf PC problemlos Spiele mit C# schreiben. Die Rechner sind heute so schnell, da ist das kein Thema mehr. Gutes beispiel ist ja auch Android und Java, da laufen ja auch aufwendigere Sachen mittlerweile darauf und das ende ist noch lange nicht in sicht.