Discussion :

[rems14]

Bonjour à tous !

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

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

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

[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

[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 ???

[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

[Mat007]

Salut,

Juste je me demandais ce que signifiait :

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.

[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

[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 ?

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

[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

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

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

[Aurelien.Regat-Barrel]

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

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.

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

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

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

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.

[Aurelien.Regat-Barrel]

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.

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.

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

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

[zais_ethael]

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.

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

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++???

[Aurelien.Regat-Barrel]

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

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 :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
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.

[nikko34]

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

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

[zais_ethael]

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

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

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:

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

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

[Aurelien.Regat-Barrel]

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.

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.

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

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 ?