IOHandler.ReadBytes: TIdBytes inkompatibler Typ ???

[OlafSt]

Hallo Freunde,

so langsam ist es wohl an der Zeit, meinen Job an den Nagel zu hängen und Gärtner zu werden.

Folgende, extrem simple Routine:

Delphi-Quellcode:

//Compiler ist Delphi XE4 Professional
uses
     IdBaseComponent, IdComponent, IdSocketHandle,
     IdGlobal, IdContext, IdCustomTCPServer, IdTCPServer,
     IdIOHandler;

[...]

procedure TCUD_Main.MyTCPServerExecute(AContext: TIdContext);
var
   W: Word;
   b: byte;
   Block: IdGlobal.TIdBytes;
begin
     //
     w:=AContext.Connection.IOHandler.ReadWord;
     if (w <> $4711) then
     begin
          exit;
     end;
     b:=AContext.Connection.IOHandler.ReadByte;
     Setlength(Block, b);
     Block:=AContext.Connection.IOHandler.ReadBytes(Block, b, false);
end;

Daran ist ja nun nix schlimmes. Mein XE4 mein nun in der Zeile "Block:=AContext.Conn...":

Fehler E2010 Inkompatible Typen: 'TIdBytes' und 'procedure, untyped pointer or untyped parameter' :evil:

Ctrl-Click auf ReadBytes ergibt:

Delphi-Quellcode:

procedure TIdIOHandler.ReadBytes(var VBuffer: TIdBytes; AByteCount: Integer; AAppend: Boolean = True);

Was ist denn nu schon wieder kaputt ? :cry:

[baumina]

Warum machst dus nicht einfach so wies dort steht? Einfach das Block:= weglassen.

Delphi-Quellcode:

AContext.Connection.IOHandler.ReadBytes(Block, b, false);

[OlafSt]

Okay... Das ist der Beweis, das ich echt urlaubsreif bin. Jetzt kann ich Prozeduren nicht mehr von Funktionen unterscheidem :oops:

[himitsu]

TIdBytes und TBytes sind nicht das "Selber", auch wenn sie das "Gleiche" sein mögen.

Leider ist man bei (vorallem Emba) nicht auf die geniale Idee gekommen und hat es (nicht) als TArray<Byte> deklariert. :wall:

[OlafSt]

Nunja... Wenn man sieht, wie Emba Generics compilertechnisch implementiert hat, kann ich das verstehen. Teile der VCL und natürlich Indy selbst wären in der Größe explodiert und die Größen der EXE-Dateien - ohnehin schon reichlich fett - wären noch heftiger geworden.

Ich frage mich, wie Microsoft in C# / VB.NET die Sache mit den Generics gelöst hat. Code wird jedenfalls nicht dupliziert.

[Der schöne Günther]

Ich kenne mich technisch so weit unten nicht aus, aber ich glaube Delphi ist technisch wesentlich näher an dem dran was man in C++ als Templates kennt. Da wird der Code auch dupliziert, aber in den Toolsets sind die Linker so schlau das wieder zu 99% herauszukürzen. Delphi ist da wohl noch nicht so weit.

Wie Generics in JIT-Sprachen wie Java oder .NET implementiert sind habe ich ehrlich gesagt keine Ahnung.

[Sir Rufo]

Zitat:

Zitat von OlafSt (Beitrag 1314549)

Ich frage mich, wie Microsoft in C# / VB.NET die Sache mit den Generics gelöst hat. Code wird jedenfalls nicht dupliziert.

Woher willst du das wissen? Was schaust du dir an, um das zu beurteilen? Die erzeugte EXE?

Wie das dort umgesetzt ist, kann ich auch nicht sagen, aber ich weiß, dass dieser erzeugte Code vor der Ausführung nochmals compiliert wird (JIT wie Günther schon geschrieben hat). Dieses müsste man sich konkret anschauen um eine zuverlässige Aussage treffen zu können. ;)

[frankyboy1974]

Hallo,

in Java wird der Code zuerst in einen Bytecode übersetzt, und erst zur Laufzeit dann in Maschinensprache schlussübersetzt (ob nun JIT oder nicht), ich habe zwar noch nie eine Java-VM programmiert, kann mir aber kaum vorstellen, dass es schneller geht, erst zu überprüfen ob bereits eine ähnliche Prommierlogik bereits übersetzt wurden ist oder es direkt in Maschinensprache zu übersetzen. Also ich würde davon ausgehen, dass eine Java-VM, durchaus Code dupliziert wieder gibt.

mfg

[mkinzler]

Java/.Net verwendet Hotspot/JIT. So können grundsätzlich Entscheidungen in Folge von vorigen Läufen getroffen werden.
Zunehmend findet auch AOT-Kompilierung statt (z.B. ART).