(Erledigt) Array dynamik (ohne vektor)
-
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.
-
it's used by people who simple do not know C++ (and often not C either). When used by programmers, it typically indicates a "C++ is C with a few useful and a lot of useless complicated features added" attitude. Often, that is the point of view of people who like to write their own strings and hash tables with little knowledge of the standard library beyond printf and memcpy.
-
Xebov schrieb:
...
ich würde vorschlagen, lass uns das thema nochmal angehen, nachdem du "Exceptional C++" gelesen hast.
-
Xebov schrieb:
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.
Dann sei mal gesagt, dass du durch einen std::vector VERDAMMT VIEL gewinnen würdest. Nur weil du zu faul bist C++ zu lernen, verzichtest du auf sehr angenehme Dinge der Sprache. Ich empfehle dir DRINGENDS dich mit der Standardbibliothek von C++ auseinander zu setzen!
Exceptional C++ wurde schon genannt, ansonsten würden wohl bereits die Artikel im Magazin gut tun -> http://magazin.c-plusplus.net/
Oder halt sonst ein Buch, welches die Standardbibliothek behandelt. Zum Beispiel "Die C++ Programmiersprache".
Ich kann dir einfach nur wärmstens empfehlen, dass du dich mit dem Bereich auseinander setzt, sonst endet das in der Zukunft fatal.Grüssli
-
Dravere schrieb:
Ich kann dir einfach nur wärmstens empfehlen, dass du dich mit dem Bereich auseinander setzt, sonst endet das in der Zukunft fatal.
Weltuntergangsstimmung
Aber ich schau mir immer gern alles an, ich lern ja auch ständig neues dazu wie ich es brauche.
-
Xebov schrieb:
Weltuntergangsstimmung
Dravere hat schon Recht. Falls du später mal etwas Grösseres programmierst, womöglich sogar noch kommerziell, wirst du es wahrlich schätzen, eine fehlerfreie, effiziente, exceptionsichere und debug-unterstützende STL zu haben. Aber schon im Moment kann sie dir das Leben enorm erleichtern und eine Menge Ärger ersparen.
