Datentyp WORD und Operation "+ ?L"
-
3L ist eine long-Litaral mit dem Wert 3 (im Gegensatz dazu ist 3 ein intLiteral - der Unterschied ist zwar minimal, aber in einigen Anwendungsfällen doch bedeutsam ;)).
-
Danke für die vielen Antworten
Hätte gleich noch eine Frage für euch:
Ein WORD sind doch 2 Byte, damit ähnelt es doch einem unsigned short (bzw. ist gleich). Warum wird dann trotzdem WORD verwendet und nicht unsigned short? Ich vermute wegen der Performance...aber stimmt das auch?
-
Hallo
WORD ist doch nur ein typedef für unsigned short.
chrische
-
krüml schrieb:
Warum wird dann trotzdem WORD verwendet und nicht unsigned short?
Weil irgendein MS-Programmierer der Meinung war, daß die Bezeichnung 'unsigned short' nicht aussagekräftig genug ist
-
Oder weil irgendein MS-Programmierer der Meinung war, es sei eine gute Idee dafür zu sorgen, dass man falls die Größe von short sich ändert nur ein typedef ändern muss, damit WORD weiterhin zwei Byte lang ist.
-
Hallo
Und nicht zu vergessen auch noch die Notwendigkeit die WinAPI von den Bezeichnungen her sprachneutral zu machen. Ein unsigned char mag es vom Namen her in C++ geben, in anderen Sprachen eben nicht. Deshalb war es notwendig Metanamen zu definieren, die für jede Sprache dann interpretiert werden.
bis bald
akari
-
krüml schrieb:
Ein WORD sind doch 2 Byte, damit ähnelt es doch einem unsigned short (bzw. ist gleich). Warum wird dann trotzdem WORD verwendet und nicht unsigned short?
Weil WORD eben nicht das gleiche ist. WORD ist ein WinAPI Datentyp, der als vorzeichenlose 16 Bit Ganzzahl definiert ist. unsigned short ist hingegen ein Standard Datentyp, dessen genaue Grösse nicht festgelegt ist. Unter Win32 entspricht der Typ zufälligerweise der Definition von WORD, mehr aber auch nicht.
-
akari schrieb:
Und nicht zu vergessen auch noch die Notwendigkeit die WinAPI von den Bezeichnungen her sprachneutral zu machen.
unsinn, welche sprache schluckt denn windows codes ausser C und C++?
-
Hallo
Es geht nicht konkrete Implementationen, sondern um das Interface der WinAPI. Und selbstverstandlich kann man die WinAPI auch zum Beispiel von Delphi aus verwenden.
bis bald
akari
-
akari schrieb:
Und selbstverstandlich kann man die WinAPI auch zum Beispiel von Delphi aus verwenden.
okay, aber das ist kein verdienst der winapi.
delphi kann C-funktionen aufrufen, wie jede sprache das können muss, in der winapi-aufrufe möglich sind.
-
Hallo
Und was sind "C-Funktionen"? Doch nur der kleinste gemeinsame Nenner aller imperativen Sprachen. Es ist möglich eine DLL in Delphi zu schreiben und in einem VB-Programm zu benutzen. Alles über die Vorgaben der WinAPI und des PE-Formats. Aber wo ist da echtes C? Wohl nur in der WinAPI-Funktion LoadLibrary und Konsorten.
bis bald
akari
-
na gut
ich hätte besser schreiben sollen "mit einem C compiler übersetzte und zum PE-format gelinkte funktionen".
damit man die z.b. von C++ aufrufen kann gibts 'extern "C" void __stdcall f()'
vb hat dafür sowas kompliziertes wie
'Declare Function blablubb Lib "kernel32" Alias "blubbdiblubb" (ByVal XXX As String) As Long
delphi hat sicher auch irgendwie sowas ähnliches.
also 'einfach so' geht's nicht...
-
Hallo
Solche Import-Anweisungen müßen grundsätzlich in jeder Sprache angelegt werden. Da viele DLLs in C/C++ geschrieben sind gibts meistens auch gleich einen Header dazu, wo genau diese Import-Anweisungen schon rausgezogen werden können.
Wenn du aber einfach eine DLL ohne C-Header hast, must du auch in C manuell Import-Anweisungen schreiben (egal ob statisch oder dynamisch). Und die sehen nur nur etwas anders aus als die von Basic oder Co.bis bald
akari
-
akari schrieb:
Wenn du aber einfach eine DLL ohne C-Header hast, must du auch in C manuell Import-Anweisungen schreiben (egal ob statisch oder dynamisch). Und die sehen nur nur etwas anders aus als die von Basic oder Co.
das stimmt, aber weil winapi aus einem haufen C-funktionen besteht, ist diese import-syntax in C nicht halbwegs so eigenartig als in anderen sprachen.