spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Zitat von »CBenni::O«

Gibt es in C# keine möglichkeiten, Implementierugen per #ifdef o.ä. umzuschalten? Habe zu lange nicht mehr damit gearbeitet...

mfg CBenni::O

C# Kompilate laufen erst garnicht auf beliebigen Platformen.

O.o Wieder einmal was gelernt...

Ich weiß, warum ich in C++ arbeite

mfg CBenni::O

Zitat von »David_pb«

Zitat von »CBenni::O«

Gibt es in C# keine möglichkeiten, Implementierugen per #ifdef o.ä. umzuschalten? Habe zu lange nicht mehr damit gearbeitet...

mfg CBenni::O

C# Kompilate laufen erst garnicht auf beliebigen Platformen.

mit mono läuft es auch auf linux.

Zitat von »DasBlub«

mit mono läuft es auch auf linux.

Ja, zumindest mal bedingt... Aber was hilft das wenn ich z.B. auf den GBA portieren will? Ist ja aber auch egal und trägt egtl nichts zum Thema bei.

@newby

zu c) mach dir eine std::map<unsigned int, std::wstring>, wobei der erste Parameter dein Fehlercode und zweiter die Beschreibung dazu sind. Kannst sogar noch ein wenig weiter gehen und das Ganze um std::pair erweitern, dann könntest du Lokalisierung machen.

@newby und Jonathan_Klein

zu d) nicht ganz, um kompletten Code ein try block zu machen ist es nicht sinnvoll. Nur um die Bereiche, wo es wirklich eine Exception auftretten kann. Jonathan, da hast du unrecht, die Exceptions werden nicht automatisch weitergeleitet, stell dir vor, du rufst ohne eigenen try-Block irgendeine System-Funktion (memcpy, fstream read, rohe arrays überlauf) in dem Fall crasht es bei dir, und die Verarbeitung der Exception übergeht an System (Windows), dabei stürt aber auch dein Programm ab.

@newby

zu g) es ist nicht schwierig, du hast nur bis jetzt wenig damit zu tun gehabt, das ist alles. Wie der Jonathan aber schon geschrieben hat, gibts zur Umwandlung nette Sachen wie boost:lexical_cast etc.

zu i) nicht empfehlenswert

zu k) Es muss nicht unbedingt eine Partierung sein, stell dir vor jemand hat eine 32 Bit Maschine und du entwickelst auf einer 64 Bit, da haben z.B. die Integer Werte verschiedene Größen. Wenn du jetzt aber deine eigene Datentypen deklarierst wie typedef unsigned long long u64. So brauchst du dann nur an einer Stelle später was ändern, wenn zu Problemen kommt oder du was umschreiben willst. Wie der CBenni schon gesagt hat.

@CBenni und David_pb

Die C# Programme haben ähnliche Konstrukte wie #ifdef, werden (müssen) auch verwendet werden, wenn man das Spiel/Programm für PC und XBOX entwickelt, da es einige Unterschiede z.B. bei Steuerungsgeräten, Storagemedien etc gibt.

Viele Grüße,
Sergius

Zitat von »Sergius«

Die C# Programme haben ähnliche Konstrukte wie #ifdef, werden (müssen) auch verwendet werden, wenn man das Spiel/Programm für PC und XBOX entwickelt, da es einige Unterschiede z.B. bei Steuerungsgeräten, Storagemedien etc gibt.

Das weiß ich wohl, das bringt dir aber auch nichts wenn dein C# Programm erst gar nicht auf einer Platform lauffähig ist.

Zitat von »Sergius«

die Exceptions werden nicht automatisch weitergeleitet, stell dir vor, du rufst ohne eigenen try-Block irgendeine System-Funktion (memcpy, fstream read, rohe arrays überlauf) in dem Fall crasht es bei dir, und die Verarbeitung der Exception übergeht an System (Windows), dabei stürt aber auch dein Programm ab.

Das ist blödsinn, und vor allem wirfst du zwei dinge durcheinander.
C++-Exceptions werden automatisch den kompletten callstack durchgereicht, und erst wenn eine excpetionbis einschließlich in der main keinen handler findet, schmiert das programm ab.
die von dir erwähnten Funktionen/Fehler werfen aber afaik keine C++-Exceptions, sondern führen zu ner access violation oder ähnlichem, die keine C++-Exceptions produzieren, sondern höchstens auf OS-spezifische weise gefangen werden können.

Zitat

Zitat

die Exceptions werden nicht automatisch weitergeleitet, stell dir vor, du rufst ohne eigenen try-Block irgendeine System-Funktion (memcpy, fstream read, rohe arrays überlauf) in dem Fall crasht es bei dir, und die Verarbeitung der Exception übergeht an System (Windows), dabei stürt aber auch dein Programm ab.

Das ist blödsinn, und vor allem wirfst du zwei dinge durcheinander.
C++-Exceptions werden automatisch den kompletten callstack durchgereicht, und erst wenn eine excpetionbis einschließlich in der main keinen handler findet, schmiert das programm ab.
die von dir erwähnten Funktionen/Fehler werfen aber afaik keine C++-Exceptions, sondern führen zu ner access violation oder ähnlichem, die keine C++-Exceptions produzieren, sondern höchstens auf OS-spezifische weise gefangen werden können.

Habe mich vielleicht ein wenig falsch ausgedruckt.
Was du schreibst stimmt, das verneine ich auch nicht.

Es geht mir dadrum, dass die Engine/Framework bei Exceptions sauber beendet werden muss.
Man soll die Exceptions also schon frühzeitig fangen und teiweise sachen aufräumen auf den höheren Ebenen und dann weiterleiten.

Es bringt nicht viel, wenn ganzer Callstack bis zur Main durchgerollt wird, und man versucht erst da alles aufzuräumen. Das wäre in manchen Fällen auch gar nicht möglich.

Viele Grüße,
Sergius

Zitat von »Sergius«

Man soll die Exceptions also schon frühzeitig fangen und teiweise sachen aufräumen auf den höheren Ebenen und dann weiterleiten.

Naja, zum "aufräumen" kann man (meistens) RAII verwenden. Exceptions fangen muss man (bei gutem, RAII benutzendem Design) nur, wenn man an dieser stelle

• Irgendwen (Benutzer, log, ...) von dieser benachrichtigen will
  
• Informationen zur exception hinzufügen kann
  
• Den Fehler beheben kann
  

oder eben in der main, um die Absturzmeldung zumindestens durch was aussagekräftigeres zu ersetzen.