Est-ce une bonne idée de recréer les en-têtes de Win32?

cemment, je me suis retrouvé à faire plus de code C / C ++ contre Win32 et, issu d’un arrière-plan C #, j’ai développé une obsession pour le “code propre” qui est tout à fait cohérente. Le méli-mélo de #defines qui composent les fichiers d’en-tête de l’API Win32 est un choc culturel.

Après avoir parcouru la liste alphabétique des principales fonctions Win32 de MSDN, j’ai compris à quel point la conception de l’API Win32 est simple. Il est regrettable qu’elle soit entourée de toutes les cruautés des 25 dernières années, y compris de nombreuses références à la programmation 16 bits qui sont totalement hors de propos Monde 64 bits.

Je vais bientôt commencer un nouveau projet en C / C ++, et je réfléchissais à la façon dont je pourrais recréer les en-têtes de Win32 selon les besoins. Je pouvais concevoir que ce soit beau, et pourtant il maintiendrait une compatibilité à 100% binary (et source) avec les programmes existants (parce que #defines résoudra finalement la même chose).

Je me demandais si quelqu’un avait déjà tenté cela (Google n’a rien révélé) ou si quelqu’un voulait me dissuader de le faire.

Une autre chose à laquelle je pensais, c’était comment, avec une API Win32 C plus propre, il devenait possible de concevoir un wrapper plus propre et plus facile à utiliser l’API C ++ Win32, car il n’y aurait pas de pollution des espaces de noms provenant des anciens éléments C Win32.

MODIFIER:

Juste pour clarifier les choses, je ne le fais pas pour améliorer les performances de compilation ni pour aucun type d’optimisation, je suis tout à fait conscient que le compilateur supprime tout ce qui n’est pas utilisé. Ma quête ici est de pouvoir travailler avec une bibliothèque d’entêtes Win32 (car je n’aurai pas besoin d’appuyer sur Caps-lock chaque fois que j’utilise une fonction).

Ne fais pas ça.

C’est peut-être possible, mais cela prendra beaucoup de temps et conduira probablement à des bugs subtils.

Cependant, et plus important encore, cela rendra votre programme absolument impossible à maintenir.

Cela ne sert à rien. Ce n’est pas parce qu’il y a un nombre supplémentaire de fichiers crus qu’il est compilé dans le binary (tout ce qui n’est pas utilisé sera optimisé). En outre, lorsque EXTREME a peu de chance que quelque chose change (je ne sais pas, peut-être WM_INPUT le numéro de WM_INPUT change), il est beaucoup plus facile d’utiliser les en-têtes système. De plus, quoi de plus intuitif? Je pense que #include est beaucoup plus facile à comprendre que #include "a-windows-of-my-own.h" .

En outre, honnêtement, vous ne devriez jamais même avoir besoin de regarder le contenu de windows.h. Oui, je l’ai lu, oui c’est moche comme péché, mais il fait ce dont j’ai besoin et je n’ai pas besoin de le maintenir.

Le seul inconvénient de l’utilisation réelle de windows.h est qu’il PEUT ralentir la compilation de quelques millisecondes.

No. Quel est le point? WIN32_LEAN_AND_MEAN simplement et définissez quelques macros telles que WIN32_LEAN_AND_MEAN , VC_EXTRALEAN , NOGDI , NOMINMAX , etc.

Bien que les en-têtes Win32 puissent être considérés comme “en désordre”, vous n’avez pratiquement jamais à (ou ne voulez) regarder à l’intérieur d’eux. Tout ce que vous avez besoin de savoir est documenté dans le SDK Win32. Le contenu exact des fichiers d’en-tête est un détail d’implémentation.

Il y a une tonne de choses là-dedans qui prendraient du temps et seraient inutilement difficiles à reproduire, en particulier concernant différentes versions du SDK Win32.

Je recommande:

 #include  

À mon avis, c’est une mauvaise pratique. La propreté et la brièveté sont obtenues en respectant autant que possible les pratiques habituelles et en tirant le maximum parti de la plate-forme. Vous devez supposer que Microsoft possède l’expertise ultime sur sa propre plate-forme, certains aspects allant au-delà de ce que vous savez actuellement. En termes simples, c’est leur produit et ils savent mieux.

En roulant le vôtre:

  • … vous quittez l’API de Microsoft pour que Microsoft ne puisse plus vous fournir de mises à jour via ses canaux standard
  • … vous pouvez introduire des insectes en raison de votre propre orgueil, en sentant que vous avez trouvé quelque chose alors que vous ne l’avez pas encore fait.
  • … vous perdriez beaucoup de temps sans aucun avantage tangible (car les en-têtes C ne génèrent pas de surcharge dans le binary compilé)
  • … vous finirez par créer un projet moins élégant

Le code le plus élégant est celui qui comporte plus de lignes de code de la logique de programme réelle et le moins possible de lignes de crédit pour la “gestion interne” (c’est-à-dire un code qui n’est pas directement lié à la tâche à accomplir). Ne manquez pas d’exploiter les en-têtes Platform SDK pour rendre votre projet plus élégant.

Cela a été tenté dans le passé.

Dans son répertoire include , MinGW contient sa propre version de windows.h . Cela existe probablement pour que les en-têtes fonctionnent avec gcc. Je ne sais pas si cela fonctionnera avec un compilateur Microsoft.