Frage zur Funktion List.push_back()

[Nexus]

triffts ziemlich gut...

Warum überhaupt so viele Variablen? Würde man das Ganze ein wenig sinnvoll kapseln, käme man nur noch auf vereinzelte Member pro Klasse. Also überlege dir, welche Variablen logisch zusammengefasst werden können, und lagere diese aus.

[drakon]

Ja, die Variable kommt auch auf den Heap. Und ja, du kannst dir die Zeiger sparen, unbedingt!

Also das, worauf der Zeiger zeigt befindet sich auf dem "Heap", aber der Zeiger selbst befindet sich auf dem "Stack". (ich schreibe das in Anführgungszeichen, weil ja eher dynamisch und automatisch gemeint ist, aber das mal ausser Acht gelassen.)

[Dravere]

drakon schrieb:

Ja, die Variable kommt auch auf den Heap. Und ja, du kannst dir die Zeiger sparen, unbedingt!

Also das, worauf der Zeiger zeigt befindet sich auf dem "Heap", aber der Zeiger selbst befindet sich auf dem "Stack". (ich schreibe das in Anführgungszeichen, weil ja eher dynamisch und automatisch gemeint ist, aber das mal ausser Acht gelassen.)

Er redet aber nicht vom Zeiger, sondern von der Variable in A. Keine Ahnung, wie du auf den Zeiger kommst. Vielleicht weil du so viele Zeiger gesehen hast?

Grüssli

[Nexus]

Ihr habt beide Unrecht.

A *first = new A;

A ist hier keine Variable und kein Zeiger, sondern ein Typ. :p

[Dravere]

@Nexus,
Dann sage mir, wie Neo Gandar es richtig hätte formulieren sollen. Womöglich:
"Wohin kommt die Variable im Objekt vom Typ A?"

Dann bist du aber ein Erbsenzähler! :p

Grüssli

[Neo Gandar]

oook hab ich das also richtig verstanden:

bei

class A{
private:
int a;
...
}; 	

A *first = new A;

*first befindet sich auf dem Stack, und zeigt auf das Object A, das sich im Heap befindet. Und somit ist die Variable a auch im Heap.

wenn ich jetz eine Liste erstelle

list<A> *Liste = new list<A>;

Dann befindet sich *Liste auf dem Stack, und zeigt auf die list im Heap.
Dadurch befinden sich, auch alle anderen Objekte und deren Zeiger, die in die Liste eingefügt werden im Heap.

Also ist das Einzige was dabei im Stack abgelegt wird *Liste, der rest kommt in den Heap. Oder?

Weil wär nicht so passend wenn die Zeiger für 100.000 Objekte, die in der Liste sind, auf dem Stack gespeichert werden

[drakon]

Dadurch befinden sich, auch alle anderen Objekte und deren Zeiger, die in die Liste eingefügt werden im Heap.

Gespeichert werden die Objekte in std::list und den meisten anderen Containern ebenfalls auf dynamisch (heap). Das ist ja der Sinn davon. Eine dynamische Menge an Objekten zu verwalten. Wenn du da dann mit eigenem new Zeugs kommst ist die ganze Übung umsonst und hättest alles von vorne selbst machen können.

@Nexus & Dravere:
Ihr seit doch beide Kindsköpfe. :p

[Dravere]

@Neo Gandar,
Alles korrekt bis auf den Teil, welcher drakon zitiert hat. Die Schlussfolgerung stimmt da nicht. Die Elemente liegen dort nicht auf dem Heap, weil du die Liste auf dem Heap gesetzt hast. Die Elemente in einer Liste haben nichts gemeinsames mit Membervariablen.

Schau auch ruhig nochmals meinen vorherigen Beitrag an und probier es aus:
http://www.c-plusplus.net/forum/viewtopic-var-p-is-1719623.html#1719623

Oder probier als Übung mal eine Double-Linked-List zu implementieren

@drakon,
So bleibt man jung

Grüssli

[Neo Gandar]

Ok, glaub jetz hab ich verstanden Hab dein Beispiel auf mit deque probiert

Muss jetz aber einen großteil des Programmes umschreiben, ich meld mich also wieder wenn das erledigt ist. Vermute aber, das ich irgendwo schlampig gerarbeitet hab, und dadurch der Fehler verursacht wird.

[Neo Gandar]

So, hab mich entschieden das Programm als Grundlage für ein neues zu nehmen da ich viel zu viele Fehler beim schreiben des Codes gemacht habe.

Hab die Klasse jetz aufgeteilt, und die erste Klasse fertig. Die Zweite sieht dann vom Aufbau her gleich aus.

Hier die data.h:

#ifndef _data_h
#define _data_h

#include <string>

using namespace std;

//Daten, die vom Programm erzeugt/ergänzt werden

class Data{

private:
	string itemName;
	string locationName;
	long long quantity;
	long long soll;
	long long difference;
	string groupID;
	string group;
	string categoryID;
	string category;

	bool adjusted;

public:
	Data();
	Data(const Data &base);	

	Data & operator = (Data const &base){
		string temp(base.itemName);
		temp.swap(this->itemName);

		temp = base.locationName;
		temp.swap(this->locationName);

		temp = base.groupID;
		temp.swap(this->groupID);

		temp = base.group;
		temp.swap(this->group);

		temp = base.categoryID;
		temp.swap(this->categoryID);

		temp = base.category;
		temp.swap(this->category);

		this->quantity = base.quantity;
		this->soll = base.soll;
		this->difference = base.difference;

		return *this;
	};
//Weitere Methoden
};

Und hier die data.cpp:

#ifndef _data_cpp
#define _data_cpp

#include <string>

#include "data.h"

using namespace std;

/* Variablen der Klasse Data:
    string itemName;
	string locationName;
	long long quantity;
	long long soll;
	long long difference;
	string groupID;
	string group;
	string categoryID;
	string category;

	bool adjusted;

*/

Data::Data(){
	itemName = "";
	locationName = "";
	quantity = 0;
	soll = 0;
	difference = 0;
	groupID = "";
	group = "";
	categoryID = "";
	category = "";
	adjusted = false;
};

Data::Data(const Data &base) 
		: itemName(base.itemName),
		locationName(base.locationName),
		quantity(base.quantity),
		soll(base.soll),
		difference(base.difference),
		groupID(base.groupID),
		group(base.group),
		categoryID(base.categoryID),
		category(base.category),
		adjusted(base.adjusted) {};

//Weitere Methoden

#endif

Hab versucht eure Vorschläge/Verbesserungen umzusetzten und hoffe dass das so jetzt auch passt

Grüße

[drakon]

Warum schiebst du bei deinem operator = alles zuerst in einen temporären String?
Du kannst alles direkt swappen und dann machst du einfach eine Kopie des gesamten Objektes (unter Benutzung des copy-ctor).
Und rufst dann swap auf.

Und warum benutzt du im default ctor die Initialisierungsliste nicht, wo du sie doch im copy-ctor benutzt?!

[unskilled]

Naja - ich find vieles nich so dolle - nen bissl was davon zähl ich hier mal auf:

#ifndef _data_h
#define _data_h

Makros werden eigtl groß geschrieben und (dann) am Anfang auch keine Unterstruiche enthalten - außerdem fehlt hier das #endif...

using namespace std;
Sollte man nie im Header stehen haben!
In der Source-Date (*.cpp) ist es aber in Ordnung - lediglich noch Geschmackssache ^^

Data & operator = (Data const &base){
		string temp(base.itemName);
		temp.swap(this->itemName);

base ist nen komischer name : D
Außerdem implementiert man den op= eigtl durch Copy&Swap:

Data& operator= (Data const &rhs)
{
 Data to_swap(rhs);
 swap(to_swap);
 return *this;
}

und wenn du es schon unbedingt so lassen möchtest, dann lass bitte das this-> weg - das führt ja zu Augenkrebs

string itemName;
	string locationName;
	long long quantity;
	long long soll;
	long long difference;
	string groupID;
	string group;
	string categoryID;
	string category;

	bool adjusted;

So viele Member-Variablen sind meist ein Indiz dafür, dass man die Klasse noch weiter aufsplitten sollte....
Außerdem: Warum IDs als string speicher?
Und warum alles englisch außer "soll"? : D

#ifndef _data_cpp
#define _data_cpp

Ähmm.. Nein? Die Source-Datei braucht keine Include-Guards... Hier gabs vor kurzem auch nen Thread, wo wir ein wenig erklärt haben, wie das mit den Source-Dateien ist (in Kurzform: werden von der IDE automatisch kompiliert - genau einmal und die *.h wird immer nur included, wenn iwas benötigt wird - und genau deshalb wird sie nur einmal geparst und braucht deshalb keine Include-Guards... Die würden btw auch nichts bringen, wenn du die *.cpp iwo includen würdest ^^

/* Variablen der Klasse Data:
    string itemName;
	string locationName;
	long long quantity;
	long long soll;
	long long difference;
	string groupID;
	string group;
	string categoryID;
	string category;

	bool adjusted;
*/

Nette Idee - aber eigtl überflüssig und vor allem umständlich

Data::Data(){
	itemName = "";
	locationName = "";
	quantity = 0;
	soll = 0;
	difference = 0;
	groupID = "";
	group = "";
	categoryID = "";
	category = "";
	adjusted = false;
};

-> Initialisierungsliste
Bei mir würde das so aussehen:

Data::Data()
:  quantity(0), soll(0), difference(0), adjusted(false)
{}

Japp, das reicht - mehr brauchst du nicht hinzuschreiben...
Der Standard-CTor von std::string liefert ja (logischerweise) nen leeren String... ^^

Data::Data(const Data &base) //wieder nen komischer Name ^^
		: itemName(base.itemName),
		locationName(base.locationName),
		/*...*/
		category(base.category),
		adjusted(base.adjusted) //ich würde nur ein Tab einrücken ^^
{}; //';' ist überflüssig

bb

[Neo Gandar]

außerdem fehlt hier das #endif...

Habs nur nicht mitkopert, da ich die ganzen Methoden nicht mitkopieren wollte ^^ habs übersehen dass es hier im Post fehlt.

Außerdem: Warum IDs als string speicher?

Weil die IDs sowieso nur als Vergleich zwischen verschiedenen Objekten dienen und ich diese aus ner Datei als string einlese, und mir die Typenumwandlung sparen wollte ^^.

Und warum alles englisch außer "soll"? : D

Weil mir, als ich damals das erste mal diese Klasse erstellt habe, der englische Begriff für "Sollwert" ned eingefallen ist ^^ und sieht ja nacher im Programm eh keiner

So viele Member-Variablen sind meist ein Indiz dafür, dass man die Klasse noch weiter aufsplitten sollte....

Man könnte die ganzen Variablen auch mit ner struc lösen, jedoch nutze ich den vorteil von Klassen, um über Polymorphie über die gleiche Methode nen string in eine long long variable umzuwandeln usw.

Warum ich das weiter aufteilen soll geht mir nicht ein, da die Methoden ja wirklich nur max. 4 Zeilen lang sind, und sich der Aufwand durch mehrere Klassen ja nur erhöht.

Warum schiebst du bei deinem operator = alles zuerst in einen temporären String?
Du kannst alles direkt swappen und dann machst du einfach eine Kopie des gesamten Objektes (unter Benutzung des copy-ctor).
Und rufst dann swap auf.

Hab mir das aus dem Link auf der ersten Seite abgeschaut, dass das auch mit dem ganzen Objekt geht wusste ich ned.

Zum using Namespace std; :
Das ganze Prog ist eigentlich in dem Namespace, und da ich nicht einbinde das nen anderen Namensraum hat, geht es doch so schneller oder? Oder lauf ich dadurch irgendwie in Gefahr?

Hab die Klasse mal geändert:

data.h

#ifndef DATA_H
#define DATA_H

#include <string>

using namespace std;

//Daten, die vom Programm erzeugt/ergänzt werden

class Data{

private:
	string itemName;
	string locationName;
	long long quantity;
	long long soll;
	long long difference;
	string groupID;
	string group;
	string categoryID;
	string category;

	bool adjusted;

public:
	Data();
	Data(const Data &rhs);	

	Data& operator= (Data const &rhs){
		Data to_swap(rhs);
		swap(to_swap, *this);
		return *this;
	} 
        //jede menge Methoden
};
#endif

data.cpp:

#include <string>
#include "data.h"

using namespace std;

Data::Data()
:	quantity(0),soll(0),difference(0),adjusted(false)
{}

Data::Data(const Data &rhs) 
	: itemName(rhs.itemName),
	locationName(rhs.locationName),
	quantity(rhs.quantity),
	soll(rhs.soll),
	difference(rhs.difference),
	groupID(rhs.groupID),
	group(rhs.group),
	categoryID(rhs.categoryID),
	category(rhs.category),
	adjusted(rhs.adjusted) {}

//Jede Menge Methoden

[Nexus]

Dein swap könntest du effizienter gestalten, indem du die jeweiligen Member einzeln tauschst. std::string zum Beispiel hat ein eigenes swap() implementiert. Das könnte zum Beispiel so aussehen:

void Data::swap(Data& other)
{
    std::swap(itemName, other.itemName);
    std::swap(quantity, other.quantity);
    // ...
}

Zudem kannst du noch ein globales swap() für deine Klasse anbieten. Ist zwar etwas Schreibaufwand, aber es ist gut, sich solche Dinge anzugewöhnen, auch später wegen Exceptionsicherheit. Dein Zuweisungsoperator könnte dann so aussehen:

Data& operator= (const Data& other)
{
    Data(other).swap(*this);
    return *this;
}

Brauchst du eigentlich long long ? Dieser Typ ist nicht im C++-Standard enthalten. In den meisten Fällen reichen eigentlich int bzw. long . Und IDs würde ich auch eher als Zahlen speichern...

Zum using namespace std; - ich würde mir generell abgewöhnen, using namespace in Headerdateien zu verwenden. Dadurch wird der gesamte Namensraum in allen inkludierenden Dateien ausgeschüttet, was nicht immer erwünscht ist. Die paar std:: sollten wohl noch drin liegen, soviel Aufwand ist das nicht. Ich gebe bei mir den Namensraum eigentlich immer an, auch in lokalen Funktionen.

[Neo Gandar]

Ok, danke für die Tipps, werd versuchen sie umzusetzten und mir das mit dem namespace abgewöhnen

Warum long long. Es kommt vor, dass die Zahlen bis zu einigen Milliarden groß sind (größte was ich gefunden hab waren ~150 Mrd), und das ist zuviel für ne normale long, da diese dann den Bereich überschreitet.

[Nexus]

Neo Gandar schrieb:

Warum long long. Es kommt vor, dass die Zahlen bis zu einigen Milliarden groß sind (größte was ich gefunden hab waren ~150 Mrd), und das ist zuviel für ne normale long, da diese dann den Bereich überschreitet.

Ah, dann ist es okay. Ich hatte nur irgendwie das Gefühl, du hättest mal vorsorglich grosse Typen genommen.

Du solltest dir einfach im Hinterkopf behalten, dass mit long long nicht mehr ganz standardkonform bist, solltest du zum Beispiel mal eine Portierung oder Ähnliches vorsehen.

[Neo Gandar]

Gibt es Standartkonforme Lösungen dafür? Da ich das Programm sowieso grad neu schreibe (und vorallem Strukturiere ) könnte ich es dann ja auch gleich ändern.

[Nexus]

Da müsstest du wohl auf externe Bibliotheken zurückgreifen. Solange es nur zur Übung ist oder du dich nicht gross um Portabilität kümmerst, würde ich sagen, lohnt sich der Aufwand einer Umstellung nicht. Eine Bibliothek impliziert nämlich das Suchen, Downloaden, Installieren, Doku-Lesen und Linken.

[drakon]

Neo Gandar schrieb:

Gibt es Standartkonforme Lösungen dafür? Da ich das Programm sowieso grad neu schreibe (und vorallem Strukturiere ) könnte ich es dann ja auch gleich ändern.

Naja. Ich würde ganz einfach ein typedef machen und dann diesen Typen benutzen. Dann kannst du das, wenn du das portieren willst einen geeigneten Typen suchen und den da anpassen. Dafür eine externe lib zu verwenden finde ich ein wenig übertrieben.

[unskilled]

Neo Gandar schrieb:

So viele Member-Variablen sind meist ein Indiz dafür, dass man die Klasse noch weiter aufsplitten sollte....

Man könnte die ganzen Variablen auch mit ner struc lösen, jedoch nutze ich den vorteil von Klassen, um über Polymorphie über die gleiche Methode nen string in eine long long variable umzuwandeln usw.

Warum ich das weiter aufteilen soll geht mir nicht ein, da die Methoden ja wirklich nur max. 4 Zeilen lang sind, und sich der Aufwand durch mehrere Klassen ja nur erhöht.

Es gibt zwischen struct und class fast keine Unterschiede...
Unterschiede:
- default access (public vs private)
- bei templates kann man (neben <typename T> auch) <class T> schreiben aber nicht <struct T>
- structs können nicht als class vorwärts deklariert werden - gleiches gilt auch umgedreht
ansonsten gibt es keinen Unterschied (der mir gerade einfallen würde)

also ist es egal, ob struct oder class - darauf wollte ich auch nicht hinaus, was ich fragen wollte:

string itemName;
    string locationName;
    long long quantity;
    long long soll;
    long long difference;
    string groupID; //1)
    string group; //1)
    string categoryID; //2)
    string category; //2)

    bool adjusted;

was ist der unterschied bei 1 und 2? (reicht vll die groupid aus und die group hängt von der groupid ab?)
wofür willst du deine Klasse Data nehmen? und was genau baust du damit?

falls du zu allen member-variablen ein paar worte sagen könntest, könnte man das mit sicherheit ein wenig aufsplitten (ich glaube z.bsp., dass adjusted im Ggnsatz zu dem Rest nur etwas über das Design aussagt - und würde es deshalb wohl nicht mit in die Klasse nehmen, die sich eigtl nur um den Inhalt kümmert...
Jz wirst du dich bestimmt fragen: Wieso? So gehts auch, ich brauch eh alles und so hätte ich viel mehr Arbeit: Ich finde aber, man sollte das Design immer vom Inhalt trennen - z.bsp. ist wahrscheinlich der fkt, die den bb-code durch html-tags ersetzt ziemlich egal, ob die standard-schriftfarbe rot oder gelb ist und wie die standard-text-größe ist...
Du könntest das Zeugs dann einfach mal viel schöner erweitern und wirst auch später noch gut durchsehen...

Außerdem würde ich die 3 Zahlen (weil sie alle als einziges was über die Kapazität aussagen), noch mal extra kapseln...

am ende würde ich wahrscheinlich auf so was in der richtung kommen:

string itemname; //wobei ich hier wahrscheinlich nur die id oder so was speichern würde und nen singleton oder ne fkt. oder so haben würde, was mir aus ner produktnr. den anzeigename geben könnte - so würde es ja wahrscheinlich auch in der datenbank aufgebaut sein
string locationname; // ---------------------- "" ----------------------
TCapacity capacity; //soll, haben - differenz wird berrechnet, wenn nötig
TGroup group; //falls obige annahme stimmt würde ich hier auch wieder nur die id...
TCategory category; //... speichern und den name wieder über nen singleton oder eben ne einfache fkt raussuchen

ich hoffe, ich habe dich nicht ganz so verwirrt ^^

bb