Je ne vois franchement pas l'intérêt de cet apport.
Pour contourner le problème de Windows ou Unix, il y a déjà la macro WIN32.
Pour le reste on est le plus souvent obligé d'indiquer des chemins pour les fichiers d'en-tête.
gcc -o test.o -I./include test.c
ou
gcc -o test.o -I./include/experimental test.c
Et si c'est pour utiliser des API différentes, alors mieux vaut avoir des fichiers sources différents, ce qui se gère au niveau du Makefile.
Et j'y vois de nouveaux inconvénients:
- des nouveaux blocs de codes morts, au lieu de fichiers de code par cible.
- des mélanges d'utilisation avec les macros déjà existantes, donc de nouvelles illisibilités dans le code.
J'aurais préféré un système pour connaître la version d'une API. Là il y aurait un vrai plus et on aurait pu faire du ménage dans les préprocesseurs de Makefile. (adieu autotool et consort).
Je ne trouve pas les exemples proposés convaincants.
Je suis prêt à changer d'avis si vous m'en proposez d'autres.
# L'intérêt ???
Posté par mpurple . En réponse à la dépêche C++17 indique la disponibilité des en‐têtes (header). Évalué à 5.
Je ne vois franchement pas l'intérêt de cet apport.
Pour contourner le problème de Windows ou Unix, il y a déjà la macro WIN32.
Pour le reste on est le plus souvent obligé d'indiquer des chemins pour les fichiers d'en-tête.
ou
Et si c'est pour utiliser des API différentes, alors mieux vaut avoir des fichiers sources différents, ce qui se gère au niveau du Makefile.
Et j'y vois de nouveaux inconvénients:
- des nouveaux blocs de codes morts, au lieu de fichiers de code par cible.
- des mélanges d'utilisation avec les macros déjà existantes, donc de nouvelles illisibilités dans le code.
J'aurais préféré un système pour connaître la version d'une API. Là il y aurait un vrai plus et on aurait pu faire du ménage dans les préprocesseurs de Makefile. (adieu autotool et consort).
Je ne trouve pas les exemples proposés convaincants.
Je suis prêt à changer d'avis si vous m'en proposez d'autres.