redesign windows header

Meep Meep

bloeder titel. ich weiß.

weiß jemand ob es ein project gibt das die WINAPI modernisiert und die defines in die tonne tritt ?
mit modernisieren mein ich das die headerfiles ueberarbeitet werden, damit die gannzen defines usw. weg sind

Meep Meep

Fake oder Echt

Und anstatt der Defines dann Enums oder Konstanten?
Da viele Defines versionsabhängig sind (was ja wiederum über Defines geprüft wird), kann ich mir das nicht vorstellen. Die Absicht, alle Defines zu ersetzen erachte ich auch als relativ wirkungsarm.

Was genau soll das Ziel sein?

Meep Meep

mir gehts eher darum das sachen wie

#define CreateFile  CreateFileW

oder

#define __STRUCT__ struct
#define interface __STRUCT__

wegfallen. mit den #define konstanten hab ich eigendlich keine probleme

Fake oder Echt

An die Makros, die für die compiler-gestützte Umstellung des Zeichensatzes zuständig sind, würde ich persönlich nicht gehen. Es ist zwar meist keine riesige Erleichterung, da bei mir bspw. immer Unicode und somit die W-Replacements eingesetzt werden (die man somit auch direkt selbst nutzen könnte), aber dementsprechend ist es auch nicht wirklich störend. Oder?

Diese Re-Replacements sind auch eher aus Gründen der Portabilität eingebunden. Vermutlich zur Erhöhung der Abstraktion wurde nachdem __STRUCT__ schon existierte noch interface dazugenommen. Entweder um auf noch kommende Features vorzubereiten oder um alte weiterhin zu unterstützen (oder um für einen Spezialfall eine bessere Abgrenzung zu schaffen). Mich persönlich stören sie nicht. Falls du Probleme mit eigenen Makros hast, würde ich vorschlagen, dass du vorher deine Makros auf Existenz prüfst:

#ifdef interface
#undef interface
#endif

#define interface WHATEVER

Als Hardcore-Variante könntest du dir ja auch einen Parser schreiben, der die Header auf bestimmte Muster hin untersucht und diese dann löscht/erstetzt. Oder die entsprechenden Stellen von Hand löschen (beide Varianten besser mit BackUp). Ein Projekt, was deinen Wünschen entspricht, ist mir nicht bekannt.

Martin Richter

Meines Wissens nach sind keine Projkete geplant, die eine so weitgehende Umstellung des API Codes vorsehen.

Dann verwende einfach nicht CreateFile sondern eben was DU willst CreateFileW oder CreateFileA...

Meep Meep

Martin Richter schrieb:

Dann verwende einfach nicht CreateFile sondern eben was DU willst CreateFileW oder CreateFileA...

mir gehts nicht darum. ob ich nun CreateFile, CreateFileA oder CreateFileW schreib ist mir egal.
aber ich kann z.b. CreateFile selber nicht mehr benutzen. weder als enum, noch als funktionsname.
oftmals muss ich mir dann ewig nen neuen namen fuer ein enum oder einen funktionsnamen ueberlegen
,weil MS ihn schon mit nem define verkorkst hat

Fake oder Echt

Meep Meep schrieb:

Martin Richter schrieb:

Dann verwende einfach nicht CreateFile sondern eben was DU willst CreateFileW oder CreateFileA...

mir gehts nicht darum. ob ich nun CreateFile, CreateFileA oder CreateFileW schreib ist mir egal.
aber ich kann z.b. CreateFile selber nicht mehr benutzen. weder als enum, noch als funktionsname.
oftmals muss ich mir dann ewig nen neuen namen fuer ein enum oder einen funktionsnamen ueberlegen
,weil MS ihn schon mit nem define verkorkst hat

Ganz allgemein gesagt und meine persönliche Meinung: Eigene Funktionen/Klassen/Methoden/Enums/etc. sollte man immer von den systemeigenen Bezeichnern abgrenzen. Hat man eine Funktion, die eine Datei erstellt, sollte man diese nicht CreateFile nennen. Namen wie MyCreateFile oder generell einsatzbezogene Namen (bspw. CreateBackupFile, CreateSaveFile, CreateXMLFile, besser noch backupFile_create, saveFile_create XMLFile_create o.ä.) sind wenigstens anzuraten. In C++ könnte man zwar das Konzept der Polymorphie nutzen, um bereits belegte Funktionsnamen zu "übernehmen", die Wartbarkeit wird dadurch aber ziemlich erschwert. Geht es wirklich nur um einen Bezeichner wie interface würde ich entweder wie oben beschrieben per vorherigem undef das alte Makro löschen oder mein interface konkretisieren. Je nach Art des Interfaces würde ich es auch so benennen, dann weiß ich nächstes Jahr nämlich auch auf Anhieb noch, was das machen soll (z.B. com_interface, usb_interface, canvas_interface, o.ä.)

hustbaer

Klar nervt das, und zwar wie auch noch.

class __declspec(dllexport) Foo
{
//...
     void LoadImage();
};

Abhängig davon ob windows.h inkludiert wurde oder nicht heisst die Funktion jetzt LoadImage oder halt LoadImageW .
Tolle Wurst.

Oder die GetCurrentTime Funktion die ich irgendwo definiere heisst auf einmal GetTickCount .
Sollen wir jetzt jeden Bezeichner mit "my" prefixen? Pfff...

Techel

Irgendwann wird die Windows API nochmal redesignt werden. Vielleicht
Aber wenigstens Namensraumprefixe hätten die bei MS schon einbauen können, z.B. WINCreateFile oder WINLoadImage.

Fake oder Echt

hustbaer schrieb:

Klar nervt das, und zwar wie auch noch.
class __declspec(dllexport) Foo
{
//...
     void LoadImage();
};
Abhängig davon ob windows.h inkludiert wurde oder nicht heisst die Funktion jetzt LoadImage oder halt LoadImageW .
Tolle Wurst.

Oder die GetCurrentTime Funktion die ich irgendwo definiere heisst auf einmal GetTickCount .
Sollen wir jetzt jeden Bezeichner mit "my" prefixen? Pfff...

class __declspec(dllexport) Foo
{
//...
     void loadImage();
};

class __declspec(dllexport) Foo
{
//...
     void LoadFooImage();
};

#ifdef LoadImage
#undef LoadImage
#endif 

class __declspec(dllexport) Foo
{
//...
     void LoadImage();
};

4. (gemäß roflos Anmerkung)

#ifdef LoadImage
#ifdef UNICODE
#define WINLoadImage LoadImageW
#else
#define WINLoadImage LoadImageA
#endif
#undef LoadImage
#endif 

class __declspec(dllexport) Foo
{
//...
     void LoadImage();
};

volkard

roflo schrieb:

Irgendwann wird die Windows API nochmal redesignt werden. Vielleicht
Aber wenigstens Namensraumprefixe hätten sie einbauen können, z.B. WINCreateFile oder WINLoadImage.

Ist dich schon laaange!
Nur MS fängt Funktionen mit Großbuchstaben an. Wenn man das nachmacht, klar kollidiert es dann.
Das erinnert mich an die Fachleute, die mit Borland-Produkten arbeiten und ihre eigenen Klassen mit T - bzw die mit MS-Produkten arbeiten und ihre eigenen Klassen mit C anfangen lassen. Das ist keine so krass gute Idee.
Also ich hab fast keine Kollisionen, klar, mal max und min, und vielleicht mal das DOMDocument.

hustbaer

@Fake oder Echt
Ist mir schon klar.
Nur inwiefern auch nur eine dieser Möglichkeiten akzeptabel ist musst du mir noch erklären.

Heisst: ich kann deinen "ist doch OK/alles kein Problem" Standpunkt so überhaupt nicht nachvollziehen.

volkard schrieb:

Nur MS fängt Funktionen mit Großbuchstaben an. Wenn man das nachmacht, klar kollidiert es dann.

*facepalm*

Fake oder Echt

hustbaer schrieb:

Heisst: ich kann deinen "ist doch OK/alles kein Problem" Standpunkt so überhaupt nicht nachvollziehen.

Ich sehe es so ... wer sich daran stört, der soll sich eine eigene Lösung einfallen lassen. Schließlich sind die Funktionen der WinAPI Teil der API. Wer C++ nutzt und sich ärgert, dass er als Bezeichner nicht const, static, int, auto, new oder sonstwas wählen kann, der sollte sich einen anderen Weg zur Realisierung seiner Projekte suchen. Wer sich an den (zugegebener Maßen ausgiebig genutzten) Defines der WinAPI stört, sollte sich ein Framework suchen, bei dem das nicht der Fall ist bzw. das alles besser gekapselt ist. Aber auch da gilt es, sich von den internen Bezeichnern abzugrenzen. Wer dazu nicht in der Lage ist und regelmäßig mit bereits bestehenden Bezeichnern aneinandergerät, der sollte sich Gedanken über seinen Programmierstil machen.
Von den Undefs halte ich persönlich auch nichts, es wäre aber eine Mittel zum Zweck. Mehr als die Defines stören mich in der WinAPI die teils haarsträubende Dokumentation inkl. crashender Beispiele aus der MSDN oder un-/ bzw. teildokumentiertes Verhalten.

hustbaer

Fake oder Echt schrieb:

hustbaer schrieb:

Heisst: ich kann deinen "ist doch OK/alles kein Problem" Standpunkt so überhaupt nicht nachvollziehen.

Ich sehe es so ... wer sich daran stört, der soll sich eine eigene Lösung einfallen lassen.

Die Sache ist bloss dass es keine wirklich gute Lösung gibt.

Fake oder Echt schrieb:

Schließlich sind die Funktionen der WinAPI Teil der API.

Und?

Fake oder Echt schrieb:

Wer C++ nutzt und sich ärgert, dass er als Bezeichner nicht const, static, int, auto, new oder sonstwas wählen kann, der sollte sich einen anderen Weg zur Realisierung seiner Projekte suchen.

Aha.
Und deswegen macht das Standardkommittee auch mit jedem C++ Standard mehrere Hundert neue Keywords dazu. Und jeder der ne eigene Funktion LoadImage nennen möchte ist unfähig und soll sich nen anderen Job suchen. Klar, OK.

Fake oder Echt schrieb:

Wer sich an den (zugegebener Maßen ausgiebig genutzten) Defines der WinAPI stört, sollte sich ein Framework suchen, bei dem das nicht der Fall ist bzw. das alles besser gekapselt ist.

Es gibt auch Leute die solche Frameworks entwickeln. Frag die mal was sie von den #defines in den Windows Headern halten. z.B. die Entwickler von wxWidgets. Oder ... z.B. auch ... mich. Ne, warte, ich bin ja doof.

Fake oder Echt schrieb:

Aber auch da gilt es, sich von den internen Bezeichnern abzugrenzen. Wer dazu nicht in der Lage ist und regelmäßig mit bereits bestehenden Bezeichnern aneinandergerät, der sollte sich Gedanken über seinen Programmierstil machen.

Hast du schonmal was von Namespaces gehört? Weisst du wozu diese u.A. gedacht sind? Und davon wie sich #defines so überhaupt nicht um diese scheren?

Fake oder Echt schrieb:

Von den Undefs halte ich persönlich auch nichts, es wäre aber eine Mittel zum Zweck.

Lustig, denn genau das ist mMn. noch die beste Lösung.

Fake oder Echt schrieb:

Mehr als die Defines stören mich in der WinAPI die teils haarsträubende Dokumentation inkl. crashender Beispiele aus der MSDN oder un-/ bzw. teildokumentiertes Verhalten.

Wer nicht in der Lage ist die MSDN zu lesen bzw. mit (meist aus trivialen Gründen) crashenden Beispielen klarzukommen...
Ne, ich sags jetzt nicht.

Fake oder Echt

Ich kann nicht ganz nachvollziehen, warum du dich angegriffen fühlst. Weil ich nicht deine Meinung vertrete? Weil ich sowohl was die Doku als auch die generelle Usability betreffend andere (negative) Erfahrungen gemacht habe?
Wenigstens scheinen wir uns ja bei der Undef-Geschichte insofern einig zu sein, als das das die einzige "Quick"-Lösung ist, auch wenn ich sie "Dirty" finde.
Weitere polemische Rhetorik, die nicht zum Thema gehört und die keine rhetorische/n Frage/n ist/sind, nehme ich gern über PN entgegen.

hustbaer

Fake oder Echt schrieb:

Ich kann nicht ganz nachvollziehen, warum du dich angegriffen fühlst. Weil ich nicht deine Meinung vertrete? Weil ich sowohl was die Doku als auch die generelle Usability betreffend andere (negative) Erfahrungen gemacht habe?

Weil du das Problem mit einen total unpassenden Vergleichen ins lächerliche ziehst um dann in Folge Leute die es eben als Problem wahrnehmen für doof bzw. unfähig zu erklären. Kommt zumindest für mich genau so rüber.

Wenn du das Problem nicht hast bzw. es nicht als Problem wahrnimmst, schön für dich. Das heisst aber nicht dass es nicht existiert oder dass jeder doof bzw. unfähig ist der es eben schon als Problem sieht.

Fake oder Echt

hustbaer schrieb:

Fake oder Echt schrieb:

Ich kann nicht ganz nachvollziehen, warum du dich angegriffen fühlst. Weil ich nicht deine Meinung vertrete? Weil ich sowohl was die Doku als auch die generelle Usability betreffend andere (negative) Erfahrungen gemacht habe?

Weil du das Problem mit einen total unpassenden Vergleichen ins lächerliche ziehst um dann in Folge Leute die es eben als Problem wahrnehmen für doof bzw. unfähig zu erklären. Kommt zumindest für mich genau so rüber.

Wenn du das Problem nicht hast bzw. es nicht als Problem wahrnimmst, schön für dich. Das heisst aber nicht dass es nicht existiert oder dass jeder doof bzw. unfähig ist der es eben schon als Problem sieht.

Das mit dem doof und unfähig kann ich nicht nachvollziehen, wo man das bei meinen Antworten rauslesen könnte. Aber gut, das war dann das typische Sender-Empfänger-Problem und beim geschriebenen Wort geht das ja meist eh recht schnell mit den Missverständnissen.

Naja. Programmieren ist ja eh ein bisschen wie eine Ehe. Man muss lernen sich zu arrangieren. Das geht mal mehr, mal weniger.