Verschiedene Objekte mit wiederkehrender Arbeit initialisieren
-
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
-
...
-
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
)
-
...
-
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!
-
...
-
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.
-
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.
-
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.
-
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[]
unddelete[]
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
, sondernstd::array
:pAber 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.
-
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; }
-
* zwei Anmerkungen: das "n" in "foo" brauchst du vermutlich nicht mehr
* dem Konstruktor von "bar" solltest du den vector als Referenz übergeben
-
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; }
-
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.
-
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.
-
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 Optionstd=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.
-
Klaus82 schrieb:
Was mich etwas wundert: Mir wurde zur Verwendung von z.B.
vector
geraten, aber das ist doch 'nur' STL.Was heisst hier "nur"? Die STL ist nach wie vor eine der wichtigsten Komponenten der C++-Standardbibliothek. In C++11 sind neue Container und Algorithmen dazu gekommen, was nicht heisst, dass man die alten nicht mehr benutzen sollte.
Auch musst du beim Begriff "STL" etwas aufpassen. Teilweise wurde er für alternative Implemenentierungen verwendet (d.h. Container-Bibliotheken ausserhalb der Standardbibliothek), besonders vor der Standardisierung. In diesem Forum ist mit STL aber meist die Standard Template Library als Bestandteil der Standardbibliothek gemeint, sowohl in C++98 als auch in C++11.
-
So,
fast das große Finale: Ist die Intention bisher richtig verpackt?
Die Struktur foo ist mittels
build
dafür zuständig die (x,y) Paare für lineare Funktionen zu basteln, während ich als Argument gerade die Steigung vorgebe.
Im ersten Fall erstelle ich die Tupel für die Steigung m=1, initialisiere eine Strukturb_one
mit diesen Werten und räume anschließend infoo
mittelsclean_up
wieder auf, sodass diese bereit ist für die nächste Funktion.Schließlich bastle ich für die Steigung m=2 die nächsten (x,y) Werte, übergebe diese an die zweite initialisierte Struktur
b_two
und räume dann auch wieder auf.Ist die STL jetzt richtig und sinnvoll eingesetzt?
Gruß,
-- Klaus.<-- Hier stand Blödsinn -->
-
So,
ich habe versucht das obige Vorgehen dahingehend zu ändern, dass ich nicht jedes Mal eine Instanz vonbar
initialisieren muss, sondern diese brav in einenvector
schiebe.Leider habe ich dann wieder das alte Problem des Speicherzugriffs.
Sehe ich das richtig, dass die Verwendung von
std::vector<struct bar>
mein Problem des Speicherzugriffsfehlers nicht löst und ich mich nach wie vor mit Copy & Swap Idiom beschäftigen muss, wie in diesem Post beschrieben?Ich hatte mich schon gewundert, dass die Verwendung von
vector
diese Probleme beheben soll, immerhin definiere ich einen Konstruktor und Destruktor vonfoo
, d.h. ich muss mich nach Ro3 automatisch mit Kopieren und Zuweisung beschäftigen?Gruß,
-- Klaus.<-- Hier stand Blödsinn -->
-
Also ich kriege es einfach nicht hin.
Ich habe versucht den Kopier- und Zuweisungsoperator zu basteln, aber ich kriege immernoch einen Speicherzugrifffehler und Valgrind schimpft auch mit mir.
// mb.cpp #include <iostream> #include <vector> #include <gsl/gsl_errno.h> #include <gsl/gsl_spline.h> struct foo { void build (unsigned int const); void clean_up(); std::vector<double> x_values; std::vector<double> y_values; }; void foo::build(unsigned int const m) { for(unsigned int i = 0; i < 100; ++i) { x_values.push_back(i); y_values.push_back(m*i); } } void foo::clean_up() { x_values.clear(); y_values.clear(); } struct bar { bar(std::vector<double> &,std::vector<double> &); bar(bar const &); bar& operator=(const bar&); ~bar(); std::vector<double> x_values; std::vector<double> y_values; double get(double); gsl_interp_accel* acc; gsl_spline* spline; }; bar::bar(std::vector<double> & x, std::vector<double> & y): x_values(x), y_values(y), acc(gsl_interp_accel_alloc()),spline(gsl_spline_alloc(gsl_interp_cspline,x_values.size())) { gsl_spline_init(spline,& x_values.front(),& y_values.front(),x_values.size()); } bar::bar(bar const & other): acc(other.acc),spline(other.spline) {} bar& bar::operator=(const bar& other) { if(this != &other) { gsl_spline_free(spline); gsl_interp_accel_free(acc); } acc = gsl_interp_accel_alloc(); spline = gsl_spline_alloc(gsl_interp_cspline,x_values.size()); return *this; } bar::~bar() { if(spline != 0) gsl_spline_free(spline); if(acc != 0) gsl_interp_accel_free(acc); } double bar::get(double x) { return gsl_spline_eval(spline,x,acc); } int main() { struct foo f; std::vector<struct bar> bars; f.build(1); bars.push_back(bar(f.x_values,f.y_values)); f.clean_up(); return 0; }