répartition du code entre .c et .h

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.

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.

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.

Citation:

---

Envoyé par denispir

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.

Citation:

---

* 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:

---

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:

---

#define SALUTATION "hello"

---

Et a la compilation :

Citation:

---

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.

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.

Citation:

---

Envoyé par 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.

---

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.

Citation:

---

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...

Citation:

---

Envoyé par 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.

---

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...).

Citation:

---

*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... ;)

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:

---

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:

---

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:

---

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.

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.

Citation:

---

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").

Citation:

---

Envoyé par denispir

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 ?

---

8O
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.

Citation:

---

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é.

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 :mrgreen:

Je clore ici ce mini hors sujet.

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.

Citation:

---

Envoyé par kwariz

...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).

Citation:

---

Envoyé par 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 ?

---

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 :ccool:.
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

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 ;).

Citation:

---

Envoyé par 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.

---

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

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 ?

Citation:

---

Envoyé par denispir

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 :whistle: 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 ...).

Citation:

---

Envoyé par kwariz

Par exemple pour développer un nouveau langage il faut clairement avoir potassé un minimum la littérature sur le sujet (au hasard :whistle: 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...

Citation:

---

Envoyé par 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 ?

---

Je sais pas, c'est pê plus un blocage men:?tal. 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

Salut,

Citation:

---

Envoyé par denispir

développer c'est avant tout penser et coder, non?

---

et déboguer, aussi non? :lol: Et pour ça, une IDE bien conçue, ça aide. Je ne sais pas vous, mais moi, il m'est déjà arrivé de suer sur quelques-uns.

A+

Pfeuh

Citation:

---

Envoyé par pfeuh

Salut,


et déboguer, aussi non? :lol: Et pour ça, une IDE bien conçue, ça aide. Je ne sais pas vous, mais moi, il m'est déjà arrivé de suer sur quelques-uns.

A+

Pfeuh

---

Ouais, mais moi pour déboguer je suis obligé de penser beaucoup et très fort. Mais c'est sûrement parce que je suis vachement moins fort et surtout moins doué!

Denis

Citation:

---

Envoyé par denispir

Ouais, mais moi pour déboguer je suis obligé de penser beaucoup et très fort. Mais c'est sûrement parce que je suis vachement moins fort et surtout moins doué! Denis

---

C'est surtout parce que tu manques d'entraînement, tout simplement. Déboguer une application est compliqué par nature et tous les programmeurs sont passés au moins une fois sur un cas difficile qui leur a fait perdre des jours, alors qu'il s'agissait le plus souvent d'une broutille comme un point-virgule mal placé.

Citation:

---

Envoyé par denispir

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 ;

---

Ah moi c'est le contraire. J'ai fait du C pendant plusieurs années et quand je suis passé à Python ça a été le jour et la nuit. J'ai été content de ne plus avoir à me taper 45 lignes et 25 tests pour faire un append dans un tableau...

Citation:

---

Envoyé par denispir

on s'en lasse, non ?

---

Pas moi... :D

J'ai fais 7 ans de python avant de commencer le C ces temps-ci.

Le C semble répétitif, les listes simplement chaînée, les listes doublement chaînées, ...

Ce qui m'embête le plus maintenant (avant c'était les pointeurs), c'est les fuites mémoires où je me bat gaiement avec Valgrind.

Je travaille beaucoup le C, car au final mon objectif est d'être à niveau pour un langage que je considère être entre le C et python, c'est à dire le C++.

Citation:

---

Envoyé par Sve@r

Ah moi c'est le contraire. J'ai fait du C pendant plusieurs années et quand je suis passé à Python ça a été le jour et la nuit. J'ai été content de ne plus avoir à me taper 45 lignes et 25 tests pour faire un append dans un tableau...

---

J'ai actuellement cette même impression, mais j'ai le sentiment que le C++ sera un juste milieu entre l'efficacité et la simplicité.

Le C, reste tout de même simple dans sa syntaxe, pas beaucoup de mots clé.

Citation:

---

Envoyé par denispir

on s'en lasse, non ?

---

En fait je ne me lasse pas de python pour faire des choses simples et avoir à éviter de m'occuper de la gestion mémoire.

Je me lasse de stagner dans quelque-chose que je connais déjà et où je ne progresserais que très peu.

Le C permet de progresser en algorithme... pour moi c'est déjà ne plus stagner, c'est ce que je cherche.

Le C++ va ajouter un gros plus dans sa gestion des exceptions...

Chacun m'apportera ce que je souhaite, c'est à dire, éviter absolument la routine!

Citation:

---

Envoyé par Sve@r

Ah moi c'est le contraire. J'ai fait du C pendant plusieurs années et quand je suis passé à Python ça a été le jour et la nuit. J'ai été content de ne plus avoir à me taper 45 lignes et 25 tests pour faire un append dans un tableau...

---

Je me suis mis à Python et je pense la même chose. Les exemples tu m'avais montré par mp étaient très aguicheurs, la suite a été encore mieux !

Hier, j'ai ecris un bout de code qui :
- à partir d'un vecteur d'objets, crée un nouveau vecteur
- contenant la valeur d'un attribut d'instance
- des objets pour lesquels une méthode de cette classe rend True
en une seule ligne !

Exceptionnel !!!

Citation:

---

Envoyé par Bktero

Je me suis mis à Python et je pense la même chose. Les exemples tu m'avais montré par mp étaient très aguicheurs, la suite a été encore mieux !

Hier, j'ai ecris un bout de code qui :
- à partir d'un vecteur d'objets, crée un nouveau vecteur
- contenant la valeur d'un attribut d'instance
- des objets pour lesquels une méthode de cette classe rend True
en une seule ligne !

Exceptionnel !!!

---

Code:

---

1 2	[obj.attr for obj in objets if (obj.meth() == True)]

---

lol ;-)

(Je préfère séparer le mapping du filtrage, en 2 opérations. Mais python a un syntaxe terrible pour les fonctions anonymes (lambda truc), alors on est obligés d'utiliser les compréhensions de listes, et une fois qu'on en est là, autant tout grouper.)

Denis

Citation:

---

Envoyé par fred1599

J'ai fais 7 ans de python avant de commencer le C ces temps-ci.

Le C semble répétitif, les listes simplement chaînée, les listes doublement chaînées, ...

Ce qui m'embête le plus maintenant (avant c'était les pointeurs), c'est les fuites mémoires où je me bat gaiement avec Valgrind.

Je travaille beaucoup le C, car au final mon objectif est d'être à niveau pour un langage que je considère être entre le C et python, c'est à dire le C++.



J'ai actuellement cette même impression, mais j'ai le sentiment que le C++ sera un juste milieu entre l'efficacité et la simplicité.

Le C, reste tout de même simple dans sa syntaxe, pas beaucoup de mots clé.



En fait je ne me lasse pas de python pour faire des choses simples et avoir à éviter de m'occuper de la gestion mémoire.

Je me lasse de stagner dans quelque-chose que je connais déjà et où je ne progresserais que très peu.

Le C permet de progresser en algorithme... pour moi c'est déjà ne plus stagner, c'est ce que je cherche.

Le C++ va ajouter un gros plus dans sa gestion des exceptions...

Chacun m'apportera ce que je souhaite, c'est à dire, éviter absolument la routine!

---

Je crois que python est beaucoup plus compliqué, et bien moins intuitif, que beaucoup le disent. C'est dû au fait qu'il reprend l'essentiel de la sémantique des langages de la lignée C/Unix (c'était d'ailleurs un des buts de Guido, il en parle je ne sais plus où), avec une syntaxe plus sympa et sémantique à la fois plus claire et plus juste. Du coup tout nous paraît (plus) simple, mais c'est un peu une illusion d'optique, je crois.
En plus, au fil du temps, le langage c'est vachement complexifié. Avec les méta-classes, les coroutines primitives (génrateurs), les décorateurs, tu peux complètement exploser le modèle/paradigme central de python.

Si tu cherches qq ch entre C et python, va peut-être fouiller un temps du côté de D(2) et Go. D, c'est C++ moins pmal foutu. Go, bon, tout le monde en parle (*). Explorer la gamme des Modula et Oberon peut aussi valoir le coup, pour toucher à d'autres principes "language design", même si tu n'as pas l'intention de les adopter.

Denis

(*) Je dois dire malheureusement que Go est selon moi très bien conçu, du moins selon les principes de base choisis (pas de générique, par ex). Le typage dit "structurel" est excellent et je parle même pas du modèle de concurrence (hérité d'Erlang). La syntaxe "répare" l'essentiel des verrues de C/++. Malheureusement, parce que Google me fout sacrément la trouille: je préférerais que leurs projets de langages soient des ratés conceptuels (Mais avec Ken Thompson dans le lot...) et des échecs publics (mais avec la puissance de google....

Citation:

---

En plus, au fil du temps, le langage c'est vachement complexifié. Avec les méta-classes, les coroutines primitives (génrateurs), les décorateurs, tu peux complètement exploser le modèle/paradigme central de python.

---

Question de point de vue, personnellement je trouve pas.

complexifié et amélioré.

Citation:

---

D, c'est C++ moins pmal foutu

---

Mouiiii, C'est moins répandu, dommage!

Citation:

---

Go, bon, tout le monde en parle

---

Pas tant que ça, ça fait longtemps que j'en ai pas entendu parler. Par contre j'entend parler de Haskell, python, objective C

Citation:

---

Je me suis mis à Python et je pense la même chose. Les exemples tu m'avais montré par mp étaient très aguicheurs, la suite a été encore mieux !

---

Oui, mais ce sont deux langages qui ne sont pas comparables.

Le Python est un excellent langage, mais la majeure partie de ses « grands avantages par rapport au C » sont surtout ceux des langages interprétés. Les lambda-fonctions, par exemple, existent en LISP depuis 1960.

Il est décevant de constater que peu de gens se rendent compte que les difficultés du C sont ce qu'elles sont parce que les ordinateurs fonctionnent globalement de cette façon, au plus bas niveau, et pas à cause d'une conception arbitraire et maladroite au départ.

Loin de l'idée de comparer !!!

C'est juste que ça c'est mis à en parler. Venant d'une formation info indus, je connais tout l'intérêt d'un langage proche de la machine comme C. A la longue, sur PC, c'est saoulant pour faire de petites appli de se dire "alors.... pour mon tableau, je mets quoi comme taille avec mon #define ?". Au boulot ces deniers jours, j'ai développé un petit outil pour exploiter des fichiers issus d'un boitier qui est connecté à un bus et enregistre toutes les trames qui passent. Faire ça en Python a été un plaisir car je n'ai pas eu à gérer la mémoire, j'a bénéficié d'écrire de haut niveau et compactes, la possibilité de faire des classes, etc. J'ai utilisé un langage adapté à mon besoin. En revanche, je ne suis pas fan du côté interprété. Ou alors je n'ai pas encore l'habitude. J'aime bien en C faire "compiler" et qu'il me dise "erreur : telle variable est inconnue car j'ai fait une faute de frappe" ; en Python, j'exécute et je vois que ça plante. Si c'est un morceau du code où je ne passe pas systématiquement, je risque de m'en rendre compte plus tard.

Enfin, bref, on diverge ^^

Code:

---

1 2	[obj.attr for obj in objets if (obj.meth() == True)]

---

Bien vu ^^
Tu peux même enlever le == True et les parenthèses !


PS : message numéro http://www.youtube.com/watch?v=7mHe6FMs46o !