TimeSpan+DateTime etc unter Delphi Win32

[Lemmy1]

Edit: Project-Homepage gibts nun hier

Hallo zusammen,

da Delphi 2006 nun intelligentere Records kann als seine Vorgänger (damit meine ich Function, Private/Public, Class Functions und Operatorüberladung), lag es einmal nahe, die bekannten schönen Valuetypes aus .Net mal für Win32 nachzuprogrammieren.

Oberstes Gebot für mich dabei war Quellcodekompatibilität, so dass ein und derselbe Code in beiden Welten funktioniert. Via {$IFDEF} macht sich die Unit dann unter .Net selbst unsichtbar.

Zum Üben hab ich mir zu erst einmal "TimeSpan" rausgesucht und bin damit auch fertig geworden. Funktioniert relativ gut, wenn man von zwei Delphi 2006 Bugs absieht:
- Der Debugger crasht leider total, da er wohl die ganzen neuen Recordfeatures noch nicht so ganz kennt
- Beim Aufruf gibt es gelegentlich einen Compilerfehler, so dass man in diesen Fällen den Code etwas umschreiben muss

Hab beide Bugs hier unter Bugreports gemeldet. Der zweite ist auch bereits bei Borland auf Status=Open. Bei dem anderen vertrau ich in Sakuras Fähigkeiten, seine Kollegen in den allerwertesten zu treten :-D

Als nächstes Projekt steht für mich DateTime an, da TimeSpan ohne DateTime nur halb so viel Spaß macht. Aber es gibt noch viele weitere interessante Klassen, wobei für mich die Valuetypes (=records) im Vordergrund stehen.

Später könnte man sich auch überlegen, Klassen wie StringBuilder nachzuprogrammieren. Sie hat zwar in der Delphi-Win32 Welt eigentlich nichts zu tun, aber man würde Sourcecode Kompatibilität erreichen, ohne seinen Code durch $IFDEFs verschandeln zu müssen.

Was meint Ihr dazu?

[Lemmy1]

Und hier nun mit einer ersten Version von DateTime. Fehlen noch einige Funktionen drin (ToString, Parse und alles, was mit Umrechnen von und zu UTC zu tun hat).

Sollte aber auf jeden Fall schon verwendbar sein und bestimmt besser also Delphi's TDateTime :)

[jbg]

Die Bezeichnung .NET unter Win32 ist etwas ungeschickt gewählt. Denn bei mir läuft .NET auch unter Win32. Mit Mono sogar unter Linux. Das was du meinst heißt "Natives Win32".

[mschaefer]

Das hört sich ja sehr motiviert an. Bin mal gespannt was aus dem Projekt wird. Vielleicht solltest Du sowas mal bei Source-Forge anmelden, ob da noch mehr Net-Entwickler Interesse haben. Interessant ist das allemal, allerdings muß man schon ein D2005/6 in seiner Sammlung haben und da bin ich noch weit von entfernt. Aber das Projekt beobachte ich jedenfalls mit Neugier..

Grüße // Martin

[Lemmy1]

Eigentlich ist es sogar nur Delphi 2006, da 2005 die ganzen Möglichkeiten für Records fehlen (Methoden, Sichtbarkeit, Operatorüberladung) :(

[Lemmy1]

Hab das nun mal an die Jedi Jungs als Vorschlag geschickt. Kam auch schon eine erste vielversprechende Antwort, dass sie interessiert wären, das sort zu integrieren.

Guck mer mal :)

[jbg]

Bei welchem JEDI Projekt? JediDotNet oder JCL? Oder ein eigenes neues?

[Lemmy1]

Das müssen die entscheiden, ich tippe aber mal auf Unit in JCL

[Lemmy1]

Ich wollte eigentlich nur mal Bescheid geben, dass ich nun ein eigenes Projekt für diese Library (die inzwischen etwas gewachsen und getestet ist) auf SourceForge angelegt habe. Warte noch auf Approval. Name: Net4Native.

Grüße

[3_of_8]

Ich hab mal versucht, das ganze für mein Delphi 7 umzuschreiben.

Das Problem an der Sache: Der Compiler schmiert beim Versuch, es zu kompilieren, übelst mit einer AV ab. Und zwar nicht nur der IDE-Compiler, sondern auch der Commandline-Compiler.

Probiert es vllt mal bitte mit anderen Versionen zu kompilieren.

Unit im Anhang.

[Lemmy1]

Hi!

Schonmal im Vorraus Danke für das Interesse. So langsam möchte ich das Projekt wirklich durchziehen und zumindest die wichtigsten Klassen 100% kodieren und testen.

Zu Deinem Problem: Also ich hab nur Delphi 2006 installiert. Alle anderen Versionen stehen im Schrank.

Das Problem an der Delphi 7 Sache ist aber, dass da einfach Sprachfeatures fehlen: Records mit Methoden und Operator Overloading.

Ziel des ganzen ist es ja, die Sourcecode Kompatibilität zu .Net herstellen, so dass man einfach zwischen .Net und Win32 wechseln kann OHNE auf die ganzen coolen Framework classes zu verzichten.

Operator Overloading auf Records könnte man dann ja nur mit irgendwelchen Funktionen von außen in der Art von "TimeSpanAdd(ts1, ts2)" machen, aber das würde dann eben nicht unter .Net kompilieren. Außerdem wärs hässlich :)

[3_of_8]

Schau dir mal meinen Code an.

Ich verwende objects, das sind Records mit Methoden.

Ich ersetze einfach die Propertys direkt durch ihre Accessor-Methoden und deklariere die Klassenoperatoren als Funktionen.

Man muss die Dinger nicht instantiieren oder sowas, kann aber trotzdem mit ihnen ein paar Spielereien machen. Nur Operatorenüberladung funktioniert halt nicht.

[omata]

Wenn ich ein Delphicompiler wäre hätte ich auch so reagiert. In der Unit waren soviele gemeine Fehler, dass ich da auch abgedret wäre :zwinker:

Gruss
Thorsten

[3_of_8]

Ich konnte es ja nicht debuggen - habs jetzt unter Delphi 2005 gedebuggt und jetzt läuft es - nur unter Delphi 7 nicht, da kommt weiterhin die AV.

Ein Aufruf sähe so aus:

Delphi-Quellcode:

var time1, time2: TimeSpan;
begin
time1:=time1.Create(16,20,0);
time2:=time2.Create(18,40,0);
showmessage(time2.Subtract(time1).toString);

[omata]

Mit der oben angehängten Unit kommt unter Delphi7 und deinem Beispiel folgendes heraus: 02:20:00

Edit: Deine Unit sieht jetzt im Prinzip so aus wie meine überarbeitete. Jetzt funktioniert auch diese unter Delphi7.
Was mir gerade aufgefallen ist: Wieso benutzt du hier object und nicht class?

Gruss
Thorsten

[3_of_8]

Was hast du erwartet?

18-16=2
40-20=20

stimmt doch.

[omata]

Ich habe gar nichts erwartet. Ich habe nicht versucht die Unit zu verstehen. Ich habe nur die Fehler behoben. Da du ein Beispiel gepostet hast, war ich nur an einer Lösung interresiert.

Gruss
Thorsten

[3_of_8]

Sry, das klang so als würdest du das Ergebnis für falsch halten.

Ich verwende deshalb nicht class, weil man Klassen instantiieren muss.

Auf die Dinger kann man auch ohne Instantiierung zugreifen.

Allerdings könnte man natürlich auch Klassen verwenden, das ist klar.

[Lemmy1]

Gibt es denn abgesehen von der fehlenden Operator Überladung noch irgendwelche Unterschiede zwischen Records mit Funktionen und old-style "object"s?

Hrm könnt ja als kompilierswitch ganz nett sein, dass auch via objects zu realisieren....hrm

[3_of_8]

objects haben Methoden. records nicht.

objects können zwar auch Propertys haben, aber die werden vom Compiler so umgesetzt, dass sie AVs auslösen.