Methoden-Parameter soll Referenz, aber kein nil sein können

[Der schöne Günther]

Hallo.

Kann ich den "Gültigkeitsbereich" eines Parameters einschränken, dass ich zwar gerne Objekte annehme, aber kein

Delphi-Quellcode:

nil

?

Beispiel:

Delphi-Quellcode:

procedure TMyClass.OperateOnObject(const someObject: TObject);
   if not Assigned(someObject) then raise EArgumentNilException.Create(..);
   
   // Kram
   
end;

myInstance.OperateOnObject(nil); // <-- Soll nicht kompilieren

Somit könnte ich mir auch immer das Exception werfen am Methodenanfang sparen. Gibt es da etwas?

Bislang fällt mir nur ein, den Methoden-Parameter zu einem var-Parameter zu machen aber das kann ja auch nicht Sinn der Sache sein.

Die Delphi-Hilfe spricht von einem sehr gut aussehenden [Ref]-Attribut für Parameter. Ich sehe allerdings bei mir keinen Unterschied: Das scheint mal wieder nur im iOS/Android-Compiler zu stecken...

Zitat:

Da S1 und S2 im Rumpf von CompareStr nicht geändert werden, können sie als Konstantenparameter deklariert werden.

Konstantenparameter können je nach verwendetem Compiler an die Funktion per Wert oder per Referenz übergeben werden. Um den Compiler zu veranlassen, einen Konstantenparameter per Referenz zu übergeben, können Sie den Dekorator [Ref] mit dem Schlüsselwort const verwenden.

Das folgende Beispiel zeigt, wie Sie den Dekorator [Ref] entweder vor oder nach dem Schlüsselwort const angeben können:

Delphi-Quellcode:

 function FunctionName(const [Ref] parameter1: Class1Name; [Ref] const parameter2: Class2Name);

[himitsu]

Nein.

Und zum Selberprüfen gibt es taustende Möglichkeiten.

Delphi-Quellcode:

Assert(Assigned(someObject));

Assert(Assigned(someObject), 'Du hast voll Mist gebaut,');

if not Assigned(someObject) then
  raise EProgrammerNotFound.Create('Hirn bitte anschalten!');  // Diese Exception wird eh zu selten verwendet.

[Uwe Raabe]

De Compiler kann doch noch gar nicht erkennen, ob der übergebene Parameter zur Laufzeit nil ist. Oder geht es dir um nil als Konstante im Quelltext?

[Der schöne Günther]

Richtig, wenn dort felsenfest und absichtlich nil steht.

[jensw_2000]

Sowas hier?

Delphi-Quellcode:

method MyObject.DivideBy(aValue: Integer);
require
  aValue <> 0;
begin
  MyValue := MyValue/aValue;
end;

Delphi-Quellcode:

method MyObject.Add(aItem: ListItem);
begin
  InternalList.Add(aItem);
ensure
  Count > 0;
End;

Require_(keyword)


Pre- und Postconditions stehen auch auf meiner Delphi Sprachfeature Wunschliste ganz oben.
Hoffentlich baut EMBT das irgendwann mit ein.
Wird echt mal wieder Zeit für ein paar echte Delphi Features, anstatt nur Halbherzigkeiten drum herum zu bauen.

[Mikkey]

Einstweilen hilft Dir vielleicht auch eine Suche nach

Code:

\(.*nil.*\)

Ich habe seinerzeit für C mir auch ein Suchmakro gemacht, das nach 'if' und einem einzelnen Gleichheitszeiten in derselben Zeile gesucht hat - Bsp.

Code:

if (a = 0) { ... }

[Der schöne Günther]

Das Suchen im Quelltext müsste aber jeder selbst in seiner IDE machen, richtig?

Weil einen "echten" Präprozessor habe ich in Delphi irgendwie auch noch nicht gefunden...


Den Wunsch nach einem "Design by Contract" habe ich persönlich jetzt weniger, mir ging es nur um eine ganz harmlose Typeneinschränkung zur Compilierzeit. Aber sowas wär natürlich auch nicht schlecht ;-)

Vor allem wundere ich mich weiterhin über das [Ref]-Attribut. Ich habe kein Android oder iOS-Device auf dem ich ein "Nextgen-Compiler"-Produkt laufen lassen könnte. Oder kann man mit den x86-Simulatoren für iOS und Android da was drehen?

[himitsu]

Aber diese Pre- und Postconditions werden doch auch erst zur Laufzeit geprüft?

Wobei ich den Sinn nicht verstehen kann, warum der Compiler den Wert eines Parameters prüfen können soll.
Was ist denn er unterschied, zwischen einem nil als Konstante und einem nil, das zur Laufzeit als Variable übergeben wird?

Und den Sinn hinter den Pre- und Postconditions, als neues Sprachfeature, seh ich irgendwie auch nicht.

Delphi-Quellcode:

require
  aValue <> 0;
begin

Ist dann doch wohl das Selbe wie das? :gruebel:

Delphi-Quellcode:

begin
  Assert(aValue <> 0);

[Namenloser]

Der Unterschied ist, dass man Post- und Preconditions wenigstens zum Teil statisch auswerten könnte.

[himitsu]

Was meinst du denn mit statisch?

[Meflin]

Das Feature, was du hier eigentlich willst, sind Nullable Types. Aber eigentlich egal, auch das kann Delphi nicht :mrgreen:
(Andere Sprachen lösen das Problem, indem sie gleich auf das Fail-by-Design Konstrukt von Nullwerten verzichten... siehe z.B. Options in Scala).

In deinem Fall kann man nur sagen: In den Methodenkommentar/Doku schreiben, dass null nicht erlaubt ist, und fertig. Alles andere ist verschwendete Zeit ;)

[Namenloser]

Zitat:

Zitat von himitsu (Beitrag 1237851)

Was meinst du denn mit statisch?

Sowas wie der Compiler auch macht, wenn er z.B. sagt "Warnung: Result ist möglicherweise undefiniert" oder "Warnung: Auf Variable X zugewiesener Wert wird nicht benutzt", nur eben komplexer und ausgeweitet.

https://de.wikipedia.org/wiki/Statische_Code-Analyse

[Mikkey]

Zitat:

Zitat von Namenloser (Beitrag 1237854)

Zitat:

Zitat von himitsu (Beitrag 1237851)

Was meinst du denn mit statisch?

Sowas wie der Compiler auch macht, wenn er z.B. sagt "Warnung: Result ist möglicherweise undefiniert" oder "Warnung: Auf Variable X zugewiesener Wert wird nicht benutzt", nur eben komplexer und ausgeweitet.

https://de.wikipedia.org/wiki/Statische_Code-Analyse

Einfacher gesagt: einen Fehler in der Art

Code:

Eine Konstante mit dem Wert 'abc' darf gemäß Einschränkung der Methode nicht als Parameter verwendet werden

[Furtbichler]

Nebenbei: Entgegen landläufiger Meinung sind null-Referenzen weder ansteckend noch gefährlich. Man muß halt nur wissen, wann sie erwünscht sind, und wann nicht.

Fail-Fast und Gehirnschmalz (immer zusammen verwenden) in nichthomöopatischer Dosis löst dieses Problem (und erstaunlich viele andere) ebenso zuverlässig wie nachhaltig.

Zitat:

Zitat von Meflin (Beitrag 1237853)

In den Methodenkommentar/Doku schreiben, dass null nicht erlaubt ist, und fertig. Alles andere ist verschwendete Zeit ;)

Ja, und eben ein kleines Assert am Anfang, wie schon erwähnt und eigentlich auch logisch.

Mir scheint, hier wird der Wunsch nach einem mitdenkenden Compiler laut, der nicht nur syntaktische, sondern auch semantische Fehler in statu nascendi erkennt. Dann aber bitte gleich mit Codegenerator, dem man einfach das Problem durch verzweifelte Blicke und Gestiken vermittelt.

[Christian Seehase]

Moin Günther,

um mal auf das Beispiel Deines Eingangspostes zu kommen:
Wenn Du den Parameter als var oder out deklarierst und nicht als const lässt sich zumindest die Konstante nil nicht übergeben.

[Sherlock]

Zitat:

Zitat von jensw_2000 (Beitrag 1237842)

Hoffentlich baut EMBT das irgendwann mit ein.
Wird echt mal wieder Zeit für ein paar echte Delphi Features, anstatt nur Halbherzigkeiten drum herum zu bauen.

Um Himmels Willen bloß nicht! Lass die doch erstmal in Ruhe Bugs fixen, FMX beschleunigen und sonstiges Gerümpel erledigen. Diese überflüssige Featuritis macht mich krank.

Früher mussten wir die Lochkarten von Hand ausstechen und den Stapel 5km zu Fuß, bergauf und im Schnee ins Rechenzentrum tragen, damit er dort eingelesen werden konnte. Wenn ein Bug drin war mussten wir zurück...zu fuß 5km durch den Schnee bergauf....seltsam, wenn ich daran zurückdenke. Aber worauf ich hinauswill: Man braucht das nicht! Und es wird maximal dann sinnvoll, wenn der Rest halbwegs funktioniert.


Sherlock

[himitsu]

Zitat:

Zitat von Mikkey (Beitrag 1237866)

Code:

Eine Konstante mit dem Wert 'abc' darf gemäß Einschränkung der Methode nicht als Parameter verwendet werden

Gut, wenn es dann eingebaut wurde und der Compiler das erfolgreich verhindert ... Wer hindert dann das laufende Programm daran diesen Wert gut versteckt in einer Variable zu übergeben?

[Mikkey]

Zitat:

Zitat von himitsu (Beitrag 1237882)

Wer hindert dann das laufende Programm daran diesen Wert gut versteckt in einer Variable zu übergeben?

Niemand (bzw. die Überprüfung, die der intelligente Compiler in die Methode einbaut).

Es werden ja auch Warnungen wegen nicht initialisierten lokalen Variablen nicht zuverlässig ausgegeben bzw. nicht ausgegeben.

Ich selbst muss sowas auch nicht unbedingt haben, ich wollte nur die Intention weitergeben. (OT:) Mir wären zutreffendere Compilermeldungen viel wichtiger.

[jfheins]

Kurze Antwort: Geht nicht.
Lange Antwort:

Zitat:

Zitat von Meflin (Beitrag 1237853)

Das Feature, was du hier eigentlich willst, sind Nullable Types.

Glaube ich nicht. Es klingt eher nach nicht-nilbaren Referenztypen (bzw. non-nullable reference types)

Da wird auch schön erklärt, dass das nachrüsten von denen nicht unter beibehaltung von Kompatibilität möglich ist. Der Speicher für ein neues Objekt muss ja erst alloziert werden. In diesem Moment wird der Speicher mit Nullen gefüllt. Wird der Thread genau danach unterbrochen, kann ein anderer Thread das Objekt beobachten. Referenztypen haben damit standardmäßig den Wert nil (weil eben ein 0x00000000 im Speicher steht) und Wertetypen ebenfalls 0 oder 0.0
Es ist eben kein Zufall, dass das Bitmuster 0x00000000 für alle Typen einen gültigen Wert darstellt.

Design by contract trifft eigentlich schon sehr genau das, was der TE will:

Delphi-Quellcode:

require
  aMyReference <> nil;

davor schreiben. Entweder kann der Compiler durch Codeanalyse feststellen, dass der Parameter niemals zu nil werden kann. Oder er wirft einen Fehler und zwingt den Programmierer eine entsprechende Prüfung einzubauen. (Wahrscheinlich im Fall = nil eine Exception werfen...) Und ja, die Prüfung geschieht bereits zur Compilezeit, soweit möglich. Genau so wie der Compiler ja auch schon ermittelt "Variable x wird ein Wert zugewiesen, aber niemals benutzt" kann er auch nil-Referenzen verfolgen und eine "Vertragsverletzung" feststellen.

Ich finde aber auch die Argumentation schlüssig, dass ein nicht-nilbarer Referenztypen (bzw. non-nullable reference type) nicht viel zur Sprache beiträgt. Gäbe es diesen Typen, müsste sich diese Anforderung ja nach oben hin ausbreiten. Die Variable, die ich hinen stecke, müsste ja genau so nicht-nilbar sein. (Ähnich wie in Java: Ich muss Exceptions entweder fangen oder deklarieren dass die Methode diese werfen kann)
D.h. ich habe den Null-check eben weiter oben in der Hirarchie, aber letztlich nicht gespart.

P.S.: Zusammenfassung aus dem Link oben:

Zitat:

So, long story short: non-nullable reference types is a great idea, but as a practical manner, the objections to implementing it now are enormous. Non-nullability is the sort of thing you want baked into a type system from day one, not something you want to retrofit in 12 years later. Keep that in mind the next time you design a new type system!

[Der schöne Günther]

Zitat:

Design by contract trifft eigentlich schon sehr genau das, was der TE will:

Ja, nachdem ich jetzt nochmal das kürzliche Thema Verträge für Delphi / Design by Contract gelesen habe, merke ich das auch :-)

[himitsu]

Zwar nicht im Compiler, aber zur Laufzeit sollte es gehen?

Delphi-Quellcode:

type
  TSimpleNonNullable<T> = record
    class operator Implicit(const Value: TSimpleNonNullable<T>): T; inline;
    class operator Implicit(const Value: T): TSimpleNonNullable<T>; inline;
    class procedure Check(const Value: T); inline; static;
  public type
    ENonNullable = class(Exception);
  private
    FValue: T;
  end;

{ TSimpleNonNullable<T> }

class operator TSimpleNonNullable<T>.Implicit(const Value: TSimpleNonNullable<T>): T;
begin
  Check(Value);
  Result := Value.FValue;
end;

class operator TSimpleNonNullable<T>.Implicit(const Value: T): TSimpleNonNullable<T>;
begin
  Check(Value);
  Result.FValue := Value;
end;

class procedure TSimpleNonNullable<T>.Check(const Value: T);
begin
  case SizeOf(Value) of
    4:   if PInteger(@Value)^ <> 0 then Exit;
    8:   if PInt64(@Value)^   <> 0 then Exit;
    else raise ENonNullable.CreateFmt('TNonNullable<T>: Type %s is not supported.', [GetTypeName(TypeInfo(T))]);
  end;
  raise ENonNullable.CreateFmt('TNonNullable<T>: Variable %s(%p) is null.', [GetTypeName(TypeInfo(T)), @Value]);
end;

Delphi-Quellcode:

uses
  TypInfo, Variants;

type
  TNonNullable<T> = record
    class operator Implicit(const Value: TNonNullable<T>): T; inline;
    class operator Implicit(const Value: T): TNonNullable<T>; inline;
    class procedure Check(const Value: T); static;
  public type
    ENonNullable = class(Exception);
  private
    FValue: T;
  end;

{ TNonNullable<T> }

class procedure TNonNullable<T>.Check(const Value: T);
begin
  case PTypeInfo(TypeInfo(T)).Kind of
    tkPointer, tkClass, tkClassRef, tkInterface, tkProcedure, tkString, tkUString, tkDynArray, tkWString:
      if PPointer(@Value)^ <> nil then
        Exit;
    tkInteger, tkChar, tkWChar, tkEnumeration, tkSet:
      case GetTypeData(TypeInfo(T)).OrdType of
        otSByte, otUByte:
          if PByte(@Value)^ <> 0 then
            Exit;
        otSWord, otUWord:
          if PWord(@Value)^ <> 0 then
            Exit;
        otSLong, otULong:
          if PLongWord(@Value)^ <> 0 then
            Exit;
        else
          raise ENonNullable.CreateFmt('TNonNullable<T>: Type %s is not supported.', [GetTypeName(TypeInfo(T))]);
      end;
    tkInt64:
      if PInt64(@Value)^ <> 0 then
        Exit;
    tkFloat:
      case GetTypeData(TypeInfo(T)).FloatType of
        ftSingle:
          if PSingle(@Value)^ <> 0 then
            Exit;
        ftDouble:
          if PDouble(@Value)^ <> 0 then
            Exit;
        ftExtended:
          if PExtended(@Value)^ <> 0 then
            Exit;
        ftCurr:
          if PCurrency(@Value)^ <> 0 then
            Exit;
        else
          raise ENonNullable.CreateFmt('TNonNullable<T>: Type %s is not supported.', [GetTypeName(TypeInfo(T))]);
      end;
    tkMethod:
      if TMethod(Pointer(@Value)^).Code <> nil then
        Exit;
    tkVariant:
      if not VarIsNull(PVariant(@Value)^) and VarIsEmpty(PVariant(@Value)^) then
        Exit;
    else
      raise ENonNullable.CreateFmt('TNonNullable<T>: Type %s is not supported.', [GetTypeName(TypeInfo(T))]);
  end;

  raise ENonNullable.CreateFmt('TNonNullable<T>: Variable %s(%p) is null.', [GetTypeName(TypeInfo(T)), @Value]);
end;

class operator TNonNullable<T>.Implicit(const Value: TNonNullable<T>): T;
begin
  Check(Value.FValue);
  Result := Value.FValue;
end;

class operator TNonNullable<T>.Implicit(const Value: T): TNonNullable<T>;
begin
  Check(Value);
  Result.FValue := Value;
end;

[Der schöne Günther]

Parametrisierte, operator-überladene Records. Jetzt habe ich alles gesehen. :roteyes:

[himitsu]

Zitat:

Zitat von Der schöne Günther (Beitrag 1237896)

Parametrisierte, operator-überladene Records. Jetzt habe ich alles gesehen. :roteyes:

Ich hatte hier vor Jahren mal irgendwo eine Codezeile gepostet, die sah aus wie ein C++-Code, oder eher wie soein obfuscateter JavaScript-Code.
Aber im Grunde war es nur eine For-Step-Schleife, wie man sie aus QBasic kennt, welche aus anonymen Methoden bestand, vielleicht noch mit bissl Generics und alles "schön" als Einzeiler.

Delphi-Quellcode:

FOR X% = 0 TO 9 STEP 3  // 0 3 6 9 

FOR X% = 3 TO 0 STEP -1  // 3 2 1 0

Aber leider finde ich den einfach nicht mehr :cry: