Konstanter dynamischer Array <- Möglich?

[himitsu]

nja, kann auch D7 gewesen sein

aber da hatte ich zumindestens in Assembler die per "DB daten" eingebaut und dann das gesammte Array (nicht nur die Unterarrays) daruf umgeleitet.

praktisch nachträglich einer leeren Array-Variable diese konstanten Daten zugewiesen

[add]

Zitat:

Habsch do!
Edit2: Oder meinst du im Integer-Array? Da gabs aber keine Probleme. Ich ändere es gleich. Besser ist.

jupp, im Integer Array

Nicht daß mal der MemoryManager unter unglücklichen Umständen ausversehn versucht die konstanten Daten, welche nicht hier ja in seinem Bereich liegen freizugeben.

Oder ausversehn in einem anderem Var-Array, welchem man vorher dieses Array übergeben hat, beim Ändern von Werten diese versucht werden in der Konstante zu ändern, statt vorher eine Kopie anzulegen.

Die Referenzzählung machte bei mir schonmal Probleme, als ich (nur bei normalen Array's und nicht expliziet bei soeinem Const-Array) versuchte den Wert zu ändern.

Delphi-Quellcode:

// nur daß hierbei auch Array1[x] geändert wurde
Array2 := Array1;
Array2[x] := irgendwas;

// hier ging es aber o.O
Array2 := Copy(Array1);
Array2[x] := irgendwas;

[SebE]

@sirius :
Dein Beispiel ist sehr interessant.
Wenn ich das richtig verstanden habe: Der Referenzzähler ist 2 -> einer für die Konstante selbst und der zweuite für die "Record-Zuweisung"

Meine Idee war Nullterminierte Arrays anzulegen.

Schön, dass sich dieser Thread selbstständig gemacht hat und man wieder etwas lernen konnte.

Edit: Warum legen dynamische Array keine Größen-/Referenz-Felder an?

[sirius]

Zitat von SebE:

@sirius :
Dein Beispiel ist sehr interessant.
Wenn ich das richtig verstanden habe: Der Referenzzähler ist 2 -> einer für die Konstante selbst und der zweuite für die "Record-Zuweisung"

eigentlich müsster er -1 sein. Denn das bedeutet (zumindest bei Strings), dass das Array nie gelöscht wird. Darf es ja auch nicht, ist ja eine Konstante. Der Wert 1 wäre eigentlich "am richtigsten", aber hier gibt es Probleme aus noch nicht näher geklärten Gründen. Und es schadet ja nicht, den Zähler richtig hoch zu setzen.

Zitat:

Edit: Warum legen dynamische Array keine Größen-/Referenz-Felder an?

Machen Sie ja. Aber eben nur zur Laufzeit.

[himitsu]

Eigentlich ist die Referenz -1 (steht normaler Weise für "liegt nicht im RAM") .. bzw 1, wenn nur eine Refferenz vorhanden ist ... hier aber sicherheitshalber 2, damit es nicht unter blöden Umständen vorkommt, daß mal versucht wird den "nicht vorhandenen" Speicher freizugeben oder darin rumzuschreiben.

Delphi-Quellcode:

Type TDynArray = packed Record
    RefCount:     LongInt;
    ElementCount: LongInt;
    Data:         packed Array[0..High({var})] of {Typ};
  End;

Var var: TMyDynArray;

var = @TDynArray.Data;  // die Variable zeigt auf den Anfang von Data

// Pointer(var)     = nil     > nil {in EXE}     > nil {in RAM}
//
// RefCount         = 0       = -1               > 0
// ElementCount     = 0       = Length(var)      = Length(var)
// @Data            -         = var              = var

also man kann (zumindestens bei Strings, welche im Grunde auch nur ein dynamisches Array darstellen)
aus dem Pointer rausbekommen, ob es Inhalt gibt oder der String '' ist
und aus RefCount bekommt man mit wo der String liegt (-1 = Konstante, 0 gibt's nicht und größer 0 gibt es die Anzahl der Referenzen an)

PS: Beim alten Delphi-MemoryManager lag vor RefCount noch dein weiter Integer vom SpeicherManager (welcher Status des Speicherblocks angab)


[add]

Zitat von SebE:

Edit: Warum legen dynamische Array keine Größen-/Referenz-Felder an?

bei statischen Array's ist das anders angelegt.
da gibt es keine Referenzzählung und auch die Arraygröße ist nicht in die Datein eingebaut.

dieses sieht praktisch so aus:

Delphi-Quellcode:

Type TStaticArray = packed Record
    Data: packed Array[0..High({var})] of {Typ};
  End;

Length(array) und High(array) werden dabei direkt in das Programm eingebaut.
(die Länge kennt der Compiler ja und baut dann da wo diese Funktionen aufgerufen würden direkt die entsprechende Zahl ein)

[SebE]

Super, danke euch.

Ist es eine "reine" Delphi-Angewohnheit oder machen es andere (imperative) Sprachen (wie C) auch so?

Wo habt ihr eurer genaues Wissen her (Delphi-Tutorials, oder zählt das unter "allgemein", so dass man das im Theorieteil eines Informatik-Buches nachlesen kann)?

[sirius]

Das ist delphispezifisch. Gerade so eine "tolle" Sprache wie C hat diese tolle Verwaltung von Strings nicht. Ähnlich sieht es mit dynamischen Arrays aus.
Hier hat der Delphi-Compiler im Hintergrund auch ganz schön zu tun.

Wo man das Wissen herbekommt?
Mitlesen in dem Forum und Rumprobieren und Angucken des CPU-Fensters....

[himitsu]

[info] hatte oben noch was zum StaticArray nacheditiert.

und rausbekommen hatte ich es, indem ich einfach mal Speicher mir angeguckt hatte

PS: bei WideString (OLE32Str) ist der ElementZähler in Byte angegeben, also immer doppelt so groß wie die Zeichenanzahl.
und es gibt keine Referenzzählung (bzw. die ist immer 1)

[add]
schau dir einfach mal im Anhang die Funktionen DynArrayInfo/DynArrayInfoC bzw. StringInfo/StringInfoC an

[sirius]

Zitat von himitsu:

PS: bei WideString (OLE32Str) ist der ElementZähler in Byte angegeben, also immer doppelt so groß wie die Zeichenanzahl.

Widestring ist ja auch von Windows implementiert. Da werden intern nur die API-Funktion StrAlloc, StrLen,.... StrDispose aufgerufen.
Und eine neue Variable bekommt auch immer eine Kopie und niemals eine zweite Referenz auf einen Widestring. Dafür gibts ja jetzt UnicodeStrings

[SebE]

Zitat:

bei WideString (OLE32Str) ist der ElementZähler in Byte angegeben, also immer doppelt so groß wie die Zeichenanzahl.

Wie soll ich das verstehen?
Ein Element (ein Zeichen) ist doch immer ein Byte(?)

[himitsu]

WideString = WideChar = 2 Byte pro Zeichen

UnicodeString (gibt es seit D2009) = WideChar = auch 2 Byte pro Zeichen,
aber hier gibt ElementCount die anzahl der Elemente/Zeichen an,
so wie eigentlich bei allen Delphi-Array's auch.
(OK Ansi = 1 Byte pro Zeichen, also da stimmt es überein)

Der Grund: WideString ist nur eine delphiinterne Umleitung zum OLEString und der zählt halt anders.