Organisation du code source

**_kal_** · 02/08/2006, 14h25

Bonjour à tous,

Je suis en train de définir un template sous Emacs pour mes fichier .c, et je me penche donc sur la façon correcte d'organiser un code source.

Pour cela, je me suis rendu sur l'excellent site d'Emmanuel Delahaye, à l'adresse suivante :

http://emmanuel-delahaye.developpez.com/codage.htm

Il y est proposé la liste de séparateur suivante pour un fichier .c :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
/* macros ============================================================== */
/* constants =========================================================== */
/* types =============================================================== */
/* structures ========================================================== */
/* private variables =================================================== */
/* private functions =================================================== */
/* internal public functions =========================================== */
/* entry points ======================================================== */
/* public variables ==================================================== */

Ce que je ne comprend pas, c'est la différence entre les entry points et les fonctions publiques. De même, pourquoi écrire "internal public functions" ? Si la fonction est publique, alors elle n'est pas interne ?

J'aurai pu adresser un mail/MP à Emmanuel Delahaye, mais les futurs réponses pourront être bonne à n'importe qui, j'ai décider de le poster ici. Et puis, si vous avez d'autre(s) façon(s) de structurer vos codes sources, n'hésitez pas à le(s) partager !

**Emmanuel Delahaye** · 02/08/2006, 15h56

Envoyé par _kal_

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
/* macros ============================================================== */
/* constants =========================================================== */
/* types =============================================================== */
/* structures ========================================================== */
/* private variables =================================================== */
/* private functions =================================================== */
/* internal public functions =========================================== */
/* entry points ======================================================== */
/* public variables ==================================================== */

Ce que je ne comprend pas, c'est la différence entre les entry points et les fonctions publiques. De même, pourquoi écrire "internal public functions" ? Si la fonction est publique, alors elle n'est pas interne ?

C'est dû à l'organisation des gros programmes.

http://emmanuel-delahaye.developpez.com/codage_sep.htm

J'espère que c'est plus clair... Si on a jamais fait de gros projets, on a du mal à saisir ce genre de subtilité... En fait, on crée plusieurs niveau de visibilité...

Ne pas hésiter à poser des questions...

**_kal_** · 02/08/2006, 16h58

Merci pour cette explication, j'en avais bien besoin

J'ai enfin compris la difference entre "entry points" et "internal public functions", qui est, comme tu dis : subtile.

Donc, pour résumer :

Entry points : Fonctions publiques réalisant l'interface
Internal public fonctions : Fonctions publiques utilisé uniquement par les entry points. Non accessible directement en dehors du module.
Private functions : Fonctions privées (statiques) appellées depuis les entry points. Non accessible directement en dehors du module.

Maintenant, afin de m'éclaircir les idées, je vais proposer le type d'instruction qu'on peut mettre dans les autres parties du découpages. Merci de me corriger si je me trompe.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
 
/* macros ============================================================== */
#define PI 3.14
 
/* constants =========================================================== */
const int pi = PI;
 
/* types =============================================================== */
typedef int entier;
 
/* structures ========================================================== */
struct temps
{
  int heure;
  int minute;
  int seconde;
};
 
/* private variables =================================================== */
static struct temps temps;
 
/* public variables ==================================================== */
int myGlobaleVar;

**Emmanuel Delahaye** · 02/08/2006, 17h04

Envoyé par _kal_

Entry points : Fonctions publiques réalisant l'interface
Internal public fonctions : Fonctions publiques utilisé uniquement par les entry points. Non accessible directement en dehors du module.
Private functions : Fonctions privées (statiques) appellées depuis les entry points. Non accessible directement en dehors du module.

Ca dépend de ce qu'on appelle 'module'. Je préfère parler de 'Bloc Fonctionnel' (voire de 'classe').

Un 'module', c'est souvent confondu avec une 'unité de compilation' (un .c).

Maintenant, afin de m'éclaircir les idées, je vais proposer le type d'instruction qu'on peut mettre dans les autres parties du découpages. Merci de me corriger si je me trompe.

C'est OK. Il est important de bien respecter l'ordre préscrit. Il peut y avoir des omissions (perso, je laisse même les sections vides[1], évolution oblige...), mais pas d'inversions.

Des dizaines d'exemples d'utilisation ici :

http://emmanuel-delahaye.developpez.com/clib.htm

--------------
[1] Sauf évidemment dans l'explication donnée ci-dessus, pour éviter la surcharge inutile......

**_kal_** · 02/08/2006, 17h28

Envoyé par Emmanuel Delahaye

Ca dépend de ce qu'on appelle 'module'. Je préfère parler de 'Bloc Fonctionnel' (voire de 'classe').

Un 'module', c'est souvent confondu avec une 'unité de compilation' (un .c).

Effectivement, ici module était employé dans le sens de bloc fonctionnel.

Envoyé par Emmanuel Delahaye

C'est OK. Il est important de bien respecter l'ordre préscrit. Il peut y avoir des omissions (perso, je laisse même les sections vides[1], évolution oblige...), mais pas d'inversions.

Je ne comprend pas le placement de la partie "public variables". En effet, pourquoi la placer à la fin du fichier? Cela nous empêche alors d'utiliser nos variable globales dans nos précédentes fonctions. D'ailleurs, tu as placé cette section ailleurs dans ce fichier :

http://emmanuel-delahaye.developpez....ed/src/vt100.c

Ici, la section "public variables" est placé avant les entry points, afin de pouvoir être utilisé. Au passage, la définition à l'intérieur de celle-ci (const char *colorNameTable[]) devrai être placé dans la section "constants" en vue de ce qui a été dit au dessus, non ?
Donc, soit je n'ai pas compris l'utilisation de la section "public variables", soit elle est mal placée.

Voici un exemple de fichier source, qui plante bien évidemment à la compilation puisqu'il ne connait pas la variable globale :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
 
/*
** File     : decoupage.c
** Author   : kal
** Created  : Wed Aug  2 16:49:59 2006
*/
 
#include <stdio.h>
#include <stdlib.h>
 
#include "decoupage.h"
 
/* macros ============================================================== */
#define PI 3.14
 
/* constants =========================================================== */
const int pi = PI;
 
/* types =============================================================== */
typedef int entier;
 
/* structures ========================================================== */
struct temps
{
  int heure;
  int minute;
  int seconde;
};
 
/* private variables =================================================== */
static struct temps temps;
 
/* private functions =================================================== */
static int
ma_fonction_privee(void)
{
  myGlobaleVar = 1;
  return EXIT_SUCCESS;
}
 
/* internal public functions =========================================== */
 
/* entry points ======================================================== */
int
main()
{
  printf("myGlobaleVar = %d\n", myGlobaleVar);
  printf("Appel de ma_fonction_privee\n");
 
  ma_fonction_privee();
 
  printf("myGlobaleVar = %d\n", myGlobaleVar);
  return(EXIT_SUCCESS);
}
 
/* public variables ==================================================== */
int myGlobaleVar;

**Emmanuel Delahaye** · 02/08/2006, 22h26

Envoyé par _kal_

Je ne comprend pas le placement de la partie "public variables".

Hé hé !

C'est le fruit d'une longue reflexion (de 10 minutes). En fait, il est fortement conseillé, pour des questions de vérification de cohérence, que les unités de compilations (UC) qui définissent des globales publiques (chose rare) incluent la déclaration de ces globales (.h), ce qui les rend accessible à toute l'UC. Si on oublie le .h, comme la définition est en fin d'UC, l'acces n'est plus possible, et on s'en rend compte tout de suite.

http://emmanuel-delahaye.developpez....s.htm#globales

**_kal_** · 02/08/2006, 22h43

Ah ok, je comprend mieux ainsi!

Sur ton site, on peux lire :

Un usage abusif des variables globales est fortement déconseillé pour diverses raisons (manque de lisibilité, maintenance et compréhension du code difficiles, effets secondaires indésirables, sécurité précaire, code non réentrant...) La liste est longue...

Quel type d'effets secondaires entends-tu ?
La sécurité : peut-on plus facilement acceder au contenu de la variable car elle n'est pas allouer dans la pile ?
Code non réentrant : je ne connais pas ce terme, cela signifie-t-il que l'acces à la variable n'est pas exclusif, a moins de le proteger par un sémaphore ?

Le code d'exemple que tu as ecrit dans ta première réponse devrait être mis sur ton site pour compléter l'explication, ca m'a servis et pourra servir à d'autres

Merci encore pour les explications, j'ai maintenant des fichiers sources tout propres

**Emmanuel Delahaye** · 02/08/2006, 23h56

Envoyé par _kal_

Quel type d'effets secondaires entends-tu ?

La valeur d'une variable change 'toute seule'... (en fait, on pense qu'elle va avoir une valeur et elle en a une autre)

La sécurité : peut-on plus facilement acceder au contenu de la variable car elle n'est pas allouer dans la pile ?

Comme elle est publique, n'importe quelle fonction peut changer sa valeur. on est pas forcément au courant du 'coup en douce'...

Code non réentrant : je ne connais pas ce terme, cela signifie-t-il que l'acces à la variable n'est pas exclusif, a moins de le proteger par un sémaphore ?

Par exemple.

Le code d'exemple que tu as ecrit dans ta première réponse devrait être mis sur ton site pour compléter l'explication, ca m'a servis et pourra servir à d'autres

C'est fait !

**Franck.H** · 03/08/2006, 10h29

Une petite question pour une précision:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
/* types =============================================================== */
/* structures ========================================================== */

Si tu définit un typedef sur une structure, tu le met où ?

**Emmanuel Delahaye** · 03/08/2006, 10h36

Envoyé par Franck.H

Si tu définit un typedef sur une structure, tu le met où ?

'Structures.'

'Types', c'est pour les types simples ou les pointeurs de fonctions.

Les types enum sont dans 'Constants'.

**Franck.H** · 03/08/2006, 10h39

Envoyé par Emmanuel Delahaye

'Structures.'

'Types', c'est pour les types simples ou les pointeurs de fonctions.

Les types enum sont dans 'Constants'.

Ok merci pour la précision !

**Lunixinclar** · 03/08/2006, 12h28

Bonjour,
Est-ce que la section "internal public functions" correspond à la déclaration des prototypes de fonctions?
Seconde question: peut-il y a voir plus d'un point d'entrée dans le programme?

**Emmanuel Delahaye** · 03/08/2006, 12h41

Envoyé par Lunixinclar

Bonjour,
Est-ce que la section "internal public functions" correspond à la déclaration des prototypes de fonctions?

Dans un .h, oui.

Seconde question: peut-il y a voir plus d'un point d'entrée dans le programme?

Un programme n'a qu'un point d'entrée : main() (je fais abstraction des signaux et autres interruptions asynchrones...)
Il est recommandé de placer ce point d'entrée dans le fichier main.c (c'est plus clair...).
Il est recommandé, pour une bonne organisation du code, que ce fichier n'ai pas d'autre point d'entrée ni aucune fonctions ou objets publics.
Dans un BF, il y a au moins un point d'entrée.
Dans une UC, il y a au moins une fonction ou un objet public.

Rappel : BF = Bloc Fonctionnel, UC = Unité de Compilation.

**_kal_** · 03/08/2006, 12h44

Envoyé par Lunixinclar

Bonjour,
Est-ce que la section "internal public functions" correspond à la déclaration des prototypes de fonctions?

Oui si c'est dans un .h.
La section "internal public functions" concerne les modules appellé depuis l'entry points du bloc fonctionnel.

Supposons que tu disposes d'une librairie TOTO, te proposant l'accès aux fonctions titi() et tata(), donc le code se trouve dans le fichier toto.c.
La fonction titi() peut très bien faire appel à la fonction d'un autre module toto_tools.c. Par conséquent, les fonctions de toto_tools.c seront placées dans "internal public functions".
C'est ce que j'en ai compris, retourne voir la premiere réponse d'Emmanuel Delahaye, il explique cela mieux que moi

Envoyé par Lunixinclar

Seconde question: peut-il y a voir plus d'un point d'entrée dans le programme?

Oui tout à fait. Si tu disposes d'une bibliothèque de liste chainée, tu dois avoir accès directement depuis l'extérieur aux fonctions AjouterElement(), SupprimerElement(), SupprimerListe() etc... (les noms de fonctions ne sont pas important). Ce sont les points d'entrées de ta bibliothèque.
Par contre un programme n'a qu'un seul point d'entrée : main()

J'espère avoir été assez clair

**Thierry Chappuis** · 03/08/2006, 16h28

Merci pour ce post! je me rend compte maintenant que je ne comprenais pas vraiment les subtiles différences entre "entry points" et "internal public functions". Vos exemples sont précieux et clarifient les choses.

Encore merci

A+

Thierry

**Lunixinclar** · 04/08/2006, 12h16

Une librairie avec plusieurs points d'entrée? C'est nouveau ça. Ne pas confondre les fonctions exportées avec le point d'entrée (sans S).

Donc si les prototypes de fonction ne sont pas dans un en-tête, on ne les appelle pas du tout? C'est à perdre son latin!

**_kal_** · 04/08/2006, 12h24

Envoyé par Lunixinclar

Une librairie avec plusieurs points d'entrée? C'est nouveau ça. Ne pas confondre les fonctions exportées avec le point d'entrée (sans S).

Donc si les prototypes de fonction ne sont pas dans un en-tête, on ne les appelle pas du tout? C'est à perdre son latin!

Prenons par exemple ce module :
http://emmanuel-delahaye.developpez.com/clib/ed/src/q.c

Il dispose de plusieurs fonctions dans la section "entre points", ce sont celle accessible depuis l'exterieur. C'est tout à fait normal. En effet, ce module correspond à la gestion d'une liste simplement chainée. Il est donc normal de pouvoir acceder depuis la fonction appellante aux fontions :

Q_init() : Creation/Initialisation d'une liste
Q_end() : Supression d'une liste
Q_clear(): effacement de la file
etc

Je pense que c'est ainsi que çà marche.

**Emmanuel Delahaye** · 04/08/2006, 14h13

Envoyé par Lunixinclar

Une librairie avec plusieurs points d'entrée? C'est nouveau ça. Ne pas confondre les fonctions exportées avec le point d'entrée (sans S).

Problème de vocabulaire. Je rappelle qu'il ne s'agit que de mes recommandations, et non s'une science universelle absolue.

Tu voudrais ajouter une couche en différenciant :

Le point d'entrée de l'application (entry point) : main()
Les fonctions publiques (public functions) : les fonctions des bibliothèques et des BF accessibles aux programmeurs d'application (SDK).
Les fonctions publiques internes (internal public functions) : les fonctions publiques internes des bibliothèques et des BF. Non accessibles au programmeurs d'application.

Sur le plan théorique, pourquoi pas. Sur le plan pratique, c'est une question de point de vue. Mon organisation étant plutôt orientée 'SDK', j'ai cru bon de faire comme j'ai fait, main() ne faisant pas partie du SDK, mais à l'évidence de l'application...

D'autre part, dans mon esprit, la nature particulière de main() (point d'entrée de l'application) est suffisament claire et non ambiguë pour ne pas nécessiter de qualification particulière autre que celle supposée être connue des programmeurs...

Donc si les prototypes de fonction ne sont pas dans un en-tête, on ne les appelle pas du tout? C'est à perdre son latin!

J'ai rien compris !

En tout cas, je n'impose rien. Je propose le fruit de mon expérience et de mes cogitations, c'est tout. C'est certainement perfectible.

Fait ce qui te semble être le mieux, du moment que c'est cohérent.

**Emmanuel Delahaye** · 04/08/2006, 14h15

Envoyé par _kal_

Je pense que c'est ainsi que çà marche.

Absolument.

Organisation du code source

C

Discussions similaires

Partager

Partager