je ne sais pas d'où vient cette idée, mais quiconque à travaillé sur du C/C++ sait que non c'est pas comme ça que ça marche.
Souvent l'ordre des includes peut faire planter la compilation, des macros peuvent être définie dans les includes; je ne parle même pas du boulet qu'a fait un include guard (#ifndef machin ... #define machin), en le recopiant d'un autre include
J'ai même eu un projet où l'ordre des chemins d'includes (défini via la chaine de compilation) changeait le comportement (et oui c'était voulu).
Donc non supprimer une fonction cantonnée au fichier, on vérifie via un search dans ledit fichier, et on vérifie que ce même fichier n'est pas inclus ailleurs car le #include "machin.cc" j'ai déjà vu aussi, et pour plus de sûreté on fait un grep et on analyse les résultats.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: bah non
Posté par fearan . En réponse au journal Le bon sens et le C++. Évalué à 4.
je ne sais pas d'où vient cette idée, mais quiconque à travaillé sur du C/C++ sait que non c'est pas comme ça que ça marche.
Souvent l'ordre des includes peut faire planter la compilation, des macros peuvent être définie dans les includes; je ne parle même pas du boulet qu'a fait un include guard (#ifndef machin ... #define machin), en le recopiant d'un autre include
J'ai même eu un projet où l'ordre des chemins d'includes (défini via la chaine de compilation) changeait le comportement (et oui c'était voulu).
Donc non supprimer une fonction cantonnée au fichier, on vérifie via un search dans ledit fichier, et on vérifie que ce même fichier n'est pas inclus ailleurs car le #include "machin.cc" j'ai déjà vu aussi, et pour plus de sûreté on fait un grep et on analyse les résultats.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent