Pointer in unsafe code eriner VCL.Net-Anwendung

[Luke1410]

Beim Versuch folgenden VCL.Net Code mit Delphi 2005 zu compilieren bekomme ich in der markierten Zeile diesen Compilerfehler:[Error] Unit1.pas(34): E2307 NEW standard function expects a dynamic array type identifier

Delphi-Quellcode:

unit Unit1;

interface

uses
  Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
  Dialogs;
{$UNSAFECODE ON}
type
  TForm1 = class(TForm)
    procedure FormCreate(Sender: TObject); unsafe;
  private
    { Private declarations }
  public
    { Public declarations }
  end;

  pTest = ^tTest;
  tTest = record
     value1 : integer;
  end;

var
  Form1: TForm1;

implementation

{$R *.nfm}

procedure TForm1.FormCreate(Sender: TObject); unsafe;
var
   test : pTest;
begin
   test := new(tTest); // <- Zeile 34
end;

end.

Kann mir jmd auf die Sprünge helfen, was ich falsch mache?

[Zettuu]

Ich denke beim new sollte man einen Pointer angeben. In diesem Fall ptest.

[Luke1410]

Zitat:

Zitat von Zettuu

Ich denke beim new sollte man einen Pointer angeben. In diesem Fall ptest.

Das ist es leider nicht.
Egal, ob ich

new(test)
new(pTest)
new(^tTest)
new(tTest)

aufrufe, die Fehlermeldung bleibt die gleiche.

[barf00s]

dann mach den ganzen unsafe quark weg und benutz ne klasse

TTest = class
end;


var
xTest: TTest;


begin
xTest := TTest.Create;
...
FreeAndNil(xTest);
end;

wenn du schon .NET benutzt brauchst auch kein code der eventuell "unsafe" wäre

[barf00s]

btw erfolgt der aufruf von new nich über

var
x: PTest;

begin
x := New(PTest);
end;


sondern

New(x);

[Luke1410]

@new Aufruf: Hatte ich bereits versucht, ging aber auch nicht (siehe weiter oben).

Auf unsafed code zu verzichten würde das Problem sicherlich umgehen, ist in meinem Fall aber nicht möglich.

Es muss doch jemanden geben der schonmal den new-Aufruf in einer VCL.Net-Anwendung verwendet hat und mir sagen kann wo mein (Denk-)Fehler liegt.

[barf00s]

ich hab gedacht du verwendest New() so hier

t := new(ttest);
t := new(ptest);
t := new(^ttest);
...

New is ne Prozedur ...

andnernfalls könntest dus mal mit

var
x: PTest;

begin
GetMem(x, SizeOf(TTest));
...
FreeMem(x, SizeOf(TTest));
end;

versuchen.....

[jbg]

Zitat:

Zitat von Luke1410

mir sagen kann wo mein (Denk-)Fehler liegt.

Ganz einfach: New hat unter Delphi.NET eine andere Bedeutung als es die unter Win32 hat.
Ein New in Delphi.NET entspricht einem SetLength(dynArray, Dimension1 [, Dimension2, ...]);

Delphi-Quellcode:

var
  d: array of string;
begin
  New(d, 10);
  d[9] := 'Hallo';
end;

[Robert_G]

Was du da machst ist IMHO komplett "sinnbefreit".
Entweder managed mit max. ein paar P/Invokes, oder native.
Was versprichst du dir denn von einem VCL.Net.Win32.whatever - Cocktail? :gruebel:

btw: Value types (wie es ein record nunmal ist) sind in .Net nur dumme value types...
Die werden (fast) immer kopiert und sie dürfen auch nie nil sein.
Wenn du das (aus welchen Gründen auch immer) haben willst ist .Net die falsche Plattform...

*kopf schüttel*

[Luke1410]

@barf00s: Dachte GetMem und FreeMem wären komplett aus der VCL entfernt worden. Zumindest hab ich im Netz auf mehreren Seiten gelesen, dass eben diese Aufrufe durch entsprechende Aufrufe von new() und dispose() ersetzt werden sollten. Oder verwechsel ich da jetzt was???

@jbg: Thx, das erklärt schonmal die Fehlermeldung. Aber wie soll ich dann diesen alten Win32-Aufruf ersetzen? Oder geht das überhaupt nicht? Dann wär's doch aber recht sinnlos, Pointer weiterhin in unsafed code zu erlauben, wenn man gar keinen Speicher mehr reservieren kann.

@Robert_G: Was ich mir davon verspreche ist recht einfach erklärt: Ein vorhandenes größeres Win32-Projekt mit weniger als 6 Monaten arbeitsaufwand in ein .Net Projekt zu migrieren um dadurch die Sicherheitsfeatures von .net verwenden zu können und die Möglichkeit zu haben, Code auch in anderen Programmiersprachen einfach einzubinden inkl. der Nutzung der .Net-Assembly-Verwaltungsstruktur mit der Möglichkeit den Code später in safed Code zu konvertieren und in einem 3. Schritt dann in eine WinForms.Net-Anwendung umzuwandeln.

Sry, dass ich das nicht schon vorher geschrieben habe, aber bin eher der Auffassung nur das in Posts zu schreiben, was auch wichtig zur Lösung eines Problems ist und die Community nicht mit sinnlosen großen Codefragmenten vollzusammen und Romane über das Wieso und Warum zu schreiben (zumind. nicht, wenn man eine Lösung eines einfach zu beschreibenden Problems sucht :) ).

[barf00s]

was hat das mit VCL zu tun?

VCL = VISUAL COMPONENT LIBRARY

[edit]
weil ich grad das wort "migrieren" les ...
DANN solltest du auch von linkedlists records mit fiesen pointern ;) (oder was auch immer das da sein soll bei dir) auf classes umstellen, dann schreibst auch sicheren .NET code und musst nicht mit unsafe kram rumgurken - was ja wieder dem .NET dings (eigentlich) wiederspricht

[Robert_G]

Mit der VCL.Net kannst du schon aus Prinzip nicht auf CAS zurückgreifen. Das Ding ist doch fast nur Win32...
Kommt mir jetzt *bitte* nicht damit, dass auch SWF P/I nutzt. SWF kann das, als trusted Asssembly, durch Internalcalls und somit ohne CAS zu sehr einzuschränken.

Nach dem 3. Schritt hast du CAS. ;) Und wenn es SWF aus .Net 2.0 ist dürfte Avalon auch nicht mehr so weh tun. ;)

[Luke1410]

@barf00s:
k, vertan, forget it :) VCL -> .Net-Umsetzung, dann stimmt der Satz wieder :)

Wie schon im letzten Post (ganz unten) beschrieben, fällt safed code erstmal flach (sofern es anders machbar ist), weil einfach zu aufwendig.

@Robert_G: Okok, schieben wir den Vorteil, CAS verwenden zu können ans Ende der Liste. Ändert leider nichts daran, dass zuerst unsafe code erstellt werden sollte.

[barf00s]

das klingt irgendwie komisch -

als ob DICH jemand zwinkt erst son dummfug zu produzieren, der dann sowieso NOCHEINMAL umgestellt wird?


Win32 -> unsafe blah -> pures .NET

sehr merkwürdig

[Robert_G]

Zitat:

Zitat von barf00s

als ob DICH jemand zwinkt erst son dummfug zu produzieren, der dann sowieso NOCHEINMAL umgestellt wird?
Win32 -> unsafe blah -> pures .NET

Ist gar nicht dumm. ;)
Ich denke mal, er will während des Portierens weiterhin kompilieren können. So kann seine App zu einer .Net App "reifen".

[Luke1410]

Jo, genau so sollte es sein.

Btw. ist das Problem weiterhin ungelöst... Werde wohl zwangsweise wirklich zu Klassen wechseln.
Nur kann ich immer noch nicht glauben, dass ich der einzige sein soll, der sich mit diesem Problem rumschlägt...

[Robert_G]

Zitat:

Zitat von Luke1410

Jo, genau so sollte es sein.
Btw. ist das Problem weiterhin ungelöst... Werde wohl zwangsweise wirklich zu Klassen wechseln.

:thuimb:
Die IMHO einzige, saubere Lösung für einen PBloodyRecord wäre eine TNiceClass. ;) (Wobei man auf lange Sicht die T-Prefixe über board werfen sollte, sieht einfach "falsch" aus in .Net :zwinker: )

Zitat:

Zitat von Luke1410

Nur kann ich immer noch nicht glauben, dass ich der einzige sein soll, der sich mit diesem Problem rumschlägt...

Ich selbst sehe keinen Grund für die Verwendung von Zeiger auf Records. Klassen sind genau dafür da. In .Net wirst du sogar dazu gezwungen, da value types immer per "Assignment by Copy" gehandhabt werden.
Das werden viele eingesehen haben und deshalb gar nicht mit dem Problem zu kämpfen gehabt haben. ;)