Delphi-PRAXiS
Seite 2 von 4     12 34      

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Object-Pascal / Delphi-Language (https://www.delphipraxis.net/32-object-pascal-delphi-language/)
-   -   Prism Delphi .NET Facts - was sich ändert (https://www.delphipraxis.net/5921-delphi-net-facts-sich-aendert.html)

Hansa 23. Jun 2003 11:45

Also wird das wohl so laufen, wie mit dem alten String, der jetzt ein ShortString ist. Dann würde ^QA doch helfen, string würde durch ShortString ersetzt und alles wäre kompatibel. 8) Sieht trotzdewm schwer nach "Try and error" aus. Na ja, abwarten und Tee trinken.

mirage228 23. Jun 2003 17:50

Re: Delphi .NET Facts - was sich ändert
 
Zitat:

Zitat von sakura
Pointer gelten als veraltet. Diese werden unter Umständen noch unterstützt, aber über kurz oder lang verschwinden. Pointer gelten unter .NET als unsafe Types, da deren Typ nicht überprüft werden kann. Pointer-Arithmetik ist verboten.

dabei wollte ich gerade mit Pointern anfangen... und wodurch werden Pointer dann ersetzt? Gar nicht?

Zitat:

file of <type wird nicht mehr unterstützt, da die Record-Größe abhängig von der Zielplattform sein kann.
Hab ich sowieso net gebraucht, aber ich kenn genug Leute dies vermissen werden!

Zitat:

[*]Das Schlüsselwort object, welches bis lang noch unterstützt wurde, wird komplett gestrichen - es bleibt nur noch class.
Argh, das ist Ärgerlich, denn ich benutze gerne "Object". Was ist denn so schlimm an Object?

Zitat:

String ist in Zukunft ein WideString (16 Bit/Char), nicht mehr AnsiString (8 Bit). String wird auf System.String gemappt. Entsprechend wird Char zu WideChar (16 Bit) anstatt AnsiChar (8 Bit).
Hört sich ganz sinvoll an ;-)

Zitat:

Der Pointer ExitProc wird nicht mehr unterstützt. Es muss auf initialization und finalization ausgewichen werden!
Was hat der nochmal bewirkt??


Zitat:

Die dynamische Einbindung von Interfaces via implements wird nicht mehr unterstützt. Argh, habe ich gerade erst kennen und lieben gelernt :roll:
Wolltes selber noch lernen...

Zitat:

Assembler Anweisungen werden nicht mehr unterstützt, da diese Plattform-Abhängig sind.
Also ich finde Assembler manchmal schon notwendig, besonders wenn es ganz ganz schnell gehen soll. Was wohl mein Kumpel dazu sagt, der gerade Assembler lern :roll:

Zitat:

Direkter Zugriff auf Speicher durch Methoden wie BlockRead, BlockWrite, GetMem, FreeMem und ReAllocMem sind nicht mehr möglich.
Der @-Operator wird vermutlich verschwinden
Erstes: Naja, ich Kopiere Dateien sowieo nur noch per CopyFile oder mit Streams. Ansonsten hab ich die besagten Methoden nicht so oft benutzt.
Zweites: Was kommt dan anstelle des @ ??

Zitat:

Also, wer will, kann auch schon jetzt auf diese Änderungen achten, dann wird die Umsetzung unter .NET einfacher ;-)
Vielleicht werde ich ja fertig, bis Delphi .NET rauskommt.

Amen.

mirage228

Daniel B 23. Jun 2003 17:53

Re: Delphi .NET Facts - was sich ändert
 
Hallo,
Zitat:

Zitat von mirage228
Argh, das ist Ärgerlich, denn ich benutze gerne "Object". Was ist denn so schlimm an Object?

KOP hört sich schöner und "wichtiger" an als OOP?! :mrgreen:

Grüsse, Daniel :hi:

S - tefano 23. Jun 2003 19:04

Hi,

wo außer im Zusammenhang mit Pointern wird denn in Delphi noch der @-Operator verwendet?
Wenner wirklich nur bei Pointern verwendet wird, ist es dann nicht logisch dass er mit den Pointern verschwindet?
Die Dinger (also die Pointer, nie die "@"s) konnt ich eh nie leiden...
Aber file of <type> und BlockRead/-Write werden mir fehlen. Muss man dann komplett auf FileStreams oder die ShellBefehle umsteigen?
Was mal recht interessant werden kann, sind die Methoden in Records. Haben die vielleicht deswegen die file of <type> abgeschafft, damit man das "Abspeichern von Methoden" umgehen kann? Naja, bezweifle ich mal.
Aber ich würd ja gerne wissen...
wo liegt denn dann der Unterschied zwischen einem Record und einer Klasse / einem Objekt?
Muss man dann wirklich jeden blöden String als WideString deklarieren? Wenn der normale String in seiner "Beschaffenheit" doch sowieso abgeschafft wird (wird er das?), könnte man nicht einfach nen neuen String- Typen unter demselben Namen einführen?
Is doch irgendwie schöner, oder?

Bis dann,

S - tefano

Chewie 23. Jun 2003 19:16

Alles geraten, also kein Gewähr!

Zitat:

Zitat von S - tefano
Was mal recht interessant werden kann, sind die Methoden in Records. Haben die vielleicht deswegen die file of <type> abgeschafft, damit man das "Abspeichern von Methoden" umgehen kann? Naja, bezweifle ich mal.
Aber ich würd ja gerne wissen...
wo liegt denn dann der Unterschied zwischen einem Record und einer Klasse / einem Objekt?

Man kann Records ja auch mit einem Stream speichern. Der Unterschied zwischen Records und Klassen war ja vorher, abgesehen von den Methoden, der, dass ein Record ja quasi ein Speicherblock war, während eine Klasse wegen den Methoden verschiedene Zeiger beinhaltet hat. Vielleicht wird das ja fortgeführt, die Methoden in einem Record sind auch im Speicherbereich des Records enthalten.

Zitat:

Zitat von S - tefano
Muss man dann wirklich jeden blöden String als WideString deklarieren? Wenn der normale String in seiner "Beschaffenheit" doch sowieso abgeschafft wird (wird er das?), könnte man nicht einfach nen neuen String- Typen unter demselben Namen einführen?

Aber nein, es wird weiterhin AnsiString und AnsiChar geben. Genauso, wie es wohl WideString und WideChar weiter geben wird. Während es bisher so war, dass String gleich AnsiString ist, wird in Zukunft String gleich WideString sein.

Daniel B 23. Jun 2003 19:22

Hallo,
Zitat:

Zitat von Chewie
Aber nein, es wird weiterhin AnsiString und AnsiChar geben. Genauso, wie es wohl WideString und WideChar weiter geben wird. Während es bisher so war, dass String gleich AnsiString ist, wird in Zukunft String gleich WideString sein.

Eins ist mir aber doch nicht wirklich Klar. Ein String wird zu WideString. Also schriebt man(n) "var s: WideString;" oder doch nur String und das wird "intern" geregelt!?
Und wenn man WideString schreiben muss, wer schriebt als erster im Forum ein Tool, das alle .pas auf dem Rechner durchgeht und String in WideString umschreibt? :mrgreen: :lol:

Grüsse, Daniel :hi:

Christian Seehase 23. Jun 2003 19:25

Moin Daniel,

Du kannst heute in den Optionen einstellen, wie "string" interpretiert werden soll.
Entweder als HugeString (AnsiString, Standard) oder ShortString (Pascal String).

Künfig wird unter string standardmässige WideString verstanden, und die Optionen werden einem dann eventuell die Wahl zwischen drei Varianten lassen.

Hansa 23. Jun 2003 22:52

Zitat:

Zitat von Chewie
wird in Zukunft String gleich WideString sein.

vermutlich kommen da noch einige Compiler-Direktiven dazu und dann hats sich.

sakura 24. Jun 2003 07:07

Zitat:

Zitat von Hansa
vermutlich kommen da noch einige Compiler-Direktiven dazu und dann hats sich.

Ja und nein. Was es die Assemblies betrifft, sind die wohl alle auf WideStrings ausgelegt und dann heisst es wieder vorsicht bei der Nutzung der Assemblies. Und solange es nicht um gesicherte Daten alter Programme geht, ist es auch nicht weiter dramatisch.

...:cat:...

P.S. Ich nutze schon jetzt WideStrings :mrgreen:

neolithos 31. Jul 2003 14:13

Re: Delphi .NET Facts - was sich ändert
 
Kann mir einer sagen wie ich OHNE Zeiger
- einen Binären-Such-Baum aufbauen soll
- verkettete Listen verwalten soll
- große Variable Binär-Blöcke verwalten soll (z.B. von Bildern)


Ich denke das .NET zusätzlich wie CLX entstehen wird, denn wie soll ich sonst Windows beeinflussen.

Denn das Importieren von nicht .NET-Dll's ist nicht sauber und nicht Plattformunabhängig.


Alle Zeitangaben in WEZ +1. Es ist jetzt 15:12 Uhr.
Seite 2 von 4     12 34      

Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz