Falsch/Inkonsistent definierte Win32Api Funktionen in Winapi.Windows

[Der schöne Günther]

Dass die Parameter als var x: TIrgendeinTyp statt const x: PIrgendeinTyp deklariert werden sehe ich in der WinApi ständig. Nervt mich auch, ich verstehe den Sinn dahinter nicht.

Anscheinend hatte man da mal eine Phase wo man den Benutzer (Programmierer) unter allen Umständen von Pointern fernhalten wollte.

[jaenicke]

Daraus var-Parameter zu machen finde ich schon sehr angenehm, allerdings finde ich es nicht gut, diese ohne Typ zu deklarieren...

In XE8 sieht die Deklaration aber korrekt aus:

Zitat:

Delphi-Quellcode:

  GetDiskFreeSpaceEx: function (Directory: PChar; var FreeAvailable,
    TotalSpace: TLargeInteger; TotalFree: PLargeInteger): Bool stdcall = nil;

Dass man dort so nicht nil übergeben kann, ist sicher richtig. Aber das dürfte wohl in der Mehrheit der Fälle nicht wichtig sein...

// EDIT:
Ich sehe grad, dass es die Funktion zweimal gibt. Einmal in Winapi.Windows und einmal in System.SysUtils.
In der SysUtils sieht sie aus wie ich es gepostet habe...

[mensch72]

"var x: TIrgendeinTyp" nervt nicht nur, es verhindert auch das man da gezielt mal "nil" übergeben kann...

-> NIL/NULL als Parameter ist bei vielen WinApi Funktionen für Pointer erlaubt und hat da funktionsabhängig auch durchaus sinnvolle Bedeutungen und Sonderfunktionsfälle, welche einem per "var" in Delphi versperrt werden.

[SMO]

Zitat von mensch72:

"var x: TIrgendeinTyp" nervt nicht nur, es verhindert auch das man da gezielt mal "nil" übergeben kann...

-> NIL/NULL als Parameter ist bei vielen WinApi Funktionen für Pointer erlaubt und hat da funktionsabhängig auch durchaus sinnvolle Bedeutungen und Sonderfunktionsfälle, welche einem per "var" in Delphi versperrt werden.

Verhindert und versperrt wird da gar nichts. Wo ein Wille ist, ist auch ein Weg:

GetDiskFreeSpaceEx('C:\', PLargeInteger(nil)^, PLargeInteger(nil)^, nil);

[Sir Rufo]

Zitat von SMO:

GetDiskFreeSpaceEx('C:\', PLargeInteger(nil)^, PLargeInteger(nil)^, nil);

3 Parameter vom Type PLargeInteger wo man auf unterschiedliche Arten den Wert nil übergeben muss - obwohl die laut Api komplett gleich deklariert sind.

Kleines Schmankerl (was aber nicht so ganz tragisch ist):
In der Api ist das statt einem PLARGE_INTEGER ein PULARGE_INTEGER. Gut dass es sich hier nur um das Vorzeichen handelt.

[p80286]

Large_Integer ist zwar ganz schön viel, aber ULarge_Ineger ist wohl ein wenig mehr. Und irgendwann gibt es wieder Jemanden, der weint, meine Festplatte ist kaputt, da kommen nur noch negative Werte.

Gruß
K-H

[frankyboy1974]

Hallo,

vielleicht gibt es bei Emba mehr als einen Entwickler, der nun einen Kompromiss finden musste, zwischen Windows-Api und Delphi-Programmierung. In der Theorie sind die Dinge oft einfach, in der Praxis dagegen nicht so sehr. Ich kann mich daran erinnern, auch schon öfter die C-Nomenklatur nach Delphi zu übertragen, am Ende muss es funktionieren, aber nicht unbedingt schön sein. Auch bei Emba sitzen Menschen die sich aufs Wochenende freuen.

mfg

frank

[Luckie]

Na ja, die WinAPi ist ja schon selber nicht konsistent. Man gucke such nur mal GetUserName und GetComputerName an mit den vertauschten Parameter. Liegt aber daran, dass die Fzunktionen von unterschiedlichen Abteilungen implementiert wurden. Die eine wohl von der Kernel Abteilung und die andere von einer anderen Abteilung.

Was ich aber sagen will, wie willst was konsistent bekommen, was as designed schon inkonsistent ist?

[Sunec]

Es ist nicht nur die Winapi.Windows. Auch Funktionen der Winapi.D2D1 wurden absichtlich falsch implementiert.


Habe diesbezüglich auch hier einen Thread:

http://www.delphipraxis.net/185925-d...ml#post1311751