(Erledigt) Array dynamik (ohne vektor)
-
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.
-
volkard schrieb:
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.
Ne sowas garnicht, Bäume hab ich nie gebaut.
Bei mir kommt einfach selten was obendrauf, zB eine RAM Kopie eines Vertexbuffers der zwar Dynamisch ist, aber halt länger Zeit stabil bleibt und bei dem sich lange nichts tut, da brauch ich keinen vector das kann ich auch so über ein paar Zeiger schnell machen. Ich seh generell ind en meisten Containern sehr wenig nutzen, mir ist bisher außer einmal bei ner map nie etwas begegnet wo ich sagte ok hier wäre so ein std Container sinnvoll.
-
Insgesamt ist dein Argument, das man kein Vector zuerst lernen soll, weil man ja keinen Ctor-Parameter übergibt ziemlich schwach.
Bitte ??? was ist mein Argument ? zitier mal die Stelle !!!
Einen Anfänger lasse ich lieber einfach einen Vector benutzen. Und lasse einen Menschen mit Erfahrung das ganze evtl. optimieren.
Vollkommen richtig .... Die Anfaenger sollen auch den Umgang mit den Vectoren lernen, kein Problem !
Und mir geht es auch nicht ums "Tuning" ... sondern um "Optimierungspotential" was einem sofort ins Auge sticht. Man koennt auch von "offensichtlicher falscher verwendung" sprechen.
Das mit dem Vector und den Daten reinpumpen iss nur nen Beispiel.Warum grade das Beispiel ?
Schau einfach mal in die Foren hier, findest genug beispiele fuer ! (und da braucht man keinen profiler fuer)
Und grad auch in der Praxis bekomm ich immer wieder code von angeblich erfahren c++ programmierern unter die Finger, die genau damit nen Problem haben.Fast genau so beliebt ist z.b. auch die verwendung eines Vectors, obwohl die enthaltenen Daten niemals am Stueck, oder ein zugriff ueber einen Index benoetigt/verwendet werden.
Das einzige was ich gesagt hab, ist das man angehenden Programmieren die das mehr nur als Hobby machen, das mittels solchen Uebungen eintrichtern kann. Ich zumindest find es legitim, und mir selber hats auch geholfen ...
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.
C++ ist IMHO einer der momentan gaengigsten Kompromisse aus Performance, und wartbarkeit/Übersichtlichkeit.
Faellt die Performance weg, Überholen IMHO andere Programmiersprachen.Klar, das man noch an anderen faktoren abwaegen muss, ob C++ die richtige Sprache ist. Z.b. verfuegbarkeit von Bibliotheken, Know How des verfuegbaren potentials .... aber das sind keine technischen Faktoren.
Was waeren den weitere technische Faktoren, die C++ zur Sprache der Wahl machen ?
Ciao ...
-
Captain Obvious schrieb:
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.
Sorry, aber das ist doch wohl Schwachsinn. Wenn man ernsthaft C++ programmieren will, kommt man nicht darum herum, sich mit Zeigern und manueller Speicherverwaltung auseinander zu setzen. Die STL ist zwar schön und gut und in vielen Fällen hilfreich, aber kein Wundermittel. Ich sage nicht, dass man diese Low-Level-Dinge danach die ganze Zeit anwendet - aber es gibt genügend Fälle, in denen man sie braucht. Und solange man sie nicht verstanden hat, hat man meiner Ansicht nach C++ nicht verstanden.
Xebov schrieb:
Ich seh generell ind en meisten Containern sehr wenig nutzen, mir ist bisher außer einmal bei ner map nie etwas begegnet wo ich sagte ok hier wäre so ein std Container sinnvoll.
Das liegt mit Sicherheit daran, dass du dich noch nicht gross auskennst. Hast du die STL einmal richtig studiert und weisst du, wie mächtig sie sein kann? Du sagst, du hast die Container selbst geschrieben. Wirklich? Hast du auch Iteratoren und Kompatibilität zur STL (und deren Algorithmen) bereitgestellt? Kennst du das Iterator-Prinzip überhaupt? Das ist nämlich nicht immer ganz trivial. Und die Security-Checks und Assertions im Debug-Modus hast du bestimmt auch nicht. Dabei sind die wirklich Gold wert, wenns um effizientes Debuggen geht. Die STL ist mehr als nur ein paar Container. Die kann man nicht so schnell, schnell nachbauen.
Ich wollte am Anfang auch meine eigenen Container basteln. Zum Ausprobieren, und da ich das Interface selbst bestimmen konnte - aber auch, weil ich die Standard Template Library zu wenig kannte. Ich habe sie dann doch angeschaut und bin wirklich froh, es getan zu haben. Wenn man nicht irgendwelche Spezialfälle wie die von volkard erwähnten braucht, ist es sehr selten sinnvoll, für produktiven Einsatz die Standardcontainer nachzubauen. Zumal von Nachbauen nicht wirklich eine Rede sein kann, solange man sich nicht ausführlich mit dem Original befasst hat.
-
Nexus schrieb:
Das liegt mit Sicherheit daran, dass du dich noch nicht gross auskennst. Hast du die STL einmal richtig studiert und weisst du, wie mächtig sie sein kann?
Nein.
Nexus schrieb:
Du sagst, du hast die Container selbst geschrieben. Wirklich?
Jo klar, nen kleienr Container ist ja auch nicht der riesen aufwand, das weiste ja sicher selbst.
Nexus schrieb:
Hast du auch Iteratoren und Kompatibilität zur STL (und deren Algorithmen) bereitgestellt?
Nein.
Nexus schrieb:
Kennst du das Iterator-Prinzip überhaupt? Das ist nämlich nicht immer ganz trivial.
Nein.
Nexus schrieb:
Und die Security-Checks und Assertions im Debug-Modus hast du bestimmt auch nicht.
Richtig, wobei ich hier anmerken muß das die meisten container Teil eienr Klasse waren die ihn für ihre Zwecke genutzt hat und durch die Klasse ein korrekter zugriff garantiert war.
Nexus schrieb:
Die kann man nicht so schnell, schnell nachbauen.
Naja ich habe zB nichtd avon geredet ihn bis ins detail anchzubauen sondern schon soweit das es dem grundprinziep eines Containers entspricht.
