(Erledigt) Array dynamik (ohne vektor)

Lodoss schrieb:

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.

Lodoss

zuallererst, vielen dank für eure antworten, vorallem Kurz&Knapp, dass ist eine plausible erklärung für dieses mir unerklärliche verhalten des programms, ich lass nochmal von mir hören wenn ich das problem gelöst habe. (keine sorge, keine frage, sondern meine problemlösung, damit die selbe frage nicht nochmal gestellt werden muss [wie so oft])

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)

Nexus

Lodoss schrieb:

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...

Xebov

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.

Captain Obvious

Xebov schrieb:

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);

?

Xebov

Vector besteht aber schon aus ein bischen mehr als nem Konstruktoraufruf.

Captain Obvious

Das schon. Aber was gewinnt man dadurch, wenn man willkürlich einen Teil des Ganzen ausblendet und nur noch das betrachtet was übrig bleibt?

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.

Xebov

Naja aber sie es mal von der rein Inhaltlichen und übungsmäßigen Seite. Du sagst OK schreibt ne Vector-Klasse mit allem drum und dran, dann zeigste den Leuten das es genau diese klasse schon über std gibt und das sie die dann auch benutzen sollen. Das selbst schreiben so einer Klasse zeigt den leuten imerhin wie sie im ganzen Funktioniert und ist meiner Meinung nach für Anfänger durchaus ne gute Übung.

hustbaer

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

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

RHBaum

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 ...

Tachyon

RHBaum schrieb:

... 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 .

RHBaum schrieb:

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?

Lodoss

so, das ursprüngliche problem ist gelöst

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

RHBaum

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 ...

RHBaum schrieb:

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.

RHBaum

Sag mal, was liesst Du da in meinen Posts ? zuviel zu wenig ?

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 ...

RHBaum schrieb:

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.

RHBaum schrieb:

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.

volkard

Bulli schrieb:

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.

volkard schrieb:

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.