"On" m'a toujours dit que normalement l'ordre des includes n'avait
aucune importance. Pourtant je reste sceptique notamment sur les
#define. Si le preprocesseur ne fait qu'une passe alors ces include
doivent etre inclus dans un ordre particulier. Par contre, je me demande
si le "normalement peu importe l'ordre de tes includes" ne signifie pas
"si tu fais les choses correctement, peu importe....".
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Matthieu Moy
korchkidu writes:
Bonjour,
Bonjour,
[...]
Par contre, je me demande si le "normalement peu importe l'ordre de tes includes" ne signifie pas "si tu fais les choses correctement, peu importe....".
Dans ma définition de "si tu fais les choses correctement", en effet. Un fichier fait un #include sur chaque fichier dont il a besoin, et les en-têtes sont protégés contre la double inclusion, donc, quelque soit l'ordre dans lequel tu met tes #include, ils seront au final inclus dans le bon ordre.
Par contre, tu n'auras effectivement aucun mal à écrire du code pour lequel l'ordre des #include change la sémantique ou la correction du code.
-- Matthieu
korchkidu <korch_ki_du@yahoo.fr> writes:
Bonjour,
Bonjour,
[...]
Par contre, je me demande si le "normalement peu importe l'ordre de
tes includes" ne signifie pas "si tu fais les choses correctement,
peu importe....".
Dans ma définition de "si tu fais les choses correctement", en effet.
Un fichier fait un #include sur chaque fichier dont il a besoin, et
les en-têtes sont protégés contre la double inclusion, donc, quelque
soit l'ordre dans lequel tu met tes #include, ils seront au final
inclus dans le bon ordre.
Par contre, tu n'auras effectivement aucun mal à écrire du code pour
lequel l'ordre des #include change la sémantique ou la correction du
code.
Par contre, je me demande si le "normalement peu importe l'ordre de tes includes" ne signifie pas "si tu fais les choses correctement, peu importe....".
Dans ma définition de "si tu fais les choses correctement", en effet. Un fichier fait un #include sur chaque fichier dont il a besoin, et les en-têtes sont protégés contre la double inclusion, donc, quelque soit l'ordre dans lequel tu met tes #include, ils seront au final inclus dans le bon ordre.
Par contre, tu n'auras effectivement aucun mal à écrire du code pour lequel l'ordre des #include change la sémantique ou la correction du code.
-- Matthieu
Loïc Joly
korchkidu wrote:
Bonjour,
"On" m'a toujours dit que normalement l'ordre des includes n'avait aucune importance.
Pour moi, ça veut dire qu'il ne devrait pas avoir d'importance dans du code bien fait.
Un truc tout simple permet de vérifier quelques erreurs : Dans "Toto.cpp", inclue en premier "Toto.h". Ainsi, tu es certain que tous tes .h ont été utilisés au moins une fois en première position, et donc qu'ils sont complets.
-- Loïc
korchkidu wrote:
Bonjour,
"On" m'a toujours dit que normalement l'ordre des includes n'avait
aucune importance.
Pour moi, ça veut dire qu'il ne devrait pas avoir d'importance dans du
code bien fait.
Un truc tout simple permet de vérifier quelques erreurs : Dans
"Toto.cpp", inclue en premier "Toto.h". Ainsi, tu es certain que tous
tes .h ont été utilisés au moins une fois en première position, et donc
qu'ils sont complets.
"On" m'a toujours dit que normalement l'ordre des includes n'avait aucune importance.
Pour moi, ça veut dire qu'il ne devrait pas avoir d'importance dans du code bien fait.
Un truc tout simple permet de vérifier quelques erreurs : Dans "Toto.cpp", inclue en premier "Toto.h". Ainsi, tu es certain que tous tes .h ont été utilisés au moins une fois en première position, et donc qu'ils sont complets.
