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.

[Bernhard Geyer]

Zitat:

Zitat von himitsu (Beitrag 1169345)

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.

Was hat bloss diese I*** bei MS und ANSI (?) geritten Integer nicht mehr mitwachen zu lassen. Vermutlich das Problem das das Mitwachen von Int zu 8 Byte zu viel zu übearbeitenden bedeutet hätte ...

[Bernhard Geyer]

Zitat:

Zitat von Gargamel (Beitrag 1169347)

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

(P)Char ist bei D2007 und älter ein 1-Byte-Character .
(P)Char ist ab D2009 ein 2-Byte (besser gesagt (UTF16)) Character.

D.h. wenn du mit einem D2009 PChar eine DLL aufruftst die ein 1-Byte PChar erwartet wird diese fast immer nur 1 Zeichen auslesen.

[himitsu]

Falls du das mit den generischen Typen noch nicht ganz verstanden hast ... das sind nur "Umleitungen", bzw. ist ein Alias für einen anderen Typen.

Bis Delphi 2007 und in FreePascal/Lazarus:
Char = AnsiChar
PChar = PAnsiChar
String = AnsiString

Ab Delphi 2009
Char = WideChar
PChar = PWideChar
String = UnicodeString

Also genauso wie Real, was aktuell ein Alias für Double ist.

[Gargamel]

Dann werde ich bei der Gelegenheit nicht nur Real in Double abändern, sondern gleich noch integer in Longint.
Wenn ich nun aber mit C# arbeite, wo das .net-Framework verwendet wird, sollte ich bei Übergabe von Zeichenketten AnsiString oder doch lieber WideString nehmen?

[himitsu]

Zitat:

Vermutlich das Problem das das Mitwachen von Int zu 8 Byte zu viel zu übearbeitenden bedeutet hätte ...

Also genauso wie beim PChar von ANSI zu Unicode?

Seit bekannt war, daß es bald endlich mal 64 Bit gibt, hab ich spätestens angefangen, den Integer so einzusetzen, wie es gut ist.
Also da Integer, wo es mal 64 werden kann und dort wo es 32 Bit bleiben muß, wurde LongInt eingesetzt ... also genau so, wie es mal gedacht war.

Im Gegensatz zum PChar hatte der Integer schonmal die 16-32-Bit-Grenze überschritten, also hätte man es da doch besser wissen müssen?

Toll, jetzt ist das Integer überall kaputt.
PS: Damit sind nun auch alle Integer<>Pointer-Konvertierungen futsch.

Zitat:

Zitat von Gargamel (Beitrag 1169352)

Wenn ich nun aber mit C# arbeite, wo das .net-Framework verwendet wird, sollte ich bei Übergabe von Zeichenketten AnsiString oder doch lieber WideString nehmen?

WideString ist kein eigener Delphityp.
Der ist eine Umleitung/Kapselung von SysAllocStringLen, SysReAllocStringLen, SysFreeString und SysStringLen, also im Grunde perfekt geeignet, für eine systemübergreifende Kommunikation, abgesehn von PAnsiChar und PWideChar und wird z.B. auch von vielen COM-Schnittstellen genutzt.
Es ist also praktisch in nahezu allen Programmiersprachen verfügbar, welche die WinAPI nutzen.

[Bernhard Geyer]

Zitat:

Zitat von Gargamel (Beitrag 1169352)

Dann werde ich bei der Gelegenheit nicht nur Real in Double abändern, sondern gleich noch integer in Longint.

Brauchst nicht. In C# (und Java) ist integer immer 32-Bit (http://msdn.microsoft.com/en-us/libr...(v=vs.80).aspx).
Ein managed Umgebung muss sowas unabhängig vom Zielsystem festlegen.

Zitat:

Zitat von Gargamel (Beitrag 1169352)

Wenn ich nun aber mit C# arbeite, wo das .net-Framework verwendet wird, sollte ich bei Übergabe von Zeichenketten AnsiString oder doch lieber WideString nehmen?

Widestring. Damit hast du den gleichen UTF-16 der in NET und Java eingesetzt wird. (http://msdn.microsoft.com/en-us/libr...(v=vs.71).aspx)

[Gargamel]

Danke Euch allen. Jetzt bin ich wieder auf Kurs.

[Bernhard Geyer]

Zitat:

Zitat von himitsu (Beitrag 1169354)

Seit bekannt war, daß es bald endlich mal 64 Bit gibt, hab ich spätestens angefangen, den Integer so einzusetzen, wie es gut ist.
Also da Integer, wo es mal 64 werden kann und dort wo es 32 Bit bleiben muß, wurde LongInt eingesetzt ... also genau so, wie es mal gedacht war.

Im Gegensatz zum PChar hatte der Integer schonmal die 16-32-Bit-Grenze überschritten, also hätte man es da doch besser wissen müssen?

Toll, jetzt ist das Integer überall kaputt.

Dann warst du vermutlich einer der wenigen Programmierer der sowas gemacht hat.
Und mit dem aufkommen von Managed Umgebungen hätte man auch ahnen können das diese Mitwachsen irgendwann aufgegeben wird. So gibt es eigentlich keine Bestrebungen den String-Datentyp auf 4-Byte aufzubohren (nötig wäre es ja seit ein paar Jahren seit dem die Unicode Base Plane nicht mehr ausreicht).

Glücklicherweise hat sich Delphi hier an den Rest der Programmierwelt angepasst und unter 64-Bit den Integer-Typ bei 4 Byte gelassen. Sonst hätte es in diesem Umfeld wieder größere Probleme gegeben.

Zitat:

Zitat von himitsu (Beitrag 1169354)

PS: Damit sind nun auch alle Integer<>Pointer-Konvertierungen futsch.

Sowas macht man ja auch nicht (auch wenn es manchmal der einfachste weg ist/war) :-)

[jaenicke]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1169360)

Zitat:

Zitat von himitsu (Beitrag 1169354)

PS: Damit sind nun auch alle Integer<>Pointer-Konvertierungen futsch.

Sowas macht man ja auch nicht (auch wenn es manchmal der einfachste weg ist/war) :-)

Das ist aber manchmal der einzige Weg gewesen. NativeInt gab es ja früher noch nicht.

Die Entscheidung Integer bei 32-Bit zu belassen bedeutet gleichzeitig, dass man an manchen Stellen keinerlei Möglichkeit hat, denselben Code für alte und neue Delphiversionen zu benutzen.
Hätte man ihn auf 64-Bit mitwachsen lassen, hätte ausschließlich fehlerhafter Code nicht mehr funktioniert. Genau so wie es bei PChar und PAnsiChar / PWideChar der Fall ist.

Deshalb halte ich das auch für eine Fehlentscheidung, schlechte Programmierung zu unterstützen und guten Code nicht zu ermöglichen...

[Bernhard Geyer]

Zitat:

Zitat von jaenicke (Beitrag 1169363)

Die Entscheidung Integer bei 32-Bit zu belassen bedeutet gleichzeitig, dass man an manchen Stellen keinerlei Möglichkeit hat, denselben Code für alte und neue Delphiversionen zu benutzen.

Wieso das? Es verbietet dir keiner ein NativeInt = Integer für Pre-XE2 zu definieren.

Zitat:

Zitat von jaenicke (Beitrag 1169363)

Hätte man ihn auf 64-Bit mitwachsen lassen, hätte ausschließlich fehlerhafter Code nicht mehr funktioniert.

Blöd wäre nur gewesen das dieser fehlerhafte Code sehr viel häufiger und auch teilweise sehr versteckt Portierungsprobleme verursacht hätte.

Zitat:

Zitat von jaenicke (Beitrag 1169363)

Deshalb halte ich das auch für eine Fehlentscheidung, schlechte Programmierung zu unterstützen und guten Code nicht zu ermöglichen...

Ich denkek das Embaracadero diese Entscheidung nicht so getroffen hätte wenn nicht durch C/C++/C#/Java/... dieser Weg nicht schon vorgezeichnet wäre. Wieso hier einen eigenen Weg gehen der Eigentlich nur zu Problemen bei der interoperabilität führt. Eine "reine" Entscheidung hätte dazu geführt das jeder der was mit einem Delphi-programm zu tun hat wissen muss das int von C/C++/C#/Java/... unter Delphi int32 bedeutet. Jeder würde den integer vorschlagen und müsste erstmal die Probleme bei 64-Bit-Zusammenspiel debuggen.

[jaenicke]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1169369)

Wieso das? Es verbietet dir keiner ein NativeInt = Integer für Pre-XE2 zu definieren.

Ich sprach ja von demselben Code, dass man das verhältnismäßig einfach lösen kann, ist klar.
Nun muss man aber jeden Code durchforsten, bei dem man von der eigentlichen Selbstverständlichkeit, dass Integer nach dem Schritt zu 32-Bit auch bei dem zu 64-Bit mitwächst, ausgegangen ist.

Ich habe z.B. genau aus diesem Grund schon seit Jahren Integer an solchen Stellen benutzt und LongInt usw. bei Schnittstellen. Aber das war ja nun alles für die Katz.

Zitat:

Zitat von Bernhard Geyer (Beitrag 1169369)

Blöd wäre nur gewesen das dieser fehlerhafte Code sehr viel häufiger und auch teilweise sehr versteckt Portierungsprobleme verursacht hätte.

Das heißt wenn alle statt Integer jetzt Double schreiben, dann versteht IntToStr bald auch Double Werte?

Zitat:

Zitat von Bernhard Geyer (Beitrag 1169369)

Wieso hier einen eigenen Weg gehen der Eigentlich nur zu Problemen bei der interoperabilität führt. Eine "reine" Entscheidung hätte dazu geführt das jeder der was mit einem Delphi-programm zu tun hat wissen muss das int von C/C++/C#/Java/... unter Delphi int32 bedeutet.

Das muss man nicht extra wissen, da die festen Typen in der Windows API sehr gut definiert sind und man nur diese Typen einfach benutzen muss.

Und da Embarcadero sich ja schon eher an professionelle Entwickler mit dem entsprechenden Kleingeld richtet, sollte man dann sich bei solchen Entscheidungen dann auch an diejenigen richten, die wissen was sie tun. Und nicht, ohne jemandem zu nahe treten zu wollen, an die, die so etwas eben erst noch lernen müssen... das ist ja nix Schlechtes, sollte aber nicht diese Entscheidungen beeinflussen.

[Bernhard Geyer]

Zitat:

Zitat von jaenicke (Beitrag 1169375)

..., bei dem man von der eigentlichen Selbstverständlichkeit, dass Integer nach dem Schritt zu 32-Bit auch bei dem zu 64-Bit mitwächst, ausgegangen ist.

Spätestens nachdem man bei C/C++ diese mitwachsen aufgekündigt hat war das keine Selbstverständlichkeit mehr.

Zitat:

Zitat von jaenicke (Beitrag 1169375)

Ich habe z.B. genau aus diesem Grund schon seit Jahren Integer an solchen Stellen benutzt und LongInt usw. bei Schnittstellen. Aber das war ja nun alles für die Katz.

Dann gehörst du zu einer absoluten Minderheit die das hier macht. Ich denke der größteil der Programmirschar (mich eingeschlossen) hat sich an dieser Stelle keinen Gedanken gemacht.

Zitat:

Zitat von Bernhard Geyer (Beitrag 1169369)

Und da Embarcadero sich ja schon eher an professionelle Entwickler mit dem entsprechenden Kleingeld richtet, sollte man dann sich bei solchen Entscheidungen dann auch an diejenigen richten, die wissen was sie tun. Und nicht, ohne jemandem zu nahe treten zu wollen, an die, die so etwas eben erst noch lernen müssen... das ist ja nix Schlechtes, sollte aber nicht diese Entscheidungen beeinflussen.

M.E. war die professionelle Entscheidung hier keinen Sonderweg zu gehen sondern sich hier an C/C++/Java/C# zu halten.
Oder kennst du eine (relevante) Programmiersprache dessen Haupt-Integertyp von 32-Bit nach 64-Bit gewachsen wäre?

[jaenicke]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1169377)

M.E. war die professionelle Entscheidung hier keinen Sonderweg zu gehen sondern sich hier an C/C++/Java/C# zu halten.
Oder kennst du eine (relevante) Programmiersprache dessen Haupt-Integertyp von 32-Bit nach 64-Bit gewachsen wäre?

Nein, kenne ich nicht, das habe ich mir nicht angeschaut, da ich auch dort stets konkrete Typen benutze.
Ist es denn dort auch so, dass es einen generischen Integertypen gibt, der von 16-Bit auf 32-Bit gewachsen ist, aber von 32-Bit auf 64-Bit nicht? Bei C# wüsste nicht welcher das sein sollte, int war schließlich immer 32-Bit und ist auch kein generischer Typ.
C++ kenne ich nicht gut genug um das sagen zu können.

[Furtbichler]

Zitat:

Zitat von jaenicke (Beitrag 1169379)

Bei C# wüsste nicht welcher das sein sollte, int war schließlich immer 32-Bit und ist auch kein generischer Typ.

Als der Wechsel von 16 auf 32 vollzogen wurde, war C# noch gar nicht geboren.

[Bernhard Geyer]

Zitat:

Zitat von jaenicke (Beitrag 1169379)

Ist es denn dort auch so, dass es einen generischen Integertypen gibt, der von 16-Bit auf 32-Bit gewachsen ist, aber von 32-Bit auf 64-Bit nicht?

Genauso der "normale" Integer-Datentyp. Deshalb meine ich ja das hier ein Wachsen bei Delphi einen Sonderweg darstellen würde wenn selbst C/C++ das nicht mehr bei Sprung auf 64-Bit macht.

Zitat:

Zitat von jaenicke (Beitrag 1169379)

Bei C# wüsste nicht welcher das sein sollte, int war schließlich immer 32-Bit und ist auch kein generischer Typ.

Eine managed Umgebung kann sowas gar nicht machen da du beim Compilierzeitpunkt ja gar nicht weist ob dein Programm als 32-Bit oder 64-Bit zum Einsatz kommt.

Zitat:

Zitat von jaenicke (Beitrag 1169379)

C++ kenne ich nicht gut genug um das sagen zu können.

Da C++ "nur" der Objektaufsatz auf C ist sind hier die Basistypen identisch.

[pixfreak]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1169381)

Da C++ "nur" der Objektaufsatz auf C ist sind hier die Basistypen identisch.

Moin,

ich hoffe, das >>"nur"<< war ganz bewusst gewählt... :wink:

Wenn ich mich recht entsinne, war ein int unter Turbo C noch ein 2 Byte Datentyp... Da war long der "große" 4 Byte-Typ.

GNU C++ in der 486er Zeit, da war int schon 4 Bytes groß, allerdings auch long. Gleiche Zeit und auf dem Alpha war long dann 8 Bytes groß. :wall:
Also seeehr plattformabhängig und füllte den Quelltext mit vielen Compilerdirektiven...


VG Pixfreak

[jaenicke]

Letztlich bringt es nix darüber groß zu diskutieren, jeder muss mit der Entscheidung leben. Mag er sie schlecht finden wie ich oder gut wie andere.

Insofern belasse ich das mal dabei, meine Meinung dazu habe ich ja genau genug erklärt.

[Bernhard Geyer]

Zitat:

Zitat von pixfreak (Beitrag 1169384)

ich hoffe, das >>"nur"<< war ganz bewusst gewählt... :wink:

"Nur" damit hier keine Diskussion aufkommt.

Zitat:

Zitat von pixfreak (Beitrag 1169384)

Wenn ich mich recht entsinne, war ein int unter Turbo C noch ein 2 Byte Datentyp... Da war long der "große" 4 Byte-Typ.

GNU C++ in der 486er Zeit, da war int schon 4 Bytes groß, allerdings auch long. Gleiche Zeit und auf dem Alpha war long dann 8 Bytes groß. :wall:
Also seeehr plattformabhängig und füllte den Quelltext mit vielen Compilerdirektiven...

:-)
Wahrscheinlich auch ein Grund wieso man diese mitwachsen der Datentypen mehr oder minder aufgibt.
Beim wechsel von 16 auf 32-Bit waren solche Busbreiten-Anpassen performancetechnisch noch sehr zwingend. Heutzutage kommen auch 64-Bit Prozessoren mit 32-Bit Integer ganz gut zurecht so das das hier nicht mehr ins Gewicht fällt.