Guter Programmierstil?

ghorst

lolz_ausgeloggt schrieb:

Diese großen Funktionen der WinAPI sind oftmals sehr mühsam in der Verwendung, aber die WinAPI ist die Schnittstelle zum System, sie muss nicht nur die 99% der Anforderungen abdecken sondern nahezu 100%, also auch Randfälle und deshalb sind die Funktionen so flexibel gehalten.

diese flexibilität kann man auf zwei weisen erreichen. die variante, wie sie etwa in der win32-api gewählt wurde, nämlich abgeschlossene funktionen zu schaffen, die über alle möglichen und nötigen parameter gefüttert werden oder wie es bspw in posix getan wurde, eine interaktion zwischen den einzelnen funktionen zu ermöglichen und so die einzelnen funktionen überschaubar zu halten.
das hier schon erwähnte CreateProcess vs. fork+anhang ist aus meiner sicht der klassische unterschied zwischen ansätze. CreateProcess kann schlicht alles und man muss auch alles machen (und wenn es nur ist, zu sagen, dass es doch bitte genauso haben will, wie bisher.). fork kann eigentlich erstmal nicht viel. man kann dann aber die dinge, die einen in dem speziellen fall tatsächlich interessieren sehr einfach nach dem fork lösen und muss auch nur das machen, was einen interessiert.
ich denke, die posix-variante zur prozesserzeugung ist günstiger, da sie die normalen anwendungsfälle erleichtert, die etwas seltsameren nicht unmöglich macht und vor allem flexibel angepasst werden kann (bald vierzig jahre die gleiche grund-api, aber immer sinnvoll angepasst worden...).

lolz_ausgeloggt schrieb:

Viele der Defines müssten wirklich nicht sein, aber auch da muss man bedenken wie lange es die WinAPI schon gibt.

man kann defines auch so wählen, dass sie einem nicht ständig auf die füße fallen. siehe posix und dessen ursprünge sind _deutlich_ älter...

edit: bevor jemand schreit: ich weiß, dass die winapi deutlich umfangreicher ist als posix. ich habe nur jetzt posix verwendet, um mal zu zeigen, dass sauberes design auch nach jahren noch ohne große nebenwirkungen und altlasten leben kann.

hustbaer

Mich stören bei der WinAPI z.B. Dinge die "mal so mal so" gehandhabt werden. Manche Funktionen die ein HANDLE zurückgeben verwenden 0 als "Fehlerwert" (z.B. CreateMutex), andere wieder INVALID_HANDLE_VALUE (z.B. CreateFile). Oder Funktionen die ein HANDLE zurückliefern welches zwar "HANDLE" heisst aber nicht mit CloseHandle sondern z.B. mit FindClose zuzumachen ist.

Was auch lästig ist sind diverse structs die in bestimmten Windows Versionen erweitert wurden, von denen es aber nur eine Version in windows.h gibt. z.B. RASDIALPARAMS - wenn man WINVER >= 0x401 definiert bekommt man eine Version, bei WINVER < 0x401 eine andere. Beide heissen aber RASDIALPARAMS - da wäre es praktischer einfach eine RASDIALPARAMS_EX oder ähnliches zu haben.

Oder die ganzen Funktionen die einen Zeiger auf einen Puffer + die Länge des Puffers als Parameter nehmen, allerdings nur "puffer zu klein" als Fehler zurückliefern. Das zwingt einen häufig dazu retry-loops zu basteln die die Puffergrösse dann immer schön verdoppeln und nochmal probieren - sehr sehr lästig. Hier wäre es IMO vernünftiger entweder gleich das OS den Puffer anfordern zu lassen, oder wenigstens die Funktion so zu machen dass man die nötige Grösse des Puffers irgendwie rausbekommt ohne rumzuprobieren.

Und natürlich die ganzen defines als #define LoadImage LoadImageA. Wenn man selbst "Pascal Case" für seine Funktionen verwendet bekommt man da auch recht schnell Probleme; vor allem wenn man Libs/DLLs bastelt die solche Namen enthalten, und von Programmen verwendet werden können, unabhängig davon ob das Programm mit MBCS oder UNICODE compiliert wurde. Dann muss man entweder #undef verwenden, oder seine eigene Funktion namens "LoadImage" irgendwie umbenennen.

windows-freak schrieb:

* Auf Compiler-Extensions verzichten und sich so weit es geht an den Standard halten.

ist bei plattformabhängigem code wie winapi nicht wichtig.

Naja, das sehe ich etwas anders. Genau das zwingt Compiler-Hersteller wie Intel dazu selbst die gleichen beknackten Compiler-Extensions zu implementieren wie sie im MSVC drinnen sind, bzw. führt dazu dass der MinGW Port des gcc eigene Headers mitliefern muss. Genau das führt auch dazu dass man windows.h nichtmehr inkludieren kann sobald man beim MSVC die Extensions ausschaltet.

hustenbär, gute kritkpunkte^^