![]() |
Delphi-Version: XE2
TStringList.Capacity Zuweisung?
Wieso ist in TStringList SetCapacity eigentlich nicht definiert? Gibt es einen speziellen Grund dafür?
Delphi-Quellcode:
procedure TStrings.SetCapacity(NewCapacity: Integer);
begin // do nothing - descendents may optionally implement this method end; |
AW: TStringList.Capacity Zuweisung?
Meinst du jetzt TStringList oder TStrings?
TStringList (als Nachfahre von TStrings) hat es nämlich implementiert. |
AW: TStringList.Capacity Zuweisung?
Du bist da wohl klein wenig durcheinander gekommen. Bei TStringList steht in SetCapacity etwas (zumindest in D7). Bei TStrings nicht. Das ist der Vorfahr von TStringList.
Delphi-Quellcode:
procedure TStrings.SetCapacity(NewCapacity: Integer);
begin // do nothing - descendents may optionally implement this method end; procedure TStringList.SetCapacity(NewCapacity: Integer); begin ReallocMem(FList, NewCapacity * SizeOf(TStringItem)); FCapacity := NewCapacity; end; |
AW: TStringList.Capacity Zuweisung?
Es steht doch im Kommentar :gruebel:. Die Alternative wäre gewesen, die Methode abstract zu deklarieren, aber dann muss jede abgeleitete Klasse sie implementieren. So kann jede Ableitung selbst entscheiden, ob sie das tut oder eben nicht.
|
AW: TStringList.Capacity Zuweisung?
Zitat:
Wenn in der Basisklasse eine Methode keinen Sinn macht, sondern nur in einer speziellen geerbten Klasse, dann würde ich es in der Basisklasse einfach gar nicht deklarieren. Das wäre so, als wenn ich in einer Klasse TKraftfahrzeug die Methode "Schwimmen" anbiete, obwohl das nur in der Klasse TAmphibienfahrzeug Sinn macht. Alle Kraftfahrzeuge haben jetzt die Methode Schwimmen, doch bei den meisten funktioniert diese eben nicht... Irgendwer kommt dann auf die Idee, mit einem TMotorrad in einen See zu fahren, weil es ja die Methode Schwimmen besitzt. (übertriebenes Beispiel :-D) Man könnte sogar so weit gehen, und noch eine zweite Klasse dazwischen hängen, falls es SetCapacity in mehreren Nachfahren geben soll... TStrings > TGrowStrings > TStringList, TOtherStrings,... Ob es da irgendeine Eigenheit bei ObjectPascal gibt, damit das keinen Sinn machen könnte, weiß ich nicht, aber in strengen OOP-Sprachen würde ich das so machen... |
AW: TStringList.Capacity Zuweisung?
@Morphie
Ich sehe das genau umgekehrt, ein paar zusätzliche virtuelle Methoden und vor allem mehr Methoden virtuell statt statisch implementiert würde einem oft viel "gefrickel" ersparen. Das von Dir gewählte (etwas extreme) Beispiel würde ich auch nicht implementiert haben wollen. |
AW: TStringList.Capacity Zuweisung?
Dir ist aber schon aufgefallen, dass es sich um den Setter der Property Capacity handelt? Da kannst Du wenn überhaupt höchstens die ganze Property in der Basisklasse weglassen, zumindest fällt mir auf die Schnelle keine saubere Alternative ein. Irgendwer bei (wahrscheinlich noch) Borland wird sich dabei schon etwas gedacht haben.
|
AW: TStringList.Capacity Zuweisung?
Zitat:
|
AW: TStringList.Capacity Zuweisung?
Ich denke hier ist es nicht sinnvoll ein capacity-property schon in der Basisklasse einzuführen. Diese Property macht dort keinen Sinn da sowas zu sehr an die Speicherorganisation von TStringList (Dumme Pointerlist statt performanterer Tree oder Hashmap) angelehnt ist.
Willst du mit Variablen vom Typ TStrings arbeiten aber wenn es nötig ist die Capacity (vor-)belegen wäre ein setzen mit den RTTI-Funktionen möglich. Haben uns selbst SetIntProperty-Funktionen gebastelt um nur bei Klassen mit entsprechenden Properties diese zu setzen und bei fehlen einfach nix zu machen. |
AW: TStringList.Capacity Zuweisung?
Der Grund meiner Frage war folgender: Wenn man in einer StringList die Capacity z.B. auf den Wert 10 einstellt, sollten beim StringList.LoadFromFile maximal 10 Zeilen gelesen werden (auch wenn die Datei etwa 100 Zeilen hat). Wäre eine solche Vorgangsweise möglich? Oder müsste man dazu eher die Methode LoadFromFile überschreiben?
|
Alle Zeitangaben in WEZ +1. Es ist jetzt 20:07 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz