TStrings Speicher

[himitsu]

In einer StringListe gibt es keine einzelnen Strings, die Stringinhalte werden aller der Reihe nach in einen gemainsamen Speicherbereich geschrieben und per SLineBreak getrennt, also da ist nichts mehr mit einem Referenzzähler und gemeinsamem Speicher, welche sich zwei Strings teilen ... beim Aufruf von ComboBox2.Items[i] wird intern ja auch erst ein String erzeigt, in welchen dann die entsprechenden Stringdaten reinkopiert werden ... und wenn man einen String an ComboBox2.Items[i] übergibt, dann wird dessen inhalt ebenfalls in den großen, gemeinsamen Speicherbereich der Stringlist kopiert ... wie gesagt, egal wie ihr die Strings übergebt es sind und bleiben zwei unabhängige Speicherblöcke und demnach können die Daten nur Doppelt vorhanden sein.

[jbg]

Zitat von himitsu:

In einer StringListe gibt es keine einzelnen Strings

Und warum nutzt TStringList dann bitte schön ein "händisches" dynamisches Array of TStringItem? Die Text- und CommaText-Eigenschaft durchläuft dieses Array und baut die Strings zu einem Gesamtstring zusammen. Also kann hier die Referenzzählung greifen.

Bei TListBox und TComboBox wird aber keine TStringList benutzt sondern eine spezielle TListBoxStrings bzw. TComboBoxStrings. Und die überlässt die String-Verwaltung dem Windows Control. Hier greift die Referenzzählung natürlich nicht (außer man verwendet Unicode-Controls mit WideString).

[himitsu]

Zitat von jbg:

Und warum nutzt TStringList dann bitte schön ein "händisches" dynamisches Array of TStringItem? Die Text- und CommaText-Eigenschaft durchläuft dieses Array und baut die Strings zu einem Gesamtstring zusammen. Also kann hier die Referenzzählung greifen.

Also mir ist/war so, als wäre das genau andersrum, TStringItem baut doch auf TStrings/TStringList auf?
Und dort stehen die Strings alle in einer Reihe, da ist dann kein Platz merh, für die Refferenzzähler, Längenangaben und was sonst noch in so'nem LongString enthalten ist (neben dem reinem Text).

[jbg]

Zitat von himitsu:

Also mir ist/war so, als wäre das genau andersrum, TStringItem baut doch auf TStrings/TStringList auf?

Dann schau mal in den Quellcode von Classes.pas. TStringItem baut überhaupt nicht auf TStrings/TStringList auf. Das ist andersherum:

Code:

  PStringItem = ^TStringItem;
  TStringItem = record
    FString: string;
    FObject: TObject;
  end;

Zitat:

Und dort stehen die Strings alle in einer Reihe, da ist dann kein Platz merh, für die Refferenzzähler, Längenangaben und was sonst noch in so'nem LongString enthalten ist (neben dem reinem Text).

Und was ist dann das:

Code:

  PStringItemList = ^TStringItemList;
  TStringItemList = array[0..MaxListSize] of TStringItem;

  TStringList = class(TStrings)
  private
    FList: PStringItemList;

Einer von uns versteht das Konstrukt Array wohl im Moment nicht mehr.

[Bernhard Geyer]

Zitat von jbg:

Zitat von Bernhard Geyer:

Das hat damit nichts zu tun da TComboBoxStrings ein Nachfolger von TStringList und das Win32-Control davon nichts weis.

Das wäre mir neu:

TCustomComboBoxStrings = class(TStrings);
TComboBoxStrings = class(TCustomComboBoxStrings);

Und TStrings speicher die Strings nicht selbst. TComboBoxStrings nutzt SendMessage um die Strings zu setzen bzw. zu lesen.

OK. Hast mich überzeugt. Dachte aber das es nur einfach 'ne Ableitung des Ableitungswillens ist und nicht 'ne komplette andere Implementierung.

[himitsu]

hmm, und ich dachte TStringList hat die Stringbehandlung von TStrings geerbt und nichts eigenes verwendet

[jbg]

TStrings is eine anstrakte Klasse, die bis auf die nötigen Methodendeklarationen nichts wirkliches zu bieten hat.