Delphi-PRAXiS

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Programmieren allgemein (https://www.delphipraxis.net/40-programmieren-allgemein/)
-   -   Kommunikation Klassen von unterschiedl. Compilern Interesse? (https://www.delphipraxis.net/132788-kommunikation-klassen-von-unterschiedl-compilern-interesse.html)

schöni 19. Apr 2009 22:06


Kommunikation Klassen von unterschiedl. Compilern Interesse?
 
Hallo!

Ich weiß nicht, wie groß das allgemeine Interesse am genannten Problem ist, aber ich frage dennoch mal in die Runde ob das von allgemeinem Interesse ist?

Ich habe eine Klasse aus Freepascal, die ich mit Delphi verwenden möchte. Dabei übergebe ich einen Klassenzeiger an die Freeepascal Klasse. Dieser Klassenzeiger dient als Container für die zu übertragenden Informationen.

Delphi-Quellcode:
type
  TFPC_Class = class
  private
    FData: TPersistent;
    function GetData: TPersistent;
    procedure SetData(AData: TPersistent);
  public
    ...
    property ADataContainer: TPersistent read GetData write SetData;
    ...
  end;

//------------------------

type
  TDelphi_Class = class
  private
    FData: TPersistent;
    function GetData: TPersistent;
    procedure SetData(AData: TPersistent);
  public
    ...
    property ADataContainer: TPersistent read GetData write SetData;
    ...
  end;
Wenn die Klasse eine Komponente ist, muss doch deren Owner in der Komponente NIL sein, wenn sie in einer DLL übergeben wird oder?

Die Frage ist, gibt es für das Problem eine elegante Lösung?

Wie groß ist das allgemeine Interesse an einer Lösung innerhalb der DP?

FPC KLassen sind dabei nur beispielhaft. Vielleicht gibt es ja auch Klassen aus anderen Programmiersprachen, die man irgendwann verwenden will, ohne sie in die Lieblingsprogrammiersprache portieren zu müssen. Man bleibt dann einfach in der bevorzugten Sprache und greift auf die Fremdklasse zu, egal ob in Java, PHP, C++ .... geschrieben.

Wie oft tritt dieser Fall im Programmiereralltag auf?

Lohnt sich also der Aufwand, ein Konzept dafür zu erarbeiten oder gibt es das schon und wenn ja, wie wird das realisiert?

Tut mir leid, aber ich habe seit 2 Jahren nicht mehr programmiert und bin daher völlig aus der Übung und nicht mehr auf dem Laufenden? Habt daher bitte Nachsicht.

mirage228 19. Apr 2009 23:01

Re: Kommunikation Klassen von unterschiedl. Compilern Intere
 
Mit Interfaces (und ggf. COM) kannst Du Klassen über DLLs (bzw. Type Libraries) sprachübergreifend verwenden.

Bernhard Geyer 20. Apr 2009 06:21

Re: Kommunikation Klassen von unterschiedl. Compilern Intere
 
Klassenzeiger in DLL's zu übergeben funktioniert nur beim gleichen Compiler und auch nur bei der gleichen Compiler-/Frameworkversion sowie gleichen Compilereinstellungen. Ansonsten ist das speicherabbild zu 99,9% untrschiedlich und es kracht an allen Ecken und Enden.

Nimm wie vorgeschlagen Interfaces oder Records mit angegebenen Speicheralignment.

mjustin 20. Apr 2009 06:23

Re: Kommunikation Klassen von unterschiedl. Compilern Intere
 
Zitat:

Zitat von schöni
FPC KLassen sind dabei nur beispielhaft. Vielleicht gibt es ja auch Klassen aus anderen Programmiersprachen, die man irgendwann verwenden will, ohne sie in die Lieblingsprogrammiersprache portieren zu müssen. Man bleibt dann einfach in der bevorzugten Sprache und greift auf die Fremdklasse zu, egal ob in Java, PHP, C++ .... geschrieben.

Wie oft tritt dieser Fall im Programmiereralltag auf?

Im Enterprisebereich fast täglich. Dazu nimmt man eine Form der Serialisierung (XML, JSON, SOAP) die beide Partner verstehen. Einen Zeiger auf ein PHP oder Java Objekt kann man aber nicht einfach aus Delphi oder Free Pascal verwenden.

Web Services und REST sind zwei Stichworte.

Wer mag, kann ja versuchen einen Universaladapter zu entwickeln, mit dem man aus Delphi auf Objekte beliebiger Programmiersprachen zugreifen kann :?

Cheers,


Alle Zeitangaben in WEZ +1. Es ist jetzt 16:10 Uhr.

Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz