![]() |
pointer
mal ne ganz simple frage ...
überall hört man was von pointern ... doch ich hab keine ahnung für was man die brauchen könnte, ich bin bis jetzt immmer ohne denen ausgekommen |
Re: pointer
Da hast Du aber ganz doll Glück gehabt... :mrgreen:
|
Re: pointer
wieso das denn ...?
ist das wirklich so kompliziert wie man so hört ...? diese pointer müssen doch für irgendwas gut sein? |
Re: pointer
|
Re: pointer
thx ...
also hab ich das richtig verstanden: wenn ich mit pointern auf einen speicherplatz zugreifen kann, dann kann ich mit nen pointer auch auf einen Datentyp char als byte zugreifen ...? das wäre dann für die speicherung von farben in rgb relativ praktisch :-D |
Re: pointer
Delphi-Quellcode:
das funktioniert aber nicht ...
function ColorToString(s: String):TColor;
var R,G,B: ^Byte; begin R:=s[1]; G:=s[2]; B:=s[3]; ColorToString:=RGB(R,G,B); end; :wall: naja, ich glaub das mit den pointern hab ich noch nicht ganz verstanden |
Re: pointer
hi,
in jeder objekorientierten Entwicklung arbeitest du dauernd mit pointern, hinter jedem form1, edit2 button5 steckt ein Pointer auf den Speicherplatz, an dem dann wirklich die Datenstruktur steht. Der Entwickler muß sich nicht wirklich dauernd datum kümmern, sollte aber wissen, was er tut, um korrekte Designentscheidungen treffen zu können. Wenn du ohne untypisierte Pointer, also die dinger die du explizit dereferenzieren mußt ausgekommen bist, dann gewöhns dir auch nicht erst an, die Dinger sind zu recht verpönt, und sterben in moderen Entwicklungsumgebungen wie Java und .Net aus, bzw es gibt sie dort gar nicht, oder sie werden zumindest bei jeder verwendung als "unsafe" vom Compiler angemeckert. Grüsse Woki |
Re: pointer
Bei einem so strengen Typing wie in Pascal kommt man ohne untpyisierte Pointer aber leider nicht aus, so z.B. bei HAFs Problem:
Delphi-Quellcode:
Also, HAF: Erst dereferenzieren, dann datentypunanbhängig machen, referenzieren und zu Byte casten.
r := Byte(Pointer(@s[1])^);
g := Byte(Pointer(@s[2])^); b := Byte(Pointer(@s[3])^); Speziell für dieses Problem wäre aber viel sinnvoller:
Delphi-Quellcode:
Ich nehme aber an, dass Ord() intern so gelöst ist, wie ich das im ersten Codebeispiel gezeigt habe (vielleicht ist es aber auch uner Verwendung des Inline-Assemblers gemacht worden).
r := Ord(s[1]);
g := Ord(s[2]); b := Ord(s[3]); |
Re: pointer
Man kommt.
Aus drei Bytewerten für R und G und B einen TColor zu machen, das geht auch ohne Pointer. Außerdem ist das gleich ein Beispiel, wie zu den merkwürdigsten Fehlern kommt. Ein TColor belegt nämlich vier Byte, und dann drei davon irgendwo in den Speicher legen, und dann dem Compiler sagen, dies sei ein TColor, dürfte zu merkwürdigsten und unreproduzierbaren Problemen führen. Manchmal gibt es eine falsche Farbe, manchmal eine Zugriffsverletzung... Verwendet man dagegen die vorgesehen Convertierungsfunktionen, hat der Compiler eine Chance, fehler zu verhindern. Grüsse Woki |
Re: pointer
Eigentlich sind Pointer ganz einfach. Heimlich sind sie dir schon begegnet. "var" wird naemlich mit ihnen implementiert.
Ein Pointer ist eine Referenz. Er zeigt auf etwas. Eine Adresse ist eine Referenz. Also ist ein Pointer eine Adresse. Eine Pointer-Variable ist also eine Variable deren Wert ein Pointer sprich eine Adresse ist. Nun kann man natuerlich einen Pointer auf eine Pointer-Variable haben usw usf. Referenzieren heisst die Adresse einer Variablen bilden (nur Variablen koenen Adressen haben). Dereferenzieren heisst von einer Adresse zur Variablen gehen. |
Alle Zeitangaben in WEZ +1. Es ist jetzt 09:25 Uhr. |
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