redimensionierung von arrays

Hallo,
ich möchte in einem Code ein Array dynamisch vergrößern und verkleinern ohne das die schon vorhandenen Einträge (vor allem beim vergrößern) verloren gehen.
Dazu meine Frage: muss ich dazu das Array vorher Kopieren, es vergrößern und dann wieder zurück kopieren? Oder giebt es eine möglichkeit (ähnlich wie bei VB redim) das Array mit new zu redimensionieren ohne das ich die Daten verliere?
thx b4
Kante

Ponto

Nimm std::vector< ... > anstatt eines normalen Arrays.

Dann geht das vergrößern mit vec.resize(neue größe)

dali

Ansonsten:

Kante schrieb:

...muss ich dazu das Array vorher Kopieren, es vergrößern und dann wieder zurück kopieren?...

Ja

Thanks,
funktioniert. Aber die kann ich dann nich wierklich wie Arrays behandeln oder (mit Pouinterarithmetik und so)? ODer?
Kante

doch kannst du dann fast so wie ein normalers array benutzen. auch der pointerkrams funktioniert damit. aber um sowas wie einen pointer fuer einen std::vector zu bekommen brauchst du std::vector<...>::iterator. kann man fast alles was man mit einem normalen pointer auch machen koennte machen.

MBCS-CITP

Grundsaetzlich: Ein Array benutzt man dann, wenn weiss, wie gross die Datenmenge ist. Ist das nicht bekannt, arbeitet man mit einer verkettenen List, bei dieser kann man schnell und einfach Element anhaengen, einfuegen, loeschen, umsortieren etc. etc.

MBCS-CITP schrieb:

Grundsaetzlich: Ein Array benutzt man dann, wenn weiss, wie gross die Datenmenge ist. Ist das nicht bekannt, arbeitet man mit einer verkettenen List, bei dieser kann man schnell und einfach Element anhaengen, einfuegen, loeschen, umsortieren etc. etc.

Sofern du nicht häufig (was auch das sein mag ) an deinem "Array" rumänderst,
sondern bevorzugt den Inhalt lesen musst, ist vector bei weitem die performantere
Lösung. Insofern überleg dir einfach mal was du mit deinem "Array" so alles tun
willst oder musst bevor du dich entscheidest.
Von der Performance her ist dein VB-Redim sicher NICHT schneller als der vector.

volkard

MBCS-CITP schrieb:

Grundsaetzlich: Ein Array benutzt man dann, wenn weiss, wie gross die Datenmenge ist. Ist das nicht bekannt, arbeitet man mit einer verkettenen List

wer hat dich denn diesen quatsch gelernt?
von der überzeugungsstärke und der katastophalen falschheit her paßt das nur zur IHK.

wetten, daß es deutlich schneller ist, 1000000 ints in einen vector zu stopfen als in eine verkettete liste? wetten, es macht gar nix aus, daß der vector dabei 16-mal wachsen muss und dabei 16-mal new aufruft und fast 2000000 ints kopieren muss? wetten, deine schäbige verkettete liste braucht für 1000000 aufrufe von new viel viel länger?

alle generalisierungen sind falsch.

selbst, wenn wir jetzt einsehen, daß der vector erheblich schneller ist als die verkettete liste. es gibt fälle, wo die liste schneller ist. ich sage deswegen besser nix mit "grundsätzlich" am anfang.

virtuell Realisticer

MBCS-CITP schrieb:

Grundsaetzlich: Ein Array benutzt man dann, wenn weiss, wie gross die Datenmenge ist. Ist das nicht bekannt, arbeitet man mit einer verkettenen List, bei dieser kann man schnell und einfach Element anhaengen, einfuegen, loeschen, umsortieren etc. etc.

Was sagt dir Random Access zur Performance einer Liste?

mfg
v R

volkard

Redhead schrieb:

Von der Performance her ist dein VB-Redim sicher NICHT schneller als der vector.

ähm. doch. es benutzt nämlich malloc, free und realloc. und realloc klappt ja bei nur einem vector und sonst nix im freispeicher/heap immer. punkt für basic.

volkard schrieb:

Redhead schrieb:

Von der Performance her ist dein VB-Redim sicher NICHT schneller als der vector.

ähm. doch. es benutzt nämlich malloc, free und realloc. und realloc klappt ja bei nur einem vector und sonst nix im freispeicher/heap immer. punkt für basic.

Bist du sicher, bzw. woher weisst du das ?? Ausserdem ist ein VB-Array (= SAFEARRAY) schon ein bisschen mehr als ein normaler C-Array.

MBCS-CITP

Wenn aus einen "Schwung" eine Anzahl, sagen wir 10^6 Elemente kommen, dann allociert man einmal ein Array, liest die Zahlen ein und baut dann die Pointerbeziehung in der Liste, kommt ein zweiter Schwung Zahlen, dann wiederholt man das und verbindet beide Liste ueber die Zeiger.

volkard

MBCS-CITP schrieb:

Wenn aus einen "Schwung" eine Anzahl, sagen wir 10^6 Elemente kommen, dann allociert man einmal ein Array, liest die Zahlen ein und baut dann die Pointerbeziehung in der Liste, kommt ein zweiter Schwung Zahlen, dann wiederholt man das und verbindet beide Liste ueber die Zeiger.

du hast mit wendungen wie "dann allociert man" so eine allgemeingültigkeit, der ich einfach widerspreche. nein, es ist nicht so, wie du es darstellt.

volkard

Redhead schrieb:

Bist du sicher, bzw. woher weisst du das ?? Ausserdem ist ein VB-Array (= SAFEARRAY) schon ein bisschen mehr als ein normaler C-Array.

das weiß ich aus einfachen überlegungen.
aber ich bezog mich nicht auf VB.net, sondern auf das alte VB. eine welt ohne objektorientierung.

volkard schrieb:

Redhead schrieb:

Bist du sicher, bzw. woher weisst du das ?? Ausserdem ist ein VB-Array (= SAFEARRAY) schon ein bisschen mehr als ein normaler C-Array.

das weiß ich aus einfachen überlegungen.
aber ich bezog mich nicht auf VB.net, sondern auf das alte VB. eine welt ohne objektorientierung.

Hab dabei auch ausschliesslich an VB6 gedacht. Wie kommst du auf VB.net
Deine Überlegungen würden mich schon interessieren, man lernt ja gern dazu.

volkard

Redhead schrieb:

Hab dabei auch ausschliesslich an VB6 gedacht. Wie kommst du auf VB.net

bei VB6-arrays würde ich realloc benutzen, wo es nur möglich ist. und da die leute von ms nicht dof sind, machen die das auch. das war mein weg, herauszufinden, daß bei vb6 realloc beliebt ist. und auf vb.net schloss ich, weil du irgendwie sicher schienst, daß die leute kein realloc verwenden. ich könnte mir gut voestellen, daß die VM kein realloc bietet.

mal das wort SAFEARRAY verfolgen...
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/automat/htm/chap7_9ntx.asp
"FADF_FIXEDSIZE 0x0010 An array that may not be resized or reallocated."
hmm. irgendwas verleutet mich jetzt zu der annahme, daß dieses flag sogar sagt, wann realloc benutzt werden darf. das entsprechende if(realloc klappt) return; else wachseNormal; hüpft ganz von alleine in den code. der entwickler kann sich nicht wehren. eines morgens werden die heinzelmänchen es eingebaut haben.