dlclose() -> delete auf alle zeiger?!

firefly

namenlos schrieb:

ich denke, dass wir die ganze source brauchen, um dir zu helfen.
data *d = load(); 
  data* p = new data(*d);
scheint mir keine kluge lösung zu sein. mir ist nicht klar, wieso du das so machst und nicht einfach die daten, auf die d zeigt, weiter verwendest. werden die daten, auf die d zeigt, nicht dynamisch allokiert?

naja das problem ist, das "d"(type data) nicht nur einfach Daten enthält sondern auch Methoden, welche Pigeon anscheinend im weiteren Programmablauf verwenden möchte. Da Pigeon nachdem Aufruf von load das Plugin entladen möchte (wiso auch immer) zeigen die "Funktionszeiger" des Objektes, nachdem Entladen des Plugins, auf ungültige Adressen.
Das ist auch der Grund für den Absturz den er in seinem Ausgangspost beschrieben hat.

Pigeon

Zu fireflys ausführung habe ich nichts mehr hinzuzufügen

Ihr meint also ich sollte sämtliche plugins die ganze zeit geöffnet lassen? Die daten aus dem plugin werden wohl im programm die ganze zeit genutzt werden, wobei das laden 1-30s dauert... Zudem dachte ich mir, dass der benutzer evtl ein plugin aktualisieren möchte ohne dass alles abstürzt und die daten verloren gehen... Natürlich muss er dass nicht können, aber wenn er es einfach ausprobiert... ?

Was stichhaltigeres fällt mir im Moment nicht ein...

firefly

Pigeon schrieb:

Zu fireflys ausführung habe ich nichts mehr hinzuzufügen

Ihr meint also ich sollte sämtliche plugins die ganze zeit geöffnet lassen? Die daten aus dem plugin werden wohl im programm die ganze zeit genutzt werden, wobei das laden 1-30s dauert... Zudem dachte ich mir, dass der benutzer evtl ein plugin aktualisieren möchte ohne dass alles abstürzt und die daten verloren gehen... Natürlich muss er dass nicht können, aber wenn er es einfach ausprobiert... ?

Was stichhaltigeres fällt mir im Moment nicht ein...

Naja es gibt folgende Möglichkeiten (bestimmt unvollständig)
- das Programm erlaubt das neuladen von aktualisierten Plugins nur beim Programmstart
- wenn ein Plugin aktualisiert wird, müssen die Daten neu generiert werden.

Aber mal ne andere Frage:
Was sollen die Plugins denn genau machen können?
Liefern die Plugins nur Daten die in der Klasse Data Verwendung finden? Können die Plugins die Klasse Data um weitere Methoden ergänzen oder werden die Methoden vom Programm festgelegt?

Wenn die Plugins nur ein Daten liefern sollen, wäre es eventuell sinnvoll, das die Plugins nicht ein Data Objekt selbst erzeugt sondern ihre Daten in ein bestehendes Objekt "übertragen".

Pigeon

Jetzt mal ganz konkret:
Ich lade 3D Dateien vom Typ *.obj (Wavefront) und *.3ds (3D Stduio). Ich hab vorher keine ahnung wie viel da drin steht und was. Also muss das zeug dynmaisch angefordert werden. Ein bestehendes Objekt zu verwenden ist somit schwierig (oder?). Zumal es ja nicht auf 1 beschränkt ist... Fast alle klassen haben dabei mindestens eine virtuelle funktion.

P.S:
Wie es scheint funktioniert es wenn ich einen zeiger ans plugin übergebe, der auf eine funktion im hauptprogramm zeigt die dann irgendwas allokiert. Im plugin wird dann natürlich ausschließlich diese mehthode verwendet. Was haltet ihr davon?

firefly

Pigeon schrieb:

Jetzt mal ganz konkret:
Ich lade 3D Dateien vom Typ *.obj (Wavefront) und *.3ds (3D Stduio). Ich hab vorher keine ahnung wie viel da drin steht und was. Also muss das zeug dynmaisch angefordert werden. Ein bestehendes Objekt zu verwenden ist somit schwierig (oder?). Zumal es ja nicht auf 1 beschränkt ist... Fast alle klassen haben dabei mindestens eine virtuelle funktion.

P.S:
Wie es scheint funktioniert es wenn ich einen zeiger ans plugin übergebe, der auf eine funktion im hauptprogramm zeigt die dann irgendwas allokiert. Im plugin wird dann natürlich ausschließlich diese mehthode verwendet. Was haltet ihr davon?

Sowas ähnliches meinte ich ja ;). Die load funktion des Plugins erwartet als Parameter ein Objekt des Types Data (per Zeiger oder besser als Referenz übergeben).
Die Data-Klasse enthält dann eine oder mehrere Methoden, über die das Plugin dann die geladenen Daten in das Objekt übertragen kann.

Pigeon

firefly schrieb:

Pigeon schrieb:

Jetzt mal ganz konkret:
Ich lade 3D Dateien vom Typ *.obj (Wavefront) und *.3ds (3D Stduio). Ich hab vorher keine ahnung wie viel da drin steht und was. Also muss das zeug dynmaisch angefordert werden. Ein bestehendes Objekt zu verwenden ist somit schwierig (oder?). Zumal es ja nicht auf 1 beschränkt ist... Fast alle klassen haben dabei mindestens eine virtuelle funktion.

P.S:
Wie es scheint funktioniert es wenn ich einen zeiger ans plugin übergebe, der auf eine funktion im hauptprogramm zeigt die dann irgendwas allokiert. Im plugin wird dann natürlich ausschließlich diese mehthode verwendet. Was haltet ihr davon?

Sowas ähnliches meinte ich ja ;). Die load funktion des Plugins erwartet als Parameter ein Objekt des Types Data (per Zeiger oder besser als Referenz übergeben).
Die Data-Klasse enthält dann eine oder mehrere Methoden, über die das Plugin dann die geladenen Daten in das Objekt übertragen kann.

Du übergibts schon nur die zeiger auf die methoden? Wenn ich die klasse im plugin einkompilieren muss stehe ich ja wieder vorm selben problem ... Ich habe mir da sowas vorgestellt:

//Edit: Der code ist käse ... er folgt gleich ^^

polygon* create_polygon() { return new polygon; }

struct allocator_t
{
    typedef polygon* (*polygon_ptr)();
    const polygon_ptr create_polygon;
};

void loadModel
{

    allocator_t alloc;
    alloc.create_polygon = &create_polygon;

    //dlopen, dlsym ...

    data* dat = load(alloc);
}

Vll geht das so oder so ähnlich ...

firefly

Pigeon schrieb:

firefly schrieb:

Pigeon schrieb:

Jetzt mal ganz konkret:
Ich lade 3D Dateien vom Typ *.obj (Wavefront) und *.3ds (3D Stduio). Ich hab vorher keine ahnung wie viel da drin steht und was. Also muss das zeug dynmaisch angefordert werden. Ein bestehendes Objekt zu verwenden ist somit schwierig (oder?). Zumal es ja nicht auf 1 beschränkt ist... Fast alle klassen haben dabei mindestens eine virtuelle funktion.

P.S:
Wie es scheint funktioniert es wenn ich einen zeiger ans plugin übergebe, der auf eine funktion im hauptprogramm zeigt die dann irgendwas allokiert. Im plugin wird dann natürlich ausschließlich diese mehthode verwendet. Was haltet ihr davon?

Sowas ähnliches meinte ich ja ;). Die load funktion des Plugins erwartet als Parameter ein Objekt des Types Data (per Zeiger oder besser als Referenz übergeben).
Die Data-Klasse enthält dann eine oder mehrere Methoden, über die das Plugin dann die geladenen Daten in das Objekt übertragen kann.

Du übergibts schon nur die zeiger auf die methoden? Wenn ich die klasse im plugin einkompilieren muss stehe ich ja wieder vorm selben problem ... Ich habe mir da sowas vorgestellt:

//Edit: Der code ist käse ... er folgt gleich ^^
polygon* create_polygon() { return new polygon; }

struct allocator_t
{
    typedef polygon* (*polygon_ptr)();
    const polygon_ptr create_polygon;
};

void loadModel
{

    allocator_t alloc;
    alloc.create_polygon = &create_polygon;

    //dlopen, dlsym ...

    data* dat = load(alloc);
}
Vll geht das so oder so ähnlich ...

Nö ich meinte Folgendes:
Die Klasse Data hat z.b. eine Methode um ein Polygon darin zu speichern

Data::InsertPolygon(Polygon &p){
...
}

Das Plugin Implementiert folgende load-funktion:

void load(Data &d)
{
	Polygon p;
	...
	// lade Polygon von Datei
	...
	d.InsertPolygon(p);
	...
}

Im Hauptprogramm wird dann einfach folgendes gemacht

void main()
{
	...
	// Plugin laden und adresse für load-funktion vom Plugin laden
	...
	// Daten Laden vom plugin
	Data d;
	load(d);
	...
	//Plugin entladen
	...
	// Daten verwenden
	...
}

Pigeon

Aber wie geht das denn? Ich müsste ja "class Data" in die library einkompilieren und das kommt einem new in der library gleich und das selbe Problem taucht wieder auf. Und wenn ich das nicht einbaue erscheint ein lookup error: undefinded symbol insert polygon.

den insert polygon macht bei mir ungefähr das:

polygon_base* polygon_base::create_polygon(std::vector<coordinates_t> pdat)
{
      polygon_base* polygon = 0;

      switch(pdat.size())
      {
      case TRIANGLE:
            polygon = new triangle(pdat);
            break;
      case QUAD:
            polygon = new quad(pdat);
            break;
      ....
       ...
      };

      addToOctree(polygon);

      return polygon;
}

Auch da isses allokiert, da polygon_base die abstrakte Basisklasse der verschidenen Typen ist...

firefly

Pigeon schrieb:

Aber wie geht das denn? Ich müsste ja "class Data" in die library einkompilieren und das kommt einem new in der library gleich und das selbe Problem taucht wieder auf. Und wenn ich das nicht einbaue erscheint ein lookup error: undefinded symbol insert polygon.

den insert polygon macht bei mir ungefähr das:
polygon_base* polygon_base::create_polygon(std::vector<coordinates_t> pdat)
{
      polygon_base* polygon = 0;

      switch(pdat.size())
      {
      case TRIANGLE:
            polygon = new triangle(pdat);
            break;
      case QUAD:
            polygon = new quad(pdat);
            break;
      ....
       ...
      };

      addToOctree(polygon);

      return polygon;
}
Auch da isses allokiert, da polygon_base die abstrakte Basisklasse der verschidenen Typen ist...

Mein Vorschlag ist etwas anders als dein ursprünglicher Ansatz.
Dein Problem besteht mit meinem Vorschlag nicht (zu mindestens das Problem mit dem Absturz wenn das Plugin entladen ist und eine Methode der Klasse Data aufgerufen werden soll)
denn die Klasse als solches wird im Hauptprogramm erzeugt und nicht im Plugin. Das Plugin läd dann nur noch reine Daten von der Quelle (in deinem Fall z.b. eine 3ds Datei) und überträgt diese Daten dann über die Methoden der Klasse Data in das Data Objekt(welches der load funktion übergebenen wurde).

Und ich glaube du hast das Problem noch nicht ganz verstanden auf das du gestoßen bist.
Das Problem ist nicht das erzeugen von dynamischen Elementen per "new" sondern wie die Methoden von erzeugten Objekten aufgelöst werden.

Wenn im Plugin nur reine Daten erzeugt werden und diese in ein im Hauptprogramm erzeugtes Objekt geladen werden, kann das Plugin nach dem laden der Daten sofort wieder entladen werden.

Pigeon

firefly schrieb:

Und ich glaube du hast das Problem noch nicht ganz verstanden auf das du gestoßen bist.
Das Problem ist nicht das erzeugen von dynamischen Elementen per "new" sondern wie die Methoden von erzeugten Objekten aufgelöst werden.

Wenn im Plugin nur reine Daten erzeugt werden und diese in ein im Hauptprogramm erzeugtes Objekt geladen werden, kann das Plugin nach dem laden der Daten sofort wieder entladen werden.

Du bist der Mann der Stunde!!! Zur Kenntnis genommen, verstanden, übernommen. Es geht. Danke! :xmas2: :xmas1:

dlclose() -&gt; delete auf alle zeiger?!

dlclose() -> delete auf alle zeiger?!