IDE pour langage C, pré-processeur intégré
Shinjitm
Messages postés
13
Date d'inscription
Statut
Membre
Dernière intervention
-
Emmanuel Delahaye Messages postés 107 Date d'inscription Statut Membre Dernière intervention -
Emmanuel Delahaye Messages postés 107 Date d'inscription Statut Membre Dernière intervention -
Bonjour,
Je travaille actuellement sur un projet de C embarqué, dans lequel je dois gérer plusieurs configurations possibles. Mon code est parsemé de #ifdef pour gérer chaque configuration et basculer simplement d'une a l'autre, juste en changeant un #define en tête de fichier. L'inconvénient de cette méthode est que le code est plus difficilement lisible.
C'est pourquoi je me demandais si il existait un éditeur/IDE avec un "pré-processeur intégré", qui pourrait, à la volée, afficher ou masquer les zones de codes qui ne seront pas compilées, éventuellement afficher les headers ... enfin, afficher le code tel qu'il sera effectivement compilé, quoi ... Si en plus un tel éditeur gérait la coloration du code et l'auto-complétion, ce serait le nirvana.
D'avance merci
Shinjitm
Je travaille actuellement sur un projet de C embarqué, dans lequel je dois gérer plusieurs configurations possibles. Mon code est parsemé de #ifdef pour gérer chaque configuration et basculer simplement d'une a l'autre, juste en changeant un #define en tête de fichier. L'inconvénient de cette méthode est que le code est plus difficilement lisible.
C'est pourquoi je me demandais si il existait un éditeur/IDE avec un "pré-processeur intégré", qui pourrait, à la volée, afficher ou masquer les zones de codes qui ne seront pas compilées, éventuellement afficher les headers ... enfin, afficher le code tel qu'il sera effectivement compilé, quoi ... Si en plus un tel éditeur gérait la coloration du code et l'auto-complétion, ce serait le nirvana.
D'avance merci
Shinjitm
A voir également:
- IDE pour langage C, pré-processeur intégré
- Temperature processeur - Guide
- Langage ascii - Guide
- Fréquence du processeur - Guide
- Que veut dire achat intégré - Guide
- Langage binaire - Guide
6 réponses
C'est pas normal que ce soit autant le bazar. Une meilleure organisation du code s'impose. La portabilité se résout occasionnellement par le préprocesseur, mais on se limite plutôt aux headers. En principe, on écrit plutôt des bibliothèques spécialisées en fonction de la cible (mais qui ont toutes la même interface). La portabilité se fait alors en liant la bonne bibliothèque au projet ...
Bref, je soupçonne une mauvaise organisation du développement...
Bref, je soupçonne une mauvaise organisation du développement...
Pour les Pré-Processuer intégré, je coné pas, sinon ya code::block, et ofete , quec ki te dérange dans qulque ligne de code (headers + pré-procésseur), sa dérange pas a mon avis. :D
Au contraire, DrCrow, le code est difficilement lisible sans la fonction que je recherche.
Exemple de code :
Dur de s'y retrouver, donc ...
Exemple de code :
#ifdef CONFIG1
interrupt void maFonction(void)
{
acquitement1();
#endif
#ifdef CONFIG2
void maFonction(void)
{
acquitement2();
#endif
#ifdef CONFIG1
if(registre == 0)
#endif
#ifdef CONFIG2
if(etat == 0)
#endif
{
actionPrincipale();
}
#ifdef CONFIG1
else if(registre == 1)
#endif
#ifdef CONFIG2
if(etat == 1)
#endif
{
uneFonction();
}
else
{
}
#ifdef CONFIG2
etat = (etat + 1) % 2;
#endif
#ifdef CONFIG1
compteur++;
if(compteur==1000)
{
faireQuelqueChose();
compteur = 0;
}
#endif
}
Dur de s'y retrouver, donc ...
Exemple typique de code mal organisé. Il ne doit pas y avoir de compilation conditionnelle dans le code (la preuve, ça le rend illisible)... Il faut introduire un niveau d'abstraction supplémentaire :
Soit tu fais des macros que tu définies en fonction de la config, soit eut fais des fonctions que tu regroupes dans une bibliothèque par config.
Soit tu fais des macros que tu définies en fonction de la config, soit eut fais des fonctions que tu regroupes dans une bibliothèque par config.
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
Certes.
Je vais essayer de faire au mieux, mais ce n'est pas forcément facile. Le problème étant de tester le code dans une config non-temps réel avant de l'appliquer sur une config temps-réel. Pour que ça ai un sens, il est important de conserver, autant que possible, le même code dans les deux cas. Et s'il y a des copier-coller d'un fichier à l'autre, il y a 100% de chances que ça finisse mal (ce qui implique dans mon cas du hardware qui casse). D'où l'idée de mettre de la compilation conditionnelle là où c'est absolument indispensable, et de toucher le moins possible au "coeur" des fonctions.
Encore une fois, je vais essayer de faire au mieux ...
Je vais essayer de faire au mieux, mais ce n'est pas forcément facile. Le problème étant de tester le code dans une config non-temps réel avant de l'appliquer sur une config temps-réel. Pour que ça ai un sens, il est important de conserver, autant que possible, le même code dans les deux cas. Et s'il y a des copier-coller d'un fichier à l'autre, il y a 100% de chances que ça finisse mal (ce qui implique dans mon cas du hardware qui casse). D'où l'idée de mettre de la compilation conditionnelle là où c'est absolument indispensable, et de toucher le moins possible au "coeur" des fonctions.
Encore une fois, je vais essayer de faire au mieux ...
Il faut séparer les aspects 'algorithmes' qui ne dépendent pas de la machine des aspects E/S qui dépendent de la machine. Ce n'est pas particulièrement difficile et de toutes façons, c'est la méthode reconnue et pratiqué qui permet, par exemple, à Java de s'exécuter sur n'importe quelle machine, ou d'utiliser GTK+ sous WIndows ou Linux quasiment indifféremment ...
