FreeMem D2009 und FastMM

[EWeiss]

Zitat:

Das ist doch richtig so?

Vielleicht denke ich in einer anderen Perspektive..

Bei D2006 wäre es Richtig wenn man
function CopyFileA; external kernel32 name 'CopyFileA'; verwenden würde
function CopyFileW; external kernel32 name 'CopyFileW'; und dieses um Unicode zeichen darzustellen.


function CopyFile; external kernel32 name 'CopyFileW'; wäre dann total überflüssig.

Meine Meinung..
Die Funktionen sind so definiert Doppelt gemoppelt.
Ein cast von einem cast.

So kannst du auch nicht sagen!

Zitat:

CopyFile wäre eh falsch, denn dieses will einen PChar.

Denn es erwartet kein PChar sondern ein PWideChar.
Wäre also beides richtig, wohlgemerkt unter D2009 nicht unter D2006


gruss

[himitsu]

Funktioniert überall und in jedem Delphi und nutzt das, was man standardmäßig in der VCL vorfindet:

Delphi-Quellcode:

procedure Kopieren(Src, Dest: String);
begin
  CopyFile(PChar(Src), PChar(Dest));
end;

CopyFile(PChar(SrcEdit.Text), PChar(DestEdit.Text));

Das ist dagegen überall ANSI und genauso geht es mit dem Unicode,
egal ob Delphi 7 oder Delphi XE:

Delphi-Quellcode:

procedure Kopieren(Src, Dest: AnsiString);
begin
  CopyFileA(PAnsiChar(Src), PAnsiChar(Dest));
end;

[EWeiss]

Zitat:

Zitat von himitsu (Beitrag 1098116)

Funktioniert überall und in jedem Delphi und nutzt das, was man standardmäßig in der VCL vorfindet:

Delphi-Quellcode:

procedure Kopieren(Src, Dest: String);
begin
  CopyFile(PChar(Src), PChar(Dest));
end;

CopyFile(PChar(SrcEdit.Text), PChar(DestEdit.Text));

Das ist dagegen überall ANSI und genauso geht es mit dem Unicode,
egal ob Delphi 7 oder Delphi XE:

Delphi-Quellcode:

procedure Kopieren(Src, Dest: AnsiString);
begin
  CopyFileA(PAnsiChar(Src), PAnsiChar(Dest));
end;

Jo ;)
Und Danke für deine Ausführungen.

gruss

[Bernhard Geyer]

Zitat:

Zitat von EWeiss (Beitrag 1098109)

Und genau das ist der Müll den Embagardo oder wer auch immer verzapft hat.

Ist m.E. eine sehr gute Idee das so zu machen.

Zitat:

Zitat von himitsu (Beitrag 1098112)

Genau das Gleiche ist mit dem Integer und LongInt,
wobei hier wirklich jemand mist gebaut hat und urplötzlich, beim Umstieg von 32 auf 64 Bit den Integer eingefrohren hat. :wall:

Sun (Java), MS (.NET, Win64). Es wäre m.E. unpraktisch gewesen wenn man nur wegen "bisher ist Size(Int) = Size(Pointer)" das in D64-Bit gemacht hätte obwohl der Rest der Programmierwelt das nicht so macht.

[himitsu]

@Bernhard Geyer:
Ist schon irgendwie klar.

Wobei man das dann als ein Alleinstellunsmerkmal für Delphi hätte werten können.
In der Werbung hieße es dann "Alle anderen machen Mist und nur wir machen es richtig, so wie es früher mal geplant war." :stupid:

[Bernhard Geyer]

Zitat:

Zitat von himitsu (Beitrag 1098192)

Wobei man das dann als ein Alleinstellunsmerkmal für Delphi hätte werten können.
In der Werbung hieße es dann "Alle anderen machen Mist und nur wir machen es richtig, so wie es früher mal geplant war." :stupid:

Und man darf das fluchen Anfangen sobald man irgendwelche C-Header portieren darf bzw. definiert sich dort sein eigenes Int32_64 damit man nicht zig IFDEF's benötigt.

[himitsu]

Wieso?
In C heißen die Typen doch eh alle anders, da braucht man dann nur int und Co. nach LongInt zu übersetzen, anstatt nach Integer. :angle2:

[jbg]

Zitat:

Zitat von himitsu (Beitrag 1098220)

In C heißen die Typen doch eh alle anders

Hast du dir schon mal dir WinAPI Header Dateien angeschaut? Da kommt eine Menge "int" als Parametertyp vor.

Das fängt schon beim CreateWindowEx an.

Code:

HWND WINAPI CreateWindowEx(
  __in      DWORD dwExStyle,
  __in_opt  LPCTSTR lpClassName,
  __in_opt  LPCTSTR lpWindowName,
  __in      DWORD dwStyle,
  __in      int x,
  __in      int y,
  __in      int nWidth,
  __in      int nHeight,
  __in_opt  HWND hWndParent,
  __in_opt  HMENU hMenu,
  __in_opt  HINSTANCE hInstance,
  __in_opt  LPVOID lpParam
);