Ca existe un soft permattant d'afficher sous forme de graphe les dépendances des classes d'un programme ?
Ou bien des fichiers .h etc ?  
 
 

Doxygen le fait, il t'affichera toutes les inclusions des fichiers sous forme de graphe. Essaye tu aimeras certainement (pas forcement pour cette fonctionnalite d'ailleurs)
 
http://www.stack.nl/~dimitri/doxygen/index.html

wouaw je pensais que y avait peu de cahnces que ça existe mais si  

putain c super long  

comment ca c'est lent ?
 
sinon pour les beaux graphs il faut graphviz
http://www.research.att.com/sw/tools/graphviz/
 
exemple : http://xml.apache.org/xerces-c/api [...] e_hpp.html
 
sinon y'a pleins d'options dans le fichier de conf et y'a un utilitaire graphique pour le configurer
 
sous linux c'est inclue dans toutes les distributions recentes et c'est tres facile a utiliser

la premiere fois que je l'ai lancé c'etait super lent, apres ça allait.
Regarde ce que j'ai pondu avec les sources de emule.
http://perso.wanadoo.fr/mirak63/do [...] yemule24b/

berk de la prog MFC avec des C partout
aucune doc
aucune separation de l'interface graphique et du moteur
des CString, des char *, des BOOL et bool, des pointeurs partout, y'a jamais de const, y'a pleins de donnees membres en public, pas de STL, jamais d'assert...
on voit trop qu'il y a plusieurs gars qui codent
 
ba bonne chance et amuse toi bien
 
enfin je dis ca mais emule je l'utilise tout les jours et il marche trop bien, merci aux developpeurs

ouep certaines parties de codes sont atroces.
Enfin la base de emule a été pondue par un seul type.
le fait que y a pas de diff entre le moteur et l'IG rend son portage sous emule plutot casse gueule.
Un truc que je capte pas c'est pkoi ils utilisent des pointeurs pour certains objets comme la listes d'upload ou de download je comprend pas trop.

 
??? Ben les pointeurs c'est super utile !

 
oui je suis au courant    
Mais là je vois pas l'interet.
Ou alors y a des classes dérivées et du virtual mais vu que l'objet doit etre unique, je vois pas trop.  
A je crois que je comprends, ils doivent connaitre le passage par reference des objets  
Comme le dit tanguy c pas impossible etant donné que y a pas un seul const dans le code et pas un passage par refence non plus.  

exactement !
 
il suffit de comparer avec un truc bien programmer : Qt
http://doc.trolltech.com/3.1/qstring.html
ba au miracle y'a des const et des references partout !
 

 
bof a chaque fois que l'on pense utiliser un pointeur en reflechissant on se rend compte qu'une reference ou meme juste par valeur peut remplacer le pointeur = c'est beaucoup beaucoup beaucoup mieux a tout point de vue!
surtout pour les passages de parametres, y'a rarement besoin de pointeurs et c'est tant mieux
 
Le probleme du C++ c'est pas le C++ lui meme, c'est les developpeurs qui gardent les habitudes du C en C++ (char *, pas de const, des pointeurs partout, pas de decoupage, on reinvente la roue, pas de STL, pas de template...)
 
Il faut developper en C++ de la meme maniere qu'en Java
 
 
le plus dur en programmation c'est de faire simple, efficace et elegant
 
c'est marrant j'ai aussi un pote qui travaille sur le code d'emule et il a deja porte deja des parties sous linux

ouais.
D'ailleurs c marrant car bien qu'ayant commencé le c++ cette année en fac, je trouve que le code est atroce.
J'ai pas eu le temps d'avoir de mauvaise habitude avec le c vu que je l'ai fait vite fait en une semaine et que j'avais fait du pascal avant. Le pascal c'est d'ailleurs vahement proche du c. Le compilateur est ptetre plus gentil par contre    
Sinon ce qui m'interresse c'est pas le portage sous linux, mais plutot implementer le protocole de overnet.
Ils l'ont deja fait pour mldonkey mais c'est du ocaml. Comme j'ai fait du caml en fac benh c tentable
Dur mais bonfo ce qu'il fo pour ce motiver.

la reference et les pointeurs n'ont rien avoir et ont des propriétés différentes.
 
une reference ne peut pas etre null.
 
une variable membre declarer en reference doit etre OBLIGATOIREMENT initalisé dans le constructeur.
 
c'est les différences qui me viennent à l'esprit à 1h du mat et grippé mais il y en a surement d'autre.
 
j'ai jamais essayé des cast de reference mais a mon avis ca doit pas etre terrible ( à vérifier ).
 
les pointeurs c'est bien, encore faut il savoir BIEN s'en servir ( c'est un peu comme tout dans la vie )
 
quand vous parlez de reference et de java, c'est tout faux, java n'utilise que des pointeurs.

mais personne dit le contraire.
il est pas qu'une heure du mat on dirait  

nan sans dec !?
 
bon tout le monde est au courant, tu nous apprend rien, merci d'avoir sortie ta science
 
c'est pas parceque c'est different que l'on peut pas remplacer des pointeurs par autre chose (et c'est de cela que l'on parle).
 
tu preferes ca : toto * getToto(Titi * titi);
ou ca : toto & getToto(const Titi & titi);
 

personne n'a dit que Java utilisait des references
franchement je m'en fou de ce que Java utilise, d'ailleurs c'est pas plus des pointeurs que des references.
 
les pointeurs et les cast faut les fuire comme la peste.

 
Bizarrement je te trouve bien catégorique pour quelqu'un qui dit "savoir quelquechose"....
Pour ne pas saisir l'avantage du pointeur .... je resterai humble à ta place.
Ou alors est ce moi qui n'en perçoit pas le grand inconvénient ...  

benh c'est pourtant simple.
Quand tu utilises un objets et et que tu te serts d'un pointeur sur cet objet pour le manipuler, et bien plus d'appel de destructeur dessus en sortant de la zone ou il est déclaré. Faut declarer avec des new. On peut pas mettre de const pour blinder.
C'est moins lisible les déclarations de nouvelles variables etc.
Effectivement y a toujours moyen de remplacer des references par des pointeurs, et l'inverse est pas vrai (sauf pour les appels de destructeurs en sortie de zone de déclaration), mais c'est moche et beaucoup plus "risqué".
 
Chez po ptetre que g rien compris apres tout  

Perso je prefere les ptr pour des raisons de lisibilités. Ce que je n'aime pas avec les references c'est qu'a la lecture du code on se sait pas trop si une variable est passé en input ou input/output. Faut aller rechercher dans le proto, et c un peu chiant. Avec un ptr on voit tout de suite l'indirection, pour un peu que la var soit un type de base ca indique que c de l'input output.
 
Ceci dit, les "fuir comme la peste" me semble un tantinet extremiste, comme les casts. Des fois on est bien obligé, et meme parfois qu'il faut faire des casts descendant (je dis ca paske je viens de voir sur un site que "cai pas bien" alors que j'arrete pas d'en faire ces tps ci, ca m'a fait sourrire)

 
+1

 
Pourquoi diable as tu besoin de voir que c'est une indirection ?
l'un des interets des references c'est justement que ca simplifie l'ecriture (et aussi t'as pas besoin de te soucier du delete)
C'est transparent pour l'utilisateur.
 
donc toi tu preferes cette ecriture : toto * getToto(Titi * titi);
 
En gros pourquoi faire simple quand on peut faire compliquer ? pourquoi utiliser une ecriture qui simplifie le code alors que l'on peut foutre des pointeurs partout et avoir pleins de problemes ?
 
edit : oups j'avais pas vu que tu parlais des params en entree/sortie, dans ce cas la c'est vrai que c'est pas toujours clair et qu'un pointeur n'est pas une mauvaise idee. enfin les params en entree/sortie c'est pas souvent que l'on en a
 

 
t'as deja passe un soft sous un memory leak checker performant ?
les pointeurs croisees, les delete que l'on oublie, le code complexe... je suis con vous etes des dieu du codage et vous oubliez jamais un delete et vous savez toujours quand le faire.
malheureusement si vous vous connaissez parfaitement votre code et donc vous savez comment l'utiliser (encore que souvent c'est pas evident) ba un gars qui veut utiliser votre code sans le connaitre parfaitement il a toute les chances de se planter.
 
evidemment que l'on est oblige de les utiliser dans certain cas mais a chaque fois qu'on le fait il faut bien reflechir si il n'y a pas une solution plus elegante et moins dangereuse.
 
C'est simple et clair les pointeurs il faut eviter autant que possible ./

 
 
L'indirection m'informe qu'il y a de forte chance pour la fonction appelée modifie la valeur de mes parametres. La reference masque cette information. Ce qui te plait dans la reference me perturbe, moi.
 
 

 
Tout dépend des cas, mais en pratique j'utilise tres majoritairement les pointeur sur les references
 

L'ironie a deux balles te décribilise completement
 

 
Non, du code vieux d'y a seulement 2 mois ecrit par ma pomme peut parfois me laissé reveur, mais j'essaye de commenter, surtout quand je fais des trucs douteux
 
 

 
Pointeur ou non, reference ou pas, quand on appele du code sans savoir ce qu'il veut/fait, ca risque effectivement de merder. Pour moi il s'agit surtout d'un probleme de documentation.
 
 
 

 
Je ne suis pas motivé pour faire des contorsions pour eviter l'utilisation de pointeur. Effectivement, ils sont peut etre moins secure que les references (passage de pointeur pointant sur n'imp....) mais dans l'ensemble il ne sont pas si effrayant que ca (a mon avis). C'est une question d'habitude et de style de programmation
 

ouha tu reponds vite j'ai edite mon precedent msg
 

 
On remarquera que c'est exactement le meme probleme avec les pointeurs (dans le cas ou l'on utilise pas les references mais les pointeurs a la place) :
on a une classe a soi qui est assez grosse, on ne va pas la passer par valeur ca ferait une copie inutile, donc on le passe par pointeur (ba oui parcequ'on aime pas les references et qu'on utilise les pointeurs). mais le passage par pointeur il nous indique jamais si on modifie la valeur du param ou pas (faut lire la doc et meme souvent le code source si on veut vraiment savoir) !
 
Sauf que avec une reference on le sait tout de suite parcequ'il y a un const et que par convention quand tu fais un passage par reference on fait en sorte que ca ne modifie pas la valeur car on met un const avec.
 
donc si on a un param juste en entree : void toto(const Titi &);
 
si en entree/sortie : void toto(Titi *); mais moi j'ai pas souvent des entree/sortie et j'evite parceque c'est trop complique (eh oui) :  
Il faut imperativement que les fonctions fassent une seule chose, les debutants font regulierement des fonctions qui font plusieurs choses a la fois genre je te complete un tableau et je te ressort une valeur avec un calcul et quand tu veux utiliser le code tu comprend rien et le gars qui l'a pondu pas beaucoup plus parcequ'il ne se souvient plus (d'ailleurs c'est la pire des erreurs imho).
un param en entree/sortie ca veut regulierement dire que l'on peut splitter la fonction.
 
Donc ici les references c'est pas parfait mais c'est mieux que les pointeurs, sinon ils se seraient pas fait chier a introduire les references dans le languages.
 

 
oui c'etait une remarque debile
 

 
Nan je ne suis pas du tout d'accord, il faut qu'il y ai aucune ambiguite et le minimum de risque de se tromper. Si c'est pas le cas y'a 99% de chance que le gars va plonger dedans documentation ou pas. c'est tout le probleme de bosser en equipe.
Il faut que l'on comprenne du premier coup d'oeil et que l'on puisse l'utiliser le plus simplement possible sans lire toute la doc en detail.
 
C'est comme ton nouvel aspirateur, tu t'amuses a lire la doc en detail ? nan (au mieux tu la parcours). tu regardes les boutons (les methodes) de l'aspirateur (la classe) et tu sais l'utiliser sans te planter.
 
sinon ca ferait longtemps que j'appelerais les methodes toto1() toto2() toto3() puisque tout est indique dans la doc (oui c'est extreme mais ca aide quelque fois de pousser un raisonnement a l'extreme pour bien comprendre).
 

 
justement je dis une solution ELEGANTE.
elegant pour moi ca veut dire sans contorsions.
Les pointeurs ne sont pas effrayants parceque justement on se croit fort et c'est un tort (ma remarque debile plus haut c'etait pour ca). Ca te retombe toujours sur la gueule un jour ou l'autre, que ce soit un gars qui utilise ton code ou l'inverse. Et c'est tres vicieux, on s'en rend compte avec le memory leak checker (oui je sais ya personne qui utilise ca, personne ne fait de procedure de test ect...) et la ca fait mal parceque faut retourner dans du vieux code.
 
j'ai l'exemple ou l'on voulait ecrire dans un fichier (ou un truc du genre je sais plus exactement). la solution la plus simple et la plus direct c'etait on passe par un void * avec un cast comme ca on peut tout ecrire sans se faire chier. finalement on a opte (moi j'etais pas d'accord) pour virer le void * parceque c'est mal (tm), et ca nous a donne un truc trop complique -> ca c'est une contorsion et c'est con.
 
il n'y a pas de solution parfaite, on applique la politique du "moins pire" et dans certain cas rare c'est le pointeur.

 
 
 
vi j'avais surtout parlé pour les types de bases.
le const est effectivement une bonne protection mais a la lecture du code  on ne le voit pas non plus (par contre la le proto est plus informatif, c vrai). Enfin dans tous les cas pour autre chose que des types de bases on revient un peu au meme.
 

 
Oué ben on va dire que ca depend bpc des cas, par ex la j'ai une fonction de pas 50lignes qui doit avoir 4/5 param en entrée sortie . C aussi une question de style (par ex se garder le retour pour un code d'erreur et faire passer le reste en entrée sortie. DirectX a quasiment toutes ces fonctions sous cette forme, l'idée se defend).
 
 
Sinon pour le reste je cprends ton point de vue, et il se defend tout a fait (sauf le coup des fonctions toto1, toto2 etc etc ). Bon, on va pas entrer en guerre religieuse la dessus non plus
 
Perso je viens du C, je pense que bpc de ma facon de programmer vient de la (FILE * a la place des fstrems, pointeur, pas de const....). A mon avis, le pire que l'on puisse faire c'est de melanger des bouts de code utilisant pointeur, ref, const a tout va. et vu que je bosse sur un projet utilisant a 99% des ptr, ben...... vala
 
 
je n'utilise effectivement pas de memory leak checker parce que je n'en ai pas (et ptet aussi paske j'ai peur du resultat )

 
ba les types de base (ca depend ce que tu appelles type de base) moi je les fait passe par valeur.
par exemple std::string pouf par valeur.
 
on va me repondre que ca fait une recopie, ba nan y'a un compteur de reference dans la classe string (dans les bonnes implementations, je parle pas de MS). je me sers tellement de std::string que je trouve que ca rend plus lisible le code.
parceque "const string &" je prefere "string" c'est plus court et des que je peux le faire pour d'autre classe je le fait dans la limite du raisonnable.
 

 
moi je trouve pas que ca soit un gros probleme de ne pas utiliser toutes les possibilites du language ou de mal les utiliser (on s'ameliore toujours) mais le gros probleme c'est :
 
- la complexite des fonctions : toujours faire le plus simple possible. c'est le plus gros probleme et de tres loin
genre le truc qui fait 600 lignes et qui fait 10 truc a la fois : impossible a debugguer
 
- la non separation du code
moi j'essaye de completement modularise le code, je check meme les include pour voir si j'ai pas fais une erreur : si y'a un include ca veux dire qu'il y a une dependance
 
- la documentation
 
si tout ces elements sont reunis on pourra tres facilement faire du refactoring, ameliorer les passages de params, virer les pointeurs...
 
 
pour revenir au sujet, emule se conforte au 1er point et c'est deja tres bien, j'ai deja vu du code 100x pire.
 

 
oui je confirme.
entre un programme qui marche (genre emule) et un programme qui a :
- des belles fonctions claires, simples et courtes
- une belle doc avec doxygen/javadoc
- une procedure de test systematique a la extreme programming ou autre (moi souvent j'ecris dans un fichier tous les resultats detailles et ensuite je fais un diff avec la nouvelle version pour voir si ya des pb, enfin ca depend du programme)
- une separation complete des elements : modularisation
- check des fuites memoires
- l'utilisation correctes des possibilites du language (STL, template, reference, const...)
- une compilation avec -Wall -ansi -pedantic (et un bon compilo c'est essentiel)
- l'utilisation de libs bien foutus
- du profilage
...
 
ba c'est le jour et la nuit, le pb c'est que quand on code pour s'amuser ba ca fait chier de faire la doc, de checker les fuites memoires etc

chui d'accord avec tanguy la dessus.
Enfin a la limite si je vois une fonction (une methode pardon ) avec des const en param c clair que c'est du entrée uniquement.
Si jamais y a pas de const sur un passage par reference benh la c'est du entrée/sortie ou alors le const c'est perdu dans les bois .

Je trouves bien des avis qui me semblent bizarres...
 

Tout allait bien jusque là et... patatras !
C++ ne fait pas des new partout, et s'utilises différemment.
 

Recevoir de tels objets par valeur est surtout un truc de flemmard pour ne pas avoir à spécifier les const là où il en faudrait (fonction et appelant).
Compter sur la gestion interne supposée d'une classe pour ratraper le coup, tsss...
 

Certes une valeur ne peut pas être une sortie (directe).
Mais c'est la 'constance-sur' de la référence/pointeur qui l'indique si c'est une entrée (const) ou sortie (non const).
Le const d'une référence/pointeur indique que l'objet ne peut être modifié par son intermédiaire, pas qu'il est invariant.
 

• Recevoir par référence, à moins que les arguments soient suffisamment petits ou tellement utilisés que la recopie soit plus simple.
• Recevoir par référence ou pointeur si on a besoin de préserver l'identité.
• Utiliser un pointeur au lieu d'une référence si on a besoin de changer le référent en cours de route (parcours), ou de la valeur null, ou pour rendre le bas niveau explicite.

La transmission par valeur crée une copie locale à la fonction.
L'argument transmis peut être const, c'est sans incidence.

La transmission par référence permet de conserver l'identité de l'objet, et de faire de tests comme (&arg1==&arg2).

La transmission par pointeur est similaire à celle par référence, mais rend le travail de parcours/identité explicite et requiert la coopération de l'appelant.

(Les pointeurs peuvent être 'T*const', c'est de peu d'intérêt ici)

euh je crois pas qu'on puisse metrte de const sur un passage de pointeur.
De toutes façon les const agirait sur la valeur du pointeur (l'adresse), et protegerait pas l'objet lui même, contrairement au reference.
( c ça ? )

Un pointeur sur un objet constant ca existe si. Et non pas un pointeur constant sur un object modifiable. Ce dernier cas n'a aucun interet de toute façon car le pointeur est passé par recopie
 
Je crois que par defaut c'est le sens de const Machin *

faut pas deconner non plus
quand je dis qu'il faut developper en C++ comme en Java faut pas prendre ca au pied de la lettre, tout le monde est au courant qu'il y a des differences et qu'il faut en tenir compte.
 

 
oui bien sur, donc tu ecris "const int &" j'imagine parceque tu es pas un flemmard ?
ah non tu ecris "int" ? mais pourquoi ? ha parceque c'est un type de base ! et puis ca prend autant de passer la reference que par valeur.
ba moi je considere la classe std::string comme une classe de base tres importante au meme titre que int (oui je sais c'est pas une classe) et je l'utilise tout le temps, a ce titre je me permet de ne pas mettre de "const &"
En pascal string est de base dans le langage
 
 
un const pour un pointeur signifie que l'on ne peut pas modifier la valeur du pointeur (une adresse) : on ne peut pas changer la variable sur lequel pointe le pointeur.
par contre on peu sans prob modifier le contenu de la variable
en gros ca n'a pas beaucoup d'interet et ca ne remplace pas un const &
 
 
j'oubliais dans la liste des trucs a faire : faut rajouter CVS c'est trop bien

 
bon ben imagine que je sois un debutant (pas trop dur a imaginer puisque c'est le cas )
il faut que je prenne comment ton explication?
Vu que je ne suis pas au courant des differences dont il faudrait tenir compte et celle dont il faut tenir compte ?
 
LeGreg

 
  tu veux dire la valeur du pointeur je suppose.

il y a des confusions alors:
 
pointeur const :
T* const p;
on peut appeler toute methode const ou non const sur p
par contre on ne peut plus changer la valeur de p
p = toto; // c'est exclu.
 
Et ca sert autant que toute variable const.
 
pointeur vers objet const:
const T* p;
on peut appeler toute methode const sur p et aucune methode non const. Une methode const peut neanmoins modifier des champs mutables de p.  
p = toto; // c'est autorise
Attention les pointeurs membres de T sont const mais ne pointent pas vers des objets const eux-meme. Pour proteger ces membres il faut les rendre prives et n'autoriser l'acces que par des accesseurs surcharges pour une instance de T const:
const S* T::getS() const {return _pToS};
et
S* T::getS() {return _pToS};
 
pointeur const vers objet const:
const T* const p;
meme que ci-dessus mais en prime on a :
p = toto; // c'est exclu.
 
NB: En java pour la constness il faut passer par des interfaces.
 
LeGreg

J'utilises souvent la programmation générique par template.
Ne connaissant pas l'encombrement des types à l'avance, j'utilises les références.
Et si la fonction peut venir inline, c'est mieux pour l'optimiseur.
 
Je sais que ça peut être pénible d'utiliser const, mais ça permet vraiment de capturer des bogues.

 
moi je met en inline pratiquement que les accesseurs. parceque souvent on doit faire des includes supplementaires dans le header si on met des methodes un peu plus grosses et ca j'aime pas : en gros c'est du cas par cas je trouve (a la gueule du client)
de toute facon si je veux changer j'ai juste a cliquer sur la methode et a mettre inline : Together s'occupe du reste
 

 
mais justement on est bien d'accord !
on parle des const depuis le debut en soulignant que emule ne les utilisent pas et que c'est pas bien !
 
je ne remet pas en cause les const, bien au contraire
 
je dis simplement que j'utilise string de la meme facon que int parceque je le considere comme un type de base. mais sinon je met partout des const.