Umgang mit Single und Real

[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 von Gargamel:

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 von himitsu:

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 von himitsu:

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 von Bernhard Geyer:

Zitat von himitsu:

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 von jaenicke:

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 von jaenicke:

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 von jaenicke:

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 von Bernhard Geyer:

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 von Bernhard Geyer:

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 von Bernhard Geyer:

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 von jaenicke:

..., 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 von jaenicke:

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 von Bernhard Geyer:

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?

[Bernhard Geyer]

Zitat von Gargamel:

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 von Gargamel:

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.