[Gelöst] Implicit casting von Class oder Record

[mbc]

Ich würde gerne ein eigenes Record (oder auch eine eigene Klasse) in z.B. einen integer implizit umwandeln.

Mit "mode delphi" hat das auch funktioniert. Aber im "mode objfpc" bekomme ich es einfach nicht zum laufen.
Soweit wie ich rausgelesen habe sollte das auch möglich sein, jedoch ist die Syntax dafür abweichend.
Weder Suchfunktion noch google liefern ausreichend Ergebnisse für mich für einen Erfolg.

Könnte jemand bitte ein kurzes Beispiel geben wie und wo was stehen muss damit der compiler zufrieden ist?

[Mathias]

Meinst du sowas ?

https://wiki.freepascal.org/Type_Helper/de

[Socke]

Mit "mode delphi" hat das auch funktioniert. Aber im "mode objfpc" bekomme ich es einfach nicht zum laufen.

Kannst du deinen Quelltext und die Fehlermeldung hier posten?

Eine implizite Umwandlung kann man z.B. per Zuweisungsoperator durchführen:

Code: Alles auswählen

program Project1;
{$mode objfpc}

type
  TMyRecord = record
    i: Integer;
  end;

operator :=(const r: TMyRecord): Integer;
begin
  Result := r.i;
end;

var
  r: TMyRecord;
  i: Integer;
begin
  i := r;
end.

Man kann den Operator auch in den Record mit aufnehmen:

Code: Alles auswählen

program Project1;
{$mode objfpc}
{$modeswitch advancedrecords} // Records mit Methoden erlauben

type
  TMyRecord = record
    i: Integer;
    class operator :=(const r: TMyRecord): Integer;
  end;

class operator TMyRecord. := (const r: TMyRecord): Integer;
begin
  Result := r.i;
end;

var
  r: TMyRecord;
  i: Integer;

begin
  i := r;
end.

[mbc]

Erstmal danke für die Antworten, die Laz-Community ist wirklich toll und auch bei Laz-Anfängern sehr hilfsbereit, danke Leute !

Ich habe den original Quelltext nicht mehr, habe aber jetzt herausgefunden das es explicit funktioniert:

Code: Alles auswählen

type

  { TVariableInteger }

  TVariableInteger = record
  private
    fByteLength: Uint8;
    fDecoded: Uint64;
  public
    property ByteLength: Uint8 read fByteLength;
    property Decoded: Uint64 read fDecoded;
  public
    class function ReadFromTStream(Stream: TStream): TVariableInteger; static;
  public
    class operator explicit(Value: Uint64): TVariableInteger;
  end;
  
  implementation
  
 class operator TVariableInteger.explicit(Value: uint64): TVariableInteger;
begin
  Result.SetAsDecoded(Value);
end;  
  

Sobald ich aber jetzt das explicit wieder in ein implicit ändere geht es nicht mehr. Das verwirrt mich als Laz-Beginner dann doch.
Mit dem Wort implicit erhalte ich dann folgende Fehlermeldung:

Error: It is not possible to overload this operator. Related overloadable operators (if any) are:

Der folgende code funktioniert dann fehlerfrei, das sollte dann die implizite Version sein.

Code: Alles auswählen

operator :=(const r: TMyRecord): Integer;

Etwas verwirrend umgesetzt wie ich finde.

[Socke]

Sobald ich aber jetzt das explicit wieder in ein implicit ändere geht es nicht mehr. Das verwirrt mich als Laz-Beginner dann doch.

Laut Langage Reference Guide gibt es neben := nur explicit, der ausschließlich bei Typecasts verwendet wird. Daher ist := der richtige zu überladende Operator für einen impliziten Typecast.

Edit: Der Operatorname "implicit" scheint wohl nur im "Delphi"-Modus zu funktionieren.

[mbc]

Vielen Dank!

Ist für mich ungewohnt, ich komme von c#, da funktioniert neben explicit eben auch implicit, von daher ...
Und wenn ich das Record jetzt in eine Klasse ändere, dann funktioniert es auch wieder nicht, eine verwirrende Syntax wie ich finde.

[Winni]

Hi!

Falsch!

Du hast übelstes Syntax-Unkraut gelernt.

Jetzt geht es zurück zu einer einfachen Sprache!

Grüße
Winni

[mbc]

Hehe ... für mich zählt da eher die einfache Verwendung,
Es gibt halt Gründe warum immer weniger Personen Pascal verwenden, neuere Sprachen sind flexibler, moderner und für viele somit einfacher und schneller zu lernen.
Wenn ich in Pascal einen String trennen möchte, muss ich mich immer an den Namen der Funktion erinnern, bei anderen Sprachen bekommt man die Auswahl über Intellisense (oder CodeTools) ... und einen Integer kann man nicht trennen, somit wird da dann gar nicht erst angeboten.

Als "einfach" würde ich das hier nicht unbedingt bezeichnen.
Die Syntax hier ist in Laz für Records und Classes total unterschiedlich.
Und beim Delphi-mode dann zusätzlich nochmal. Für eingefleischte natürlich kein Problem, als Anfänger aber verwirrend und demotivierend, weil es eben viele Fehler erzeugt.
Für mich ist es logisch und konsequent neben explicit auch implicit verwenden zu können, man schreibt ja auch nicht "+" fürs addieren und "Minus" dann fürs subtrahieren .... entweder Zeichen oder Wörter einheitlich.

Aus meiner Sicht ist das eben nicht sehr benutzerfreundlich und man muß sich mehr merken, oder später immer wieder nachschlagen.
Jede Sprache hat ihre Stärken und Schwächen, aber dieser "Mischmasch" hier ist nicht unbedingt mein Geschmack oder als einfach anzusehen.
Viele sagen Pascal sei einfach und Java und C# schwerer. Ich -persönlich- empfinde das eher anders herum, aber das ist halt eine individuelle Ansichtssache einer jeden Person (und das ist auch gut so).
Dafür hat Pascal eben auch ganz andere wunderschöne Vorteile.

Aber nun, die Beispiele auf der Seite funktionen dann auch bei Klassen und ich kann definitiv bestätigen, das implicit dann im Delphi-modus funktionert, vielleicht für den ein oder anderen mal eine gute Hilfe.

[Mathias]

Wenn ich in Pascal einen String trennen möchte, muss ich mich immer an den Namen der Funktion erinnern, bei anderen Sprachen bekommt man die Auswahl über Intellisense (oder CodeTools) ... und einen Integer kann man nicht trennen, somit wird da dann gar nicht erst angeboten.

Wen du einen String trennen willst, schreibst du wen s ein String ist folgendes. s. und dann wird dir Spitt vorgegeben, oder toInteger, für eine Umwandlung in einen Integer.

Die Syntax hier ist in Laz für Records und Classes total unterschiedlich.

Das ist so, alternativ kann man "object" verwenden, dies in in der Handhabung ähnlich eines Recordes, mit dem Unterschied, das man dort vererben kann.

[PascalDragon]

Wenn ich in Pascal einen String trennen möchte, muss ich mich immer an den Namen der Funktion erinnern, bei anderen Sprachen bekommt man die Auswahl über Intellisense (oder CodeTools) ... und einen Integer kann man nicht trennen, somit wird da dann gar nicht erst angeboten.

Du darfst hier aber nicht Äpfel mit Birnen vergleichen: Die Sprache hat erstmal nichts mit der IDE zu tun. Ganz davon abgesehen, dass Lazarus mittlerweile auch sowohl die aktiven helper types anzeigen kann (also zum Beispiel mystr.Split), als auch Funktionen, die den eingegebenen Namen enthalten. Aber selbst in anderen Sprachen musst du erstmal wissen wonach du suchst. Wenn du nicht weißt, dass Split für Auftrennen steht, dann weißt du auch erstmal nicht weiter (das trifft natürlich noch mehr auf komplexere Methoden zu).
Und meiner Meinung nach steht hier Lazarus einer IDE wie Visual Studio nicht wirklich nach...

Als "einfach" würde ich das hier nicht unbedingt bezeichnen.
Die Syntax hier ist in Laz für Records und Classes total unterschiedlich.
Und beim Delphi-mode dann zusätzlich nochmal. Für eingefleischte natürlich kein Problem, als Anfänger aber verwirrend und demotivierend, weil es eben viele Fehler erzeugt.
Für mich ist es logisch und konsequent neben explicit auch implicit verwenden zu können, man schreibt ja auch nicht "+" fürs addieren und "Minus" dann fürs subtrahieren .... entweder Zeichen oder Wörter einheitlich.

Die Syntax von record und class Typen unterscheidet sich nicht zwischen den FPC und Delphi Modi. Ja, es gibt Unterschiede zwischen den beiden Modi, aber dieser ist keiner.
Und wie die Operatoren aussehen ist dokumentiert. Das hierbei symbolische Namen verwendet werden hat übrigens historische Gründe: die Unterstützung für Operator Overloading ist älter als C# (der älteste für mich zugreifbare Code des Compilers ist von 1998 und der enthält bereits Operator Overloading). Das Vorbild war nämlich hier C++.
Der Explicit Operator kam erst im Nachhinein hinzu, als Delphi den nämlich auch eingeführt hat. Ganz davon abgesehen, dass es in dein meisten Fällen gar nicht nötig ist zwischen impliziter und expliziter Zuweisung zu unterscheiden (deswegen hatte FPC das ursprünglich auch gar nicht).

Aber nun, die Beispiele auf der Seite funktionen dann auch bei Klassen und ich kann definitiv bestätigen, das implicit dann im Delphi-modus funktionert, vielleicht für den ein oder anderen mal eine gute Hilfe.

Der Delphi Modus ist nun mal zur Kompatibilität mit Delphi. Den dokumentieren wir dann allerdings auch meist gar nicht, da man dafür die Dokumentation von Delphi nutzen kann/sollte.

[mbc]

Ganz davon abgesehen, dass Lazarus mittlerweile auch sowohl die aktiven helper types anzeigen kann.

Ja, das Problem ist halt immer, dass man im Netz natürlich überwiegend noch sehr viele alte Beispiele findet und deshalb erstmal nicht darauf kommt, dass es etwas neues gibt.

Die Syntax von record und class Typen unterscheidet sich nicht zwischen den FPC und Delphi Modi. Ja, es gibt Unterschiede zwischen den beiden Modi, aber dieser ist keiner.

Das stimmt, aber bei den Operatoren dann halt schon.
Bei Records müssen die innerhalb der Typendefinition als "class" definiert werden, bei Klassen liegen sie außerhalb der Typendefinition.
Wie gesagt --- für Anfänger --- wie mich, sehr verwirrend, zumal ich auch hier nicht wirklich ein Beispiel finden konnte und wenn es eines gab, dann war nicht ersichtlich ob der Codeschnipsel für eine Klasse oder ein Record war.

Und wie die Operatoren aussehen ist dokumentiert.

Und wie das manchmal so ist, habe ich auch gerade eben erst verstanden was das mit den ganzen Linien soll ... Es ist super erklärt, könnte man auch nicht besser machen, aber manchmal kapiert der Leser dennoch nicht was gemeint ist ...

Das hierbei symbolische Namen verwendet werden hat übrigens historische Gründe: die Unterstützung für Operator Overloading ist älter als C# (der älteste für mich zugreifbare Code des Compilers ist von 1998 und der enthält bereits Operator Overloading). Das Vorbild war nämlich hier C++.

Ist ja auch ok, das sind eben die Nachteile wenn man bereits eine andere Spache erlernt hat wo dies direkt konsistent implementiert wurde. Ich dachte mir schon das es nachträglich hinzukam. Aber dennoch die Frage: Warum kann man nicht zusätzlich auch implicit anbieten? Ok, mag nicht zu 100% konform sein, aber zerstören würde es doch auch nichts ... aus meiner Sicht macht man es sich hier etwas unötig "schwer".

Der Explicit Operator kam erst im Nachhinein hinzu, als Delphi den nämlich auch eingeführt hat. Ganz davon abgesehen, dass es in dein meisten Fällen gar nicht nötig ist zwischen impliziter und expliziter Zuweisung zu unterscheiden (deswegen hatte FPC das ursprünglich auch gar nicht).

Und das verwirrt mich dann halt. Wenn ich keinen Datenverlust bei der Umwandlung habe, ist implicit ja hervorragend. Wenn ich aber weiß es könnte die Daten abändern oder verloren gehen, ist die impizite Umwandlung nicht praktisch, in dem Fall könnte ich nur die explizite anbieten, damit der Programmierer sich dessen auch bewußt ist. Sinn macht es ja somit schon. Deshalb wurde es ja vermutlich auch nachträglich noch eingeführt.

Und zum Abschluss:
Danke für die viele Arbeit und Mühe welche ihr in dieses tolle Projekt reinsteckt! Großartige Arbeit!
Was ich aber wirklich schade finde ist, dass es keine vernünftige Lektüre für Lazarus gibt.
Für andere Sprachen gibt es Bücher mit teilweise über 1500 Seiten, schade, dass es keinen Verlag gibt der sich dafür interessiert.
EIn Buch finde ich viel angenehmer zum durchstöbern.
Im Internet sucht man sich tot und die heutzutage permanente Werbung oder Cookies an fast jeder Ecke geht einem dann auch irgendwann auf die Nerven.

[Mathias]

Win jemand die IDE von Lazarus zu stir tindet, der sollte mal die IDE von Arduino angucken, die ist fast so komfortabel wie notepad von Windows.

[PascalDragon]

Die Syntax von record und class Typen unterscheidet sich nicht zwischen den FPC und Delphi Modi. Ja, es gibt Unterschiede zwischen den beiden Modi, aber dieser ist keiner.

Das stimmt, aber bei den Operatoren dann halt schon.
Bei Records müssen die innerhalb der Typendefinition als "class" definiert werden, bei Klassen liegen sie außerhalb der Typendefinition.

Globale Operatoren können auch für record Typen verwendet werden. Der große und wichtige Unterschied (und neben Delphikompatibilität auch der Grund, warum Operatoren in records eingeführt wurden), ist dass nur dann die Operatoren von Generics mit genutzt werden.
Ich spiele schon länger mit dem Gedanken, da noch was zu ändern, damit auch globale Operatoren (und Helper) in Generics genutzt werden können, aber einerseits muss ich die Zeit dazu finden und andererseits auch sichergehen, dass dadurch nichts kaputt geht.

Und wie die Operatoren aussehen ist dokumentiert.

Und wie das manchmal so ist, habe ich auch gerade eben erst verstanden was das mit den ganzen Linien soll ... Es ist super erklärt, könnte man auch nicht besser machen, aber manchmal kapiert der Leser dennoch nicht was gemeint ist ...

Gute, alte Syntaxbeschreibung.

Das hierbei symbolische Namen verwendet werden hat übrigens historische Gründe: die Unterstützung für Operator Overloading ist älter als C# (der älteste für mich zugreifbare Code des Compilers ist von 1998 und der enthält bereits Operator Overloading). Das Vorbild war nämlich hier C++.

Ist ja auch ok, das sind eben die Nachteile wenn man bereits eine andere Spache erlernt hat wo dies direkt konsistent implementiert wurde. Ich dachte mir schon das es nachträglich hinzukam. Aber dennoch die Frage: Warum kann man nicht zusätzlich auch implicit anbieten? Ok, mag nicht zu 100% konform sein, aber zerstören würde es doch auch nichts ... aus meiner Sicht macht man es sich hier etwas unötig "schwer".

Weil eben beschlossen wurde in den nicht-Delphi Modi symbolische Operatoren zu verwenden. Und eine Programmiersprache sollte möglichst orthogonal sein, sprich nicht zwei mögliche Varianten um genau das Gleiche zu erreichen (bei Free Pascal eingeschränkt auf jeweils einen Syntaxmodus).

Der Explicit Operator kam erst im Nachhinein hinzu, als Delphi den nämlich auch eingeführt hat. Ganz davon abgesehen, dass es in dein meisten Fällen gar nicht nötig ist zwischen impliziter und expliziter Zuweisung zu unterscheiden (deswegen hatte FPC das ursprünglich auch gar nicht).

Und das verwirrt mich dann halt. Wenn ich keinen Datenverlust bei der Umwandlung habe, ist implicit ja hervorragend. Wenn ich aber weiß es könnte die Daten abändern oder verloren gehen, ist die impizite Umwandlung nicht praktisch, in dem Fall könnte ich nur die explizite anbieten, damit der Programmierer sich dessen auch bewußt ist. Sinn macht es ja somit schon. Deshalb wurde es ja vermutlich auch nachträglich noch eingeführt.

Ich habe ja auch nicht gesagt, dass es keinen Sinn macht. In den meisten Fällen ist es allerdings unnötig.

Und zum Abschluss:
Danke für die viele Arbeit und Mühe welche ihr in dieses tolle Projekt reinsteckt! Großartige Arbeit!

Bitte. Aber ich arbeite einfach gern mit (Object) Pascal und an und mit FPC sowie Lazarus.

Was ich aber wirklich schade finde ist, dass es keine vernünftige Lektüre für Lazarus gibt.
Für andere Sprachen gibt es Bücher mit teilweise über 1500 Seiten, schade, dass es keinen Verlag gibt der sich dafür interessiert.
EIn Buch finde ich viel angenehmer zum durchstöbern.
Im Internet sucht man sich tot und die heutzutage permanente Werbung oder Cookies an fast jeder Ecke geht einem dann auch irgendwann auf die Nerven.

Schon mal hier geschaut? (und soweit ich weiß arbeitet Michael van Canneyt zur Zeit auch an einem aktuellerem Buch)

Win jemand die IDE von Lazarus zu stir tindet, der sollte mal die IDE von Arduino angucken, die ist fast so komfortabel wie notepad von Windows.

Oh ja, ich weiß, warum ich Visual Studio Code dafür nutze (für C). Oder eben Lazarus, wenn's um Pascal geht.

[Mathias]

Win jemand die IDE von Lazarus zu stir findet, der sollte mal die IDE von Arduino angucken, die ist fast so komfortabel wie notepad von Windows.

Oh ja, ich weiß, warum ich Visual Studio Code dafür nutze (für C). Oder eben Lazarus, wenn's um Pascal geht.

Meinst du mit Visual Studio, das Atmel Studio ?
Für Arduinos kann ich kann ich Sloeber empfehlen, wen es C/C++ sein muss.

[Warf]

Meinst du mit Visual Studio, das Atmel Studio ?
Für Arduinos kann ich kann ich Sloeber empfehlen, wen es C/C++ sein muss.

Er schrieb doch Visual Studio Code, das ist nicht Visual Studio.

Code (wie der Open Source Core heist, VS Code ist eine MS distribution mit propritärern featues wie einem auto update) ist ein hoch konfigurierbarer source code editor ähnlich wie emacs oder vim, nur deutlich einfacher sowohl in der benutzung als auch in der entwicklung (erweiterbar durch javascript und konfigurierbar durch json).

Gibt ne hervoragende Arduino extension dafür, mit allen relevanten features um auf arduino zu arbeiten, sowie allem schnick-schnack den man von seiner IDE erwartet (jump to implementation, code completion, live syntax error checking, etc.)