DLL/Klassen/Funktionen



  • Hallo,

    ich bin recht neu in der Welt von C/C++.

    Ich wollte nun ein paar allgemeine Funktionen und Klassen die mehrere Programme verwenden in eine DLL auslagern. Klappt auch soweit ganz gut, ausser bei freigeben des Speichers bei den Klassen bekomme ich dann Speicherzugrifffehler.

    hier ein kleier Source Auszug:

    Zeile die Problem macht hat Kommentar //Fehler

    // Auszug Main.cpp von Programm
    void initGlobalVars(){
      extMemwatchINI = new TIniFile( ChangeFileExt(Application->ExeName, ".INI") );
      pVersionInfo = new TCRVerInfo(Application->ExeName);
      pCUPInfo = new TCRCPUInfo();
    }
    //---------------------------------------------------------------------------
    void deleteGlobalVars(){
      delete extMemwatchINI; //Klappt ist aber ne Borland Klasse :-)
      delete pVersionInfo;   //Fehler
      delete pCUPInfo;       //Fehler
    }
    

    Danke im voraus
    Gruß
    IcemanX 🕶



  • Hallo IcemanX,
    ich glaube das ist schwer zu sagen ohne den Destructor deiner Klassen zu kennen. Was spielt sich in deinem Destructor ab?

    Mfg
    Evi48



  • Hi evi48,

    hier mein konstructor und destructor!!!!

    Danke im voraus 🙂

    Gruß IcemanX

    TCRVerInfo::TCRVerInfo(AnsiString slExeName)
    {
      DWORD handle; // Dummy, Windows does not use this parameter.
      DWORD size;
      if(!FileExists(slExeName)) { slExeName = Application -> ExeName; }
    
      size = GetFileVersionInfoSize(slExeName.c_str(), &handle);
    
      if(size == 0)
        return; // No file information
    
      char *buffer = new char [size];
      bool status = GetFileVersionInfo(slExeName.c_str(), 0, size, buffer);
      if(!status)
      {
        delete [] buffer;
        return;
      }
    
      // Extract the language ID
      UINT datasize;
      unsigned short *translation;
    
      /*status =*/ VerQueryValue( buffer, "\\VarFileInfo\\Translation",
        (void **) &translation, &datasize);
    
      // Here we create a prefix string that is the same for all the keys.
      AnsiString prefix = "\\StringFileInfo\\"
          + AnsiString::IntToHex(translation [0], 4)
          + AnsiString::IntToHex(translation [1], 4);
    
      // Extract all the version information.
      company_name         = GetVersionKey(buffer, prefix, "CompanyName");
      file_description         = GetVersionKey(buffer, prefix, "FileDescription");
      file_version         = GetVersionKey(buffer, prefix, "FileVersion");
      internal_name        = GetVersionKey(buffer, prefix, "InternalName");
      legal_copyright         = GetVersionKey(buffer, prefix, "LegalCopyright");
      legal_trademarks         = GetVersionKey(buffer, prefix, "LegalTrademarks");
      original_filename  = GetVersionKey(buffer, prefix, "OriginalFilename");
      product_name         = GetVersionKey(buffer, prefix, "ProductName");
      product_version         = GetVersionKey(buffer, prefix, "ProductVersion");
      file_comments        = GetVersionKey(buffer, prefix, "Comments");
      delete [] buffer;
      return;
    }
    //--------------------------------------------------------------------
    // Dekonstuktor
    TCRVerInfo::~TCRVerInfo(){
      return;
    }
    


  • Lass im Destruktor mal das return; weg



  • hatte ich schon probiert!!!! 😞



  • Hallo IcemanX,

    ich habe in meinem Projekt nachgesehen und festgestellt, dass ich die gleiche Klasse benutze. Allerdings habe ich keinen Destruktor in der Klasse und benutze das alles wie nachstehend:

    VerInfo * pVer = new VerInfo(Exe);
    	// Ist das Objekt erfolgreich generiert?
    	if(pVer != NULL)
    	{
    		Version	= pVer->GetVerInfo(VI_FILE_VERSION);
    		delete pVer; pVer = NULL;
    	}
    

    So funktioniert das bei mir problemlos.

    All das findest du auch hier: http://www.bytesandmore.de/rad/index.htm?http://www.bytesandmore.de/rad/cpp/snipp/sc06001.php

    Viel Erfolg
    Evi48



  • Was ist mit der __finally Erweiterung von Borland ? Funktioniert das in diesem Falle nicht ?

    try {
    pVersionInfo = new TCRVerInfo(Application->ExeName);
    pCUPInfo = new TCRCPUInfo();

    }
    __ finally {

    delete pVersionInfo;
    delete pCUPInfo;
    }



  • Hallo wegus,
    dein Tip ist sicher nicht schlecht, doch so weit ich IcemanX verstanden habe tritt der Fehler beim löschen des Objektes auf. Dein Vorschlag würde nur dann die finally durchlaufen wenn beim Erzeugen ds Objektes ein Fehler aufgetreten wäre.

    Evi48



  • @evi48:

    Ehrlich ? Dann habe ich das Konzept von __finally falsch verstanden ! Ich dachte im Gegensatz zu try/catch wird __finally auch ohne Fehler abgearbeitet. Muß ich wohl noch mal nachlesen... 🙄



  • Hallo,

    Eine Instanz dieser Klasse sollte problemlos zu löschen sein. Ich vermute hier einfach mal, dass der Fehler zwischen den Aufrufen dieser beiden Funktionen liegt. Evtl. wird delete vorher schonmal aufgerufen. Ein Destruktor (nicht Dekonstruktor) ist hier ebenfalls nicht nötig.
    Das Design dieser Klasse halte ich allerdings für fragwürdig (returns im Konstruktor u. ä.). Zu Abfragen der Versionsinformationen würde doch auch eine einfach Funktion reichen.

    @evi48
    Ich weis, das der Code zur Abfrage aus diesem Link stammt, verstehe aber trotzdem diesen Aufwand nicht. Warum muss die Instanz dynamisch erzeugt werden? Ein einfaches Instanziieren (so wie VerInfo pVer;) reicht doch auch. Die Abfrage if(pVer != NULL) ist ebenfalls sinnlos. Wenn die Instanz nicht erzeugt werden konnte gibts eine Exception. Ein delete eines NULL-pointers gibt keinen Fehler. Warum das Ganze also?

    Ciao



  • wegus schrieb:

    Ehrlich ? Dann habe ich das Konzept von __finally falsch verstanden ! Ich dachte im Gegensatz zu try/catch wird __finally auch ohne Fehler abgearbeitet. Muß ich wohl noch mal nachlesen... 🙄

    Ja, du hast recht - finally wird immer durchlaufen. Du fängst aber nur die Fehler beim Erstellen ab. Obwohl aber gerade das delete überprüft werden soll. (Laut Evi48)



  • Hallo C++ Freunde,
    ich möchte nicht von behaupten absolut fitt in C++ zu sein aber ich denke IcemanX geht es nur um den Destruktor seiner Klasse.

    IcemanX schrieb:

    Klappt auch soweit ganz gut, ausser bei freigeben des Speichers bei den Klassen bekomme ich dann Speicherzugrifffehler.

    Mit finally habe ich nachgelesen und hatte Unrecht doch löst es auch nicht das Problem.

    Evi48



  • Hallo,

    Leute da ich ich ja ne Diskusion in die Welt gerufen !!!!

    Kann es sein das es ein Problem der Speicherverwaltung meiner DLL ist oder so.

    Gebe gerne mal das Projekt weiter bei Interesse!!! (es lebe open source) 🙂

    Da kann wer will mal die Klasse aus meinr im eigenen Projekt testen, ob das gleiche passiert !!!???!!!!

    Gruß
    IcemanX



  • Hallo,

    haben noch eine Person mit dem gleichen Prob. gefunden,

    siehe Beitrag ^16:13:27 18.11.2003 SilentSurfer^

    [url]http://www.c-plusplus.net/forum/viewtopic.php?t=55626&highlight=dll+klassen+delete
    [/url]

    dort steht aber auch keine Lösung!!!!!!!!!!! 😞


  • Mod

    Hallo

    kannst du dein Projekt online stellen
    (finden sich moeglicherweise einige die das dann checken)

    MfG
    Klaus





  • hat schon wer nen Anhaltspunkt 😕



  • kann ihm denn keiner helfen der ist bestimmt schon ganz frustriert 😉





  • Hallo,

    habe gerade von einem aufmerksamen User erfahren das viele gar keine *.rar Dateien öffnen können. Dachte eigentlich das sich RAR durch die grössere Leistung gegenüber ZIP schon mehr durchgesetzt hat ..... 🙄

    Vielen Dank an Hinterthuer Dieter für die Info 🙂

    Hier der Link im ZIP Format:

    http://www.cr-solutions.net/temp/crlib.zip


Log in to reply