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

Organisation du code source

C

Vue hybride

Discussions similaires

Partager

Partager