[Débutant] Je veux apprendre à "bien programmer"

Version imprimable

27/06/2007, 17h44
rems14

[Débutant] Je veux apprendre à "bien programmer"

Bonjour à tous :D !

Voilà j'ai lu un livre entier pour apprendre le C++, je connais donc pas mal de choses. Mais j'ai un gros problème, c'est que je ne sais pas "bien programmer".
J'entends par là, savoir comment bien séparer le code source (avec les classes et calculs) de l'interface graphique (ou flux d'entrée/sortie), le tout pour que ça soit portable et facile à mettre à jour.
En effet dans les livres que j'ai pu voir, on en parle presque pas, on apprends juste à programmer. Moi je veux programmer "intelligent". Je pourrais vous faire un programme mais bonjour les dégats si je veux qu'il soit portable ou changer d'interface graphique, donc ça ne m'intéresse pas.

J'ai vu sur le net qu'il fallait que son programme soit codé en plusieurs couches (fonctions de bases / flux d'entrée et sortie / interfaces graphique), ou qu'il soit modulable, mais je n'ai pas trouvé comment le faire.

Ma question : Pouvez-vous me conseiller un cours sur internet ou un livre qui m'apprenne ces concepts de programmation ?

Merci d'avance :)
27/06/2007, 18h44
zais_ethael

Pour commencer, tu as toute la partie Conception du site. Il s'agit principalement de design patterns ou de méthodologies applicables à l'orienté objet et donc difficilement transposables au C++ mais c'est mieux que rien.
Plus précisément pour le C++, il est fort présomptueux de dire qu'on connait beaucoup de choses après avoir lu un bouquin :). C'est un langage excessivement complexe et même ceux qui l'utilisent depuis 10 ans te diront qu'ils apprenent de nouveaux trucs tous les jours.
28/06/2007, 08h39
ZaaN

Bien que le rapport ne semble pas etre forcement evident,
le modèle des couches OSI est la théorie universelle dans l'architecture informatique (du hard au soft). Si tu comprend et intègre ce principe ce sera un grand pas dans la structure de tes composants logiciels.
28/06/2007, 22h59
koala01

Salut,

De manière générale, il ne faut pas se "jeter directement" sur le clavier pour "vomir du code" qui ne serait pas murement réfléchi.

Avant d'en arriver à l'écriture du code, il est important de passer par des étapes d'analyse, de conception et de création d'algorithmes.

L'analyse des besoin te permettra de "dégrossir" les choses, de manière à avoir en tete ce que doit faire l'application, afin entre autre, qu'elle fasse ce qu'elle doit.

La conception te permettra d'avoir une idée précise de la manière dont tu va organiser l'application afin, justement, de satisfaire aux besoins que tu a déterminé.

Les algorithmes te permettront enfin d'être sur(e) de la logique à mettre en oeuvre pout qu'une - ayant en gros pour but de satisfaire ne serait ce qu'en partie un besoin, ou de fournir les outils qui permettront de le faire - puisse dans les meilleures conditions de sécurité arriver au résultat escompté.

Il existe plusieurs méthodes d'analyse des besoins, de conception et d'algorithmie, et chacune ayant - comme d'habitude - ses avantage, ses inconvéniants, ses adeptes et ses détracteurs...

Si tu veux améliorer ta manière de programmer, il semble cohérent de t'intéresser aux différentes méthodes, d'en choisir une dans chaque catégorie qui te plaise le plus ou qui présente le plus d'avantages à ton gout, et de t'y initier tres largement...

Une fois que tu auras atteint une certaine maturité dans ces méthodes, tu considérera - peut etre - l'écriture du code elle-même comme un *simple* travail de traduction et de dactylographie ;)
28/06/2007, 23h31
rems14

Merci pour vos réponses.

C'est vrai je n'avais pas vu la partie conception, je vais regarder ça.
Sinon pour la norme OSI c'est vrai qu'à première vu on dirait qu'il n'y a aucun rapport, je dirais même que ça me fait peur tellement c'est abstrait ! Si j'ai la motive je m'y intéresserais. ;)
Enfin je sais que l'analyse d'un programme c'est hyper important pour en faire un bien structuré, et je n'en fais pas. Le pb c'est que je ne sais pas en faire. Ce que j'ai pu lire dessus était très vague, donc passez détailler pour apprendre. Aussi un sujet sur lequel il faudrait que je m'intéresse.

Encore merci, et si d'autres personnes peuvent me donner des conseils je suis prenant ! ;)

edit : je ne trouve aucun cours qui traitent de la programmation en couches en C++, je commence à désespérer. Comment l'avez-vous appris ???
30/06/2007, 01h51
zais_ethael

La conception orientée objet s'apprend, la programmation en couche ou plus généralement l'abstraction pas vraiment. C'est basé sur l'expérience et la logique.
Par exemple, prenons un programme de comptabilité permettant d'encoder des factures. En général on voudra créer au moins deux couches: d'une part une couche "données" contenant des fonctions pour ajouter/supprimer/modifier des factures dans le fichier et d'autre part une couche "interface" pour tout ce qui compose l'interface graphique. La couche interface va utiliser la couche données mais surtout pas l'inverse (c'est d'ailleurs un très bon truc à apprendre dés le début: rendre le programme indépendant de l'interface graphique).
Pour le cas du modèle OSI c'est moins compliqué qu'il n'y parait et en dehors des couches 1, 5 et 6 il est justement très concret, bien sur il faut connaitre un minimum le fonctionnement des réseaux pour piger le fonctionnement :)
30/06/2007, 10h36
Mat007

Salut,

Juste je me demandais ce que signifiait :

Citation:

Envoyé par zais_ethael

Il s'agit principalement de design patterns ou de méthodologies applicables à l'orienté objet et donc difficilement transposables au C++ mais c'est mieux que rien.

??

Personnellement j'ai l'impression de faire de l'orienté objet de la même façon en C++ qu'en Java par exemple.
Ok y'a quelques petites différences mais au final on y retrouve les mêmes mécanismes globaux d'organisation d'une application.
Tu veux dire que tu n'as (ou ne vois émerger) aucun 'design pattern' en C++ ? J'avoue que je ne comprends pas bien, mes applications sont truffées de proxies et de factories :)

MAT.
30/06/2007, 12h10
koala01

J'avoue ne pas non plus avoir parfaitement saisi ce qu'il voulait dire:

Les Desing patterns permettent de modéliser des problèmes de conceptions récurents dont on a déterminer une bonne fois pour toute la solution qui semble la moins mauvaise...

Comme la modélisation reste fort indépendante du langage - meme si on *peut* décider de se rapprocher de certaines contraintes de langages, en évitant, par exemple, de modéliser un héritage multiple - il n'est pas plus difficile d'implémenter un modèle (a fortiori de DP) en C++ qu'en n'importe quel autre langage orienté objet...

Le paradigme "orienté objet" a été envisagé différemment en java, en VB ou en C++, soit, mais... Au final, tous les langages disposent d'une meme base, et les desing patterns ne s'intéressent, justement, qu'à cette base ;)
03/07/2007, 19h30
rems14

Encore merci des réponses.
Connaissez-vous un petit programme open source qui sépare la couche "interface" de la couche "données" pour que je puisse voir quelles techniques C++ ils utilisent ?
03/07/2007, 23h42
zais_ethael

Diable non, moultes langages ont une approche similaire de l'orienté objet (Java, C#, perl, python, ruby, php, javascript, smalltalk pour ceux qui me viennent à l'esprit) mais le C++ est radicalement à part (le Delphi aussi, mais en moins bien). C'est avant tout un langage multi-paradigmes et l'orienté-objet est juste l'un de ces paradigmes, si on le compare avec le C, il permet juste une syntaxe plus agréable (à la rigueur l'identification des types ne serait pas évident à simuler en C).
Pour ce qui est d'implémenter un programme à partir d'un modèle objet pensé indépendamment du langage de destination, c'est bien sur possible mais c'est une vrai saleté. Bien trop de choses accessoires dans la plupart des langages mais essentielles en C++ n'apparaissent pas sur un diagramme, avec en tête de liste la gestion du cycle de vie des objets. Que fait on alors? On met des smarts pointers par ci, de simples pointeurs par la (avec le risque d'erreur de manip que cela implique),... Et quand on a réussi à trouver l'agencement correct on se rend compte qu'il faut modifier le diagramme, et bien evidemment l'ancien code n'est pas adaptable au nouveau modèle. Alors que faire? => limiter l'orienté objet au strict minimum et profiter des autres fonctionnalités du C++ qui n'ont rien à voir avec ça.
Comme le dit si bien Alan Kay: "I invented the term Object-Oriented, and I can tell you I did not have C++ in mind."
04/07/2007, 01h09
koala01

Je ne suis pas vraiment du meme avis...

Finalement, au niveau des desing patterns, un visiteur restera un visiteur, qu'il soit écrit en C++ ou en java...

L'implémentation du visiteur sera modifiée en fonction des spécificité du langage, mais, et bien que je ne connaisse pas particulièrement java, le package du java me fait étrangement penser à l'espace de nommage (namespace) du C++...

Peut etre y a-t-il des différences entre les deux, mais du point de vue de quelqu'un qui ne maitrise pas java, ca semble relativement similaire :P

Et, à partir du moment où seul le nom change, selon le langage envisagé, mais que le but de quelque chose reste *sensiblement* identique dans les deux langages, on est rapidement contraint à décider que le nom n'est plus qu'une histoire de convention... Qu'on aurait tres bien pu l'appeler snoopy ou pluto, ce que serait encore revenu au meme :P

Bien sur, et je l'ai tout de suite indiqué, il y a de fortes différences entre le C++ et les autres langages... Mais il y a, malgré tout, énormément de points communs, et, si tu décide d'utiliser le paradigme objet en C++, rien ne t'empeche d'implémenter - avec succes - un shéma qui aurait été pensé à la base pour etre implémenté en java... ou l'inverse ;)
04/07/2007, 07h51
Aurelien.Regat-Barrel

Citation:

Envoyé par zais_ethael

si on le compare avec le C, il permet juste une syntaxe plus agréable

Si tu vas par la, c'est le cas de tous les langages, par rapport a l'assembleur ;)

Citation:

Envoyé par zais_ethael

Pour ce qui est d'implémenter un programme à partir d'un modèle objet pensé indépendamment du langage de destination, c'est bien sur possible mais c'est une vrai saleté. Bien trop de choses accessoires dans la plupart des langages mais essentielles en C++ n'apparaissent pas sur un diagramme, avec en tête de liste la gestion du cycle de vie des objets. Que fait on alors? On met des smarts pointers par ci, de simples pointeurs par la (avec le risque d'erreur de manip que cela implique),... Et quand on a réussi à trouver l'agencement correct on se rend compte qu'il faut modifier le diagramme, et bien evidemment l'ancien code n'est pas adaptable au nouveau modèle. Alors que faire? => limiter l'orienté objet au strict minimum et profiter des autres fonctionnalités du C++ qui n'ont rien à voir avec ça.
Comme le dit si bien Alan Kay: "I invented the term Object-Oriented, and I can tell you I did not have C++ in mind."

Ton explication reste un peu abstraite pour moi. Par rapport aux smart ptr, ils apportent une solution plus globale que la gestion du cycle de vie : la gestion des ressources. J'ai pu coder une gestion d'objets en C++ au moyen de shared_ptr qui m'a réellement fait percevoir la puissance des templates. C'était simple et propre. Dans un autre langage, j'aurais eu des références croisées inutiles d'un point de vue du diagramme objet, relevant du détail d'implémentation. Merci le RAII, une spécificité C++ dont on a du mal a se passer.
04/07/2007, 09h38
buzzkaido

Moi je conseillerais autre chose, en parrallele de lecture de doc et compagnie :

Foncer !

Ecrire des petites applis.

Dans 6 mois, quand tu auras ecrit 2-3 applications en C++, bien pourries car tu ne sais pas encore comment organiser le code, ben tu te rendras compte tout seul de plein de choses concernant les méthodologies, les couches, l'abstraction, la modelisation...

Et à ce moment là, une lecture de doc sur le sujet sera réelement efficace.

Tant qu'on ne s'est pas vraiment planté, on ne sait pas vraiment comment rester debout...
04/07/2007, 12h19
zais_ethael

Pour les packages: effectivement, tu ne connais pas assez le Java. En règle générale, tous les programmeurs C++ s'accordent à dire que c'est un manque énorme et qu'un système similaire (ou un minimum plus évolué que les namespace) serait plus que bien venu.
Tu devrais aller voir ce thread, une partie de la discussion est consacrée aux packages.

Citation:

Envoyé par Aurelien.Regat-Barrel

Si tu vas par la, c'est le cas de tous les langages, par rapport a l'assembleur ;)

L'orienté objet n'est pas si difficile à faire en C, GTK l'utilise à outrance. Le plus énervant c'est surtout l'absence de tout un tas d'autres fonctionnalités du C++ (les destructeurs, les opérateurs,...). Par contre, j'aimerais faire une remarque à koala01 sur le fait que ce n'est pas possible en VB. C'est un langage qui ne permet pas de manipuler des fonctions directement ou indirectement, ce qui est le seul prérequis pour que l'orienté objet soit possible (par contre COM le permet, mais uniquement si on s'en sert en C++ je suppose).

Citation:

Envoyé par Aurelien.Regat-Barrel

Merci le RAII, une spécificité C++ dont on a du mal a se passer.

Bien sur! Sinon on ne pourrait tout simplement pas utiliser les exceptions. Le RAII n'est pas mal, mais je ne comprends toujours pas pourquoi les membres du commité de normalisation refusent l'inclusion de la forme finally. C'est beaucoup plus simple dans les cas où on doit utiliser des biblio en C ou en C with classes, c'est à dire 90% de celles qu'on a besoin d'utiliser en pratique. Au vu de toutes les autres fonctionnalités complexes qu'ils ont ajoutés au C++, une aussi simple qui pourrait s'avérer tellement utile ne serait pas du luxe.
04/07/2007, 14h02
Aurelien.Regat-Barrel

Citation:

Envoyé par zais_ethael

Pour les packages: effectivement, tu ne connais pas assez le Java. En règle générale, tous les programmeurs C++ s'accordent à dire que c'est un manque énorme et qu'un système similaire (ou un minimum plus évolué que les namespace) serait plus que bien venu.
Tu devrais aller voir ce thread, une partie de la discussion est consacrée aux packages.

En ce qui me concerne, je trouve que la séparation déclaration/implémentation est une bonne chose. Quand j'ouvre un fichier source Java et que je me retrouve avec tout le code source en un meme endroit, je suis un peu paumé. Question d'habitude peut etre.
Ce que j'aimerais en C++, c'est plutot d'avoir la possibilité de ne pas faire figurer dans le .h ce qui est private, comme les packages en ADA.

Citation:

Envoyé par zais_ethael

L'orienté objet n'est pas si difficile à faire en C, GTK l'utilise à outrance. Le plus énervant c'est surtout l'absence de tout un tas d'autres fonctionnalités du C++ (les destructeurs, les opérateurs,...).

Mouai, enfin, on est vite limité des qu'il commece a y avoir de l'héritage, c.a.d la base de tout model objet. Enfin bon on va pas s'éterniser la dessus.;)

Citation:

Par contre, j'aimerais faire une remarque à koala01 sur le fait que ce n'est pas possible en VB. C'est un langage qui ne permet pas de manipuler des fonctions directement ou indirectement, ce qui est le seul prérequis pour que l'orienté objet soit possible (par contre COM le permet, mais uniquement si on s'en sert en C++ je suppose).

Je ne comprends pas trop "manipuler des fonctions directement ou indirectement". Mais sache que VB est bati sur COM. Les classes VB sont des objets COM. Les chaines de caractere aussi, etc...

Citation:

Bien sur! Sinon on ne pourrait tout simplement pas utiliser les exceptions. Le RAII n'est pas mal, mais je ne comprends toujours pas pourquoi les membres du commité de normalisation refusent l'inclusion de la forme finally. C'est beaucoup plus simple dans les cas où on doit utiliser des biblio en C ou en C with classes, c'est à dire 90% de celles qu'on a besoin d'utiliser en pratique. Au vu de toutes les autres fonctionnalités complexes qu'ils ont ajoutés au C++, une aussi simple qui pourrait s'avérer tellement utile ne serait pas du luxe.

Le RAII est la réponse C++ au probleme de libération des ressources. Si tu fais du RAII, pas besoin de finally. On se soucie de libérer la ressource au moment ou on en prend possession. C'est beau, c'est propre, ca simplifie le code. Mais ca demande d'utiliser des objets spéciaux (smart ptr). Pour ca y'a shared_ptr que le commité a normalisé, et puis y'a les templates pour se faire ses propres trucs.
Cela dit, je ne connais pas les motivations du commité.
04/07/2007, 23h44
zais_ethael

Citation:

Envoyé par Aurelien.Regat-Barrel

En ce qui me concerne, je trouve que la séparation déclaration/implémentation est une bonne chose. Quand j'ouvre un fichier source Java et que je me retrouve avec tout le code source en un meme endroit, je suis un peu paumé. Question d'habitude peut etre.
Ce que j'aimerais en C++, c'est plutot d'avoir la possibilité de ne pas faire figurer dans le .h ce qui est private, comme les packages en ADA.

La est toute la beauté du java. Le C++ hérite son système de modules (ou ce qui s'en rapproche) du C, qui lui même utilisait... des inclusions de fichiers textes (THE prouesse technologique). En java on a le code du programmeur de l'api et à coté l'interface publique visible par l'utilisateur. Traduction: d'une part le code en lui même et d'autre part la javadoc.
C'est parfaitement logique en fin de compte, pourquoi rédiger les deux? L'interface publique peut très bien être générée automatiquement et tant qu'à faire pas dans un vulgaire fichier texte illisibles, une belle page web est largement mieux.

Citation:

Envoyé par Aurelien.Regat-Barrel

Je ne comprends pas trop "manipuler des fonctions directement ou indirectement". Mais sache que VB est bati sur COM. Les classes VB sont des objets COM. Les chaines de caractere aussi, etc...

Directement -> comme en lisp ou en C. Indirectement-> comme en java (via une interface contenant une seule méthode, mais on s'en fout puisque java c'est déja de l'objet partout). Et oui, VB est batit sur COM mais néanmoins il ne supporte ni l'héritage ni le late binding. Oui c'est débile mais c'est comme ça, et ça fait de lui l'un des rares langages où l'orienté objet est impossible. Pas de bras pas de chocolat :mouarf:

Citation:

Envoyé par Aurelien.Regat-Barrel

Le RAII est la réponse C++ au probleme de libération des ressources. Si tu fais du RAII, pas besoin de finally. On se soucie de libérer la ressource au moment ou on en prend possession. C'est beau, c'est propre, ca simplifie le code. Mais ca demande d'utiliser des objets spéciaux (smart ptr). Pour ca y'a shared_ptr que le commité a normalisé, et puis y'a les templates pour se faire ses propres trucs.
Cela dit, je ne connais pas les motivations du commité.

C'est beau, c'est propre, mais uniquement si on manipule des classes C++! L'absence de finally oblige à créer systématiquement des wrappers par dessus la moindre petite structure C si on veut rester exception safe, ce qui prend un temps fou. Beaucoup de développeurs refusent d'utiliser les fonctionnalités avancées du C++ pour ce genre de raisons, je ne comptes plus les projets où j'ai pu lire dans la faq "il n'est pas recommandé d'utiliser la stl avec notre biblio" pour ne pas avoir à se préoccuper des exceptions.
Alors oui il y aurait deux possiblités pour faire la même chose, mais comme si ce n'était pas déja le cas pour milles autres choses en C++???

Citation:

Envoyé par zais_ethael

La est toute la beauté du java. Le C++ hérite son système de modules (ou ce qui s'en rapproche) du C, qui lui même utilisait... des inclusions de fichiers textes (THE prouesse technologique). En java on a le code du programmeur de l'api et à coté l'interface publique visible par l'utilisateur. Traduction: d'une part le code en lui même et d'autre part la javadoc.
C'est parfaitement logique en fin de compte, pourquoi rédiger les deux? L'interface publique peut très bien être générée automatiquement et tant qu'à faire pas dans un vulgaire fichier texte illisibles, une belle page web est largement mieux.

Ok, tu es fana de Java, mais essaye d'etre un minimum objectif.:D
En C++ aussi il y a de la doc générée depuis le source. Mais ce n'est pas une fonctionalité du langage. Et perso, je suis moyennement fan. Alourdir chaque fonction de 5 a 10 lignes de commentaires qui nous réexpliquent que le premier parametre s'appeller toto, le deuxieme titi, etc... Sans parler que plus il y a de commentaires plus il y a de chance qu'il ne soit plus a jour... et que personne ne lit la doc, on sait comment ca se passe. Je suis plutot adepte d'un précepte de l'XP programming qui dit "les commentaires, c'est mal". Chocking ? Mais l'idee est intéressante : si l'on a besoin de mettre des commentaires, c'est que le code n'est pas clair, donc il vaut mieux le réécrire afin qu'il n'ait plus besoin d'etre commenté. Bref, je suis pour commenter utile, sinon, pour moi, c'est de l'obfuscation. Tu vois, tous les gouts sont dans la nature, et c'est ce que j'apprécie avec C++ : on a le choix. Et le choix demande un peu plus de travail, car il faut... choisir. Et il est facile de se tromper dans ses choix, je te l'accorde.

Citation:

Envoyé par zais_ethael

C'est beau, c'est propre, mais uniquement si on manipule des classes C++! L'absence de finally oblige à créer systématiquement des wrappers par dessus la moindre petite structure C si on veut rester exception safe, ce qui prend un temps fou. Beaucoup de développeurs refusent d'utiliser les fonctionnalités avancées du C++ pour ce genre de raisons, je ne comptes plus les projets où j'ai pu lire dans la faq "il n'est pas recommandé d'utiliser la stl avec notre biblio" pour ne pas avoir à se préoccuper des exceptions.
Alors oui il y aurait deux possiblités pour faire la même chose, mais comme si ce n'était pas déja le cas pour milles autres choses en C++???

A la base, quand on programme en C++, on manipule des classes. Maintenant, si on veut utiliser une lib C, il faut avoir a l'esprit que dans un autre langage comme Java, cette lib n'aurait pas été utilisable, et donc le fait de pouvoir l'utiliser directement en C++ est un gain de temps énorme. Et écrire un wrapper objet pour cette lib demande beaucoup moins de travail que de la réécrire en integralité, ou d'écrire un wrapper a la JNI/SWIG.
Apres tu parles du refus d'utiliser les fonctionnalités avancées. ca reste encore obscure comme formulation, mais les fonctionnalités avancées de C++ sont justement ce qui permet de réduire considérablement la charge de travail quand il faut écrire des wrapper RAII. Grace aux templates, et a ce qui existe deja, comme shared_ptr.
Et meme, considérer qu'écrire a la main en entier un wrapper pour un objet est une perte de temps comparé au gain en robustesse/simplicité d'utilisation par la suite, c'est ne pas voir plus loin que le bout de son nez. Les quelques dizaines de lignes écrites pour ce wrapper, ce sont des centaines de lignes économisées a ne pas écrire des bloc try...finally. Si l'on rajoute qu'avec les templates et les smart_ptr cette tache est rapide et aisée, alors...

Tu m'as motivé a réécrire et achever un article que j'avais commencé a écrire il y a un certain temps et que j'avais perdu. J'avais commencé sa rédaction quand j'avais découvert la puissance de certaines fonctionnalités des templates. Il n'est pas encore achevé, alors je copie-colle juste un extrait:
Code:

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 class Ressource { public: // Allocation des ressources : doit etre appelée // en premier, et une seule fois! bool Init(); // Libération des ressources allouées : ne pas // oublier de l'appeler une fois terminé! void Free(); void DoSomething(); }; class RessourceRAII { public: RessourceRAII(); ~RessourceRAII(); void DoSomething(); }; void TestRessource() { Ressource r; if ( r.Init() ) { try { r.DoSomething(); } catch ( ... ) { r.Free(); throw; // relancer } r.Free(); } else { // heu... que faire, quel est le problème ??? } } void TestRessourceRAII() { RessourceRAII r; // exception levée si échec r.DoSomething(); }
Le RAII, c'est un peu plus de travail pour le concepteur de la bibliotheque, et beaucoup moins pour le programmeur client. Et surtout, c'est un gain énorme en terme de robustesse.

Pense a cela deux seconde : te rends-tu compte que le programmeur d'une bibliotheque te demande a toi de t'assurer de libérer les ressources qu'il a alloué, sinon la fiabilité du systeme est menacée. Il te demande de faire une partie de son boulot, sinon, patatra. Ca ne te choque pas ? Moi ca me pose un gros probleme. Une utilisation basique de sa bibliotheque suffit a casser sa stabilité.

Le RAII remédie a cela, tout en simplifiant l'interface d'utilisation. C'est beaucoup plus robuste.

05/07/2007, 08h44
nikko34

Citation:

L'absence de finally oblige à créer systématiquement des wrappers par dessus la moindre petite structure C si on veut rester exception safe, ce qui prend un temps fou.

Mais il n'y a que le C++ qui peux te renvoyer des exceptions, pas le C... En C tu auras des retours d'erreurs et éventuellement du errno etc..

Citation:

Beaucoup de développeurs refusent d'utiliser les fonctionnalités avancées du C++ pour ce genre de raisons, je ne comptes plus les projets où j'ai pu lire dans la faq "il n'est pas recommandé d'utiliser la stl avec notre biblio" pour ne pas avoir à se préoccuper des exceptions.

j'ai du mal à comprendre là.
05/07/2007, 23h14
zais_ethael

Citation:

Envoyé par Aurelien.Regat-Barrel

Ok, tu es fana de Java, mais essaye d'etre un minimum objectif.:D

Je le suis, je ne vois pas du tout la nécéssité de devoir écrire à la main l'interface publique de nos classes.

Citation:

Envoyé par Aurelien.Regat-Barrel

Je suis plutot adepte d'un précepte de l'XP programming qui dit "les commentaires, c'est mal".

Wash, tu connais bien mal l'extreme programming pour dire une telle annerie. Mais passons sur l'aspect "commentaires" qui est bien éloigné du sujet. Qu'est-ce qui pourrait empécher la génération de javadoc même sans documentation javadoc dans le code? Ca ferait exactement la même chose qu'avec doxygen -> générer un document html sans explications certes, mais avec des listes triées des packages/namespaces, des classes, des méthodes ect... C'est-y pas plus pratique?

Maintenant j'aimerais attirer ton attention sur les deux citations suivantes:

Citation:

Envoyé par Aurelien.Regat-Barrel

Et meme, considérer qu'écrire a la main en entier un wrapper pour un objet est une perte de temps comparé au gain en robustesse/simplicité d'utilisation par la suite, c'est ne pas voir plus loin que le bout de son nez. Les quelques dizaines de lignes écrites pour ce wrapper, ce sont des centaines de lignes économisées a ne pas écrire des bloc try...finally. Si l'on rajoute qu'avec les templates et les smart_ptr cette tache est rapide et aisée, alors...

Citation:

Envoyé par Aurelien.Regat-Barrel

Tu vois, tous les gouts sont dans la nature, et c'est ce que j'apprécie avec C++ : on a le choix.

Qu'est ce qui me dit que je vais devoir en faire 100 des try/finally? Si ça se trouve je veux juste faire deux appels de fonctions. Pourquoi on me laisse pas le "choix" de ce que je vais faire?

Citation:

Envoyé par Aurelien.Regat-Barrel

Pense a cela deux seconde : te rends-tu compte que le programmeur d'une bibliotheque te demande a toi de t'assurer de libérer les ressources qu'il a alloué, sinon la fiabilité du systeme est menacée. Il te demande de faire une partie de son boulot, sinon, patatra. Ca ne te choque pas ? Moi ca me pose un gros probleme. Une utilisation basique de sa bibliotheque suffit a casser sa stabilité.

Sans blague, comme si ce n'était pas le cas partout. Les exceptions comme boost sont bien trop rares pour qu'on puisse se permettre de n'utiliser que des biblios de cette qualité.
06/07/2007, 08h02
Aurelien.Regat-Barrel

Citation:

Envoyé par zais_ethael

Je le suis, je ne vois pas du tout la nécéssité de devoir écrire à la main l'interface publique de nos classes.

Le sens de ma remarque était qu'il ne faut pas mélanger le langage avec les outils qui existent pour ce langage. Quant a écrire a la main l'interface publique, allez, meme si des fois je commence ainsi afin de me donner une idée du design de ma classe, je te l'accorde, c'est pénible. Mais c'est pénible pour celui qui écrit la classe, et profitable pour celui qui l'utilise. Alors au final je trouve ca bien. Je suis toujours partisan du plus d'effort pour le concepteur afin de simplifier pour l'utilisateur.

Citation:

Wash, tu connais bien mal l'extreme programming pour dire une telle annerie. Mais passons sur l'aspect "commentaires" qui est bien éloigné du sujet. Qu'est-ce qui pourrait empécher la génération de javadoc même sans documentation javadoc dans le code? Ca ferait exactement la même chose qu'avec doxygen -> générer un document html sans explications certes, mais avec des listes triées des packages/namespaces, des classes, des méthodes ect... C'est-y pas plus pratique?

La aussi, pas grand chose a voir avec le langage. Pour ma remarque sur l'XP, j'ai du mélanger avec autre chose, mea culpa.

Citation:

Qu'est ce qui me dit que je vais devoir en faire 100 des try/finally? Si ça se trouve je veux juste faire deux appels de fonctions. Pourquoi on me laisse pas le "choix" de ce que je vais faire?

Parce que tu demandes le choix entre un objet robuste et un objet que tu peux facilement fouttre en l'air. Mais si ca peut te consoler, finally existe dans C++/CLI et Sutter solutionne la question du "c'est mieux l'un ou l'autre ?" par "c'est mieux les 2". Mais C++/CLI est managé, donc c'est différent. En C++, y'a pas de seconde chance, pas de repechage. Comme il n'y a pas de GC, si on utilisait finally au lieu du RAII, il faudrait l'utiliser 10 fois, 100 fois plus qu'en Java. Imagine la lisibilité du code...

Citation:

Sans blague, comme si ce n'était pas le cas partout. Les exceptions comme boost sont bien trop rares pour qu'on puisse se permettre de n'utiliser que des biblios de cette qualité.

Est-ce une raison pour trouver ca normal et en rajouter ?
06/07/2007, 14h33
loufoque

le try/finally ça se fait facilement avec C++ avec des macros.
Y'a un truc pour ça dans boost il me semble.
06/07/2007, 22h26
zais_ethael

Je ne vois pas en quoi c'est profitable pour l'utilisateur. Pour ma part il m'a fallu quelques années avant d'oser aller jeter un coup d'oeil dans des headers C, et pourtant ce n'est que du C! Aujourd'hui encore je ne le fais que quand je veux comprendre le fonctionnement d'un lib. Pour le reste je vais uniquement voir des tutos ou la doc doxygen du projet (fort heureusement, tous les projets un peu sérieux en ont), c'est bien moins casse-tête.
Un truc supplémentaire: javadoc n'est pas un juste un outil, il fait partie de la norme java. Et puis il n'y a pas que ça, il y a aussi les explorateurs de classes (mais je n'aime pas trop).

Citation:

Envoyé par Aurelien.Regat-Barrel

Parce que tu demandes le choix entre un objet robuste et un objet que tu peux facilement fouttre en l'air. Mais si ca peut te consoler, finally existe dans C++/CLI et Sutter solutionne la question du "c'est mieux l'un ou l'autre ?" par "c'est mieux les 2". Mais C++/CLI est managé, donc c'est différent. En C++, y'a pas de seconde chance, pas de repechage. Comme il n'y a pas de GC, si on utilisait finally au lieu du RAII, il faudrait l'utiliser 10 fois, 100 fois plus qu'en Java. Imagine la lisibilité du code...

Ben voila, c'est mieux les deux. Tu as l'air de penser que je voudrais absolument programmer en C++ comme en Java, je serais bien fou de vouloir une telle chose. J'ai beau désirer l'intégration du finally dans la norme, ça ne m'empèche pas de faire des classes nickel chrome quand à la gestion de la mémoire, j'ai juste pas envie de devoir en taper 20 pour utiliser une biblio C dans un projet de petite taille.
Juste une remarque: ça n'a rien à voir avec le C++/CLI, c'est une fonctionnalité qui existe dans Visual C++ depuis des années. Quelques autres compilateurs le permettent aussi (je me souviens d'un certain "cxx" qu'on utilisait en cours).
07/07/2007, 13h36
JolyLoic

Pour le finally, je n'ai jamais ressenti le besoin de l'utiliser en C++, et je serais contre son introduction si elle était proposée, car pour moi, ça incite à un mauvais style de programmation.

Pour ce qui est que le RAII prendrait de nombreuses lignes à mettre en place, je ne suis pas d'accord. Avec les shared_ptr, le RAII est monoligne.

Code:

shared_ptr<void> monPointeurC(allocatePointerC(), freePointerC);

Pour la séparation interface/implémentation, le problème principal n'est pour moi pas tant la lecture (les outils font tout ce qu'on veut) mais à l'écriture, surtout dans les grands projets : Comment confier à un développeur une interface pré-écrite et qu'il n'a pas le droit de modifier sans en référer aux architectes.
09/07/2007, 01h16
Aurelien.Regat-Barrel

Et voilà l'article :

Gérer ses ressources de manière robuste en C++

qui explique la même chose que l'unique ligne de code Loic, mais en 20 pages http://arb.developpez.com/smileys/oups.gif
09/07/2007, 01h54
Alp

J'ai lu ton article et j'ai laissé un commentaire.

zais_ethael > je pense que ta vision des choses est quand même déformée par le fait que tu as visiblement une certaine expérience en Java et que tu as visiblement bien plus programmé en Java qu'en C++. Lorsque tu conçois des bibliothèques, tu dois avoir une vision "Java" prépondérante, que tu programmes en C++ ou non.
A l'inverse, un grand nombre d'entre nous possède à l'inverse un raisonnement fortement influencé par le C++. Cela pèse beaucoup dans la conception, et cela se ressent.
Pour nous, le RAII est la solution logique au problème du code exception-safe, qu'il s'agisse de wrapper des bibliothèques C ou autres. En Java il en est autrement.
Important également : en C++, au fur et à mesure de l'apparition des nouvelles techniques comme le RAII, il y a toujours eu des améliorations et expansions de ces techniques, et bien d'autres techniques basées sur celles venant de paraître ont vu le jour. Principalement le RAII, car c'est le sujet principal ici, mais aussi d'autres techniques, ont grandement simplifié la programmation en C++. Il serait par conséquent "absurde" (quoi, j'y vais un peu fort? :mouarf:) d'introduire par exemple try...finally dont l'utilisation serait bien moins simple que le RAII.

Pour comparer, tu peux adapter le code de l'exemple de Aurélien avec des blocs try...finally, en imaginant qu'ils aient été intégrés au C++.
10/07/2007, 17h01
zais_ethael

J'ignorais que shared_ptr contenait cette fonctionnalité, c'est bon à savoir ça :)
Néanmoins, pour d'autres raisons, je n'apprécie pas trop cet exemple.
Je peux comprendre la problématique d'une classe qu'on aurait préféré ne pas être container aware, mais forcer l'utilisation d'un shared_ptr pour les utilisateurs de la biblio n'est pas une bonne idée non plus, surtout quand on parle de sockets!
Pour expliquer ceci, je vais d'abord faire une supposition: nous savons tous que contrairement à un garbage collector un smart pointer à comptage de réfèrences est déterministe. Néanmoins, en tant que programmeur, est-on vraiment en mesure de connaitre le moment de la destruction de l'objet pointé? Non, il faudrait pour cela surveiller tous les endroits dans le projet où l'objet est susceptible d'être utilisé, ce qui devient bien vite impossible ou témoigne d'une très mauvaise programmation. Il est donc préfèrable de considérer qu'un shared_ptr est non déterministe.
Donc, dans le cas où le destructeur de l'objet est sensé faire autre chose que de la simple libération de mémoire (ce dont on ne se préoccupe plus trop de nos jours, tant qu'il n'y a pas de fuite), nous n'avons aucun moyen de savoir quand cette action sera réalisée.
C'est excessivement grave dans le cas de sockets puisqu'il est impossible d'en ouvrir un sur un port déja ouvert. Si pour une raison ou une autre, notre programme doit fermer puis réouvrir des ports de temps à autre (le port d'envoi de données pour un serveur ftp par exemple), on sera bien embêté puisque la réussite de cette action dépendra du déroulement du programme (qu'en tant que bon programmeur nous préfèrerons considérer comme aléatoire).

Ton exemple est donc un exemple typique où nous préfèrerons laisser l'utilisateur de la biblio gérer le cycle de vie de l'objet à sa guise. L'idéal serait un auto_ptr, parcequ'on peut en faire tout ce qu'on veut contrairement au shared_ptr. L'ennui est que l'auto_ptr ne peut contenir ce foncteur spécial pour la destruction de l'objet. Alors on a deux possibilités:
- soit on fait quand même un objet containeur aware
- soit on rajoute une couche supplémentaire entre l'auto_ptr et l'objet, n'ayant d'autre but que d'informer le manager de la destruction.

Citation:

Envoyé par JolyLoic

Pour la séparation interface/implémentation, le problème principal n'est pour moi pas tant la lecture (les outils font tout ce qu'on veut) mais à l'écriture, surtout dans les grands projets : Comment confier à un développeur une interface pré-écrite et qu'il n'a pas le droit de modifier sans en référer aux architectes.

Il y a des diagrammes UML pour ça, voir les interfaces suivant les cas. Sans oublier que les headers C++ ne contiennent pas uniquement l'interface, il y a aussi les méthodes private. Néanmoins il est vrai que ton point de vue est intéressant.

En dehors de ça, je me demande si on s'est pas un peu écarté du sujet de départ la. Oo

Citation:

Envoyé par zais_ethael

Néanmoins, en tant que programmeur, est-on vraiment en mesure de connaitre le moment de la destruction de l'objet pointé? Non, il faudrait pour cela surveiller tous les endroits dans le projet où l'objet est susceptible d'être utilisé, ce qui devient bien vite impossible ou témoigne d'une très mauvaise programmation.

Dans cet exemple, ResourceManager sait très exactement quand l'objet qu'il a alloué est libéré, sans rien surveiller en particulier, via ResourceDeleter. Ou alors je n'ai pas compris ce que tu voulais dire.
Cet exemple est tiré d'un cas réel que j'ai codé, où en plus de mettre à jour le compteur de ResourceManager, un signal était émis par le Manager pour signaler à ses observeurs que son état avait évolué. S'il s'agit d'un gestionnaire de téléchargements par exemple, cela permet à tout plein de classes UI de s'abonner à un évènement "le nombre de téléchargements en cours a changé" et de mettre à jour leur affichage. C'était vraiment très souple d'utilisation.

Citation:

Envoyé par zais_ethael

C'est excessivement grave dans le cas de sockets puisqu'il est impossible d'en ouvrir un sur un port déja ouvert. Si pour une raison ou une autre, notre programme doit fermer puis réouvrir des ports de temps à autre (le port d'envoi de données pour un serveur ftp par exemple), on sera bien embèté puisque la réussite de cette action dépendra du déroulement du programme (qu'en tant que bon programmeur nous préfèrerons considérer comme aléatoire).

Tu peux controler le cycle de vie de tes objets de la même manière avec un shared_ptr qu'avec un pointeur brut. Exemple:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 SocketPtr s = SocketManager::New(); if ( s ) { while ( /* condition */ ) { if ( s->Open( 21 ) ) // port FTP { // effectuer un transfert TransmitFile( s ); // pour l'exemple s->Close(); } } s.reset(); // ou SocketManager::Free( s ); }
Seule la derniere ligne change en fonction que SocketPtr est un shared_ptr ou un pointeur brut Socket*. Par contre, que se passe-t-il si la fonction TransmitFile est buggée et plante en plein milieu, en laissant remonter une jolie exception catchée plus haut ?
Si c'est un shared_ptr, le port est correctement fermé, le manager est informé de la libération de la Socket, et il est possible de continuer à bosser. Si c'est un pointeur brut, eh bien...

Citation:

Envoyé par zais_ethael

Ton exemple est donc un exemple typique où nous préfèrerons laisser l'utilisateur de la biblio gérer le cycle de vie de l'objet à sa guise. L'idéal serait un auto_ptr, parcequ'on peut en faire tout ce qu'on veut contrairement au shared_ptr. L'ennui est que l'auto_ptr ne peut contenir ce foncteur spécial pour la destruction de l'objet. Alors on a deux possibilités:
- soit on fait quand même un objet containeur aware
- soit on rajoute une couche supplémentaire entre l'auto_ptr et l'objet, n'ayant d'autre but que d'informer le manager de la destruction.

Je ne comprends pas ce que auto_ptr permet de faire que shared_ptr ne peut pas. Pour la seconde solution, c'est précisement le rôle de ResourceDeleter. Tu as peut être mal compris cela, si c'est le cas dis moi ce qui n'est pas clair, que j'essaye d'améliorer :D

11/07/2007, 12h19
zais_ethael

Avec un shared_ptr, c'est comme si ton objet était contenu dans un espace de la mémoire sur lequel tu n'as aucune prise, on ne peut le détruire, on ne peut le transférer dans un autre type de smart pointer. Ceci est parfaitement logique si on imagine un peu les difficultés de sa conception. Le seul moyen de de détruire l'objet est de faire tomber toutes les réfèrences, ce qui est difficile à gérer et il est préfèrable de ne pas s'y essayer. Voila la raison pour laquelle je considère qu'ils ne devraient être utilisés que dans un but de libération de mémoire pur et simple.

Je n'ai jamais parlé de pointeur brut, c'est de toutes façons une mauvaise idée d'en renvoyer en argument d'une fonction. Dans ce genre de cas, je préfèrerais utiliser un auto_ptr parcequ'ils sont géniaux pour opérer des transferts de gestion de cycle de vie. Quand l'utilisateur reçoit un auto_ptr, il sait qu'il est le seul à gérer l'objet et qu'il peut en faire ce qu'il veut. Si il juge qu'il a besoin d'un shared_ptr, il peut simplement faire shared_ptr<bidule> machin(auto.release()), la différence est que c'est l'utilisateur de ta biblio qui décide, toi tu te contente de faire une fonction qui fonctionnera même si il oublie de récupérer le résultat.

Si dans ton exemple, tes objets ressources avaient par exemple été des images (grosse occupation de mémoire), je ne dis pas, obliger l'utilisateur à utiliser un shared_ptr ne portera probablement pas à conséquences. Mais dans le cas de sockets, où la libération du port dépend de la destruction de l'objet, il serait plus simple de conserver une entité unique pour gérer le cycle de vie de l'objet. Et c'est plus difficile avec un shared_ptr.

PS: Oulala, que je n'aime pas les typedefs sur des pointeurs.

Citation:

Envoyé par zais_ethael

Le seul moyen de de détruire l'objet est de faire tomber toutes les réfèrences, ce qui est difficile à gérer

Tu y arrives pourtant très bien en Java non ?

Citation:

Envoyé par zais_ethael

Mais dans le cas de sockets, où la libération du port dépend de la destruction de l'objet, il serait plus simple de conserver une entité unique pour gérer le cycle de vie de l'objet. Et c'est plus difficile avec un shared_ptr.

Hum... Je comprends enfin ce qui te chagrine : "la libération du port dépend de la destruction de l'objet". Ce n'est pas le cas, rien ne t'empeche de coder une fonction Close(). Par contre, dans mon exemple, le manager n'en sera pas informé, je pense que c'est ce qui te gêne.

Le fait est... que c'est volontaire. J'en ai pas trop parlé dans mon article, mais la sémantique de mon manager avec nombre limité d'instance est de gérer l'attribution des ressources, pas leur usage. Une fois qu'une ressoure t'es accordée, rien ne t'empêche de l'utiliser plusieurs fois, si elle le permet.
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 SocketPtr s = SocketManager::New(); if ( s ) { while ( /* condition */ ) { if ( s->Open( 21 ) ) // port FTP { // effectuer un transfert TransmitFile( s ); // pour l'exemple s->Close(); } } s.reset(); // ou SocketManager::Free( s ); }
Dans cet exemple, je peux utiliser plusieurs fois ma Socket sans en redemander une a chaque fois. Par exemple, si mon téléchargement est brusquement interrompu, je peux tenter de réouvrir la Socket et de le reprendre, et ceci plusieurs fois dans une limite de 5 tentatives par exemple.
Dans un contexte multithread, s'il fallait effectuer 4 appels à New() supplémentaires pour reprendre le téléchargement, un autre thread pourrait piquer la Socket qui vient dêtre fermée... Un autre point est qu'il faudrait effectuer 5 appels systeme au lieu d'un seul, ce qui en fonction de la ressource peut etre couteux et considéré comme du gaspillage si elle est facilement réutilisable une fois créée.

12/07/2007, 11h55
zais_ethael

Citation:

Envoyé par Aurelien.Regat-Barrel

Tu y arrives pourtant très bien en Java non ?

Bien sur que non. En java on se préocuppe de temps en temps de ne pas laisser des réfèrences sur des objets devenus inutiles histoire de ne pas encombrer la mémoire mais sans plus, il n'y a aucun destructeur de toutes façons, donc aucun interet de connaître le moment de destruction d'un objet. Ca veut aussi dire, par exemple pour un stream java, qu'on sera obligé d'appeler sa méthode close() et ceci toujours dans un try/finally sous peine d'avoir un "oubli" de fermeture si une exception est lancée.

Citation:

Envoyé par Aurelien.Regat-Barrel

Hum... Je comprends enfin ce qui te chagrine : "la libération du port dépend de la destruction de l'objet". Ce n'est pas le cas, rien ne t'empeche de coder une fonction Close(). Par contre, dans mon exemple, le manager n'en sera pas informé, je pense que c'est ce qui te gêne.

Une méthode close() ne serait qu'une facilité, exactement comme celle de fstream, mais il ne faut en aucun cas ne compter que sur cette méthode (et si une exception était lancée à la ligne juste avant son appel?). A moins de créer une classe supplémentaire pour l'appeler avec du RAII (un peu comme avec les locks de boost::thread), il faut principalement compter sur l'appel au destructeur.

Sinon, pour ton exemple, je croyais que le fait de compter le nombre d'instances était juste ludique (puisqu'en pratique, ben... ça sert à rien) et qu'en appliquant ce principe aux sockets le ressource manager aurait pour but de vérifier si un port est libre ou non.
Apparament, ton système a plutot pour but de créer un pool de connexions, les threads n'y ayant pas droit devant se retrouver en attente. Suivant la façon dont est programmée ton applic, il est possible que toutes les ressources finissent par être libérées à un moment où un autre. Mais en ne controlant pas leur cycle de vie par toi même, il est probable qu'elles ne soient pas libérés pile au moment ou tu n'en as plus besoin, ce qui peut nuire aux performances.