Vektor-Klasse und dynamisch allokierter Speicher
-
Hallo,ihr alle.
Also meine erste Frage ist folgende:
Wenn Speicher dynamisch allokiert wird z.B. mit malloc(),wird der Speicher dann zum Programmende freigegeben.
Man muss ihn doch nur explizit z.B. durch Free() freigeben,wenn man ihn nicht mehr benötigt.Ok,das zweite ist:
Ich mache mich an eine Vektor-Klase und das einfachst diese zu implementieren,wäre so:
Der benötigte Speicher,wird dynamisch allokiert.
Und falls man die Vektor-Größe z.B. neu setzt,dann werden zuerst,die Daten kopiert,dann der alte Speicher freigegeben und der neue angefordert wird und am Schluss die Daten in diesen eingefügt werden.
Da ich die Vektor-Klasse hauptsächlich für die Daten von 3D-Objekten benutze und diese normalerweise öfters im Programm vorkommen,könnte dies zu einer Speicherfragmentierung kommen.
Aber wenn der Speicher zur Laufzeit nicht oder selten freigegeben wird,da er zur ganzen Laufzeit genutzt wird,würde es vielleicht nicht so sehr zu einer Speicherfragmentierung kommen.Falls die Speicherfragmentierung zu sehr zum Verhängnis wird,also wenn ihr es sagt,dann werde ich die Vektor-Klasse anders implementieren.
Aber es wäre halt der einfachste Weg...
-
Was spricht gegen std::vector?
Oder meinste mathematischen Vektoren? Dafür gibts std::valarray.
Oder meinst du Vektor als mathematisch/physikalisches Tupel aus n-Elementen?
Da ist es nicht notwendig Speicher zu allozieren, da n schon zur Compilezeit bekannt ist.BTW: in C++ gibts new und delete, wobei man letzteres nicht direkt aufrufen sollte.
-
Es spricht folgendes gegen std::vector:
Wenn ich std::vector in einer Klasse oder Struktur deklariere,gibt der Compiler als Fehlermeldung,dass vor der Konstante,also die Konstante die,die Größe beschreibt,kein Typ angegeben ist,da er std::vector nichts als so einen ansieht.
-
...
-
Folgendes Beipsiel würde nicht funktionieren ...
class Test { std::vector<int>Testvektor(10); };Anscheinend erkennt er std::vector nicht als gültigen Typ an.
-
coder++ schrieb:
Anscheinend erkennt er std::vector nicht als gültigen Typ an.
Das geht so:
#include <vector> class Test { std::vector<int> Testvektor; public: Test() : Testvektor(10) {} };Die Frage ist aber, ob eine Größenangabe überhaupt sinnvoll ist!
-
coder++ schrieb:
Folgendes Beipsiel würde nicht funktionieren ...
class Test { std::vector<int>Testvektor(10); };Anscheinend erkennt er std::vector nicht als gültigen Typ an.
*facepalm* *facepalm* *facepalm*
Lern, verdammt nochmal C++!
-
Lern ich doch.
Grade 3. Buch da es z.B. Klassen-Templates,Mesthoden-Templates,usw. erklärt,über die sonst noch nie gesprochen wurde und mich immer im Glauben ließen,es gäbe nur Funktions-Templates.
-
Wenn du bis jetzt noch nicht Init.-Listen gesehen hast, solltest du die Bücher wechseln.
Welche waren das denn?
-
Also:
-Das aktuelle,das ich lese:"Moderne C++ Programmierung" von Ralf Schneeweiß
-"Einführung in die Programmierung - C/C++" von Gundolf Haase
-"C++ Programmierung" von Benjamin Buch
-Das erste:"C++ Begleitheft zum Kurs für Mathematisch-technische Assistentinnen und Assistenten" von Wilhelm HanrathWobei ich das erste ganz und die anderen oft nur teilweise gelesen habe.
Nun lese ich das neueste,also "Moderne C++ Programmierung" aber ganz.Also nur das erste ist das aktuelle und nicht auch noch die 2 darunter.
-
...
-
Swordfish schrieb:
Also ich weiß ned so recht. Ist von 2006, fast schon prähistorisch. Im Hello World (!!) ein völlig sinnloses
std::endlund den ersten wirklich groben Schnitzer auf S. 23 bei den Wertebereichen von Grunddatentypen. Magst ned evtl. lieber den Primer lesen?Dieses endl ist eine Tüpfchenscheisserei von diesem Forum, von dem kann man nur darauf schliessen, dass der Autor hier nie aktiv war.
Allerdings ist das Buch schon etwas veraltet (die Codelistings sind ja frei verfügbar); z.B. hat er ein
throw(dies, jenese)darin stehen. Im Grossen und ganzen sieht es aber ganz in Ordnung aus, die Feinheiten kann er dann hier lernen.
-
...
-
nedevtl schrieb:
Dieses endl ist eine Tüpfchenscheisserei von diesem Forum, von dem kann man nur darauf schliessen, dass der Autor hier nie aktiv war.
Und Meyers nicht liest.
http://www.aristeia.com/Papers/C++ReportColumns/novdec95.pdf
Anno 1995.
Und das wirft sehr wohl einen Schatten auf den Autor. Um ein Buch zu schreiben, sollte man sich in der Gegend recht umfassend auskennen.
-
coder++ schrieb:
Das aktuelle, das ich lese: "Moderne C++ Programmierung" von Ralf Schneeweiß.
Habe mir eben die Leseprobe angeschaut. Bei "Hello World" + std::endl hätte ich noch ein Auge zugedrückt. Dann habe ich mir Seite 22, 23 und 24 angeschaut... Ich stimme Swordfish zu, ein weiters Buch für die Kategorie Nicht empfehlenswert.
-
out schrieb:
coder++ schrieb:
Das aktuelle, das ich lese: "Moderne C++ Programmierung" von Ralf Schneeweiß.
Habe mir eben die Leseprobe angeschaut. Bei "Hello World" + std::endl hätte ich noch ein Auge zugedrückt. Dann habe ich mir Seite 22, 23 und 24 angeschaut... Ich stimme Swordfish zu, ein weiters Buch für die Kategorie Nicht empfehlenswert.
War mir schon nach dem Titel klar.
Trittbrettfahrer vom unglaublich guten Titel "Modern C++-Design".
Trittbrettfahrertitel sind immer jämmerlich.
-
...
-
"malloc()" und "free()" haben in zeitgemäßem C++-Code nichts, wirklich rein gar nichts zu suchen.
-
Swordfish schrieb:
nedevtl schrieb:
[...] Dieses endl ist eine Tüpfchenscheisserei von diesem Forum, [...]
Ein
std::endlin einem Hello World in einem Lehrbuch (!) ist einfach eine in didaktischer Hinsicht zum Himmel stinkende Kacke. Da brauchts ned mal technische Argumente ... Auf Seite 23 geht's wie gesagt weiter ... da mag ich den Rest garnicht unbedingt kennen.Nö, das mit std::endl macht Sinn. Escape-Sequenzen kann man später noch erklären, bis dahin ist std::endl schön zu lesen.
Schaden tut's in den allerseltensten Fällen.
-
Ethon schrieb:
Swordfish schrieb:
nedevtl schrieb:
[...] Dieses endl ist eine Tüpfchenscheisserei von diesem Forum, [...]
Ein
std::endlin einem Hello World in einem Lehrbuch (!) ist einfach eine in didaktischer Hinsicht zum Himmel stinkende Kacke. Da brauchts ned mal technische Argumente ... Auf Seite 23 geht's wie gesagt weiter ... da mag ich den Rest garnicht unbedingt kennen.Nö, das mit std::endl macht Sinn. Escape-Sequenzen kann man später noch erklären, bis dahin ist std::endl schön zu lesen.
Schaden tut's in den allerseltensten Fällen.Der Schüler weiß anfangs ebensowenig wie endl funktioniert, (das war doch eine void-Funktion, für die der op<< eine Überladung hat, und die '\n' ausgibt und dann flusht,) noch wie '\n' funktioniert. Und man muß es ebensowenig erklären. Einfach nur '\n' bewirkt in der Ausgabe einen Zeilenumbruch.
Er kann doch '\n' tippen, oder? Und er ist (noch) kein Programmierdepp. Was sich aber ändern wird, wenn man ihn nur so behandelt.
