JLI Spieleprogrammierung Foren-Übersicht JLI Spieleprogrammierung

 
 FAQFAQ   SuchenSuchen   MitgliederlisteMitgliederliste   BenutzergruppenBenutzergruppen 
 medals.php?sid=7b6a86be89f768faa33a3c2bf7650a1bMedaillen   RegistrierenRegistrieren   ProfilProfil   Einloggen, um private Nachrichten zu lesenEinloggen, um private Nachrichten zu lesen   LoginLogin 

Verständnis Try - Catch
Gehe zu Seite 1, 2  Weiter
 
Neues Thema eröffnen   Neue Antwort erstellen    JLI Spieleprogrammierung Foren-Übersicht -> Entwicklung
Vorheriges Thema anzeigen :: Nächstes Thema anzeigen  
Autor Nachricht
Mat
Senior JLI'ler


Alter: 35
Anmeldedatum: 17.09.2005
Beiträge: 205
Wohnort: Koblenz
Medaillen: Keine

BeitragVerfasst am: 04.04.2007, 01:43    Titel: Verständnis Try - Catch Antworten mit Zitat

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
Benutzer-Profile anzeigen Private Nachricht senden Website dieses Benutzers besuchen
AFE-GmdG
JLI MVP
JLI MVP


Alter: 44
Anmeldedatum: 19.07.2002
Beiträge: 1374
Wohnort: Irgendwo im Universum...
Medaillen: Keine

BeitragVerfasst am: 04.04.2007, 08:37    Titel: Antworten mit Zitat

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
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden Website dieses Benutzers besuchen
DirectXer
Dark JLI'ler



Anmeldedatum: 05.02.2005
Beiträge: 1201
Wohnort: Köln
Medaillen: Keine

BeitragVerfasst am: 04.04.2007, 09:16    Titel: Antworten mit Zitat

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? Rolling Eyes ) ausgeführt wird und dein Programm da schon crasht. Dann würde es nie zu deiner MessageBox kommen...

Gruß DXer
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden
David
Super JLI'ler


Alter: 38
Anmeldedatum: 13.10.2005
Beiträge: 315

Medaillen: Keine

BeitragVerfasst am: 04.04.2007, 09:38    Titel: Antworten mit Zitat

Was für ne Meldung kommt den? Zur not versuchst dus halt mal mit Hardwareexceptions.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
Mat
Senior JLI'ler


Alter: 35
Anmeldedatum: 17.09.2005
Beiträge: 205
Wohnort: Koblenz
Medaillen: Keine

BeitragVerfasst am: 04.04.2007, 10:44    Titel: Antworten mit Zitat

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
Benutzer-Profile anzeigen Private Nachricht senden Website dieses Benutzers besuchen
PeaceKiller
JLI Master


Alter: 35
Anmeldedatum: 28.11.2002
Beiträge: 970

Medaillen: Keine

BeitragVerfasst am: 04.04.2007, 11:27    Titel: Antworten mit Zitat

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
Benutzer-Profile anzeigen Private Nachricht senden Website dieses Benutzers besuchen
AFE-GmdG
JLI MVP
JLI MVP


Alter: 44
Anmeldedatum: 19.07.2002
Beiträge: 1374
Wohnort: Irgendwo im Universum...
Medaillen: Keine

BeitragVerfasst am: 04.04.2007, 11:28    Titel: Antworten mit Zitat

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
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden Website dieses Benutzers besuchen
Mat
Senior JLI'ler


Alter: 35
Anmeldedatum: 17.09.2005
Beiträge: 205
Wohnort: Koblenz
Medaillen: Keine

BeitragVerfasst am: 04.04.2007, 11:53    Titel: Antworten mit Zitat

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
Benutzer-Profile anzeigen Private Nachricht senden Website dieses Benutzers besuchen
David
Super JLI'ler


Alter: 38
Anmeldedatum: 13.10.2005
Beiträge: 315

Medaillen: Keine

BeitragVerfasst am: 04.04.2007, 12:50    Titel: Antworten mit Zitat

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
Benutzer-Profile anzeigen Private Nachricht senden
Mat
Senior JLI'ler


Alter: 35
Anmeldedatum: 17.09.2005
Beiträge: 205
Wohnort: Koblenz
Medaillen: Keine

BeitragVerfasst am: 04.04.2007, 13:30    Titel: Antworten mit Zitat

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 Wink

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
Benutzer-Profile anzeigen Private Nachricht senden Website dieses Benutzers besuchen
David
Super JLI'ler


Alter: 38
Anmeldedatum: 13.10.2005
Beiträge: 315

Medaillen: Keine

BeitragVerfasst am: 04.04.2007, 15:03    Titel: Antworten mit Zitat

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
Benutzer-Profile anzeigen Private Nachricht senden
fast hawk
Senior JLI'ler



Anmeldedatum: 15.07.2005
Beiträge: 237
Wohnort: Freiburg
Medaillen: Keine

BeitragVerfasst am: 04.04.2007, 19:46    Titel: Antworten mit Zitat

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..!! Confused

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
Benutzer-Profile anzeigen Private Nachricht senden Website dieses Benutzers besuchen
Mat
Senior JLI'ler


Alter: 35
Anmeldedatum: 17.09.2005
Beiträge: 205
Wohnort: Koblenz
Medaillen: Keine

BeitragVerfasst am: 04.04.2007, 20:00    Titel: Antworten mit Zitat

@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 Smile
_________________
- - - - - - - - - - - - - - - - - - - -
-> http://www.sea-productions.de
-> http://www.krawall.de
- - - - - - - - - - - - - - - - - - - -
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden Website dieses Benutzers besuchen
David
Super JLI'ler


Alter: 38
Anmeldedatum: 13.10.2005
Beiträge: 315

Medaillen: Keine

BeitragVerfasst am: 04.04.2007, 20:52    Titel: Antworten mit Zitat

@fast hawk: Das sind Exceptions die direkt vom System geworfen werden. Also mitunter das oft erwähnte undefinierte Verhalten. Smile

@Mat:
Nein da wird keine Instanz erzeugt, das musst du vorher machen!
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
DirectXer
Dark JLI'ler



Anmeldedatum: 05.02.2005
Beiträge: 1201
Wohnort: Köln
Medaillen: Keine

BeitragVerfasst am: 04.04.2007, 22:12    Titel: Antworten mit Zitat

@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 Razz

Gruß DXer
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden
Beiträge der letzten Zeit anzeigen:   
Neues Thema eröffnen   Neue Antwort erstellen    JLI Spieleprogrammierung Foren-Übersicht -> Entwicklung Alle Zeiten sind GMT
Gehe zu Seite 1, 2  Weiter
Seite 1 von 2

 
Gehe zu:  
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

Impressum