Umgang mit Single und Real

[Gargamel]

Hi

Ich habe mir eine Reihe von Mathematikfunktionen programmiert, die alle mit Real arbeiten. Jetzt möchte ich die Funktionen in Form einer DLL auch in C# nutzen und MUSS dort (leider) den Datentyp Float nutzen.
Jetzt ist es so, daß Float in C# dem Datentyp Single in Delphi entspricht. Und Double (C#) entspricht Real (Delphi).

Zwei mögliche Lösungen sind mir eingefallen:

1. Die exportierten Funktionen der Delphi-DLL nutzen den Datentyp Single und arbeiten trotzdem mit den Mathematikfunktionen, die Real nutzen.

2. Ich erstelle nochmal alle Mathematikfunktionen, diesmal mit dem Datentyp Single und lasse, je nach Compilerdirektive, mit Single oder Float kompilieren.
(die schon bestehenden Mathematikfunktionen möchte ich ungern ändern)

Was meint Ihr dazu?

Danke
Gargi


Edit: In C++ hatte ich mal gesehen, daß man sich eigene Datentypen erstellen kann, die auf normalen Datentypen basieren. Auf diese Weise konnte man plattformübergreifend programmieren, ohne ständig überall am Code Änderungen vorzunehmen. Wäre das eine Lösung für mein Problem?

[Gargamel]

Ich habe mal die dritte Lösung ausprobiert. Der Delphi-Compiler meckert zumindest erstmal nicht.

Delphi-Quellcode:

unit Unit_dwDatastructures;

interface

type

gargi = real;

Vec3D = record
  x,y,z:gargi;
end;

Vec2D = record
  x,y:gargi;
end;

implementation

end.

[jaenicke]

Real ist äußerst ungeeignet, da er keinem bestimmten Typ entspricht, sondern ein generischer Typ ist. Überspitzt gesagt sagst du damit dem Compiler: "Nimm irgendeinen Typ mit Nachkommastellen, welcher ist mir egal."
Insbesondere für Schnittstellen sollte man daher grundsätzlich konkret Single (4 Byte), Double (8 Byte) usw. benutzen, da es dort sehr wichtig ist, dass ein konkreter Typ benutzt wird.

[Bernhard Geyer]

Zitat:

Zitat von Gargamel (Beitrag 1169322)

Und Double (C#) entspricht Real (Delphi).

Jein. Double (C#) entspricht Double (Delphi). Real ist ein andere Name für den Double-Datentyp.

[jaenicke]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1169338)

Real ist ein andere Name für den Double-Datentyp.

Nein, ein generischer Datentyp. Man kann zwar ziemlich sicher davon ausgehen, dass es in Zukunft immer Double sein wird, aber festgeschrieben ist das nicht.

Und wenn irgendwo mit {$REALCOMPATIBILITY ON} die Kompatibilität eingeschaltet wird, ist es z.B. kein Double mehr, sondern Real48.
Fazit:
Am besten nie Real benutzen, es sei denn der Datentyp ist wirklich absolut egal.

[Bernhard Geyer]

Zitat:

Zitat von jaenicke (Beitrag 1169339)

Nein, ein generischer Datentyp. Man kann zwar ziemlich sicher davon ausgehen, dass es in Zukunft immer Double sein wird, aber festgeschrieben ist das nicht.

eigentlich kann man davon ausgehen das es in zukunft nur single und double geben wird.

Zitat:

Zitat von jaenicke (Beitrag 1169339)

Und wenn irgendwo mit {$REALCOMPATIBILITY ON} die Kompatibilität eingeschaltet wird, ist es z.B. kein Double mehr, sondern Real48.
Fazit: Am besten nie Real benutzen, es sei denn der Datentyp ist wirklich absolut egal.

Gibts den real48 überhaupt unter 64 Bit? Extended wurde ja nicht nach 64-Bit Portiert.

[jaenicke]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1169340)

Gibts den real48 überhaupt unter 64 Bit? Extended wurde ja nicht nach 64-Bit Portiert.

Ja, gibt es und auch {$REALCOMPATIBILITY ON} funktioniert dort genauso (Real --> Real48).

[Gargamel]

OK, danke erstmal. Dann werde ich mir in Zukunft Real verkneifen und immer Single bzw. Double verwenden.
Aber was ist mit Lösung 3? (zweiter Post)

[himitsu]

Genauso ungeeignet, also wenn du da Real letztendlich wieder als Typ verwendet.

Real, String, Char, PChar, Integer, Cardinal, NativeInt und NativeUInt sollte/darf man niemals für eine externe modul- und systemübergreifende Kommunikation, sowie zum Speichern verwenden,
denn das sind alles generische Typen.
Für externe Daten sind statische Typen aber extrem wichtig.
War sehr leicht zu merken, als mi Delphi 2009 PChar und String urplötzlich Unicode wurden, was keiner ahnen konnte, obwohl schon seit unzähligen Jahren bekannt war, daß diese Typen nicht statisch sind.
Genauso wie damals der Integer von 16 auf 32 Bit wuchs und eigentlich auch auf 64 Bit gewachsen währe ... währe da nicht ein I*** auf die Idee gekommen den einzufrieren und stattdessen z.B. den NativeInt zu erfinden.

Aber es kann seine Vorteile haben, wenn man eine Typen selber deklariert, da man diese später sehr leicht ändern kann, sollte es unbedingt nötig sein und muß dabei nur eine einzige Stelle ändern.

[Gargamel]

Ja, klar. Posting 2 hatte noch real drin, da mir erst später gesagt wurde, daß ich lieber Double nehmen soll.

Aber das mit PChar verstehe ich nicht. Die Übergabe von Zeichenketten hatte auf diese Weise immer sehr gut funktioniert.