(Erledigt) Array dynamik (ohne vektor)
-
Vector besteht aber schon aus ein bischen mehr als nem Konstruktoraufruf.
-
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.
-
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.
-
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 ...
-
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?
-
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
-
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.
-
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.
-
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.
-
kurz&knapp schrieb:
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.
Das es sie gibt steht in jedem Tutorial. Und was zb Container angeht was will man da wissen? Ich denke mal wie ein Container aussieht und arbeitet dürfte sich jeder vorstellen können udn danach einen selebr zu bauen dürfte auch gehen, der rest komtm dann wenn man mal damit arbeitet und feststellt was so alles fehlt, das sorgt dann schon für aha Effekte. Ich will hier übrigends mal anmerken das ich noch nie einen Vector oder irgendeinen anderen Container aus der std benutzt habe. Ich schreibe die Container immer selbst da ich meist den umfang der std garnicht brauche.
-
Xebov schrieb:
Ich will hier übrigends mal anmerken das ich noch nie einen Vector oder irgendeinen anderen Container aus der std benutzt habe. Ich schreibe die Container immer selbst da ich meist den umfang der std garnicht brauche.
diese aussage und deine postings hier im forum zeigen aber auch deutlich, dass du keine ahnung hast und deshalb ein denkbar schlechtes vorbild bist. wer will sich schon von einem blinden die farben erklären lassen?
-
Xebov schrieb:
Ich will hier übrigends mal anmerken das ich noch nie einen Vector oder irgendeinen anderen Container aus der std benutzt habe. Ich schreibe die Container immer selbst da ich meist den umfang der std garnicht brauche.
Dir ist schon bewusst, dass ein Kompiler und Linker die Funktionen weglässt, welche du nicht brauchst? Wieso um alles in der Welt sollte man sich jedesmal erneut die Arbeit machen, all das Zeug selber zu schreiben? Sowas macht man höchstens wenn man wirklich MEHR Funktionalitäten braucht oder es eindeutig wegen der Performance hapert. Allerdings sind das beides extrem seltene Fälle. Die STL Container reichen in den meisten Fällen völlig aus.
Grüssli
-
kurz&knapp schrieb:
Xebov schrieb:
Ich will hier übrigends mal anmerken das ich noch nie einen Vector oder irgendeinen anderen Container aus der std benutzt habe. Ich schreibe die Container immer selbst da ich meist den umfang der std garnicht brauche.
diese aussage und deine postings hier im forum zeigen aber auch deutlich, dass du keine ahnung hast und deshalb ein denkbar schlechtes vorbild bist. wer will sich schon von einem blinden die farben erklären lassen?
Was hat bitte Ahnung im zusammenhang mit Funktionsweise zu tun? Ich mein ob man die std Container benutzt oder nicht sagt doch 0 darüber aus ob man weiß wie sie funktionieren.
Dravere schrieb:
Dir ist schon bewusst, dass ein Kompiler und Linker die Funktionen weglässt, welche du nicht brauchst?
Damit hab ich mich nie beschäftigt was weggelassen wird und was nicht.
Dravere schrieb:
Wieso um alles in der Welt sollte man sich jedesmal erneut die Arbeit machen, all das Zeug selber zu schreiben?
Weils einfach ist, schnell geht und ka warum sonst noch ich mach es einfach imemr so, hat mich nie gestört.
-
Xebov schrieb:
Ich schreibe die Container immer selbst da ich meist den umfang der std garnicht brauche.
ich nehme an, du meinst zum beispiel bäume, die aufwärtszeiger haben, damit man durchiterieren kann. oder den vector, der die ganzen ints drin erstmal auf 0 setzt.
