|
JLI Spieleprogrammierung
|
Vorheriges Thema anzeigen :: Nächstes Thema anzeigen |
Autor |
Nachricht |
Mat Senior JLI'ler
Alter: 36 Anmeldedatum: 17.09.2005 Beiträge: 205 Wohnort: Koblenz Medaillen: Keine
|
Verfasst am: 04.04.2007, 01:43 Titel: Verständnis Try - Catch |
|
|
Hey,
ich habe hier gerade eine Situation, mich ein wenig erschreckt, da ich ein anderes verhalten erwartet habe.
Also, ich habe folgenden Code vorliegen:
CPP: | try
{
//if(mSceneMgr)
delete mSceneMgr;
}
catch(...)
{
MessageBoxA( NULL, "main", "scene!", MB_OK | MB_ICONERROR | MB_TASKMODAL);
}
|
Jetzt dachte ich, dass kein Fehler (außer der die von mir gewollte Fehlermessage) angezeigt werden darf, auch wenn bei delete was schief läuft.
Aber das ist nicht der Fall.
Die Anwendung hat Probleme den Speicher von mSceneMgr frei zu geben (warum muss ich noch untersuchen), aber warum verhindert das abfange mit try-catch nicht den Absturz ? _________________ - - - - - - - - - - - - - - - - - - - -
-> http://www.sea-productions.de
-> http://www.krawall.de
- - - - - - - - - - - - - - - - - - - - |
|
Nach oben |
|
|
AFE-GmdG JLI MVP
Alter: 45 Anmeldedatum: 19.07.2002 Beiträge: 1374 Wohnort: Irgendwo im Universum... Medaillen: Keine
|
Verfasst am: 04.04.2007, 08:37 Titel: |
|
|
Selbst mit ... können nicht wirklich ALLE Fehler abgefangen werden - und ich glaube zu wissen, dass der Versuch, Speicher freizugeben, welcher nicht (mehr) reserviert ist dazuzählt!
Verwechselst du hier eventuell Heap und Stack? - Speicher vom Stack kann (darf!) man nämlich nicht freigeben! _________________
CPP: | float o=0.075,h=1.5,T,r,O,l,I;int _,L=80,s=3200;main(){for(;s%L||
(h-=o,T= -2),s;4 -(r=O*O)<(l=I*I)|++ _==L&&write(1,(--s%L?_<(L)?--_
%6:6:7)+\"World! \\n\",1)&&(O=I=l=_=r=0,T+=o /2))O=I*2*O+h,I=l+T-r;} |
|
|
Nach oben |
|
|
DirectXer Dark JLI'ler
Anmeldedatum: 05.02.2005 Beiträge: 1201 Wohnort: Köln Medaillen: Keine
|
Verfasst am: 04.04.2007, 09:16 Titel: |
|
|
du könntest ja mal einen catch zweig mit std::exception machen; wenn da eine eine ausgeworfen wird, hättest du eine chance die zu kriegen. Komisch nur wäre dann, dass die nicht auch in deinem jetzigen catch gefangen wird. Ansonsten ist es aber auch wahrscheinlich, dass du die Fehlermeldung schon bei delete bekommst aka access violation, sodass diese _vor_ der Ausnahmen-werfung (heißt das so? ) ausgeführt wird und dein Programm da schon crasht. Dann würde es nie zu deiner MessageBox kommen...
Gruß DXer |
|
Nach oben |
|
|
David Super JLI'ler
Alter: 39 Anmeldedatum: 13.10.2005 Beiträge: 315
Medaillen: Keine
|
Verfasst am: 04.04.2007, 09:38 Titel: |
|
|
Was für ne Meldung kommt den? Zur not versuchst dus halt mal mit Hardwareexceptions. |
|
Nach oben |
|
|
Mat Senior JLI'ler
Alter: 36 Anmeldedatum: 17.09.2005 Beiträge: 205 Wohnort: Koblenz Medaillen: Keine
|
Verfasst am: 04.04.2007, 10:44 Titel: |
|
|
Die Fehlermeldung lautet ungefähr so:
Code: | Unbehandelte Ausnahme bei 0x00453458 in code_red.exe: 0xC0000005: Zugriffsverletzung beim Lesen an Position 0x00c4f050. |
Aber es geht mir eher darum was AFE-GmdG gesagt hat. Es war nicht wirklich mein Ziel diese Exception unter Kontrolle zubekommen, sondern eher, zu verstehen, warum die Exception durch schlüpft.
Achja, der Speicher liegt übrigens sicher auf dem Heap (per new angelegt), aber wie gesagt, dass ist für mich fast nebensächlich ... _________________ - - - - - - - - - - - - - - - - - - - -
-> http://www.sea-productions.de
-> http://www.krawall.de
- - - - - - - - - - - - - - - - - - - - |
|
Nach oben |
|
|
PeaceKiller JLI Master
Alter: 35 Anmeldedatum: 28.11.2002 Beiträge: 970
Medaillen: Keine
|
Verfasst am: 04.04.2007, 11:27 Titel: |
|
|
Mat hat Folgendes geschrieben: | Aber es geht mir eher darum was AFE-GmdG gesagt hat. Es war nicht wirklich mein Ziel diese Exception unter Kontrolle zubekommen, sondern eher, zu verstehen, warum die Exception durch schlüpft.
|
Nicht alle Fehler sind Exceptions, es gibt auch etwas im Standard das sich »undefiniertes Verhalten« nennt. Wenn du mit delete nicht vorsichtig umgehst, kann sich das z. B. in so einer Fehlermeldung äußern. _________________ »If the automobile had followed the same development cycle as the computer, a Rolls-Royce would today cost $100, get a million miles per gallon, and explode once a year, killing everyone inside.«
– Robert X. Cringely, InfoWorld magazine |
|
Nach oben |
|
|
AFE-GmdG JLI MVP
Alter: 45 Anmeldedatum: 19.07.2002 Beiträge: 1374 Wohnort: Irgendwo im Universum... Medaillen: Keine
|
Verfasst am: 04.04.2007, 11:28 Titel: |
|
|
Führst du den speziellen DestruktorCode aus? eventuell kracht es dort - was prinzipiell vermieden werden sollte! _________________
CPP: | float o=0.075,h=1.5,T,r,O,l,I;int _,L=80,s=3200;main(){for(;s%L||
(h-=o,T= -2),s;4 -(r=O*O)<(l=I*I)|++ _==L&&write(1,(--s%L?_<(L)?--_
%6:6:7)+\"World! \\n\",1)&&(O=I=l=_=r=0,T+=o /2))O=I*2*O+h,I=l+T-r;} |
|
|
Nach oben |
|
|
Mat Senior JLI'ler
Alter: 36 Anmeldedatum: 17.09.2005 Beiträge: 205 Wohnort: Koblenz Medaillen: Keine
|
Verfasst am: 04.04.2007, 11:53 Titel: |
|
|
Bei dieser Klasse gibt es nun keine Probleme mehr, sowiet ich weiß wird der Speicher über die klasse frei gegeben, die das Objekt besitzt - das klappt auch.
Seltsamer ist dieser Fehler:
er tritt unter exakt den gleichen Bedingungen auf, nur dass ich hier den Speicher einer anderen Klasse freigeben will.
Diese wurde so erstellt:
CPP: | mMenu = new Menu(mWindow, mSceneMgr); |
Und so versuche ich diese freizugeben:
CPP: | if(mMenu)
delete mMenu; |
Komisch ist, dass der aufgeführte Pfad nichts mit meiner Ordnerstruktur zu tuen hat! _________________ - - - - - - - - - - - - - - - - - - - -
-> http://www.sea-productions.de
-> http://www.krawall.de
- - - - - - - - - - - - - - - - - - - - |
|
Nach oben |
|
|
David Super JLI'ler
Alter: 39 Anmeldedatum: 13.10.2005 Beiträge: 315
Medaillen: Keine
|
Verfasst am: 04.04.2007, 12:50 Titel: |
|
|
Wieso komisch? Da steht irgendwo im Code ein assert(...). Is die Klasse "Menu" von dir, wie sieht der Code aus, was wird zerstört uswusw. Sieht so aus als wolltest du ein Singltonobjekt freigeben.
Achja: Per WinAPI kannst du Hardwareexceptions abfangen. Das sind solche die auftreten wenn du einen Nullzeiger dereferenzieren willst usw... |
|
Nach oben |
|
|
Mat Senior JLI'ler
Alter: 36 Anmeldedatum: 17.09.2005 Beiträge: 205 Wohnort: Koblenz Medaillen: Keine
|
Verfasst am: 04.04.2007, 13:30 Titel: |
|
|
Normalerweise gibt assert doch die Datei an, in der der Fehler aufgetreten ist, aber Laufwerk E: ist mein DVD-Laufwerk, und da liegt mein Programm bestimmt nicht
Menu ist von mir, beinhaltet aber Objekte die aus CEGUI sind.
Sieht derzeit so aus:
CPP: | #pragma once
////mem probs without this next one
#include <OgreNoMemoryMacros.h>
#include <CEGUI/CEGUIImageset.h>
#include <CEGUI/CEGUISystem.h>
#include <CEGUI/CEGUILogger.h>
#include <CEGUI/CEGUISchemeManager.h>
#include <CEGUI/CEGUIWindowManager.h>
#include <CEGUI/CEGUIWindow.h>
#include "OgreCEGUIRenderer.h"
#include "OgreCEGUIResourceProvider.h"
////regular mem handler
//#include <OgreMemoryMacros.h>
namespace CODE_RED
{
class Menu
{
public:
Menu(Ogre::RenderWindow* Window, Ogre::SceneManager* SceneMgr);
virtual ~Menu(void);
bool Init(void);
protected:
//CEGUI::Renderer* mGUIRenderer;
CEGUI::OgreCEGUIRenderer* mGUIRenderer;
CEGUI::System* mGUISystem;
CEGUI::Window* mGUISheet;
Ogre::RenderWindow* mWindow;
Ogre::SceneManager* mSceneMgr;
private:
};
} // namespace
|
PS: Normalerweise ist es kein singleton, wobei CEGUI::WindowManager ein Singleton ist.
Kann man die Menu-Klasse nicht per delete wegräumen, wenn da ein Singleton enthalten ist ?
EDIT:
Der Destructor:
CPP: | Menu::~Menu(void)
{
if(mGUISheet)
{
CEGUI::WindowManager::getSingleton().destroyWindow(mGUISheet);
}
if(mGUISystem)
{
delete mGUISystem;
mGUISystem = 0;
}
if(mGUIRenderer)
{
delete mGUIRenderer;
mGUIRenderer = 0;
}
} |
_________________ - - - - - - - - - - - - - - - - - - - -
-> http://www.sea-productions.de
-> http://www.krawall.de
- - - - - - - - - - - - - - - - - - - - |
|
Nach oben |
|
|
David Super JLI'ler
Alter: 39 Anmeldedatum: 13.10.2005 Beiträge: 315
Medaillen: Keine
|
Verfasst am: 04.04.2007, 15:03 Titel: |
|
|
Hi!
Verwendet WindowManager die Singletonvorlage von Ogre? Wenn ja, wurde da schon eine Instanz von erzeugt. Setz einfach mal nen Breakpoint in den D'tor und durchlauf von dort ab den Programmablauf, dann siehst du ja wo er abbricht. |
|
Nach oben |
|
|
fast hawk Senior JLI'ler
Anmeldedatum: 15.07.2005 Beiträge: 237 Wohnort: Freiburg Medaillen: Keine
|
Verfasst am: 04.04.2007, 19:46 Titel: |
|
|
moin
ganz kapier ich den unterschied auch net aber...
1. Zugriff auf nichtvorhanden speicher(speicherüberschreitungen)
2. Zugriff auf Undefinierte Pointer
3. und noch en paar sachen
zählen als Hardwareexceptions(siehe Patriks Thread...).
Ich kann mir des nur so erklären des sie net "direct" vom code verursacht werden sonder Hardwareabhängig(arbeitsspeicher).
vllt kann des hier noch jmd. erklären der es checkt..!!
mfg fast_hawk _________________ Jetziges Projekt: The Ring War
Status: 40%
-----------------------------------
Nicht weil es schwer ist, wagen wir es nicht, sondern weil wir es nicht wagen, ist es schwer.
--
Lucius Annaeus Seneca (4)
röm. Philosoph, Dramatiker und Staatsmann |
|
Nach oben |
|
|
Mat Senior JLI'ler
Alter: 36 Anmeldedatum: 17.09.2005 Beiträge: 205 Wohnort: Koblenz Medaillen: Keine
|
Verfasst am: 04.04.2007, 20:00 Titel: |
|
|
@DAVID:
Also die Singleton vorlage stammt nicht von Ogre, aber es handelt sich um eine ähnliche von CEGUI. Diese sieht wie folgt aus:
CPP: | template <typename T> class CEGUIEXPORT Singleton
{
protected:
// TODO: Come up with something better than this!
// TODO:
// TODO: This super-nasty piece of nastiness was put in for continued
// TODO: compatability with MSVC++ and MinGW - the latter apparently
// TODO: needs this.
static
#ifdef __MINGW32__
CEGUIEXPORT
#endif
T* ms_Singleton;
public:
Singleton( void )
{
assert( !ms_Singleton );
ms_Singleton = static_cast<T*>(this);
}
~Singleton( void )
{ assert( ms_Singleton ); ms_Singleton = 0; }
static T& getSingleton( void )
{ assert( ms_Singleton ); return ( *ms_Singleton ); }
static T* getSingletonPtr( void )
{ return ( ms_Singleton ); }
}; |
Eine Instanz wird hier direkt erzeugt, aber was genau hat das mit dem Dtor zu tuen ?
PS: das mit dem Breakpoint muss ich gleich nochmal probieren, eben habe ich es versucht, da ist der Rechner abgestürzt oO.
@fast hawk:
Das ist auch nicht weiter tragisch, aber gut zu wissen das es sowas gibt _________________ - - - - - - - - - - - - - - - - - - - -
-> http://www.sea-productions.de
-> http://www.krawall.de
- - - - - - - - - - - - - - - - - - - - |
|
Nach oben |
|
|
David Super JLI'ler
Alter: 39 Anmeldedatum: 13.10.2005 Beiträge: 315
Medaillen: Keine
|
Verfasst am: 04.04.2007, 20:52 Titel: |
|
|
@fast hawk: Das sind Exceptions die direkt vom System geworfen werden. Also mitunter das oft erwähnte undefinierte Verhalten.
@Mat:
Nein da wird keine Instanz erzeugt, das musst du vorher machen! |
|
Nach oben |
|
|
DirectXer Dark JLI'ler
Anmeldedatum: 05.02.2005 Beiträge: 1201 Wohnort: Köln Medaillen: Keine
|
Verfasst am: 04.04.2007, 22:12 Titel: |
|
|
@Mat:
das was David sagt ist richtig, denn der C-Tor der Basisklasse oben funtkioniert folgendermaßen: CPP: | Singleton( void )
{
assert( !ms_Singleton );
ms_Singleton = static_cast<T*>(this);
} |
da wird ms_Singleton die Instanz nur zugewiesen, durch eine Art "down_cast" von this auf die (abgeleitete) Klasse des Typs T. Er geht aber davon aus, dass die Instanz vorher erzeugt wurde, da das da nur eine Zuweisung ist. Insofern ist das assert() vor der Zuweisung, das eigentlich dafür da sein sollte, um anzuzeigen dass noch keine Instanz erzeugt wurde, eigentlich quatsch, wenn niemand ms_Singleton vor dem Konstruktor explizit mit 0 initialisiert
Gruß DXer |
|
Nach oben |
|
|
|
|
Du kannst keine Beiträge in dieses Forum schreiben. Du kannst auf Beiträge in diesem Forum nicht antworten. Du kannst deine Beiträge in diesem Forum nicht bearbeiten. Du kannst deine Beiträge in diesem Forum nicht löschen. Du kannst an Umfragen in diesem Forum nicht mitmachen.
|
Powered by phpBB © 2001, 2005 phpBB Group Deutsche Übersetzung von phpBB.de
|