edit:: Problem gelöst, siehe http://www.c-plusplus.net/forum/viewtopic-var-p-is-1692735.html#1692735

ich bin noch ne in diesem Forum, und bin auch noch ein Anfänger (wenn nicht sogar blutiger Anfänger) in c++ (Befasse mich normalerweise eher mit webprogrammierung)

Ich habe vor kurzem mit der Ausbildung zum Fachinformatiker für Anwendungsentwicklung angefangen und habe eine Aufgabe bekommen,

ich hatte im vorfeld eine doppelt verkettete liste erstellt die auch ihren dienst tut, und soll jetzt eine Baumstrucktur daraus machen, folglich aus nur einem Unterelement sollen unbegrenzt viele neue werden.

Rahmenbedigung:

Ich soll dies mithilfe eines Statischen Arrays machen.(ohne Vektor)

struct TListenKnoten
	{
		string nodename;
		string wert;
		TListenKnoten *lastelement;
		TListenKnoten **Sarray;

	};

	struct TListenKnoten *handle=0;
	struct TListenKnoten *startknoten=0;
	struct TListenKnoten *neu=0;
	int count;
	string auswahl="0";

Das ist erstmal das struckturelement an sich und die dazugehörigen globalen variablen.
mein ansatz ist, das ich im TListenKnoten einen Pointer habe der auf ein array aus pointern zeigt die wiederrum auf die folgenden structurelemente zeigen.

der array soll nach aufgabenstellung (ich würds ja anders machen...) beim erstellen eines neuen subelements in einen anderen array rüberkopiert werden und im anschluss ein neuer array erstellt werden der ein feld größer ist, und dann natürlich zurückkopieren.

Hier de Quelltext bezüglich des Kopierens der Arrays

TListenKnoten *arbackup[sizeof(handle->Sarray)/sizeof(handle->Sarray[0])];
			count=0;			
			while (handle->Sarray[count]!=NULL)
			{
				arbackup[count]=handle->Sarray[count];
				count++;
			}

			delete handle->Sarray;

			handle->Sarray=new struct TListenKnoten*[sizeof(arbackup)/sizeof(arbackup[0])+1];
			count=0;
			while (count<(sizeof(arbackup)/sizeof(arbackup[0])))
			{
				handle->Sarray[count]=arbackup[count];
				count++;
			}

die Aktuelle Problematik ist, das scheinbar irgendetwas beim Kopieren der Arrays nicht richtig funktioniert, bzw. der Array nicht wie gewünscht vergrößert wird.
Bei der Ausgabe zeigt er lediglich das zuletzt erstellte element.
Mein erster verdacht war, dass er das erste element überspeichert, allerdings zeigt er mir beim testen, das dieses element des arrays leer ist.

hat jemand ne idee bzw. nen rat für mich?

und btw. ich weiß, globale variablen nur setzen wenn man einen guten grund hat^^ ich habs hier einafch mal gemacht um formfehler zu vermeiden, erstmal solls funktionieren, dann wirds schön gemacht.

Ich bedanke mich jetzt schonmal für jede hilfestellung

Grüße Lodoss

PS: Hier nochmal der gesamte Quelltext:

#include <iostream>
#include <fstream>
#include <string>

using namespace std;

	struct TListenKnoten
	{
		string nodename;
		string wert;
		TListenKnoten *lastelement;
		TListenKnoten **Sarray;

	};

	struct TListenKnoten *handle=0;
	struct TListenKnoten *startknoten=0;
	struct TListenKnoten *neu=0;
	int count;
	string auswahl="0";
	int durchlauf=0;

int main ( int argc, char *argv[] )
{

	do
	{
		cout << "[## Menü ##]" << endl;
		cout << "[n] Neuen Knoten erstellen" << endl;
		cout << "[l] Liste" << endl;
		cout << "[q] Ende" << endl;

		count=0;
		if (handle!=0) {
			while (handle->Sarray[count]!=NULL)
			{
				cout << "[" << count << "]" << handle->Sarray[count]->nodename << " ";
				count++;
			}
		}
		cout << endl;

		cin >> auswahl;

		if (auswahl=="n") 
		{
			if (startknoten==0)
			{
				neu = new struct TListenKnoten;
				startknoten=neu;
				handle=startknoten;
			}
			else
			{
				neu = new struct TListenKnoten;
			}

			neu->Sarray = new struct TListenKnoten*[0];
			cout << "Name des Knotens:" << endl;
			cin >> neu->nodename;
			cout << "Wert des Knotens: " << endl;
			cin >> neu->wert;

			count=0;

			while (handle->Sarray[count]!=NULL)
			{
				count++;
			}

			// Kommentar: Array Vergrößern

			TListenKnoten *arbackup[sizeof(handle->Sarray)/sizeof(handle->Sarray[0])];
			count=0;			
			while (handle->Sarray[count]!=NULL)
			{
				arbackup[count]=handle->Sarray[count];
				count++;
			}

			delete handle->Sarray;

			handle->Sarray=new struct TListenKnoten*[sizeof(arbackup)/sizeof(arbackup[0])+1];
			count=0;
			while (count<(sizeof(arbackup)/sizeof(arbackup[0])))
			{
				handle->Sarray[count]=arbackup[count];
				count++;
			}
			cout << "count ist: " << count << endl;

			handle->Sarray[sizeof(handle->Sarray)/sizeof(handle->Sarray[0])-1]=neu;
		}

		if (auswahl=="l")
		{
			//rekursive schleife aller elemente => funktion

			/*
			funktion X
			{
				for ("anzahl subelemente vom derzeitigen hangeln")
				{
					cout name des subelements
					aufruf von "funktion X" mit hangeln auf subelement

				}
			}
			*/
		}

	}
	while (auswahl!="q");

	return 0;
}

std::vector

jop, wäre auch mein ansatz, es geht bei der aufgabe aber primär darum, die Baumstruktur zu verdeutlichen, ich würds auch gerne mit nem vektor machen, allerdings ist die aufgabenstellung explezit: "statischer array"

PS: wirklich kurz und knapp die antwort^^

PS: ich habe natürlich auch schon die boardsuche ausgeschöpft, das inetrnet durchstöbert und tutorials durchgeschaut, entweder nix egfunden oder eben "benutz nen vektor" (was ja richtig ist, nur in meinem falle nicht umsetzbar)

Ich soll dies mithilfe eines Statischen Arrays machen.(ohne Vektor)

deine arrays sind aber nicht statisch.

warum bringt man leuten eigentlich c++ bei, wenn sie es nicht benutzen dürfen?

Ich soll dies mithilfe eines Statischen Arrays machen.(ohne Vektor)

deine arrays sind aber nicht statisch.

warum bringt man leuten eigentlich c++ bei, wenn sie es nicht benutzen dürfen?

streng genommen sind es nicht mal arrays...

Ich soll dies mithilfe eines Statischen Arrays machen.(ohne Vektor)

deine arrays sind aber nicht statisch.

warum bringt man leuten eigentlich c++ bei, wenn sie es nicht benutzen dürfen?

nunja, beibringen ist das eine, verständnis das andere
es geht primär ums verstnis der struckturen und deren funktionsweise, die man sonst so leichtfertig benutzt

streng genommen sind es nicht mal arrays...

inwiefern, was unterscheidet mein "konstruckt" von dem ich denke das es ein array ist von einem array? ist ne reine neugierfrage am rande, sollte aber nicht zu weit vom thema wegführen

derweil habe ich auch noch weiter versucht das problem zu lösen und mir mal
(sizeof(handle->Sarray)/sizeof(handle->Sarray[0])
ausgeben lassen, der zurückgegebene wert ist immer 1, daher vermute ich den fehler hier:

handle->Sarray=new struct TListenKnoten*[(sizeof(arbackup)/sizeof(arbackup[0]))+1];

sodass der neue array nicht größer als der alte ist, und damit nicht über das erste folgeelement hinausgeht

allerdings ist dies nur eine vermutung

es geht primär ums verstnis der struckturen und deren funktionsweise, die man sonst so leichtfertig benutzt

wenn es um strukturen verstehe ich erst recht nicht, warum vector nicht benutzt werden darf...

derweil habe ich auch noch weiter versucht das problem zu lösen und mir mal
(sizeof(handle->Sarray)/sizeof(handle->Sarray[0])
ausgeben lassen, der zurückgegebene wert ist immer 1

das ist nicht weiter verwunderlich, weil du die größe eines zeigers auf einen zeiger durch die größe eines zeigers teilst.
wenn du in den ausdruck mal die konkreten typen reinschreibst, wird es vielleicht klar:
sizeof(TListenKnoten**)/sizeof(TListenKnoten*)
ein TListenKnoten** ist genau so groß wie ein TListenKnoten*, deshalb kommt da immer 1 raus.

ein statisches array sieht übrigens so aus:

int array[100]; // größe muss eine konstante sein

new hat da nix verloren.

was die arays betrifft, nach meinem verständnis ist also ein statisches array ein array, dessen größe konstant ist und von programmstart an klar ist, ein dynamisches array ein array dessen größe sich zur laufzeit ergibt und ein vector ist ein "array" dessen größe sich wärend der laufzeit ändern kann, liege ich damit richtig?
(euer wissen und eure zeit soll ja nicht verschwendet sein)

was die arays betrifft, nach meinem verständnis ist also ein statisches array ein array, dessen größe konstant ist und von programmstart an klar ist, ein dynamisches array ein array dessen größe sich zur laufzeit ergibt und ein vector ist ein "array" dessen größe sich wärend der laufzeit ändern kann, liege ich damit richtig?

Ja, damit liegst du richtig. Wobei std::vector eine gesamte Klasse ist, die noch viel mehr Funktionalität bietet. Aber das hast du wahrscheinlich mit den Anführungszeichen gemeint.

kurz&knapp schrieb:

warum bringt man leuten eigentlich c++ bei, wenn sie es nicht benutzen dürfen?

Weil sie gewisse Dinge nicht lernen, wenn sie von Anfang an nur STL benutzen. Was eher vorkommt, ist die Tatsache, dass sie danach nicht mal zu solchen Dingen greifen und für Programme, die effizient sein sollen, dauernd Low-Level-Dinge anwenden. Und viele Leute haben auf diese Weise trotzdem das Gefühl, einen Grossteil von C++ verstanden zu haben...

warum bringt man leuten eigentlich c++ bei, wenn sie es nicht benutzen dürfen?

Ich fidne es zu trainingszwecken nicht verkehrt wenn die leute wissen wie es innen drin aussieht und in die lage kommen sowas auch selbst mal zu schreiben.

kurz&knapp schrieb:

warum bringt man leuten eigentlich c++ bei, wenn sie es nicht benutzen dürfen?

Ich fidne es zu trainingszwecken nicht verkehrt wenn die leute wissen wie es innen drin aussieht und in die lage kommen sowas auch selbst mal zu schreiben.

Naja. Was hast du denn an Einblick gewonnen, wenn du

int* a = new int[23];

schreibst anstelle von

std::vector<int> a(23);

?

Wenn man lernen soll mit Zeigern und Allokationen umzugehen, warum wird dann nicht C gelehrt statt so ein kleines Subset von C++? Es ist doch völlig realitätsfern, in C++ mit new und raw arrays zu hantieren. Das tun doch nur die, die es (noch) nicht verstanden haben. Oder denen man es halt so beigebracht hat und nun glauben, sie kennen C++, obwohl sie nicht mal an der Oberfläche gekratzt haben.

TListenKnoten *arbackup[sizeof(handle->Sarray)/sizeof(handle->Sarray[0])];

Da Sarray in deinem Beispiel ein Zeiger ist, ist das da oben totaler Unfug.

was die arays betrifft, nach meinem verständnis ist also ein statisches array ein array, dessen größe konstant ist und von programmstart an klar ist, ein dynamisches array ein array dessen größe sich zur laufzeit ergibt und ein vector ist ein "array" dessen größe sich wärend der laufzeit ändern kann, liege ich damit richtig?

statisches Array - klar, groesse muss zur kompilezeit bekannt sein. Das ist die einschraenkung fuer den User. Die eigentliche Bosonderheit ist doch aber, das das Ding komplett aufn stack liegt ! Also die aufwendige dynamische Speicherverwaltung ned beansprucht wird.

dynamisches Array - der Speicher fuer das Ding wird dynamisch erzeugt, also ueber die Speicherverwaltung. Dafuer braucht erst zur Laufzeit die groesse bekannt sein.

std::vector - STL-Implementation eines Dynamischen Arrays mit ner Menge Komfort drumherum.

Wenn jemand wirklich beruflich programmieren will/soll, find ich es schon sinnvoll, ihm mal paar standard klassen nachprogrammieren zu lassen. Jemand der mit dynamischen C-Arrays z.b. umgehen kann, tut sich viel leichter, kosten (Laufzeit) fuer die so tollen komfortfunktionen der STL und anderer Frameworks abzuschaetzen ....

Ciao ...

... kosten (Laufzeit) fuer die so tollen komfortfunktionen der STL und anderer Frameworks abzuschaetzen ....

Ciao ...

Welche Kosten meinst Du denn? Erkläre das mal am Beispiel eines std::vector .

std::vector - STL-Implementation eines Dynamischen Arrays mit ner Menge Komfort drumherum.

kosten (Laufzeit) fuer die so tollen komfortfunktionen der STL und anderer Frameworks abzuschaetzen ....

Hast du einen Beweis, das die Komfortfunktionen von vector Mehrkosten haben, als wenn man es selber implementiert?

Lösungsweg:

habe dem array einen zusätzlichen wert verpasst und den array via schleife gezählt bis dieser wert drinnsteht

mit der dadurch gewonnenen länge des arrays konnte ich durch new die richtige neue größe erstellen

vielen dank nochmal an alle helfer

PS: nette diskussion die hier vom zaune gebrochen ist, ich lese ausmerksam mit

ast du einen Beweis, das die Komfortfunktionen von vector Mehrkosten haben, als wenn man es selber implementiert?

Hab ich irgendwas von Mehrkosten gegenueber eines dynamischen Arrays geschrieben ?
Ich meinte damit, das durch die "Komfortfunktionen" bei der STL, viele "Programmierer" sich weniger Sorgen machen, was genau da passiert !

der Vector ist doch das perfekteste beispiel dafuer!

Bei nem Dynamischen Array bin ich doch gezwungen, mir vorab gedanken zu machen, wie gross ich es machen muss, beim vector ?
Wie oft sieht man, das nen Vector mitm standard Ctor angelegt wird und dann massenweisse daten "reingepumpt" werden ?
Wer verwendet denn den Ctor wo ich ich schon mal die Groesse des puffers fuer den vector anlegen kann ?

Wenn man selber mal ne Methode implementiert hat, wo nen Dynamisches Array "vergroessert" werden muesste, erinnert man sich vielleicht mal dran, beim naechsten std::vector::push_back ^^

Ciao ...

Wenn man selber mal ne Methode implementiert hat, wo nen Dynamisches Array "vergroessert" werden muesste, erinnert man sich vielleicht mal dran, beim naechsten std::vector::push_back ^^

mit der gleichen begründung kann man auch new und delete ablehnen, weil man da ja auch nicht weiß, was genau passiert. also direkt die speicherverwaltung des kernels benutzen... moment! da weiß man ja auch nicht was passiert. also keine betriebssystemfunktionen benutzen, statt dessen direkt die hardware programmieren. also müssen alle erst mal assembler lernen... moment! die mnemonics sind ja auch eine abstraktion, die den eigentlichen kern der sache verschleiern... also besser die instruktionen direkt binär codiert eingeben. am besten in den selbstgebauten computer, damit man sich mal gedanken drüber macht, wie das ding innendrin funktioniert!

p.s.: du plenkst.

Ich lehne die STL ueberhaupt ned ab, und ich sehe auch nur einen Grund, ein dynamisches Array durch einen std::vector nicht zuersetzen, und das ist zu Übungszwecken im nichtproduktiven Einsatz!
Ich plädiere nur dafuer, sich Gedanken zu machen, wie man die Dinger richtig und effektiv einsetzt !

damit man sich mal gedanken drüber macht, wie das ding innendrin funktioniert!

Mal ehrlich, wenn Dir das Laufzeitverhalten egal ist, meinst Du nicht das ne andere Programmiersprache als C++ vielleicht bissi besser geeignet waere ?

Ciao ...

damit man sich mal gedanken drüber macht, wie das ding innendrin funktioniert!

Mal ehrlich, wenn Dir das Laufzeitverhalten egal ist, meinst Du nicht das ne andere Programmiersprache als C++ vielleicht bissi besser geeignet waere ?

Ciao ...

Man benutzt nicht C++ ausschließlich wegen der (angeblichen) überlegenen Performance. Sondern auch, weil die Sprache diverse Eigenschaften hat, die mal nichts mit Performance zu tun haben.

Übrigens: einfach nur im Ctor von Vector eine Reservierung anzugeben, muß nicht unbedingt performanter sein, als einfach nur push_back zu benutzen. Denn push_back kann auch ziemlich intelligent implementiert werden. Und die Reservierung ist auch kein Allheilmittel. Es spielen viele Faktoren eine Rolle.

Insgesamt ist dein Argument, das man kein Vector zuerst lernen soll, weil man ja keinen Ctor-Parameter übergibt ziemlich schwach. Weil ich genauso argumentieren kann, das jemand, der versucht schlauer zu sein als die Standard-Lib (was hast du eigentlich immer mit deiner STL?), das Ganze auch nach hinten los gehen kann. Veruschen schlauer als die Stdlib zusein, sollte man erst, wenn man wirklich merkt, das die Software langsam und unperformant ist. Und dann auch nur, wenn man den Profiler benutzt.

Weiterhin: wann lohnt sich denn das Reservieren? Ganau, wenn man sehr viele Objekte haben wird, z.B. 1 Mio. Elemente. Aber werden das dann eher kleine oder große Objekte sein? Eher kleine! Ist der std-Allocator für kleine Objekte optimiert? Nein! Also macht es nicht unbedingt Sinn, sondern man benutzt schon mal einen anderen Allocator oder einen Memmory-Pool oder einen Smartheap-Library.

Puh... meine Fresse.

Weiter im Text: du hast große Objekte. Hem, davon kann ich aber nicht viele auf einmal reservieren. Also nur wenige Objekte. Hem, wenige Objekte lohnt sich nicht unbedingt zu reservieren. Das kann push_back ganz gut alleine machen.

Also wann muß ich denn reservieren bzw. wann lohnt es sich wirklich?

Das hängt von vielen Faktoren ab. Ich sage dazu nur: da muß man echt schon Profi mit Erfahrung sein, um DAS alles entscheiden und umsetzen zu können. Für einen Einsteiger eine total sinnlose Überforderung, ihm zu sagen, er soll schlauer als die Std-lib sein.

Einen Anfänger lasse ich lieber einfach einen Vector benutzen. Und lasse einen Menschen mit Erfahrung das ganze evtl. optimieren.

damit man sich mal gedanken drüber macht, wie das ding innendrin funktioniert!

Mal ehrlich, wenn Dir das Laufzeitverhalten egal ist, meinst Du nicht das ne andere Programmiersprache als C++ vielleicht bissi besser geeignet waere ?

laufzeitverhalten spielt für einen anfänger überhaupt keine rolle. ein anfänger soll lernen, eine sprache *richtig* einzusetzen. und c++ setzt man richtig ein, indem man die standardbibliothek verwendet statt alles selbst und schlechter zu implementieren.

ich bezweifle außerdem, dass von einem anfänger selbst gestrickte arrays ein besseres laufzeitverhalten aufweisen als vector. von den memory-leaks ganz zu schweigen. schau dir doch den code des OP an: hat er doch gleich schon mal das falsche delete benutzt. wahrscheinlich kennt sein lehrer auch nicht den unterschied zwischen delete und delete[].

es wäre viel schlauer gewesen, diesen quasi c-code gleich in c zu programmieren, statt ihn umständlich in c++ nachzubauen. das ist es nämlich, was ihm so beigebracht wird: in c++ programmieren wie in c.

Weiterhin: wann lohnt sich denn das Reservieren? Ganau, wenn man sehr viele Objekte haben wird, z.B. 1 Mio. Elemente. Aber werden das dann eher kleine oder große Objekte sein? Eher kleine! Ist der std-Allocator für kleine Objekte optimiert? Nein!

Doch!
malloc ist eher für große optimiert und operator new für kleine. falls der compilerbauer mitgedacht hat, und davon darf man ausgehen. nur kann man mit threadlokalen oder gar objektgebundenen freispeicherlisten oder fixed-size-allokatoren noch mehr rausholen.
und der weg dahin führt unweigerlich darüber, daß man sich mal ein kleines dynamisches array selber baut. wie will man's denn sonst lernen? man sollte immer neugierig bleiben. und der versuch, die standardbibliothek zu schlagen, ist eswas sehr edles und vielleicht besser, als die hundertste mp3-player-bedienoberfläche zu schreiben.

und der weg dahin führt unweigerlich darüber, daß man sich mal ein kleines dynamisches array selber baut. wie will man's denn sonst lernen?

man beachte:

Lodoss schrieb:

bin auch noch ein Anfänger (wenn nicht sogar blutiger Anfänger) in c++

warum soll ein blutiger anfänger so tief einsteigen?

der versuch, die standardbibliothek zu schlagen, ist eswas sehr edles und vielleicht besser, als die hundertste mp3-player-bedienoberfläche zu schreiben.

dazu müsste man erst mal wissen, dass es die standardbibliothek gibt, was sie tut und wie man sie benutzt.