(Erledigt) Array dynamik (ohne vektor)
-
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.
-
Nun gut. Wie gesagt, ich konnte mir anfänglich auch nicht vorstellen, dass meine eigenen Container nicht mehr gut genug seien. Und Iteratoren? Wozu braucht man das? Mein Index-Zugriff in meinem dynamischen Array reicht mir. Verkettete Listen sind sowieso nichts für mich. :p
Inzwischen könnte ich mir gar nicht mehr vorstellen, meine Projekte ganz ohne STL zu entwickeln. Falls du wirklich effizient programmieren willst, rate ich dir, die STL mit all ihren Möglichkeiten einmal in Ruhe anzuschauen. Du wirst begeistert sein. Besonders im Zusammenhang mit Algorithmen, Templates und funktionaler Programmierung ist ein Erstaunen gut möglich.
Xebov schrieb:
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.
"Garantiert" ist schnell gesagt. In der Praxis sieht es aber oft so aus, dass nicht alles 100% korrekter Code ist. Flüchtigkeitsfehler passieren immer. Wenn die Standardbibliothek einen beim Debuggen noch zusätzlich unterstützt, sollte man diese Möglichkeit auch nutzen. Denn wer sagt, dass in deinem Code nicht irgendwo ein Fehler steckt, der sich erst nach einigen Wochen bemerkbar macht, und dann noch nach 20 Minuten Programmdurchlauf? Die Fehlersuche gestaltet sich in so einem Fall nämlich besonders lustig. Oder ein kleines Memory Leak, das momentan noch nicht auffällt, aber bei grösseren Datenmengen deinen Computer zum Erliegen bringt?
-
Nexus schrieb:
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.
richtig. aber das low-level zeug ist alles ziemlich advanced und für einen anfänger überhaupt nicht notwendig. sollte man nicht zuerst mal die grundlagen lernen, bevor man ans eingemachte geht? std::vector ist grundlage, low-level speicherverwaltung ist das eingemachte. anscheinend sehen das viele, auch dozenten, andersrum. völlig falsche herangehensweise imho - so werden die programmierer gleich zu anfang versaut.
die erfinden dann wie xebov das rad jedesmal neu und machen dabei die immer gleichen fehler, die schon hunderttausende vor ihnen gemacht haben und die einfach nicht auftreten würden, wenn man die vorhandenen mittel kennen und anwenden würde. und sie erkennen es nicht, weil sie ihr vorgehen und ihre ignoranz für richtig halten.
-
kurz&knapp schrieb:
richtig. aber das low-level zeug ist alles ziemlich advanced und für einen anfänger überhaupt nicht notwendig. sollte man nicht zuerst mal die grundlagen lernen, bevor man ans eingemachte geht? std::vector ist grundlage, low-level speicherverwaltung ist das eingemachte.
Was heist Grundlegend und eingemacht, wenn ich new und delete nehme und damit dynamische Speicherverwaltung betreibe gehört das für mich zur Sprache, wärend sachen wie Container für mich mehr ein extra sind, denn die lassen sich mit hilfe der Grundstrukturend er Sprache ja erstellen. Damit wäre die Speicherverwaltung eine Grundlage für Vectoren, und nicht umgedreht, andersherum sehe ich eher die gefahr das man sich zu sehr an die bordmittel gewöhnt und es am ende nicht richtig hinbekomt weil man es imemr über die bequeme std gemacht in der alles schon schön verpackt drinlag.
-
öhhhm, um mal meine eigenen erfahrungen zu schildern,
ihr sprecht hier von "grundlagen" und "advanced", und seid euchd abei sehr uneinig
aber ob std::vector nun advanced ist oder nicht kommt auf die sichtweise an.sichtweise 1: Schwirigkeit der Umsetzung
sichtweise 2: verständnis der Umsetzungdiejenigen die sichtweise 2 vertreten haben durchaus recht wenn sie behaupten, das der umfang, den so ein vector eigentlich hat, und was eig. passiert wenn man ihn benutzt erst dann wirklich bewusst ist, wenn man das ganze mal manuell mit arrays nachkonstruiert.
diejenigen die sichtweise 1 vertreten haben allerdings mit ihrem standpunkt auch recht, denn man sollte sich von leicht nach schwer arbeiten, denn wenn man die leichten dnge versteht kann man sich den schweren zuwenden.(übrigens, "schwer" ist relativ)
meine sichtweise: ich habe das ganze ejtzt nochmal machen dürfen, diesmal mit vectoren und eins ist klar, es ist deutlich leichter, und deutlich angenehmer als die array-wurstelei, und ich glaube nicht,d as ich ohne die vorrangegangene aufgabe das bewusstsein bekommen hätte was da wirklich im hinetrgrund passiert.
Ich weiß vectoren jetzt wirklich zu schätzen, und das auch nicht grundlos^^
PS: speicherlecks hatte ich mich zu dem zeitpunkt noch nicht wirklich drum gekümmert, inzwischen wird der speicher richtig freigegeben.
-
Ich weiß nicht, ob bereits darauf hingewiesen wurde. Aber Exceptionsicherheit ist ein weiteres (starkes) Argument für std::Container. Nach dem Wissen von Xebov über Container und Iteratoren zu urteilen, hat er wohl keinen Plan von Exceptionsicherheit. Viele Routinen werden deshalb einfach falsch sein, bzw. nicht mal die kleinste Exceptiongarantie gewährleisten und Speicherleaks verursachen. Exceptionsicherheit kann man oft durch kleine Umstellungen im Code oder "Tricks" wie Copy&Swap erreichen. Dazu muss man aber das Konzept verstanden haben.
@Xebov: Du kannst das Gegenteil beweisen, indem du mal den
operator =deiner Container postest.Gruß
Don06
-
Don06 schrieb:
@Xebov: Du kannst das Gegenteil beweisen, indem du mal den
operator =deiner Container postest.nee. er benutzt noch keine exceptions. also brauchen seine container auch nicht exceptionsicher zu sein.
-
volkard schrieb:
Don06 schrieb:
@Xebov: Du kannst das Gegenteil beweisen, indem du mal den
operator =deiner Container postest.nee. er benutzt noch keine exceptions. also brauchen seine container auch nicht exceptionsicher zu sein.
Tut mir Leid, aber er arbeitet mit Exceptions:
http://www.c-plusplus.net/forum/viewtopic-var-p-is-1686502.html#1686502@Xebov,
Simple Frage: Wieso verwendest du nicht die Container aus der Standardbibliothek? Was ist dein Grund auf diese zu verzichten? Was verstehst du unter "zu umfangreich", bzw. wo siehst du darin einen Nachteil?Ich glaube es ist am einfachsten, wenn wir es an dieser Wurzel anpacken
Grüssli
-
volkard schrieb:
Don06 schrieb:
@Xebov: Du kannst das Gegenteil beweisen, indem du mal den
operator =deiner Container postest.nee. er benutzt noch keine exceptions. also brauchen seine container auch nicht exceptionsicher zu sein.
Ich benutze Exceptions, ua auch um solche operationen abzusichern, allerdings mache ich es an den Stellen wo ich sie zzt verwende nicht über Copy&Swap.
Wie ich bereits egsagt habe sind die Container zum Teil nicht einzelln sondern gehen in andere Klassen natlos ein dh sie sind ein Teil eienr Klasse und stellen zB eine Verwaltungseinheit dar. Im Falle meiner Vertex/Indexbufefr habe ich das ganze zB so gelöst das ich temporär Variablen benutze, das klingt zwar zunächst nicht sehr praktisch, wenn man sich aber vor augen hält das ich nur Zeiger habe ist es einfacher einen temporären zeiger zu haben der das Objekt hält wärend versucht wird alels zu erweitern als erst über Copy&Swap zu gehen.
Dravere schrieb:
@Xebov,
Simple Frage: Wieso verwendest du nicht die Container aus der Standardbibliothek? Was ist dein Grund auf diese zu verzichten? Was verstehst du unter "zu umfangreich", bzw. wo siehst du darin einen Nachteil?Ich glaube es ist am einfachsten, wenn wir es an dieser Wurzel anpacken
Ich verwende Sachen meist nur dann wenn ich einen Sinn darin sehe, und genau den sehe ich halt im Falle eines vectors nicht. Ich geb dir ein konkretes Beispiel, weiter oben habe ich ja Vertex/Indexbufefr angesprochen, die halten bei mir eine RAM Kopie auf einem Zeiger bereit. Jetzt ist es für mich genauso leicht einfahc einen Zeige rzu nehmen und Funktionen zum Rein und Rauspacken zu schreiben, die ich ja auch mit einem Vector in gewisser weise als Schnittsteleld er Klasse bräuchte und diese dann auf die Weite zu bearbeiten und verwalten. Mit einem Vector habe ich da weder was gewonenn noch verloren, udn genau das is es halt es macht für mich in den Sachen die ich so geschrieben habe keinen unterschied, da ich zudem ncoh mit Vectoren nie gearbeitet habe ist es für mich einfacher einen relativ gut gesichertesn Kleinen Container in eine Klasse einzulassen als erst groß mit den Vectoren herumzuhantieren.
