3. Verschiedene Objekte mit wiederkehrender Arbeit initialisieren

Verschiedene Objekte mit wiederkehrender Arbeit initialisieren

  • S

    Was mein Vorposter bereits verlinkt hat, will ich dir nun kurz erklären.

    Die Regel der Drei besagt:
    Wenn man einen der folgenden Drei Funktionen definiert: Destruktor, Zuweisungsoperator oder Kopierkonstruktor - sollte man alle Definieren.
    Denn höchstwahrscheinlich wird in diesen Funktionen etwas getan (bspw. Resourcen-Verwaltung), was in den anderen auch getan werden sollte. Da die vom Compiler generierten Default-Versionen dieser Funktionen eben einfach etwas falsches tun könnten, wie nicht den Pointee sondern den Pointer zu kopieren.

    Dein Beispiel hat die Macke, dass es wirklich unschön gelöst ist.
    Was du wirklich willst, ist nicht eine komische Funktion die etwas völlig unintuitives tut (ein Getter ist i.d.R. immer const -qualifiziert und verändert das Objekt nicht), sondern die Regel der großen Drei beachten:

    struct foo
{
    foo(unsigned int const); 
    foo( foo const& );

    ~foo();
    foo& operator=(foo f);

    foo& swap( foo& ); /// Optional, verwende ich hier für das Copy&Swap-Idiom

    unsigned int const n;
    double* p_array;
};

    Und die Definition sieht folgendermaßen aus:

    foo::foo( foo const& f ):
    n(f.n),
    p_array( new double[n] )
{
    std::copy( f.p_array, f.p_array + n, p_array ); // Array rüberkopieren
}

foo& foo::operator=(foo f) /// Diese Art, den Zuweisungsoperator zu definieren nennt man das Copy&Swap-Idiom. Google es mal.
{
    return swap(f);
}

foo& foo::swap( foo& f)
{
    /// Hier werden nur die unterliegenden Skalare kopiert, nicht das Array o.ä.
    std::swap(f.n, n);
    std::swap(f.p_array, p_array);
    return *this;
}

    Was du also tust ist, die korrekte Verwaltung der Ressourcen - kopieren, zerstören, usw. - gewissermaßen zu erzwingen, in dem du die entsprechenden Funktionen definierst. Dadurch kann gar nix mehr schiefgehen, rein theoretisch nicht.

    Also schön RAII beachten. 😋 👍

    Da du p_array einen ekligen Präfix ( p_ ) dranhängst, verweise ich dich auf Hungarian Notation.

    Code ist übrigens net getestet. ⚠

    0
  • ?

    Sone schrieb:

    Code ist übrigens net getestet. ⚠

    eyyy gooooil, oldääär!
    sogar netzwerkgetesteten code gibbet hier!
    👍

    0
  • ?

    Sone schrieb:

    struct foo
{
    foo(unsigned int const); 
    foo( foo const& );

    ~foo();
    foo& operator=(foo f);

    foo& swap( foo& ); /// Optional, verwende ich hier für das Copy&Swap-Idiom

    unsigned int const n;
    double* p_array;
};

    Und die Definition sieht folgendermaßen aus:

    foo::foo( foo const& f ):
    n(f.n),
    p_array( new double[n] )
{
    std::copy( f.p_array, f.p_array + n, p_array ); // Array rüberkopieren
}

foo& foo::operator=(foo f) /// Diese Art, den Zuweisungsoperator zu definieren nennt man das Copy&Swap-Idiom. Google es mal.
{
    return swap(f);
}

foo& foo::swap( foo& f)
{
    /// Hier werden nur die unterliegenden Skalare kopiert, nicht das Array o.ä.
    std::swap(f.n, n);
    std::swap(f.p_array, p_array);
    return *this;
}

    foo::~foo()
{
    delete[] p_array;
}
    0

  • ...

    0
  • ?

    Swordfish schrieb:

    template< typename T >
class foo_t
{
    std::size_t /* warum zum teufel const */ size;
    T * data;

    Warum nicht const?

    Swordfish schrieb:

    public:
        foo_t( std::size_t const size )

    Ich frag mich eher, was das const hier soll :p

    0

  • ...

    0
  • ?

    Swordfish schrieb:

    out schrieb:

    Swordfish schrieb:

    template< typename T >
class foo_t
{
    std::size_t /* warum zum teufel const */ size;
    T * data;

    Warum nicht const?

    Weils't dann gleich ein Array nehmen kannst. :p

    Verstehe ich gerade nicht. Wie meinst?

    (mal schauen obs morgen früh klarer wird 🤡 )

    0

  • ...

    0
  • D

    Klaus82 schrieb:

    Auf jeden Fall scheine ich mit dem folgenden Minimalbeispiel (siehe unten) genau den Kern meines Problems zu treffen:

    Warum besitzt das struct ein rohes Array?

    double* p_array; // warum kein std::vector???????

    Wenn du dieses Array durch einen std::vector ersetzt, erleichterst du dir das Leben ungemein!

    0

  • ...

    0
  • K

    daddy_felix schrieb:

    Klaus82 schrieb:

    Auf jeden Fall scheine ich mit dem folgenden Minimalbeispiel (siehe unten) genau den Kern meines Problems zu treffen:

    Warum besitzt das struct ein rohes Array?

    double* p_array; // warum kein std::vector???????

    Wenn du dieses Array durch einen std::vector ersetzt, erleichterst du dir das Leben ungemein!

    Eine schlichte Antwort ist einfach, dass ich die ganzen Methoden eines STL Containers nicht benötige.

    Wie gesagt, zum Einen möchte ich in einer Struktur Arrays bereithalten, welche die GSL dann verwendet, um interpolierte Werte zu berechnen.

    Und zum anderen möchte ich einen Array von solchen Strukturen, genauer einen Array mit Pointern auf solche Strukturen, anlegen, um die verschiedenen Strukturen zu verwalten und mittels Index darauf zugreifen zu können.

    Damit ist die Verwendung eines STL Containers für mich 'mit Kanonen auf Spatzen schießen' in diesem Zusammenhang.

    Gruß,
    -- Klaus.

    0
  • D

    Klaus82 schrieb:

    Eine schlichte Antwort ist einfach, dass ich die ganzen Methoden eines STL Containers nicht benötige.

    Doch, das tust du. Der Container nimmt dir bspw. das Speichermanagement ab und du hast keine Probleme beim Kopieren. Zudem musst du nicht die Größe separat mitschleppen.

    Klaus82 schrieb:

    genauer einen Array mit Pointern auf solche Strukturen

    Warum denn schon wieder Pointer?

    BTW, Indexzugriff mit [] ist bei einem std::vector genauso möglich wie bei einem veralteten C-Array.

    0
  • V

    daddy_felix schrieb:

    BTW, Indexzugriff mit [] ist bei einem std::vector genauso möglich wie bei einem veralteten C-Array.

    veraltet, haha. ich hab's! nicht idiomatisch. ein anti-pattern. 🤡

    0
  • N

    Klaus82 schrieb:

    Eine schlichte Antwort ist einfach, dass ich die ganzen Methoden eines STL Containers nicht benötige.

    Zusätzlich zu dem, was daddy_felix schon sagte: Diese Aussage klingt so, als würdest du einen ungeheuren Overhead befürchten. Das ist nicht so, std::vector ist üblicherweise genau gleich schnell wie dynamisch angelegte Arrays. Je nach Operation sogar schneller, dank seiner Allokationsstrategie. Ausserdem erscheinen nicht aufgerufene Methoden nicht im Binary, sodass du nur für das bezahlst, was du wirklich brauchst.

    Klaus82 schrieb:

    Damit ist die Verwendung eines STL Containers für mich 'mit Kanonen auf Spatzen schießen' in diesem Zusammenhang.

    Ne. STL-Container sind der Standardansatz, wenn du dynamische Datenstrukturen benötigst. Wenn du eine selbstgestrickte Lösung oder direkt new[] und delete[] einsetzt, solltest du einen wirklich guten Grund dafür haben. Denn diese sind die Ausnahme, ihre Nachteile sollte man nicht leichtfertig in Kauf nehmen. Diese wären:

    • Manuelle Speicherverwaltung ist viel aufwändiger, fehleranfälliger und weniger übersichtlich als RAII.
    • Du musst die Grösse separat speichern.
    • Du kannst nicht leicht zwischen verschiedenen Containertypen wechseln, sollten sich die Anforderungen ändern.
    • Sämtliche Operationen wie Einfügen, Löschen etc. müssen nachprogrammiert werden. Auch wenn du diese im Moment nicht brauchst, kann es plötzlich sein, dass du sehr froh um sie wärst. Mindestens ein Iterator-Interface sollte gegeben sein
    • Du hast überhaupt keine Laufzeitchecks, was Bugs schwierig zu finden macht. Vernünftige STL-Implementierungen prüfen Indizes, Iteratoren etc. im Debug-Modus (d.h. kein Overhead) auf Gültigkeit, sodass entsprechende Fehler sofort entdeckt werden.

    volkard schrieb:

    veraltet, haha. ich hab's! nicht idiomatisch. ein anti-pattern. 🤡

    Ja. Aber nicht wegen std::vector , sondern std::array :p

    Aber ernsthaft, falls man C++11 verwenden kann, spricht wirklich nichts mehr für C-Arrays. Und selbst vorher ist std::tr1::array , boost::array oder zur Not eine selbstgeschriebene Klasse sinnvoller.

    0
  • K

    So,
    ich habe für die STL Befürworter was gebastelt.

    Ist das so gemeint bzw. besser?

    Viele Grüße,
    -- Klaus.

    // mb.cpp
#include <iostream>
#include <vector>
struct foo
{
foo(unsigned int const); 
unsigned int const n;
std::vector<double> daten;
};

foo::foo(unsigned int const x):
n(x)
{
	for(unsigned int i = 0; i < n; ++i)
		daten.push_back(i*0.2);
}

struct bar
{
	bar(std::vector<double>);
	std::vector<double> daten;
};

bar::bar(std::vector<double> x):
daten(x)
{}

int main()
{

	unsigned const n = 10; 

	struct foo f(n);

	struct bar b(f.daten);

	std::cout << "Time to clean up!" << std::endl;

	return 0;
}
    0
  • D

    👍

    * zwei Anmerkungen: das "n" in "foo" brauchst du vermutlich nicht mehr
    * dem Konstruktor von "bar" solltest du den vector als Referenz übergeben

    0
  • K

    Jetzt habe ich aber das Problem, dass die GSL scheinbar mit diesen Containern nicht zurecht kommt.

    Jetzt kriege ich z.B. die Fehlermeldung

    mb.cpp: In constructor ‘bar::bar(std::vector<double, std::allocator<double> >, std::vector<double, std::allocator<double> >)’:
mb.cpp:39: error: cannot convert ‘std::vector<double, std::allocator<double> >’ to ‘const double*’ for argument ‘2’ to ‘int gsl_spline_init(gsl_spline*, const double*, const double*, size_t)’
make: *** [mb.o] Fehler 1

    Zeile 39 weißt auf die Initialisierung hin, dazu sagt auch die GSL Dokumentation, dass ich einen const Array übergeben soll.

    Was mach ich denn jetzt?

    Gruß,
    -- Klaus.

    // mb.cpp
#include <iostream>
#include <vector>
#include <gsl/gsl_errno.h>
#include <gsl/gsl_spline.h>
struct foo
{
foo(unsigned int const); 
unsigned int const n;
std::vector<double> x_values;
std::vector<double> y_values;
};

foo::foo(unsigned int const x):
n(x)
{
	for(unsigned int i = 0; i < n; ++i)
	{
		x_values.push_back(i);
		y_values.push_back(i*i);
	}
}

struct bar
{
	bar(std::vector<double>,std::vector<double>);
	~bar();
	std::vector<double> x_values;
	std::vector<double> y_values;
	unsigned int const n;

	gsl_interp_accel* acc;
	gsl_spline* spline;
};

bar::bar(std::vector<double> x, std::vector<double> y):
x_values(x), y_values(y), n(x_values.size()),
acc(gsl_interp_accel_alloc()),spline(gsl_spline_alloc(gsl_interp_cspline,n))
{
	gsl_spline_init(spline,x_values,y_values,n);
}

bar::~bar()
{
	gsl_spline_free(spline);
	gsl_interp_accel_free(acc);
}

int main()
{

	unsigned const n = 10; 

	struct foo f(n);

	struct bar b(f.x_values,f.y_values);

	std::cout << "Time to clean up!" << std::endl;

	return 0;
}
    0
  • D
     

    void DoSomething(const double* ptr)
{
// ...
}

// ...

std::vector<double> tst(10);
double* adressOfFirstElement = &tst.front();

DoSomething(adressOfFirstElement);

    Ein std::vector garantiert, dass die Elemente wie in einem Array angeordnet sind. Somit kannst du die Adresse des ersten Elements übergeben.

    0
  • K

    Also um das Beispiel von oben zu ergänzen muss ich den spline der GSL wie folgt initialisieren

    gsl_spline_init(spline,& x_values.front(),& y_values.front(),n);

    Gruß,
    -- Klaus.

    0
  • K

    Kurz dazu:

    Nexus schrieb:

    Aber ernsthaft, falls man C++11 verwenden kann, spricht wirklich nichts mehr für C-Arrays. Und selbst vorher ist std::tr1::array , boost::array oder zur Not eine selbstgeschriebene Klasse sinnvoller.

    Ich sehe regelmäßig im Linux Magazin Artikel von Rainer Grimm zum neuen C++11 Standard. Sein Buch wird auch hier im Forum als gut befunden.

    Was mich etwas wundert: Mir wurde zur Verwendung von z.B. vector geraten, aber das ist doch 'nur' STL.

    Im Wikieintrag von C++11 [1] steht z.B.

    C++11 includes several additions to the core language and extends the C++ standard library, [..]

    während beim verlinkten Artikel der standard library [2] steht

    The C++ Standard Library is based upon conventions introduced by the Standard Template Library (STL). Although the C++ Standard Library and the STL share many features, neither is a strict superset of the other. In particular, the C++ Standard Library has also been influenced by the work of Alexander Stepanov and Meng Lee.

    Was mich nun zu zwei fragen führt:

    Haben wir jetzt über einen vector der STL gesprochen oder C++11? Ich habe lediglich #include <vector> geschrieben und schon funktioniert die Verwendung. Was mich gerade zu der peinlichen Frage führt, woran sehe ich das? Ich habe ja kein C++ installiert, sondern einen Compiler ( gcc (Debian 4.4.5-8) 4.4.5). Und dem kann ich z.B. die Option std=c++0x mitgeben, was die Verwendung des neuen Standards signailisiert?

    Die nächste einfache Frage ist: Lohnt sich das Buch (schon) für mich? Wenn ich mir das Inhaltsverzeichnis [3] ansehe, dann ist nur Kapitel 'IV Standardbibliothek' relevant und dazu habe ich schon das Buch 'Die C++ Standardbibliothek von Kuhlins und Schader'

    Viele Grüße,
    -- Klaus.

    0
Anmelden zum Antworten