Frage zum Klassen Design bei WIN API Funktionen

Hallo ich entwickle im moment eine Klasse welche von verschiedenen Compilern verwendet werden soll. Diese Klasse verwendet viele WIN API Funktionen, eben hatte ich das Problem das CodeBlocks die INPUT Struktur z.b. nicht kannte das konnte ich jedoch dank diesem Thema hier lösen: http://www.c-plusplus.net/forum/277378

Ich weiss ja nicht was für ein Compiler die Leute verwenden die meine Klasse nutzen wollen.

#define WINVER 0x0502   // XP
#define _WIN32_WINNT 0x0502  // XP

#define WINVER 0x0601        // Vista / 7
#define _WIN32_WINNT 0x0601  // Vista / 7

Ist es sinnvoll am Anfang der Klasse alles zu includen damit die Klassen auf allen Windows-Systemen verwendet werden kann?

Btw. kann man nicht auch irgendwie mit dem Präprozessor überprüfen welchen Compiler der Klassen benutzer verwendet und dann die passenden Sachen includen?

[Ist das erste mal das ich eine Klasse entwickle die mit verschiedenen Compilern funktionieren soll. Mit dem Compiler den ich eigentlich immer verwende geht alles ohne Probleme.^^]

Martin Richter

Nein, das sit nicht sinnvoll. So etwas wie die Voraussetzungen gehört in die Doku der Klasse.

Und den GCC nicht vergessen!

Martin Richter schrieb:

Nein, das sit nicht sinnvoll. So etwas wie die Voraussetzungen gehört in die Doku der Klasse.

Was für ein Bullshit! Klassisches Beispiel sind 'zig OS-Projekte, die mit allen möglichen Compilern und unter allen möglichen Umgebungen funktionieren sollen. Das endet zwar - je nach Portabilität - in ziemlichen ifdef-Orgien, aber es ist eine gängige, übliche und vor allem alternativlose Praxis.

Schließlich wäre es komplett hirnrissig, ein Projekt z.B. für Linux geignet zu definieren und in der Doku steht dann was von "lässt sich nur mit Visual Studio" compilieren.

Kleiner Nebeneffekt: Code mit unterschiedlichen Compilern übersetzt ist auch noch sauberer, da jeder Compiler irgend wie leicht andere Warnungen ausspuckt, d.h. keiner findet alle potentiellen Probleme, jeder liefert nur eine Teilmenge.

Martin Richter

@Doug§: Bullshit?
Wenn Du meinst...

Wenn ich ein Projekt bekomme. Sagen wir win Tool und dieses würde diw Windows.h includen und ich würde dies wieder in ein MFC Projekt includen, dann hätte ich aber massive Probleme.

Denn: Die MFC mag es gar nicht wenn windows.h vorher included wird.
Und jetzt willst Dumir erzählen, dass in diesem Fall die Reihenfolge der Include Dateien wichtig ist.
OK. Also includen wir Deine Datei später die windows.h included, was sie aber nciht mehr tut), denn in der MFC ist die ja evtl. schon drin. Und Deine #defines sind dann auch für die Füße.

Wenn jede LIB meint sie müüsste alles für das OS includen was sie meinen dann ist das Bullshit.
Deshalb halte ich es immer noch sinnvoll die Header so aufzubauen, dass der nutzende User die notwendigen OS Header selber beisteuern muss.

Just my 2 cents.