Verschiedene Objekte mit wiederkehrender Arbeit initialisieren

Klaus82 schrieb:

Kann ich dem unique_ptr nicht sagen, dass er seine Ressource mittels der beiden freigeben soll.

Ist das eine Frage?
Die Antwort wäre ja. Und das ist wohl auch der Weg, den Du gehen solltest.

Eigentlich sollte jetzt ein kleines Beispiel kommen, aber es ist doch größer geworden (eins der Beispiele von der gsl Site).
Das Herzstück sind allerdings die beiden unique_ptr , die diesmal einen deleter mitbekommen.

#include <iostream>
#include <memory>
#include <vector>
#include <cmath>

#include <gsl/gsl_interp.h>

class interpolation{
public:
  // An C++ Algorithmen angelehnt:
  template<typename InputIter, typename InputIter2>
  interpolation(InputIter first1, InputIter last1, InputIter2 first2, const gsl_interp_type*& t = gsl_interp_cspline):
    x_(first1, last1),
    y_(first2, first2 + std::distance(first1,last1)),
    acc_(gsl_interp_accel_alloc(), gsl_interp_accel_free),
    interp_(gsl_interp_alloc(t, x_.size()), gsl_interp_free)
  {
    gsl_interp_init(interp_.get(), &x_.front(), &y_.front(), x_.size());
  }

  double operator()(double x)
  {
    return gsl_interp_eval (interp_.get(), &x_.front(), &y_.front(), x, acc_.get());
  }
  private:
  std::vector<double> x_,y_;
  std::unique_ptr<gsl_interp_accel, decltype((gsl_interp_accel_free))> acc_;
  std::unique_ptr<gsl_interp, decltype((gsl_interp_free))> interp_;
};

int main(){
  std::vector<double> x,y;
  std::cout << "#m=0,S=2\n";
  for(int i = 0;i<10; ++i){
    x.push_back(i + 0.5 * std::sin (i));
    y.push_back(i + std::cos (i * i));
    std::cout << x.back() << ' ' << y.back() << '\n';
  }
  std::cout << "#m=1,S=0\n";

  interpolation interp(begin(x), end(x), begin(y));

  for (double xi = x.front(); xi < x.back(); xi += 0.01)
    {
      std::cout << xi << ' ' << interp(xi) << '\n';
    }
}

Klaus82

Das ist mal geiler Sch***

Vielen Dank!

Ich dein Beispiel genommen und vom Syntax etwas modifiert, um schließlich eine Header und C++ Datei zu schreiben:

#ifndef WRAPPER_H_
#define WRAPPER_H_

#include <iostream>
#include <vector>
#include <memory>

#include <gsl/gsl_errno.h>
#include <gsl/gsl_spline.h>

struct wrapper
{
	wrapper(std::vector<double>&, std::vector<double>&);

	double operator() (double);

	std::vector<double> x,y;
	std::unique_ptr<gsl_interp_accel, decltype((gsl_interp_accel_free))> acc;
	std::unique_ptr<gsl_spline, decltype((gsl_spline_free))> spline;
};

#endif

#include <iostream>
#include "wrapper.h"
/*
---{}--- constructor ---{}---
*/
wrapper::wrapper(std::vector<double>& x, std::vector<double>& y):
x(x),y(y),
acc(gsl_interp_accel_alloc(), gsl_interp_accel_free),
spline(gsl_spline_alloc(gsl_interp_cspline,x.size()), gsl_spline_free)
{
	gsl_spline_init(spline.get(), x.data(), y.data(), x.size());
}
/*
---{}--- operator() ---{}---
*/
double wrapper::operator() (double x)
{
	return gsl_spline_eval(spline.get(), x, acc.get());
}

Und jetzt muss in den Kopier und Zuweisungsoperator die move Semantik von einem unique_ptr in den anderen?

Was mich anhand der GSL noch wundert: Laut der Beschreibung sind alle nötigen Informationen in spline gespeichert, d.h. ich könnte mir das kopieren der beiden Vektoren sparen, oder nicht? D.h. die Inhalte der unique_ptr werden kopiert und die Vektoren im neuen Objekt 'geleert' bzw. auf Null gesetzt?

Gruß,
-- Klaus.

Klaus82 schrieb:

Und jetzt muss in den Kopier und Zuweisungsoperator die move Semantik von einem unique_ptr in den anderen?

Im Kopier-c'tor wohl nicht.
Brauchst Du denn beide in der kopierenden Variante? Schließlich sind das - in der jetzigen Form - immer zwei Vektoren, die da kopiert werden.
Aber mach erstmal...

Klaus82 schrieb:

Was mich anhand der GSL noch wundert: Laut der Beschreibung sind alle nötigen Informationen in spline gespeichert, d.h. ich könnte mir das kopieren der beiden Vektoren sparen, oder nicht? D.h. die Inhalte der unique_ptr werden kopiert und die Vektoren im neuen Objekt 'geleert' bzw. auf Null gesetzt?

Das "higher level interface" habe ich mal schön ausser acht gelassen. Geht aber sicherlich auch ohne std::vector und dann als Wrapper um diese splines.

Klaus82

Furble Wurble schrieb:

Klaus82 schrieb:

Und jetzt muss in den Kopier und Zuweisungsoperator die move Semantik von einem unique_ptr in den anderen?

Im Kopier-c'tor wohl nicht.
Brauchst Du denn beide in der kopierenden Variante? Schließlich sind das - in der jetzigen Form - immer zwei Vektoren, die da kopiert werden.
Aber mach erstmal...

Ich bin mir gerade nicht mehr so sicher, was die Benutzung von unique_ptr angeht. Ich bin darauf aus einen Wrapper zu schreiben, d.h. eine Klasse, die ihre Ressourcen verwaltet. Zum Einen aus der Motivation heraus, dass die GSL mit Pointern arbeitet und zum anderen, um lokale Kopien der Objekte an verschiedene Threads zu verteilen (-> Open MP).

Wenn ich das mit den Pointern richtig verstehe, dann müssen sowohl der Pointer, d.h. die ihn im gespeicherte Adresse und der Speichbereich worauf er zeigt, verwaltet werden.

Dann schaue ich mir die member function constructor des uniqe_ptr an.

Wenn ich das richtig verstehe, dann geht es darum sowohl um den Pointer, d.h. die Adresse:

The object takes ownership of p

D.h. der unique_ptr kümmert sich um die Adresse des Pointers und

The object acquires the content managed by x

Da bin ich mir nicht so sicher, aber ich verstehe das so, dass mit the content managed der Speicherbereich gemeint ist, worauf der Pointer zeigt.

Die Sache ist nun, dass wir einen einzigartigen (unique) Pointer haben: Wenn ich die Intention richtig verstehe, dann ist genau der unique_ptr für den ihm gegebenen Pointer und den zugrunde liegenden Speicherbereich zuständig - und sonst niemand! Also kein anderer Pointer darf auf den gleichen Speicherbereich zeigen. Das klingt sehr sinnvoll für die beabsichtigte Resourcenverwaltung.

Wenn ich nun ein neues Objekt B anhand eines vorhandenen (gleichen) Objekts A initialisieren möchte, dann muss das doch so gehen:
i) Ich muss so viel Speicher bereitstellen, wie jener groß ist worauf der Pointer in A (verpackt im unique_ptr ) zeigt.
ii) Ich muss den Inhalt des Speichers worauf der Pointer in A zeigt hinüberkopieren in den neu angelegten Speicher.
<--- jetzt bin ich eigentlich mit Objekt A schon fertig ---->
iii) Ich muss in B einen Pointer bereitstellen, der zu dem neu angelegten Inhalt im Speicher passt.
iv) Ich muss die Adresse an diesen Pointer übergeben
v) Ich muss den Pointer (und damit den Inhalt) in einen unique_ptr stecken, der fortan darüber wacht!

Und dabei ist es kontraintuitiv, weil der unique_ptr keinen Kopierkonstruktor besitzt.
Aber vielleicht bezieht sich dieses Kopieren nur auf die Adresse im Pointer, denn es darf ja kein anderer Pointer auf den Speichbereich zeigen, also ist es unnötig die Adresse kopieren zu müssen.

Gruß,
-- Klaus.

Klaus82 schrieb:

Wenn ich das mit den Pointern richtig verstehe, dann müssen sowohl der Pointer, d.h. die ihn im gespeicherte Adresse und der Speichbereich worauf er zeigt, verwaltet werden.

Ja. Klingt einleuchtend.

Klaus82 schrieb:

Wenn ich nun ein neues Objekt B anhand eines vorhandenen (gleichen) Objekts A initialisieren möchte, dann muss das doch so gehen:
i) Ich muss so viel Speicher bereitstellen, wie jener groß ist worauf der Pointer in A (verpackt im unique_ptr ) zeigt.
ii) Ich muss den Inhalt des Speichers worauf der Pointer in A zeigt hinüberkopieren in den neu angelegten Speicher.
<--- jetzt bin ich eigentlich mit Objekt A schon fertig ---->
iii) Ich muss in B einen Pointer bereitstellen, der zu dem neu angelegten Inhalt im Speicher passt.
iv) Ich muss die Adresse an diesen Pointer übergeben
v) Ich muss den Pointer (und damit den Inhalt) in einen unique_ptr stecken, der fortan darüber wacht!

So schlimm wird's schon nicht werden - den unique_ptr benutzt Du hauptsächlich, damit die *_free() Funktionen überall ordentlich aufgerufen werden.
Bevor Du so ein Ding wie einen gsl_interp_alloc* kopierst, allozierst und generierst Du Dir lieber einen neuen über das Interface, das gsl dafür bietet.

Klaus82

<--- kann gelöscht werden --->