3. statische dlls und speicherverwaltung

statische dlls und speicherverwaltung

  • M

    Hallo,
    ich bin dabei ein Größere eigene Sammlung von Funktionen und Klassen in eine statische DLL zu kompilieren. Vorher habe ich sie einfach nur mit dem Projekt mitkompiliert.

    Gibt es da irgendwelche Dinge auf die ich achten sollte?
    Z.b. mit der Speicherverwaltung. Habe z.b. unter http://msdn2.microsoft.com/en-us/library/ms682594.aspx gelesen, dass die Anwendung und die DLL ein gemeinsamen Speicher verwendet. Gilt das auch für den C++ Speichermanager?

    Ich habe dazu eine einfache Test-Anwendung geschrieben. Funktionierte ohne Probleme. Hat aber vielleicht nix mit Realität zu tun...

    Unter http://msdn2.microsoft.com/en-us/library/d1587c1h(VS.80).aspx steht außerdem:

    An application can own things such as a stack, global memory, file handles, and a message queue, but a DLL cannot.

    Heißt das, dass ich beispielsweise keine Dateien öffnen und bearbeiten kann?
    Aber ein einfacher Aufruf von:

    std::ofstream out("c:\\ausgabe.txt");
out << "hallo"

    funktioniert innerhalb der Dll.

    Was noch wichtig zu erwähnen wäre, ist dass ich primär den GCC bzw. mingw verwende. Sollte aber theoretisch auch mit anderen Compilern funktionieren.

    Der Code wurde portabel geschrieben, sodass er sich auch unter Linux kompilieren lässt. Würde deswegen auch gerne hier was im Bezug auf linux hören.

    Es gibt auch einfache Dialoge, unter Windows direkt mit der WinAPI unter Linux vorerst als Konsolen-Ein/Ausgabe. Außerdem verwende ich OpenGL und SDL. Könnte da was mit DLLs schieflaufen?

    Danke im Voraus.

    0
  • T

    DLL = Dynamic Link Library.

    Gibt es da irgendwelche Dinge auf die ich achten sollte?
    Z.b. mit der Speicherverwaltung. Habe z.b. unter http://msdn2.microsoft.com/en-us/library/ms682594.aspx gelesen, dass die Anwendung und die DLL ein gemeinsamen Speicher verwendet. Gilt das auch für den C++ Speichermanager?

    Du solltest Speicher, den du mit malloc/new in der DLL alloziert hast, auch von der DLL wieder freigeben lassen und nicht von anderen Modulen, weil sie unterschiedliche C/C++ Laufzeitbibliotheken nutzen können.

    An application can own things such as a stack, global memory, file handles, and a message queue, but a DLL cannot.

    Heißt das, dass ich beispielsweise keine Dateien öffnen und bearbeiten kann?

    Nein. Wenn du die DLL in deinen Prozess einblendest, kannst du natürlich Dateien öffnen und alles andere ganz normal machen. Das da oben soll wohl eher heißen, daß die DLL im Speicher als solche diese Dinge nicht hat, weil sie ja kein eigenständiger Prozess ist, sondern nur von Prozessen eingeblendet wird und dann Bestandteil dieser wird.

    0
  • M

    tenchou schrieb:

    DLL = Dynamic Link Library.

    Meinte mit statisch die load-time dlls. Wirds bloß öffters mit statisch bezeichnet.

    Du solltest Speicher, den du mit malloc/new in der DLL alloziert hast, auch von der DLL wieder freigeben lassen und nicht von anderen Modulen, weil sie unterschiedliche C/C++ Laufzeitbibliotheken nutzen können.

    Heißt das, dass ich das irgnorieren kann, wenn die dll und die Anwendung mit demselben compiler (gleiche version) kompiliert wurde?

    0
  • T

    matimatiker schrieb:

    Heißt das, dass ich das irgnorieren kann, wenn die dll und die Anwendung mit demselben compiler (gleiche version) kompiliert wurde?

    Nein, das heißt ja nicht, daß sie nicht verschiedene C/C++ Laufzeitbibliotheken Versionen benutzen können.

    0

  • WENN du überall die gleiche Runtime DLL (!) verwendest dann hast du keine Probleme und "kannst das ignorieren".

    ad Runtime DLL (!): es funktioniert i.A. nicht wenn du statisch gegen die Runtime linkst. Mit VC6 zumindest garantiert nicht. Mit VC8 muss ich es erst probieren -- kann sein dass der Standardmässig den Process Heap verwendet, dann ginge Speicher rumreichen schonmal. Allerdings sind dann andere Dinge doppelt die nicht doppelt sein sollten, also am besten immer DLL Version der Runtime verwenden.

    0
  • M

    Habe im Moment ein anderes Problem.
    Z.b. wird in der Dll speicher angefordert. Wenn ich aber vom Programm aus, darauf zugreife, so zeigt der entsprechende Pointer immer noch nach nirgendwo.

    Werde mir am Wochende mal genauer anschauen und dann "berichten".

    0
  • M

    Nagut, konnte nicht bis zum Wochende warten.

    Habe diesen Thread gelesen. Eigentlich das gleiche Problem.
    Also habe ich ein Testprogramm geschrieben.

    //-------------------------------------------------------
// dll.h
//-------------------------------------------------------
#ifndef DLL_H_INCLUDED
#define DLL_H_INCLUDED

#ifdef DLL_EXPORT
#define EXPORT __declspec(dllexport)
#else
#define EXPORT __declspec(dllimport)
#endif

template <typename T>
class Test
{
public:
   static T* Get()
   {
      return &m_instance;
   }
private:
   static T m_instance;
};

template <typename T>
T Test<T>::m_instance;

//-----
int* EXPORT Get();

#endif

//-------------------------------------------------------
// dll.cpp
//-------------------------------------------------------
#include "dll.h"

int* Get()
{
   return Test<int>::Get();
}

//--------------------------------------------------------
// app.cpp
//--------------------------------------------------------
#include <iostream>

#include "dll.h"

int main()
{
   std::cout << Test<int>::Get() << std::endl;
   std::cout << Get() << std::endl;
}

    Und tatsächlich werden da zwei verschiedene Adressen ausgegeben.

    compiliert mit mingw 3.4.5 unter winxp. Die dll mit

    g++ -D DLL_EXPORT -shared -o testdll.dll dll.cpp -Wl,--out-implib,libtestdll.a

    Die Exe mit

    g++ app.cpp -L. -ltestdll

    Ok, ein Problem weniger.

    0
Anmelden zum Antworten