Prism (XE3), Integer Division

[4dk2]

Moin zusammen,
wir konvertieren im Moment von Delphi nach C#,
Was sich als gutes Werkzeug zeigt, ist das Prism ausm XE3 (XE3 war das letzte was wir mit Prism haben).
Also vom Prinzip:
1. Delphi-Code in Prism Kompilierbar machen.
2. Prism DLL, mit IL-Spy Disassemblen
3. = meistens prima C# Code

Es erleichtert bisher seeeehr viel Arbeit.

Da 80% von dem was konvertiert werden muss Berechnungen sind, kam ich ganz schnell zu dem Problem
der Integer Division.
Beispiel:
double d := 100 / 33 Prism behandelt das, wie auch c#, wie eine Integer Division.
Bei Delphi wird das ja wegen / und nicht div als Float Division behandelt.

Kann ich Prism irgendwie dazu bekommen, sich an den Delphi Standart zu halten?
Irgend ne "magic" Compiler Direktive?

[4dk2]

hat sich erledigt habs gefunden
Projekteinstellungen->Kompatiblität->Delphi Division

[hoika]

Hallo,
das folgende hätte vielleicht funktioniert.

double d = double(100)/double(33)

Eine Frage dazu:
Welche Motivation hattet ihr für die Umstellung?
Wir denken auch darüber nach, haben aber noch nicht genug Argumente, sagt die Geschäftsleitung ...

[4dk2]

double d := 100.0 / 33; geht auch

theroretisch:
double d := 100d / 33d; //aber kann prism nicht.

es ist aber gut das sie den schalter eingebaut haben.
ich muss da zich Zeilen Berechnungen übersetzten, und da alles selber zu prüfen, da baut man halt Fehler ein.

Alles was neues bisher kam, ist direkt in C# gemacht worden.
Gründe für die Umstellung sind hauptsächlich,
-Emba zu teuer wird (ist ja nicht nur Rad, sondern auch die X Komponten),
-nix wirklich neues macht,
-das was als neu deklariert ist, wie mobile usw, teilweise gratis bei den andern dabei gibt.
-mit .net-Core wird es vielleicht noch 1-2 Jahre dauern, aber dann wird man sicher solide Anwendungen mit einem Code
für Windows und Linux haben.

Aber es gibt halt auch schon von den programmier-Möglichkeiten halt etliche Gründe.
Zumal auch dann noch solche Zeitlichen(=Geld) Sachen, wie erstmal 2 Tage alle Komponenten neu installieren, nur weil emba
keinen Patcher hat, sondern nur komplett Installation (stand damals, weiss nicht wie das jetzt ist).
Bei VisuStudio+C# reicht bei eigenen+Kleinen ja mit maus die DLL auf toolbox ziehen, Fertig.
Dann noch Bugs, die die IDE abschmieren lassen.
Und es entfallen einfach so ettliche Schreibarbeiten, wenn mal neues Control brauchst, was grün stat blau ist.

Also Zeit ist wohl das größte Argument, es spart einfach Zeit.

[Schokohase]

Zitat von 4dk2:

Also Zeit ist wohl das größte Argument, es spart einfach Zeit.

Das kann ich so bestätigen.

Sehr genial ist der Griff nach Strg+. (Schnellaktionen und Refactorings) der einem bei jedem Pups unterstützt.

Oder so eine (kostenlose) Erweiterung wie IntelliSense Extender und schon ist es einem wurscht, in welchem Namespace sich welcher Typ befindet. Tippen, auswählen und weiterarbeiten.