Problem mit Leerzeile in einer TStringlist!

[Muetze1]

Zitat:

Zitat von shmia

Assert(list is TStrings) schützt vor bösartigem Gebrauch. Der Programmierer ist ganz schlecht drauf und ruft die Procedure z.B. so auf:

Delphi-Quellcode:

RemoveEmptyStrings(TStrings(Memo1));

Zitat:

Zitat von himitsu

wie wär's wenn ich der Funktion ein TEdit unterschiebe?

Tja, dann macht das mal - und sagt mir ob ihr eine Assertion bekommt, wenn ihr das so macht... :wink:

[himitsu]

was ist denn mit dem IS loß :shock:

also ich hätte da Eine erwartet

wenn ich die Funktions Parameter nach TObject ändere, dann kommt eine :gruebel:


[add]
grad getestet ...
immer wenn bei IS und AS der Typ mit dem Variablen-Typen übereinstimmt, dann macht Delphi da grarnichts :evil:

[Muetze1]

Zitat:

Zitat von himitsu

was ist denn mit dem IS loß :shock:

also ich hätte da Eine erwartet

Ich hatte nicht umsonst nach einer Begründung gefragt.

Zitat:

Zitat von himitsu

wenn ich die Funktions Parameter nach TObject ändere, dann kommt eine :gruebel:

Was auch logisch ist. IS testet eine Spezialisierung ab, wenn die Variable schon vom Typ TStrings ist, dann kann darin nur ein TStrings oder dessen Nachfahre sein - oder NIL. Das sind die einzigen zuweisungskompatiblen Inhalte. Somit ist die IS Prüfung sinnlos. Delphi prüft einzig auf <> nil, was auch das einzige ist, was von IS übrig bleibt. NIL kann niemals von einer Spezialisierung sein.

Bei deinem Beispiel habt ihr beide einen harten Cast gemacht, die einzige halbwegs unaufwändige Methode das ganze mit einem fremden Objekttyp aufzurufen. Aber gerade mit dem harten Cast umgeht ihr ja diese Zuweisungsinkompatibilität und schreibt Delphi vor: das ist TStrings. Und genau weil ihr das macht, tragt ihr die Verantwortung, da Delphi alles prüft - aber genau die Prüfung habt ihr umgangen. Damit knallts beim Zugriff (großer Zufall natürlich) auf .Count.

Wenn ihre eine Dose habt und da steht "Brotdose" drauf, dann ist die entweder leer oder da ist Brot drin. Wenn dich nun einer fragt, ist da Brot drin, dann weisst du genau: entweder Brot oder nix. Somit einfach die Dose schütteln: wenn was zu hören ist, kannst du bestätigen das Brot drinne ist. Wenn du nix hörst kannst du behaupten sie ist leer. Wenn du nun gefragt wirst ob da Mehrkornbrot drinne ist, dann musst du reinschauen und dir das Brot anschauen. Abhängig davon kannst du dies bejahen, verneinen oder feststellen, das gar nichts drinne ist.

Alles das funktioniert, wenn du davon ausgehst, dass die Dose nur sinnbestimmt verwendet wird. Wenn nun aber ein Scherzkeks dort Kaffesahne reinpackt, dann hast du bei der nächsten Brot-vorhanden-Frage eine Sauerei in der Küche - aber ist dann nicht dein Fehler, sondern von dem, der die Dose nicht bestimmungsgemäß verwendet hat. Die Brotdose trägt keine Schuld und du als "Tester" auch nicht...

[himitsu]

Blöd ist aber dann, wenn man prüfen will, ob es genau der Typ ist.
Also man kann Nachfahren übergeben und du willst wissen ist es irgendein Nachfahre oder ist es der Basistyp.

Und da gibt Delphi dann immer True, selbst wenn es nicht der Basistyp ist :?


ich hab 'ne Lösung :nerd:

Delphi-Quellcode:

Assert(TObject(o) is TStrings);

[Muetze1]

Zitat:

Zitat von himitsu

Also man kann Nachfahren übergeben und du willst wissen ist es irgendein Nachfahre oder ist es der Basistyp.

Das kannst du mit InheritsFrom() ermitteln.

Zitat:

Zitat von himitsu

Und da gibt Delphi dann immer True, selbst wenn es nicht der Basistyp ist :?

Da die Nachfahren vom Basistyp erben, sind alle Nachfahren auch gleichzeitig Basistyp kompatibel.

Alle IS Abfragen auf TObject würden bei allen Delphi Klassen true ergeben. Anders in C++Builder, da muss man zwischen VCL und C++ Klassen unterscheiden. Da gibt es aber auch noch viele andere Unterschiede zu beachten...

[alzaimar]

Das Thema war doch gleich ... :gruebel:

Oder anders ausgedrückt: Kann es sein, das ihr ein wenig abschweift?

Das ist eine sehr interessante Diskussion und sollte in einem separaten Thread noch einmal aufgegriffen werden ("Das Assert: Aufzucht und Hege" oder so), aber hier ging es dem Threadersteller um die Frage, wieso der Zugriff auf das 1.Element eines leeren Strings zu einer Exception führt...