Unit für Verknüpfung von Dateierweiterungen

[uligerhardt]

Zitat von BUG:

Und letztlich bewirkt

Delphi-Quellcode:

if Assigned(FActions) then
    FActions.Free;

das gleich wie:FActions.Free;

Schon. Ebenso wie

Delphi-Quellcode:

if Assigned(FActions) and Assigned(FActions) or Assigned(FActions) then
    FActions.Free;

(ungetestet). Ich bevorzuge hier trotzdem den Einzeiler.

[uligerhardt]

Zitat von himitsu:

Zitat von uligerhardt:

SetLength(FActions, Length(FActions)); bewirkt nichts.

Das würde ich so nicht direkt unterschreiben.
Vermutlich bewirkt es bei ihm nichts,
aber dieses wäre praktisch die Entsprechung von UniqueString für dynamische Arrays
und sorgt quasi dafür, daß es nur eine Referenz gibt und daß diese Variable als einzige Referenz für dieses Array existiert.

Also gut: Ich habe den Verdacht, SetLength(FActions, Length(FActions) + 1); wäre angemessener.

[BUG]

Zitat von uligerhardt:

Ich bevorzuge hier trotzdem den Einzeiler.

Ich auch, deshalb hab ich mich ja gewundert, das du die längere Form mit if vorgeschlagen hast, anstatt gleich nur Free

[uligerhardt]

Zitat von BUG:

Zitat von uligerhardt:

Ich bevorzuge hier trotzdem den Einzeiler.

Ich auch, deshalb hab ich mich ja gewundert, das du die längere Form mit if vorgeschlagen hast, anstatt gleich nur Free

Mit meinem Doppel-if-Konstrukt wollte ich eigentlich den Einzeiler vorschlagen. Kam wohl nicht sooo deutlich rüber.

[mleyen]

Zitat von unreal:

Echt tolle Unit für Dateiverknüpfungen!?!

Ich war am Anfang auch verwirrt. Sogar als ich den TE-Post gelesen hatte war mir noch unklar worum es sich handelt.
Nachdem ich mir dann den Quelltext runtergeladen und angeschaut habe, habe ich dann aber begriffen, dass es sich nicht um den "Umgang mit Dateiverknüpfungen" sondern um die "Verknüpfungen von Dateierweiterungen" handelte.
Danke für die Unit.

[Codewalker]

Erstmal danke für die vielen Postings. Teilweise habe ich es schon anpassen können. Im Detail (Download im ersten Posting):

Version 0.1.1:
[*] Unnötiges if-assigned im Destructor von TFileType entfernt
[-] In der Berechnung von ActionCount -1 entfernt
[-] Vergrößerung der Arraygröße war fehlerhaft

@mleyen: Guter Vorschlag, habe den Thread umbenannt

Zitat von himitsu:

Vermutlich bewirkt es bei ihm nichts,
aber dieses wäre praktisch die Entsprechung von UniqueString für dynamische Arrays
und sorgt quasi dafür, daß es nur eine Referenz gibt und daß diese Variable als einzige Referenz für dieses Array existiert.

Kannst du das noch etwas genauer erklären? Ich kann Dir da nicht 100%ig folgen.

@uligerhardt: Erbsenzählermodus ist schon okay, hab ja danach gefragt . Was deinen Vorschlag mit dem TStringPair angeht: Klingt sehr gut und werde ich vermutlich auch so umsetzen - alleine weil die Compiler-Ifs den Quelltextformatierer (JCF) aus dem Tritt bringen. Das schaffe ich aber vermutlich frühestens morgen.

[uligerhardt]

Zitat von Codewalker:

Zitat von himitsu:

Vermutlich bewirkt es bei ihm nichts,
aber dieses wäre praktisch die Entsprechung von UniqueString für dynamische Arrays
und sorgt quasi dafür, daß es nur eine Referenz gibt und daß diese Variable als einzige Referenz für dieses Array existiert.

Kannst du das noch etwas genauer erklären? Ich kann Dir da nicht 100%ig folgen.

Dynamische Array-Variablen sind nur Referenzen auf den echten Array-Speicherbereich. In folgendem Code (courtesy of http://www.hsg-kl.de/faecher/inf/mat...rray/index.php)

Delphi-Quellcode:

procedure Test;
var
  A, B: array of Integer;
begin
  SetLength(A, 1);
  A[0] := 1;
  B := A;
  B[0] := 2; // ***
end;

ist vor Zeile *** A[0] = 1, danach A[0] = 2, obwohl doch auf B[0] zugeweisen wurde. Das liegt daran, das die Zuweisung B := A dafür sorgt, dass B auf den gleichen Speicherbereich wie A zeigt. Das ändert, sich wenn du

Delphi-Quellcode:

B := A;
SetLength(B, Length(B)); // ###

oder einfacherB := Copy(A); schreibst. Die Variante mit ### meint himitsu.

[himitsu]

Zitat von Codewalker:

Kannst du das noch etwas genauer erklären? Ich kann Dir da nicht 100%ig folgen.

Delphi-Quellcode:

Var S: String;

S[123] := 'a';

Bei diesem Code macht Delphi intern

Delphi-Quellcode:

UniqueString(S);
S[123] := 'a';

daraus, somit ist sichergestellt, daß bei mehreren Referenzen nur der Stringinhalt der aktuellen "Variable" verändert wird.

Delphi-Quellcode:

Var S, S2: String;

S := '123';
S2 := S;
S[2] := 'X';

// S  = '1X3'
// S2 = '123'

Bei dynamischen Arrays ist das leider anders , denn es gibt blöder Weise kein UniqueArray
und Delphi paßt auch nicht auf, daß hier nicht mehrere Referenzen überschrieben werden.

Delphi-Quellcode:

Var A, A2: Array of Integer;

SetLength(A, 3);
A[0] := 11;
A[1] := 22;
A[2] := 33;

A2 := A;

A[1] := 88;

// A  = (11, 88, 33)
// A2 = (11, 88, 33)

Also muß man dieses unter Umständen selber einfügen:

Delphi-Quellcode:

Var A, A2: Array of Integer;

SetLength(A, 3);
A[0] := 11;
A[1] := 22;
A[2] := 33;

A2 := A;

SetLength(A, Length(A));  // oder eben   A := Copy(A);
A[1] := 88;               // aber bei RefCount=1 wäre SetLength effektiver
                          // und sonst gibt es keinen großen Unterschied 

// A  = (11, 88, 33)
// A2 = (11, 22, 33)

Normaler Weise fällt dieses Verhalten vielen nicht auf, da selbst bei mehreren referenzvariablen viele eigentlich nur ein Array benötigen ... wie z.B. bei dir.

Es sieht quasi so aus, als wenn ein Array keine Referenzzählung hätte
und ebenso, wie dein Ersatzobjekt (z.B. bei TFileTypeActions) wie ein "einfacher" Pointer reagiert.

Bei meinem TDynamicCharSet oder meinen BigMathTypen ist es aber so, daß jede Referenz ihre eigenen Daten besitzt
(selbst wenn sich mehrere Referenzen die Daten teilen, wenn der Inhalt gleich bleibt),
aber dennoch Änderungen nur in der eigenen Referenz vorgenommen werden dürfen.

hier wird ja nur X verändert:

Delphi-Quellcode:

Var X, X2: Set of AnsiChar;

X2 := X;
X := ['a'];

Wenn ich das Standardverhalten der dynamischen Arrays (mein Typ nutzt intern Soeines) nicht ändern würde, dann könnte hier quasi auch der Inhalt von X2 geändert werden.

Delphi-Quellcode:

Var X, X2: TDynamicCharSet;

X2 := X;
X := ['a'];

Darum sorge ich hier also manuell für eine Single-Referenz, wärend es in deinem Code nicht nötig ist.


PS:
Was würdest du hier erwarten?

Delphi-Quellcode:

Procedure Text(X: TIntegerDynArray);
// man beachte, daß hier kein VAR-Parameter vorliegt
Begin
  X[1] := 8888;
End;

Var A: TIntegerDynArray;

A := (11, 22, 33);
Test;
// viele würden wohl (11, 22, 33) erwarten
// aber in Wirklichkeit steckt (11, 8888, 33) in dem A

Ich würde das ja für einen Fehler in Delphi/Pascal erachten, aber auf mich hört ja keiner.

[uligerhardt]

Zitat von himitsu:

Ich würde das ja für einen Fehler in Delphi/Pascal erachten, aber auf mich hört ja keiner.

ACK. Wer will das Referenz-Verhalten bei den Arrays schon so? Copy-on-write wie bei Strings wäre IMHO auch bei Arrays das nützlichere Verhalten. Von mangelnder Konsistenz zwischen Strings und Arrays ganz zu schweigen.
[OT]Und wenn wir schon beim Thema Konsistenz sind: Warum gibt's eigentlich kein Delete und Insert für Arrays? Sollte für jemanden, der Compiler magic zur Verfügung hat, leicht zu implementieren sein. Aber für den normalsterblichen Programmierer artet's in Arbeit oder Gehacke aus.[/OT]

[himitsu]

[ot]

Zitat von uligerhardt:

[OT]Und wenn wir schon beim Thema Konsistenz sind: Warum gibt's eigentlich kein Delete und Insert für Arrays? Sollte für jemanden, der Compiler magic zur Verfügung hat, leicht zu implementieren sein. Aber für den normalsterblichen Programmierer artet's in Arbeit oder Gehacke aus.[/OT]

Wenn man Record-Helper auch auf normale Typen (wie Integer oder Arrays) anwenden könnte, dann könnte man sich dieses teilweise selber einrichten.

Und mit Class-Operatoren für "Record"-Helper,
sowie Class-Operatoren für IN (if x IN y) würde , zusammen mit dem nächsten Punkt, den Rest machen.

Blöd ist auch, daß man keine Funktionen anderer Units überladen kann.
Wenn man eine Funktion für Include oder Insert erstellt, dann kann man ohne Namespace (System.Include) die System-Funktionen nicht mehr nutzen.

Sooo, genug OT
[/ot]