Discussion :

[denispir]

Ca me gonfle grave (pardonnez l'expression, mais elle dit ça si bien ) d'avoir le code d'un "module" qui forme un tout logique concrètement réparti entre deux fichiers. Déjà, conceptuellement, ça ne veut rien dire pour moi (*). Ensuite, en pratique, des infos fondamentales relatives à ce que j'écris là maintenant ne se trouvent pas dans ce fichier-ci mais ailleurs. Donc, je passe mon temps à jongler d'une vue à une autre (heureusement qu'on a inventé les onglets, sinon ce serait pire... ). Et ce ne sont pas des infos sur des modules tiers que j'utiliserais, mais les données de base de ce module-ci (par ex, l'ordre des champs de tel type de struct, ou le type exact de tel param de telle fonction) !

Pour limiter les dégâts, je décris tout en double:
* Les #défine sont litéralement copiés-collés, puisque le compilo accepte ça (et d'ailleurs ça permet d'éviter des erreurs d'incohérence). Ca concerne à la fois les pseudo-constantes et les pseudo-fonctions.
* Les définitions de types sont copiées dans un commentaire (rigolez pas).
* Les constantes sont déclarées extern dans le .h et donc en fait définies dans le .c, là où j'en ai besoin. Je pense à mettre la valeur en commentaire dans le .h.
* Les fonctions n'ont évidemment qu'un prototype dans le .h, là tout va bien.
* Toute la doc est copiée-collée.

Le problème, c'est la maintenance de tout ça : si je change ne serait-ce que la doc, il me faut (penser à) copier les modifs dans le .h.
Comment vous vous débrouillez, vous ?

Merci,
Denis

(*) S'il s'agit de limiter la visibilité des éléments pour du code applicatif, pourquoi ne pas avoir plutôt un attribut de déclaration qui dit ça? Mais en fait la raison concrète est plutôt, sans doute, la compilation séparée, qui impose de déclarer à part pour que la compil puisse connaître ce qui existe.

[kwariz]

Salut,

Le plus simple est d'utiliser un IDE qui prend en charge ces détails ... quand je dis IDE ça va du petit vim+ctags aux gros eclipse/anjuta/... ; pour la doc tu peux utiliser des générateurs de doc qui vont puiser dans les commentaires des sources comme doxygen. Pour l'aide en général, ça va du man à devhelp en passant par les pages info ...
Chaque combinaison a des avantages et des inconvénients. Le tout est de se sentir à l'aise avec les outils utilisés.

Dupliquer du code est toujours une mauvaise idée, surtout si c'est pour du pense-bête.

[Obsidian]

Le GROS avantage du langage C, c'est qu'il ne t'oblige nullement à coder ainsi si ça t'ennuie, contrairement à certains autres langages dans lesquels 1 classe = 1 fichier. Le code proprement dit et sa source sont complètement indépendants.

Si, en plus, tu recopies l'intégralité de ton *.h dans ton *.c, le *.h lui-même n'a absolument aucun intérêt. Maintenant, c'est quand même une bonne habitude à prendre, donc tu verras immédiatement l'avantage dès que tu atteindras des codes de 500 à 1000 lignes. Évidemment, ce n'est pas la peine de décomposer la moindre fonction en des centaines de fichiers.

Le problème, c'est la maintenance de tout ça : si je change ne serait-ce que la doc, il me faut (penser à) copier les modifs dans le .h.
Comment vous vous débrouillez, vous ?

Mon éditeur me permet de « splitter » mon écran en parties fixes et égales, tout simplement. J'ai donc toujours le *.c et *.h simultanément sous les yeux.

Comme l'a dit Kwariz, si ça ne suffit pas, utilise un IDE qui gère cela pour toi. Une fois bien configuré, il te suffira de double-cliquer sur un symbole pour en retrouver la définition.

[Bktero]

* Les #défine sont litéralement copiés-collés, puisque le compilo accepte ça (et d'ailleurs ça permet d'éviter des erreurs d'incohérence).

Ou pas !

Code develoopez.c :

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

1
2
3
4
5
6
7
8
9
10
11
#include <stdio.h>
#include "developpez.h"
 
#define SALUTATION "bonjour"
 
int main(void)
{
 
    printf("%s", SALUTATION);
    return 0;
}

Code developpez.h :

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

#define SALUTATION "hello"

Et a la compilation :

d:\Documents and Settings\pgradot\Mes documents\Tools SD\A voir\developpez.c|4|warning: "SALUTATION" redefined|
d:\Documents and Settings\pgradot\Mes documents\Tools SD\A voir\developpez.h|1|warning: this is the location of the previous definition|
||=== Build finished: 0 errors, 2 warnings ===|

Donc c'est totalement le contraire : gros risque d'incohérence si tu redéfinis dans le C quelque chose qui est dans le H.

[Médinoc]

Franchement, je conseillerais de mettre toute la doc dans le .h, car c'est la partie visible. Quand on distribue une bibliothèque sous forme compilée, on donne un .a/.lib et le .h: La doc n'a rien à faire dans le code source à moins qu'on utilise un outil pour l'extraire.

L'idéal serait sans doute un outil qui générerait automatiquement le .h à partir du .c, avec une syntaxe déclarative pour dire ce qui doit ou non être visible. Mais cela interdit les dépendances circulaires entre unités de compilation, même au sein d'un même module*, ce qui n'est pas toujours possible ou désirable.

*J'emploie aussi "module" au sens Windows, c'est à dire une bibliothèque ou un exécutable: Un module peut donc être fait de plusieurs unités de compilation.

[denispir]

Le GROS avantage du langage C, c'est qu'il ne t'oblige nullement à coder ainsi si ça t'ennuie, contrairement à certains autres langages dans lesquels 1 classe = 1 fichier. Le code proprement dit et sa source sont complètement indépendants.
Si, en plus, tu recopies l'intégralité de ton *.h dans ton *.c, le *.h lui-même n'a absolument aucun intérêt. Maintenant, c'est quand même une bonne habitude à prendre, donc tu verras immédiatement l'avantage dès que tu atteindras des codes de 500 à 1000 lignes. Évidemment, ce n'est pas la peine de décomposer la moindre fonction en des centaines de fichiers.

En ce qu concerne la copie, tant que c dans ce sens là, .h vers .h, ça ne change rien --où alors c'est moi qui raisonne pas bien: j'ai toujours l'encapsulation et la compilation séparée plus légère, vur que le corps des fonctions est reste dans le .h.

Mon éditeur me permet de « splitter » mon écran en parties fixes et égales, tout simplement. J'ai donc toujours le *.c et *.h simultanément sous les yeux.

Comme l'a dit Kwariz, si ça ne suffit pas, utilise un IDE qui gère cela pour toi. Une fois bien configuré, il te suffira de double-cliquer sur un symbole pour en retrouver la définition.

Ouais, faut que j'investisse dans un écran moderne! pour pouvoir avoir 2 fenêtres en largeur...
Question IDE, non! J'ai déjà donné, merci, je préfère mille fois un outil simple léger et souple (non, je ferai pas de pub!). (*) Mais bon c'est très subjectif.

Denis

(*) A mon avis (mais c sans doute pas mesurable) avec un gros IDE tu passe ton à jouer ou te battre avec l'IDE, et c'est pourquoi le code avance pas (j'ai vu des chiffres d'enquête qui parlent d'une douzaine de lignes de code efficace pas jour en Java, et ils se confirment les une les autres). C'est comme quand t'écris du texte dans Word, tu perds ton temps avec les styles et la mise en page, et quand est-ce que t'avances le contenu? En plus, c lourdingue.
Vous avez me juger mais je m'en moque un peu: la seule IDE bien foutue que j'aie jamais vue, c'était celle de VB il y a trèèès longtemps. Super bien conçue, légère, pratique pour ce qu'elle faisait (bien). Le gars qui a conçu avait pas un carré à la place du cerveau.
Et puis ne pas ou plus savoir coder sans IDE c'est un signe aussi, à propos du codeur, de ses pratiques, du langage, de son réseau/environnement (humain), de ses outils...

[denispir]

Franchement, je conseillerais de mettre toute la doc dans le .h, car c'est la partie visible. Quand on distribue une bibliothèque sous forme compilée, on donne un .a/.lib et le .h: La doc n'a rien à faire dans le code source à moins qu'on utilise un outil pour l'extraire.

L'idéal serait sans doute un outil qui générerait automatiquement le .h à partir du .c, avec une syntaxe déclarative pour dire ce qui doit ou non être visible. Mais cela interdit les dépendances circulaires entre unités de compilation, même au sein d'un même module*, ce qui n'est pas toujours possible ou désirable.

Je pense comme toi, Médinoc. C'est sans doute faisable et même pas très difficile à partir d'une bonne représentation du source. (Je vais y songer dès que j'aurai une bon outil perso de parsing, que je dois déveloper de toute façon.)
Mais ta réflexion montre aussi (comme je le pensais déjà) qu'il n'y a pas vraiment de raison que le langage soit conçu ainsi. On pourrait très bien avoir un signe pour indiquer (à la déclaration) chaque élément exporté: const, var, type, func... (*)
On peut aussi facilement extraire les #include et rendre le collectage des dépendances automatique (D version 2 fait ça, avec un outil que tout le monde ou presque utilise).
==> plus de (besoin de ) déparation .c .h ; et plus de (besoin de) makefile. Quoique ces derniers soient bien pratiques pour définer des modes ou variantes de compil (dév, debug, publication...).

*J'emploie aussi "module" au sens Windows, c'est à dire une bibliothèque ou un exécutable: Un module peut donc être fait de plusieurs unités de compilation.

J'emploie "module" comme ça s'emploie à peu près partout, même dans les communautés de langages dont ce n'est pas un terme "officiel". 5mais j'ai vu le terme "module" dans des docs de la norme C99 ou C11: même eux sont infectés, aujourd'hui!

(*) Si ça t'intéresse, jette un oeil à la conception d'Oberon 2. Ses modules sont ainsi conçus ('*' signifie exporté), et bien conçus car pour le reste ils reprennent à peu près la sémantique de Modula, justement réputé pour pour la justesse de sa conception de la modularité. En seize pages de spécif (si je me rappelle bien), pas une de plus, Oberon est un langage compilé, typé, système (avec des opération "unsafe" bien encapsulées), et même l'OO si le coeur vous en dit... mais quasiment inutilisable en pratique à mon aves à cause de l'absence de ces petites choses qui rendent la vie du dév un peu moins pénible (mais C ne fait pas bcp mieux).
Oberon, c'est le coeur d'un langage de ce genre super bien conçu, clair, cohérent, simple. Il suffit de l'enrober d'un peu de douceur...

[kwariz]

Par curiosité, quels outils utilises-tu actuellement ?

De ce que j'ai compris, tu es sur linux et tu compiles avec gcc en utilisant un makefile. Mais quel éditeur par exemple ? Utilises-tu des outils de conception ? As-tu un outil de versionning ?

@medinoc: Le plus "simple" pour "vérouiller" une interface de bibliothèque est sans doute :

* lors du développement, avoir deux type de headers : des headers nommés (par exemple) XXXX-priv.h pour les headers qui sont propres à la création de la bibliothèques et une sentinelle du genre

Code :

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

1
2
3
#if !defined(COMPILATION_TIME)
#error "erreur : utilisation d'un header privé"
#endif

et des headers nommés XXXX.h (donc qui ne finissent pas en -priv.h) qui ont une sentinelle du genre

Code :

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

1
2
3
#if !defined(COMPILATION_TIME) && !defined(INSIDE_TOP_LEVEL_HEADER)
#error "erreur: seul TOPLEVEL.h peut être inclut"
#endif

Avec un header particulier TOPLEVEL.h qui est généré automatiquement et qui contient :

Code :

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

1
2
3
4
5
6
7
#ifndef TOP_LEVEL_HEADER
#define TOP_LEVEL_HEADER
 
#define INSIDE_TOP_LEVEL_HEADER
 
... liste de tous les headers .h et pas -priv.h en #include ...
#endif /* TOP_LEVEL_HEADER */

Lors de la création de la lib on définit un COMPILATION_TIME.

Le TOPLEVEL.h et tous les .h qui sont inclus par celui-ci seront ensuite installés dans /usr/include/MALIB-VERSION (par exemple)

Cela permet non seulement de faire dépendre l'interface du seul TOPLEVEL.h, mais également de pouvoir séparer la doc utilisateur de la doc mainteneur/développeur qui sera générée des commentaires issus de headers différents.

[Médinoc]

Tu te trompes en pensant qu'il n'y a pas de raison que le langage soit conçu ainsi: Même de nos jours en 2012, si tu as cinquante projets dépendants les uns des autres, tu es content de ne pas avoir à recompiler tout le projet quand seule l'implémentation de ta bibliothèque de plus bas niveau est modifiée. Séparer l'interface de l'implémentation permet de ne recompiler que quand l'interface change (Make fait ça très bien).

D'ailleurs, les langages sans séparation header/source les plus connus (comme Java, C#, etc.) ne font pas de compilation séparée: Ils compilent tous les fichiers sources ensemble.

J'emploie "module" comme ça s'emploie à peu près partout, même dans les communautés de langages dont ce n'est pas un terme "officiel". 5mais j'ai vu le terme "module" dans des docs de la norme C99 ou C11: même eux sont infectés, aujourd'hui!

Le problème, c'est que j'avais besoin de deux termes différents: Un pour le fichier .c compilé, tous les fichiers donnant le même exécutable (et je ne connais pas de nom officiel pour ça en dehors de Windows, à part peut-être "projet").

[Bousk]

Pour limiter les dégâts, je décris tout en double:
* Les #défine sont litéralement copiés-collés, puisque le compilo accepte ça (et d'ailleurs ça permet d'éviter des erreurs d'incohérence). Ca concerne à la fois les pseudo-constantes et les pseudo-fonctions.
* Les définitions de types sont copiées dans un commentaire (rigolez pas).
* Les constantes sont déclarées extern dans le .h et donc en fait définies dans le .c, là où j'en ai besoin. Je pense à mettre la valeur en commentaire dans le .h.
* Les fonctions n'ont évidemment qu'un prototype dans le .h, là tout va bien.
* Toute la doc est copiée-collée.

Le problème, c'est la maintenance de tout ça : si je change ne serait-ce que la doc, il me faut (penser à) copier les modifs dans le .h.
Comment vous vous débrouillez, vous ?

Etant donné que le .c inclus le .h, quel est l'intérêt de dupliquer le .h dans le .c ? action déjà réalisée par le... #include !
A part voir fleurir warning et autres erreurs (redefinition, double definition, ...), doubler la maintenance : aucune.
La doc dans le .c : inutile, si j'ai besoin de voir la doc, je regarde le .h, c'est le header, qui décrit les définitions et contient donc les doc. Ce n'est pas le but du .c.
Et attention à l'amalgame const et extern. Ce sont 2 choses indépendante.

A mon avis (mais c sans doute pas mesurable) avec un gros IDE tu passe ton à jouer ou te battre avec l'IDE, et c'est pourquoi le code avance pas (j'ai vu des chiffres d'enquête qui parlent d'une douzaine de lignes de code efficace pas jour en Java, et ils se confirment les une les autres). C'est comme quand t'écris du texte dans Word, tu perds ton temps avec les styles et la mise en page, et quand est-ce que t'avances le contenu? En plus, c lourdingue.
Vous avez me juger mais je m'en moque un peu: la seule IDE bien foutue que j'aie jamais vue, c'était celle de VB il y a trèèès longtemps. Super bien conçue, légère, pratique pour ce qu'elle faisait (bien). Le gars qui a conçu avait pas un carré à la place du cerveau.
Et puis ne pas ou plus savoir coder sans IDE c'est un signe aussi, à propos du codeur, de ses pratiques, du langage, de son réseau/environnement (humain), de ses outils...

C'est peut-être vrai la première fois que tu vas lancer Word, mais si après plusieurs fois/jour/mois/... d'utilisation t'en es toujours à perdre du temps pour définir tes styles... effectivement vaut mieux arrêter.
Pour ma part mon IDE je l'ai configuré au départ et je n'y touche plus depuis. En fait c'est même mieux que ça, tel qu'il était au départ ça me convenait, alors j'y ai même jamais touché. Et rien que l'explorer de solution, les onglets, pouvoir diviser la fenêtre pour afficher 2 fichiers côte à côte, me font aprécier travailler avec. Les raccourcis clavier pour accéder à la définition d'une variable/struct/class/define/... sont encore des avantages que j'y trouve.
Bref t'apelle ça une dépendance et ça "peut t'en dire long sur le développeur", mais l'essentiel est là : mon équipe est contente de mon boulot, je suis productif et solicité.

[gerald3d]

Pour rebondir sur le sujet des IDE (qui est un peu à côté du sujet de ce post), j'ai commencé par Ajunta pour finalement construire mon premier Makefile "a la mano" et programmer avec gedit (un "simple" éditeur de texte).

Aujourd'hui j'ai fait l'effort d'apprendre un peu à utiliser les autotools pour construire un projet proprement, j'utilise Emacs pour l'édition texte/compilation/debug et git bien sûr pour le versionning.

Tout ce cheminement a pris du temps mais au final je code plus facilement ainsi. Même si mes projets comportent une multitude de fichiers .c .h

Je clore ici ce mini hors sujet.

[kwariz]

Finalement ce n'est pas tant hs que ça. Développer ce n'est pas pisser du code, c'est plus que choisir un langage et y aller. Il y a de nombreux aspects qui dans une équipe sont généralement bien distribués (voire trop ?) mais que dans un pet project doivent être maîtrisés par une seule personne.

Denis (tu m'arêtes si je me trompe) se lance dans un projet d'envergure raisonnable dans un environnement qu'il découvre au fur et à mesure. L'aide au développement proposé par certains IDE peut être une aide non négligeable. Disons que anjuta serait plus indiqué que vim.

[gerald3d]

...Disons que anjuta serait plus indiqué que vim.

Oui, je suis d'accord. Ce type d'outil peut permettre d'optimiser le temps sur le codage plutôt que sur l'environnement pour le faire.
En contre partie il y a un risque de ne pas comprendre comment un projet s'articule (Makefile par exemple) et finalement perdre du temps lorsque l'on veut ajouter une bibliothèque (par exemple -lm, je fais comment pour le mettre dans mon projet parce que je veux utiliser math.h).

[denispir]

Par curiosité, quels outils utilises-tu actuellement ?

De ce que j'ai compris, tu es sur linux et tu compiles avec gcc en utilisant un makefile. Mais quel éditeur par exemple ? Utilises-tu des outils de conception ? As-tu un outil de versionning ?

Oui, tout ça est juste.
En plus: geany; mon pauvre petit cerveau; et mercurial (hg) quand j'en ai besoin.
(Ce qui est rare, car mes projets sont amateurs et personnels le plus souvent. Mais je me suis parfois servi de DVCS pour qq projets que d'autres ont utilisés ou récupéré (!), en python et aussi en D; et puis pour quelques logciels d'autrui déjà en verisoning et que moi j'ai récupérés pour les étudier --en les modifiant).
Et maintenant Valgrind .
Je vais peut-être me mettre bientôt à utiliser gdb. Ca semble utile, voire nécessaire, en C.

Pas d'outil de conception (si tu parles d'outil Merise ou ce genre de choses --que j'ai étudiées y a 20 ans ou +, d'ailleurs!). J'ai beausoup de mal avec les cadres de pensée prédéfinis. En revanche, j'ai récemment découvert que j'ai un paradigme perso dont on m'a aidé à voir qu'il est similaire la vision MVC (model-view-controller), mais selon une autre perspective que j'appelle (pour moi tout seul) "programmation systémique".

Denis

[gerald3d]

Allé, pour ce soir une petite découverte (peut être) supplémentaire pour toi.

Jette un oeil à gprof. Un bon complément, une fois que tu auras nettoyé ton code de toutes ces fuites mémoires qui te hantent .

[denispir]

Finalement ce n'est pas tant hs que ça. Développer ce n'est pas pisser du code, c'est plus que choisir un langage et y aller. Il y a de nombreux aspects qui dans une équipe sont généralement bien distribués (voire trop ?) mais que dans un pet project doivent être maîtrisés par une seule personne.

Denis (tu m'arêtes si je me trompe) se lance dans un projet d'envergure raisonnable dans un environnement qu'il découvre au fur et à mesure. L'aide au développement proposé par certains IDE peut être une aide non négligeable. Disons que anjuta serait plus indiqué que vim.

Tu as tout-à-fait raison, kwariz.
Sauf pour "raisonnable", sûrement. Il s'agit d'un langage que j'ai en tête depuis longtemps (et du coup qui a bcp changé) et implanté à moitié dans plusieurs langages déjà (D, freepascal, et même un gros bout en lua!).

Quant aux outils, c'est vrai que j'ai été maladroit et biaisé (pardon à Bousk, qui a eu raison de me remettre à ma place, d'ailleurs) ; mais je pense ce que je dis malgré tout.
C'est pourquoi je n'utilise que des choses très simples ou très bien conçues (ce qui est super rare, d'où mon enthousiasme pour Valgrid). L'avantage, pour moi, c'est que je ne perds pas mon temps, mon énergie, et surtout ma motivation à tenter de bouger des trucs (les gros outils mal foutus) qui pèsent des tonnes et des tonnes. Si vous voyez ce que je veux dire. Je passe tout mon temps de dév à concevoir, implanter, tester, ré-implanter, re-concevoir... ou presque.
Mais c'est sûr qu'en environnement professionnel les contraintes et besoins sont différents. (Ceci dit, développer c'est avant tout penser et coder, non? )

Denis

[Obsidian]

Je suis obligé de dire que si tu as fait du Python, du D, du C, que tu as découvert valgrind et que tu en as saisi tout le bénéfice, que tu t'intéresses aux méthodes et aux motifs de développement, au profilage, et que tu as fait un peu de déboguage, je reste très perplexe de constater que tu ne vois pas en quoi les *.h peuvent être utiles. Tu devrais au contraire être le genre de personne à raisonner spontanément de la même manière…

Si c'est juste le fait de changer d'onglet qui te saoule, alors comment fais-tu pour te référer facilement à tes définitions lorsque ton code dépasse une page ?

[kwariz]

Je vais peut-être me mettre bientôt à utiliser gdb. Ca semble utile, voire nécessaire, en C.

Pas d'outil de conception (si tu parles d'outil Merise ou ce genre de choses --que j'ai étudiées y a 20 ans ou +, d'ailleurs!). J'ai beausoup de mal avec les cadres de pensée prédéfinis. En revanche, j'ai récemment découvert que j'ai un paradigme perso dont on m'a aidé à voir qu'il est similaire la vision MVC (model-view-controller), mais selon une autre perspective que j'appelle (pour moi tout seul) "programmation systémique".

Denis

Oui, le debugger est un outil dont la maîtrise est indispensable dans n'importe quel environnement.

Quant aux "cadres de pensée prédéfinis", il ne faut pas les voir ainsi. Il ne s'agit que de méthodes qui te permettent de capitaliser les expériences d'autres personnes. Elles ne sont pas à appliquer aveuglément mais avec discernement. Je parle là aussi bien de méthodes générales de travail (getting things done !), que de conception, de gestion de projet, ...
Cela peut sembler ridicule de parler de cela pour un pet project, et pourtant.

Par exemple pour développer un nouveau langage il faut clairement avoir potassé un minimum la littérature sur le sujet (au hasard le dragon book) sinon tu vas te trouver face à un mur voire dans une impasse (c'est pire : il y a au moins trois murs ...).

[denispir]

Par exemple pour développer un nouveau langage il faut clairement avoir potassé un minimum la littérature sur le sujet (au hasard le dragon book) sinon tu vas te trouver face à un mur voire dans une impasse (c'est pire : il y a au moins trois murs ...).

Tu as bien raison ! Et aussi bien au niveau de la conception --de toutes sortes de points de vue-- que des méthodes d'implantation --que je n'ai pas encore assez explorées, loin de là. Par contre, au sujet de la conception, je commence à avoir les idées plus claires, à force d'explorer et d'en causer.
Tu vois, je suis si d'accord avec toi que, comme je ne trouvais pas ce que je cherchais (sans savoir bien ce que je cherchais, d'ailleurs, mais juste qu'il me manquait des sources d'inspiration), alors j'ai ouvert il y a qq temps une liste de diff à ce sujet, "PiLuD" (comme Prog Lang Design): https://groups.google.com/forum/?hl=...s#!forum/pilud .
Je suis aussi de temps à autres les forums sur LtU (http://lambda-the-ultimate.org/), mais c'est trop cahotique à mon goût, et les forums ne permettent pas trop des discussions suivies comme les listes, je trouve.

Denis

PS: Je suis très intéressé de connaître tes pensées à ce sujet ; en particulier, mais pas seulement si tu as toi aussi exploré le domaine, ce que tu évoques par "trois murs". Mais c'est plus qu'hors-sujet, je pense, alors causons-en en privé. Ou mieux: tu es le bienvenu sur PiLuD ! dis-moi si ça te branche et je t'inscris, sinon tu devras passer par des filtres anti-spambots...

[denispir]

Je suis obligé de dire que si tu as fait du Python, du D, du C, que tu as découvert valgrind et que tu en as saisi tout le bénéfice, que tu t'intéresses aux méthodes et aux motifs de développement, au profilage, et que tu as fait un peu de déboguage, je reste très perplexe de constater que tu ne vois pas en quoi les *.h peuvent être utiles. Tu devrais au contraire être le genre de personne à raisonner spontanément de la même manière…

Si c'est juste le fait de changer d'onglet qui te saoule, alors comment fais-tu pour te référer facilement à tes définitions lorsque ton code dépasse une page ?

Je sais pas, c'est pê plus un blocage mental. Pour moi, un module c'est un tout ; c'est aussi con que ça. Mais bon, j'y survis, hein .

Et puis j'aime bien le C, ça m'éclate bien aussi de devoir penser très lucidement à tout, dans le détail et sous tous les angles, comme ça. Quand ça marche, t'es content! alors qu'en python si t'as les idées claires sur ce que tu veux dire ça marche tout de suite ; et sans fuites mémoires ; on s'en lasse, non ?
Ceci dit la C-way c'est pas l'idéal pour pouvoir se concentrer sur son modèle mental de l'appli à concevoir ! Je me demande comment certains arrivent à faire rouler de vraies grosses applis écrites en C. La méthodologie, la coopération, les outils, ça fait pas tout (sinon les gens n'auraient jamais de bogues dans des langs de + haut niveau, hein ?). Il faut aussi une sacrée puissance de pensée, savoir voir toutes les perspectives et jongler avec les niveaux d'abstraction comme un enfant d'la balle... j'admire.

Denis