Koponenten TRealList (TSingleList) und TIntegerList gesucht

[user69]

Hallo,

Kennt jemand eine Komponente, die Single (Real) oder integer speichert und unter D2007 funktioniert?

Grüße

[oki]

Hi,

eine Liste die entsprechende Werte speichert kenne ich nicht, aber die kann man sich doch selber bauen. Schreibe eine Klasse, die die entsprechenden Werte speichert. Alle entsprechenden Methoden wie Add, Insert, Indexof ... kann man sicher relativ schnell implementieren.

Gruß oki

[Progman]

LOL, diese (merkwürdige) Frage hat er auch im DGL-Forum gestellt.
Muss man zu jedem Klacks ne Komponente haben?
Vieles kann man selber bauen!

[oki]

Moin,
ich hab immer noch nicht ganz verstanden, warum es unbedingt Listen sein müssen. Was kann man bei gespeicherten real-werten in einer Liste sinnvoller abwickeln als in einem Array of Real? Tuts das Array nicht auch?

Gruß oki

[mkinzler]

Zitat:

Tuts das Array nicht auch?

Muss es den unbedingt ein Mercedes sein, tut es ein Fiat nicht auch :stupid:

[Dax]

Zitat:

Zitat von mkinzler

Muss es den unbedingt ein Mercedes sein, tut es ein Fiat nicht auch :stupid:

Kommt immer auf die Ansprüche an :zwinker:

[oki]

Zitat:

Zitat von mkinzler

Zitat:

Tuts das Array nicht auch?

Muss es den unbedingt ein Mercedes sein, tut es ein Fiat nicht auch :stupid:

Sorry, ich antworte noch mal:

Zitat:

Zitat von user69

Hallo,

Kennt jemand eine Komponente, die Single (Real) oder integer speichert und unter D2007 funktioniert?

Grüße

Ja, ich kenne welche :thumb: :
- Array of Real,
- Array of Single,
- Array of Integer!

(kleine syntaktische Unsauberkeiten wie die Frage nach Komponenten übersehe ich wohlwollend)

Gruß oki

[DeddyH]

Wie es der Zufall will, habe ich bei Torry dies hier entdeckt.

[user69]

Hallo,

zumindest vielen Danke für die Anregungen.
Ich habe inzwischen die auch Idee aufgegriffen mir die Klassen selber zu bauen, als Ableitung von TList (zum kompletten selbst bauen - was sicher besser wäre - war ich zu faul).
Da die längen von Integer und Single, wie auch Pointer 4 Byte lang sind, ist es einfach die TList zu misbrauchen.

Arrays: Da ich anfangs nicht weiß, wie viele Element im Array sin brauche ich schon Dynamische Arrays. Diese haben für mich den Nachteil, daß sie schnell viel Speicher verbrauchen können(Hab ich mich früher auch manchmal drüber gewundert), wenn man sie manuell z.B. immer um 1 vergrößert (es wird ja immer wieder der komplette Speicher neu zugewiesen). Den anderen Speicher hält Delphis Memory Manager (er denk man könnte ihn ja nochmal brauchen) einfach vor und gibt ihn nicht wieder frei. Demzufolge muß man die größe manuell steuren, z.b. in 100er oder 1000er Schritten. Das sollte für mich die Klasse machen, wie z.B. in TList die AllocBy oder Capacity function. Deshalb die Komponente, um dies nicht immer zu überwachen.
In der Liste steckt ja am Ende auch son Dynamisches Array, aber mit genau dem Speichermanagment, das ich brauch.

Selbst Schreiben: Ok, kann man machen, aber da siegte erst mal die Faulheit. Wäre aber mal interessant, da man dann universell wäre: z.B auch für Boolean, Double, eigene Types ...

Grüße
User69

[Daniel Schuhmann]

http://delphi.smartcoder.net/source/TIntList.html

http://delphi.smartcoder.net/source/TFloatList.html

[3_of_8]

Falls man Delphi 2007 hat, ist eventuell auch die Lösung mit Generics sinnvoll. (Und elegant)

[mkinzler]

Aber nicht unter Win32

[oki]

Zitat:

Zitat von user69

Arrays: Da ich anfangs nicht weiß, wie viele Element im Array sin brauche ich schon Dynamische Arrays. Diese haben für mich den Nachteil, daß sie schnell viel Speicher verbrauchen können(Hab ich mich früher auch manchmal drüber gewundert), wenn man sie manuell z.B. immer um 1 vergrößert (es wird ja immer wieder der komplette Speicher neu zugewiesen). Den anderen Speicher hält Delphis Memory Manager (er denk man könnte ihn ja nochmal brauchen) einfach vor und gibt ihn nicht wieder frei.

Das ist mir aber neu. Die OH sagt da aber was anderes.
Grundsätzlich benutze ich aber auch lieber Listen.

Gruß oki

[user69]

Was sagt die Hilfe denn?

Zum Memory Manager gibt es da keine solche Aussage denke ich, oder doch.
Das Array an sich gibt den Speicher schon wieder frei, nur dem Memory Manager hält ihn, damit er für spätere Anforderungen schneller ist (oft hilft das zwar, aber bei sowas halt nich). Außerdem nimmt er sich immer bei Vergrößerung eines Arrays neuen Speicherplatz mit der kompletten neuen Größe.

Ich bin, wie gesagt da auch Anfangs mit meiner Anwendung reingefallen, da ich ein Dynamisches Array (von einem eigenen Type, der schon ein paar Byte bracht) genutzt habe und es immer um eins größer oder kleiner gemacht habe. Das führte irgendwann mal zu der Windows Meldung, daß nicht genug Speicher da ist (er meint wohl Heap, da allgeien noch weit mehr als genug Speicher frei war). Alleine das Umschreiben des Codes (num vergößere ich das Array immer um 1000, egal ob ichs brauch oder nicht) brachte Erfolge und keine solchen Fehlermeldungen mehr. Nachteil: ich muß die wirkliche Größe in einer separaten Variable mitführen und immer checken, wann ich das Array vergrößern muß. Deshalb hier der Ansatz einer Koponenten die beide diese Fälle löst, also die TList.

Ich habe übrigens lange im Netz gesucht, um dem Phänomen auf die Spur zu kommen. Bin aber dann doch im Netz fündig geworden, weiß aber nicht mehr wo.

[3_of_8]

Was? :shock:

Der Delphi-Memory-Manager defragmentiert seinen Speicher nicht? Das wäre mir jetzt sehr neu.

[cruiser]

Zitat:

Zitat von user69

Nachteil: ich muß die wirkliche Größe in einer separaten Variable mitführen und immer checken, wann ich das Array vergrößern muß.

Nichts anderes macht TList.. einfach mal die Grow-Methode anschaun. Mit einer eigenen Grow-Methode kann man das evtl. noch optimieren... allerdings ist der Grow bereits ganz gut gelöst.

ich würde die TList aber wrappen und nicht ableiten... bei einer Ableitung kann man immer noch auf TList casten und falsche Pointer reingeben. Gewrappt kann man nur das benutzen, was da ist.