Was nervt euch so, während der Programmierung oder so allgemein

[Stevie]

Zitat:

Zitat von himitsu (Beitrag 1134125)

seit man aber Interfaces wieder in Objekte zurückcasten kann (IInterfaceComponentReference sei Dank ... die haben mir meine Idee geklaut :cry:),
ist dieses nicht mehr sicher, denn wenn man dann auf das ältere Klasse castet und dann wieder in ein Interface, dann wird das Interface des Vorfahren und nicht das Neue verwendet.

So ne Schei... macht man ja auch nicht! Oder man schaltet sein Hirn an bevor man wirres Zeugs codet.

[himitsu]

Die Klasse ist für etwas, was hier mal veröffentlicht wird ... Und was hier für Irre rumlaufen, kann ich mir jetzt noch garnicht ausdenken. :stupid:
Allerdings könnte man sich über diese Lib die Delphi-IDE lahmlegen und das wollte ich minimieren.

[Stevie]

Dass man non ref counted interfaces haben will, ist ja noch plausibel, aber dass man TComponent Derivate mit Refcounting ausstatten will, kann ich nicht ganz verstehen, denn genau damit kannst du ganz böse Überraschungen erleben. Das TComponent livetime management wird nunmal über den Owner geregelt und nicht über das Interface. Beides zu mischen wird über kurz oder lang in die Hose gehen.

[himitsu]

Deswegen hab ich mir ja ein entsprechendes Verhalten ausgedacht, welches den Referenzzähler und die Objektreferenz beachtet ... erst wenn Beides freigeben ist, wird alles aufgeräumt. :stupid:

Denn es ist vorgesehn diese Klassen gleichzeitig in der VCL und als Interface zu nutzen und ich wollte mir eben doppelte Arbeit ersparen, das als Interface zu machen und dann nochmal 'ne Containerklasse für die VCL bereitzustellen. :oops:

[Namenloser]

Zitat:

Zitat von himitsu (Beitrag 1134149)

Deswegen hab ich mir ja ein entsprechendes Verhalten ausgedacht, welches den Referenzzähler und die Objektreferenz beachtet ... erst wenn Beides freigeben ist, wird alles aufgeräumt. :stupid:

Das klingt ziemlich kompliziert und fehleranfällig, aber wenn es funktioniert, ist es cool.

[himitsu]

Eigentlich nicht ... jedenfalls nicht, wenn ich _AddRef hätte überreiben können :cry:

Aber ich hab jetzt die Basisklase (abgeleitet von TComponent) und eine Helperklasse, welche ich als VCLInterface in TComponent einbeschmuggelt hab. :D

Nja, statt 3 Zeilen Code jetzt 10 sinnlose Funktionen, welche einfach nur wieder zurück zur Basisklasse umleiten.
*ich haß das*


So, als Rache und weil heute nich mehr viel passiert, entschlüssle ich jetzt das geheime Interface hinter den anonymen Methoden und veröffentliche es dann ... das hat emba jetzt davon.
An dem Objekt hinter dem Interface bin ich schon und nun nur noch die schöne neue überladene RTTI ausnutzen. :roll:

[himitsu]

Mir ist grade die krankeste Idee gekommen, für einen Code:

Delphi-Quellcode:

for i in(function:TArray<Integer>var i:Integer;begin SetLength(Result,5);for i:=0to 4do Result[i]:=i*10;end)()do
  ShowMessage(Variant(i));

Eigentlich sollte es doch nervig sein, wenn wunderschöner Delphi-Code urplötzlich wie eine C-Krankheit aussieht, oder etwa nicht?

PS: Das ist die Kurzfassung einer

Delphi-Quellcode:

for i := 0 to 40 step 10 do

-Schleife ... falls man es, aus welchen Gründen auch immer, tatsächlich nicht erkennen sollt. :angle2:

Delphi-Quellcode:

var
  i2: integer;


for i2 in (function: TArray<Integer>
           var
             i: Integer;
           begin
             SetLength(Result, 5);
             for i := 0 to 4 do
               Result[i] := i * 10;
           end)() do
  ShowMessage(IntToStr(i2));

Ich geb's zu, am Ende hab ich es dann doch noch so gelöst. :oops:

Delphi-Quellcode:

var
  i, i2: integer;

for i := 0 to 4 do begin
  i2 := i * 10;
  ShowMessage(IntToStr(i2));
end;

Oder wenigstens so :angle:

Delphi-Quellcode:

for i in TArray<Integer>.Create(0, 10, 20, 30, 40) do
  ShowMessage(IntToStr(i));

Ich hoffe jetzt wendet niemand genervt dem Delphi den Rücken zu und wanders zu QBasic ab. :?


Aber wirklich nervig ist eigentlich, daß

Delphi-Quellcode:

TArray<Integer>

und

Delphi-Quellcode:

array of Integer

nicht kompatibel sind, obwohl

Delphi-Quellcode:

TArray<T>

auch nur ein

Delphi-Quellcode:

array of T

ist :wall:

Delphi-Quellcode:

var
  G: TArray<Integer>;
  D: array of Integer;

D := G;  // [DCC Fehler] U.pas(56): E2010 Inkompatible Typen: 'TArray<System.Integer>' und 'Dynamic array'

Aber OK, man soll sich ja nicht so aufregen ... an der sonst so kranken Vererbungsreihe der Generics liegt es dieses Mal nicht direkt.

Delphi-Quellcode:

var
  X: array of Integer;
  D: array of Integer;

X := D;  // [DCC Fehler] U.pas(56): E2008 Inkompatible Typen

Denn der Witz ist, daß das sonst so typsichere/strenge Delphi durch die Generics "scheinbar" total verweichlicht wird.

Delphi-Quellcode:

var
  X: TArray<Integer>;
  D: TArray<Integer>;

X := D;  // denn das geht zumindestens ^_^

[Valle]

Mich nervt gerade tierisch, dass mein (Linux-) Rechner eben komplett abgestürzt ist. Das starten irgendwelcher Programme wurde mit I/O-Error quittiert, bereits geöffnete Programme froren ein, sobald sie auf die Festplatte zugreifen wollten. Nach dem nötigen Hard-Reset kamen Fehler beim Booten - und das obwohl der Linux Kernel über eine spezielle Tastenkombination erst alle Schreiboperationen vollendet und anschließend die Geräte ausgehängt hat. Also fast ein normaler Shutdown.

Eine Analyse des Dateisystem-Headers zeigt: alle 592 Bytes, welche die Schlüssel zur verschlüsselten Partition enthielten bestehen jetzt ausschließlich aus Nullen. Statt arbeiten ist jetzt also erstmal eine Neuinstallation und -Konfiguration des Systems angesagt. Datenverlust gab es zum Glück keinen, aber mit meiner tollen Internetanbindung mindestens 1 Tag Arbeit. Juhu.

Liebe Grüße,
Valentin

[Luckie]

Ich dachte man installiert nur Windows neu, wenn es abgestürzt ist. :mrgreen:

[Namenloser]

Mit Linux wär das nicht passiert :warn: