Delphi-PRAXiS
Seite 3 von 3     123   

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Object-Pascal / Delphi-Language (https://www.delphipraxis.net/32-object-pascal-delphi-language/)
-   -   Delphi Integer und Cardinal bei 32 Bit eingefroren? NativeInt? (https://www.delphipraxis.net/150014-integer-und-cardinal-bei-32-bit-eingefroren-nativeint.html)

himitsu 5. Apr 2010 20:02

Re: Integer und Cardinal bei 32 Bit eingefroren? NativeInt?
 
Zitat:

Zitat von NamenLozer
Was wird jetzt eigentlich aus der Technik z.B. Objektreferenzen in der Tag-Eigenschaft von visuellen Komponenten zu speichern? :gruebel:

Das war's dann wohl damit, also wenn .Tag und andere Integer (in SendMessage z.B., wobei da ja eh LPARAM und WPARAM genommen werden sollten) weiter als Integer (32 Bit) vorhanden sind.

Panthrax 5. Apr 2010 20:15

Re: Integer und Cardinal bei 32 Bit eingefroren? NativeInt?
 
@Implementation, wenn ein 14jähriger diese Meinung vertritt, ist das so..., allerdings ist das Zitat aus dem Zusammenhang gerissen: Es geht nicht nur um Zeiger, wenn es um die 32- oder 64-Bit-Kompilate desselben Quelltextes geht. Sondern es geht darum, dass bspw. eine Integer-Variable das ist, weshalb sie als Integer-Variable deklariert wurde: "Diese Typen sollten, wenn möglich, immer verwendet werden, da sie die optimale Ausführungsgeschwindigkeit für die zugrunde liegende CPU und das Betriebssystem gewährleisten." (Delphi-Hilfe)

Zeigeroperationen sind per se auch kein unsicherer Code. Der "Fachbegriff" "unsicherer Code" bezeichnet Code, dessen Speicherverwaltung sich der Müllabfuhr (aka "Garbage Collector") entzieht. Weil Delphi keine Müllabfuhr hat, könnte man auch Objekte dieser Kategorie zuordnen. Trotzdem werden sie verwendet, denn sie sind ein gutes, bewährtes Konzept. Genau so verhält es sich mit Zeigern.

@Alzaimar, bei Ihnen frage ich mich allerdings, ob Ihr Beitrag in Ihrem Kopf überhaupt die Moderatorenschleife durchlaufen hat!? Dass Sie das Thema nicht berührt, ist offensichtlich. Es war überflüssig, dass in einem solch feisten Beitrag zu verpacken. Im Übrigen verwendet die RTL und VCL ausgiebig den Typ Integer für Zeigerarithmetik. -- Wenn Sie die für "Frickelcode" halten? Entsprechend hohe Verbreitung hat dieses Vorgehen. Und ja, die notwendige Voraussicht, die gar nicht so weise hat sein müssen, hat man haben können. Nicht wenige haben diese auch gehabt! Zunächst war vorhersehbar, dass Speicher größer werden und Zeiger Adressen in diesem Speicher fassen können müssen. Und auch ganz praktisch sind die C-Leute schon einmal über ihre eigene Inkonsistenz gestolpert, so dass man hatte das Wort auf 2 Byte fixieren müssen. Die ursprüngliche Definition eines Wortes ist die volle Registerbreite, und ist damit das, was man in Delphi von Cardinal erwartet: Der mitwachsende, generische Datentyp. Bei der Umstellung von 16 auf 32 Bit wollte man dann aber nicht den vielen, tollen C-Quelltext ändern, und hat stattdessen das Doppelwort eingeführt. Daraus folgte wiederum, dass 16-Bit-Programme "16-Bit-Programme blieben". Delphi ist eine sehr typtreue Sprache, und es ist grotesk, wenn die wohldurchdachte Typensystematik durch externe Idiotie miniert wird.

@SirThornberry: Integer statt Cardinal zu verwenden, entstammt der Zeit, als es Cardinal noch nicht gab. Natürlich ist Cardinal semantisch besser.

An die Schnittstellen habe ich auch gedacht (*.h-Dateien, Dateiformate usw.). Meiner Ansicht nach ist es ein Fehler, etwa einen mitwachsenden Datentyp zu verwenden, wenn die Größe jedoch festgeschrieben ist. Entsprechend sollte man den Fehler korrigieren, und nicht zwangsweise den Quelltext anrühren, der zum Mitwachsen ausgelegt ist.

mkinzler 5. Apr 2010 20:18

Re: Integer und Cardinal bei 32 Bit eingefroren? NativeInt?
 
Ich finde auch das Integer mitwachsend bleiben sollte. Wer explizit 32Bit meint kann ja Cardinal verwenden.

samso 5. Apr 2010 20:23

Re: Integer und Cardinal bei 32 Bit eingefroren? NativeInt?
 
Soweit ich mich erinnere, soll die Tag-Eigenschaft auf 64 Bit erweitert werden (Delphi and the Integer data types).

SendMessage ist bei Win64 auf 64 Bit erweitert.

Zitat:

Einige Datentypen waren 32 Bit, jetzt 64 Bit
LRESULT, HANDLE, LPARAM, WPARAM, size_t, intptr_t, uintptr_t
aus
Portierung von 32Bit Applikationen auf 64Bit

Panthrax 5. Apr 2010 20:24

Re: Integer und Cardinal bei 32 Bit eingefroren? NativeInt?
 
Vielleicht noch einmal zum Versätndnis: Die Typen Integer (mit Vorzeichen) und Cardinal (ohne Vorzeichen) wurden bisher als mitwachsend propagiert. Wer feste größen benötigt kann ShortInt, SmallInt, LongInt, Word usw. verwenden.

Vom Hörensagen (Lesenschreiben :stupid: ) gibt es das Gerücht, dass Integer und Cardinal bei 32 Bit fixiert bleiben sollen.

mkinzler 5. Apr 2010 20:28

Re: Integer und Cardinal bei 32 Bit eingefroren? NativeInt?
 
Integer war bei TP und Delphi 1 16Bit. Cardinal war immer 32Bit

Panthrax 5. Apr 2010 20:33

Re: Integer und Cardinal bei 32 Bit eingefroren? NativeInt?
 
Das widerspricht sich ja nicht für die Zukunft mit der Delphi-Hilfe.

mkinzler 5. Apr 2010 20:34

Re: Integer und Cardinal bei 32 Bit eingefroren? NativeInt?
 
Allen Bauer hat allerdings für seine Pläne kräftig Gegenwind im CG Forum bekommen ud ich hoffe, das er sich diese Schnapsidee noch einmal überlegt

Panthrax 5. Apr 2010 21:19

Re: Integer und Cardinal bei 32 Bit eingefroren? NativeInt?
 
Schnapsidee, genau. Kann man den Gegenwind nachlesen? Ich habe schon ein bisschen quergelesen im Netz. Was ich so am Rande immer wieder über die C-Sachen mitbekomme, reicht auch von Verwirrung bis Widerspruch; selten, dass mal einer echte Zustimmung äußert.

mkinzler 5. Apr 2010 21:21

Re: Integer und Cardinal bei 32 Bit eingefroren? NativeInt?
 
Einen Link habe ich gerade nicht. Es gab aber den gesagten Thead im CG Forum, in dem der Zuspruch auch sehr gering war


Alle Zeitangaben in WEZ +1. Es ist jetzt 11:13 Uhr.
Seite 3 von 3     123   

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