Global macht man am besten keine Variablen.

Irgendwer hat immer eine Antwort

2. Variablen nennt man so dass man anhand des Namens und mit minimalen kenntnissten der Domäne oder des speziellen Programms weiss was sie beinhalten

Weil's noch keiner gesagt hat: Funktionen und Klassen sollte man auch so benennen (also aussagekräftig genug aber nicht zu lang).

Was den Weg dahin betrifft: Stöber öfter mal hier im Forum herum, tausche dich aus, veröffentliche Code und ernte Kritik und Übung macht den Meister

Benutze die ungarische Notation und Design wie in der WinAPI, dann behälst du den Überblick (die WinAPI ist ja rießig, d.h. die Entwickler wissen schon wie man so ein rießiges Projekt in C übersichtlich gestaltet).

das soll wohl ein 153 Seiten Thread werden

d.h. die Entwickler wissen schon wie man so ein rießiges Projekt in C übersichtlich gestaltet

ja, gar nicht. Die WinAPI ist alles andere als übersichtlich.

Wenn die WinAPI so geil designed wäre... Warum wurde sie dann nicht konsequent weiterentwicklet? Warum haben wir keine WinAPI 2.0, 3.0 etc gesehen?

Ich denke eher das die WinAPI ein einziges Chaos ist softwaretechnisch und sich daher keiner bei MS mehr da rantraut. Zu groß, um es from Scratch neu zu schreiben, zu chaotisch um es weiterzuentwicklen. Also werden immer neue Wrapper um WinAPI herumgebaut. (Mfc, Forms etc)

Ich denke eher das die WinAPI ein einziges Chaos ist softwaretechnisch und sich daher keiner bei MS mehr da rantraut. Zu groß, um es from Scratch neu zu schreiben, zu chaotisch um es weiterzuentwicklen.

Genau. Die WinAPI wurde für Vista auch garnicht weiterentwickelt, weil die sich da ja nicht ran trauen. Wie willst du die bitte neu schreiben? Tausende von Programmen bauen darauf auf und würden nicht mehr Funktionieren, wenn du die WinAPI änderst.

Aber ein Designvorbild ist sie trotzdem nicht.

Aber ein Designvorbild ist sie trotzdem nicht.

was würdet ihr denn anders machen?

pfollprovi schrieb:

Aber ein Designvorbild ist sie trotzdem nicht.

was würdet ihr denn anders machen?

alles die winapi ist grausam

alles die winapi ist grausam

das sagen viele. aber was er konkret verbessern würde, weiss keiner.

kernel32.dll-freak schrieb:

thordk schrieb:

alles die winapi ist grausam

das sagen viele. aber was er konkret verbessern würde, weiss keiner.

Zum Beispiel die Benennung.

chrische

Zum Beispiel die Benennung.

ja? und wie?
zeig's dich mal an hand eines beispiels.
nehmen wir zum beispiel CreateProcess: http://msdn2.microsoft.com/en-us/library/ms682425(VS.85).aspx
deine vorschläge bitte...

thordk schrieb:

alles die winapi ist grausam

das sagen viele. aber was er konkret verbessern würde, weiss keiner.

* Kleine spezifische Funktionen mit wenig Parametern schreiben.
* Eindeutige und verständliche Namen wählen.
* typedef gegenüber #define vorziehen.
* Wenn schon C, dann wenigstens Pseudo-Namespaces, wenn man eine Bibliothek schreibt.
* Kleine spezifische Header im Gegensatz zu einem großen Blob-Header.
* Die Einbindung von Headern sollte unabhängig von der Reihenfolge funktionieren.
* Auf Compiler-Extensions verzichten und sich so weit es geht an den Standard halten.

btw.
http://www.tilander.org/aurora/2008/01/include-windowsh.html

refactoring-freak schrieb:

chrische5 schrieb:

Zum Beispiel die Benennung.

ja? und wie?
zeig's dich mal an hand eines beispiels.
nehmen wir zum beispiel CreateProcess: http://msdn2.microsoft.com/en-us/library/ms682425(VS.85).aspx
deine vorschläge bitte...

Weg mit der UN. da gibt es aber wirklich 1000m Threads zu, also lass uns keinen neuen starten.

chrische

Weg mit der UN.

einverstanden. das ist wirklich doof.

@rüdi

* Kleine spezifische Funktionen mit wenig Parametern schreiben.

macht man am anfang so. später stellt sich heraus, dass man immer wieder 5 dieser funktionen in der selben reihenfolge aufrufen muss. also macht man sich eine grosse, die u.u. auch mehr parameter hat.

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

ist bei plattformabhängigem code wie winapi nicht wichtig.

* Kleine spezifische Header im Gegensatz zu einem großen Blob-Header.

so'n blob-header ist unglaublich praktisch, wenn man code schreiben will, der zugriff auf alles hat. ansonsten müsste man jedes source-file mit 50 #includes beginnen.

* typedef gegenüber #define vorziehen.

geht aber nur für typen, sonst kann typedef #define nicht ersetzen.

* Eindeutige und verständliche Namen wählen.

da stimme ich dir zu, aber die namen der winapi-funktionen sind im grossen und ganzen gar nicht so schlecht, ausser dass etwas mehr prefixe angebraucht wären.

http://www.tilander.org/aurora/2008/01/include-windowsh.html

#define small char
#define far
#define near

Das ist guter Codestil
Vorsicht: dieser Beitrag enthaelt Ironie.

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

Das Design selbst finde ich für C sehr gelungen, da die WinAPI eine objektbasierten Ansatz verfolgt.

Das Design selbst finde ich für C sehr gelungen, da die WinAPI eine objektbasierten Ansatz verfolgt.

das ganze OS ist objektbasiert. man denke nur mal an die 'handles', die nichts anderes sind als objektreferenzen.

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.

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.