#0 Re : -1 » [C++] problème tout simple sur les pointeurs (RESOLU) » Le 24/02/2012, à 15:27
- Luc Hermitte
- Réponses : 14
NB: tu ne veux pas copier des armes.
Il s'agit typiquement d'entités (sans parler que tu les manipules déjà via des pointeurs), et les entités on ne veut pas les copier. Non seulement c'est techniquement une source d'ennuis (je reste poli), mais surtout c'est un besoin que nous n'avons jamais : il n'y a aucune pertinence à faire cela.
mots clés -> sémantique entité, valeur
Un petit lien que j'ai sous le coude: http://akrzemi1.wordpress.com/2012/02/0 … semantics/
#1 Re : -1 » Problème en C++ avec les templates et l'héritage » Le 22/02/2012, à 16:47
- Luc Hermitte
- Réponses : 4
1- C'est une erreur
Tu ne veux pas dériver les conteneurs standards. Ce n'est pas fait pour, tu va aller de galère en galère.
De plus, tous les algos ensemblistes sont déjà dans <algorithm>. À la limite si tu trouves leur utilisation un chouilla peu pratiques, il n'est pas impossible qu'une version simplifiée se trouve dans boost.
2- std::set ?
Sinon, il est possible d'aller plus vite avec des vecteurs triés. Mais attention, en OO une liste triée n'est pas une liste.
3- Oublie le Java.
L'héritage de conteneurs est une catastrophe (slicing, collecte, non prévu pour être polymorphe, etc)
6- oh les vilains pointeurs pris sur des trucs renvoyés par valeur...
template <typename Seq_, typename Metric_>
inline
Matrix<typename Seq_::value_type, typename Seq_::value_type, double> buildSingularityMatrix(Seq_ const& seq, Metric_ const& metric) {
Matrix<typename Seq_::value_type, typename Seq_::value_type, double> res(seq.size(), seq.size());
for (size_t i=0 ; i!=seq.size() ; ++i) {
for (size_t j=0 ; j!=seq.size() ; ++j) {
res(i,j) = metric(seq[i], seq[j]); // à supposer que bati sur un vecteur, à convertir en itérateurs sinon
}
}
return res;
}PS: tu ne veux pas utiliser new pour instancier des conteneurs. Tu perds tous l'avantage RAII des conteneurs à procéder de la sorte.
PPS: les forums C++ comme celui de dvpz sont plus adaptés à traiter ce genre de questions ...
#2 Re : -1 » Problème en C++ avec les templates et l'héritage » Le 23/02/2012, à 15:55
- Luc Hermitte
- Réponses : 4
Je réponds aux questions qui n'ont pas été abordées sur le sdz.
- Entre class et typename, la seule différence dans les paramètres templates, c'est celle que l'on veut bien leur accorder.
Dit autrement, il n'y en a pas. Mais certaines personnes utilisent class uniquement quand il est certain que le paramètre doit être une classe et ne peut pas être un type primitif comme int p.ex.
- L'inlining est nécessaire sur les fonctions qui sont déclarées et définies dans des .h. Dans le cas des fonctions template, la définition doit impérativement (*) être dans un .h -- et dans le cas où elles ne sont pas membres (et donc pas définies dans une classe, comme en Java) l'utilisation explicite du mot clé est requise.
(*) parfois j'ai l'impression que c'est lié à des compilos, parfois non.
- Le value_type de vector<T>, c'est T. À partir du conteneur, cela permet de retrouver le type des éléments stockés.
Là l'utilisation de typename n'a rien à voir avec celle que je décrivais dans le premier point, elle est requise, et class n'est pas utilisable à la place. Pour faire court, regarde la FAQ C++ de dvpz.
#3 Re : -1 » Discussion autour du concept de la POO » Le 06/01/2012, à 15:52
- Luc Hermitte
- Réponses : 83
L'OO c'est d'abord beaucoup d'abstraction au niveau de l'objet.
L'objet rend des services, on ne veut pas savoir comment il fait. Exemple que j'aime bien ressortir: http://www.siteduzero.com/forum-83-4119 … l#r3810730
Corolaire: getter et setters, c'est tout sauf de l'OO. C'est de l'orienté données: on abdique aux objets extérieurs un total contrôle sur notre état interne.
L'OO c'est aussi le polymorphisme dit d'inclusion. Là où un algo attend à manipuler un objet d'un certain type, on peut lui faire manipuler un objet enfant plus spécialisé (qui aura éventuellement adapté des points de variation prévus dans le parent/l'algo).
Mot clé: LSP (Principe de Substitution de Liskov)
La réutilisation, c'est un faux argument, et une fausse spécificité de l'OO. Bien au contraire, c'est régulièrement une mauvaise exploitation de certaines possibilités syntaxique des langages OO.
#4 Re : -1 » Discussion autour du concept de la POO » Le 23/01/2012, à 16:49
- Luc Hermitte
- Réponses : 83
Hormis les faits :
- qu'il s'agisse d'une variable globale ? (ce qui induit introduit des couplages invisibles, gêne la mise en oeuvre de tests unitaires, ...)
- que s'il nécessite une initialisation paramétrée, alors la construction paresseuse n'a plus le moindre sens ? (hors c'est grooso-modo le seul intérêt des singletons)
- que disposer d'une construction paresseuse thread-safe et "légère" est impossible avec certains langages (C++98/03 ; plus C++11)
- que parfois l'assurance d'unicité est plus une contrainte qu'un véritable bénéfice ?
L'avantage: briller en société: http://www.siteduzero.com/forum-83-7230 … l#r6981704
google -> singleton anti-pattern
#5 Re : -1 » Discussion autour du concept de la POO » Le 26/01/2012, à 15:14
- Luc Hermitte
- Réponses : 83
a- Le principal problème du singleton c'est qu'il pompe de la ressource.
b- Y'a aussi une mouvance anti-singleton en ce moment, justifiée ou non, telle est la question ...
a- quoi ?
Le problème majeur, c'est un problème de couplage. C'est la raison pour laquelle les variables globales sont décriées en premier lieu.
b- Ce qui arrive aujourd'hui, c'est le contre-coup de l'effet de mode "vive les design patterns" qui est "ce pattern il est moisi en fait"
De la lecture il n'en manque pas (il y en a des kilomètres)
- http://caines.ca/blog/programming/singl … tern-ever/
- http://www.developpez.net/forums/d53021 … i-pattern/
- http://accu.org/index.php/journals/337
#6 Re : -1 » Discussion autour du concept de la POO » Le 27/01/2012, à 16:13
- Luc Hermitte
- Réponses : 83
a- Par exemple, dans le contexte d'un logiciel où une personne doit s'identifier et puis a accès à certaines choses suivant un système de droit, pourquoi est-ce qu'utiliser un singleton pour l'objet qui représente l'utilisateur est mauvais?
b- De même, dans le cadre d'un magasin en ligne où il faut gérer un panier, ou dans le cas d'un jeu vidéo où il faut gérer l'inventaire des objets du joueur, qu'est-ce qui fait qu'un singleton est si mauvais? Et surtout, qu'utiliserais-tu comme autre solution, et quels seraient les avantages de ladite solution?
Tu me poses des questions faciles.
a- cela complique grandement la mise en place de tests unitaires. [désolé, mais je ne partirai pas dans la démonstration du bien fondé de cette technique http://www.youtube.com/watch?v=wEhu57pih5w ]
b- Comment gères-tu un panel d'utilisateurs ?
Tu as certes un panier par utilisateur, mais certainement pas pour un panier pour ton application.
Pour le jeu video, comment gèrerai-tu les sacs à dos des autres personnages ? Voire les sacs et sacoches (au pluriel) de ces personnages ? Le singleton n'est absolument pas adapté.
J'avais même croisé des articles sur gamedev qui démontaient les singletons pour définir des engines.
PS: pour le lien, google singleton + anti-pattern est le lien à prendre. Je n'ai fait qu'en extraire 3.
autre lecture: http://www.ibm.com/developerworks/libra … index.html
#7 Re : -1 » Discussion autour du concept de la POO » Le 10/02/2012, à 17:31
- Luc Hermitte
- Réponses : 83
Les setters sont généralement des ruptures d'encapsulation. Même avec vérification, ils sont signe d'une réflexion en termes de données et non de services rendus.
Hop, de la lecture (mode fainéant, désolé -- j'avais pas posté des liens à ce sujet dans ce fil déjà ? Ah si, message 38) :
- http://www.siteduzero.com/forum-83-4119 … l#r3810730
- http://blog.emmanueldeloget.com/index.p … accesseurs
- http://blog.emmanueldeloget.com/index.p … de-demeter
- http://www.javaworld.com/javaworld/jw-0 … olbox.html
- http://stackoverflow.com/questions/5650 … tters-evil
- http://www.idinews.com/quasiClass.pdf (pas sûr que le lien marche encore ...)
#8 Re : -1 » Discussion autour du concept de la POO » Le 14/02/2012, à 14:50
- Luc Hermitte
- Réponses : 83
On a effectivement un problème de nomenclature : un truc sensé faire set mais qui fait bien plus -- on retrouve l'article d'Emmanuel Deloget.
Mais ce qui me gêne le plus dans l'exemple du jdr, c'est le problème de responsabilité. Si tu exposes les PV, la responsabilité est déportée à l'extérieur. Ma vision est plus proche de celle qu'a détaillée Yohann. J'ai d'ailleurs un exemple à ce sujet, qui raffine encore un chouilla ce qu'il explique.
-> http://www.siteduzero.com/forum-83-6896 … l#r6675973
Ailleurs que je dis pas que l'approche variable en public me gêne.
Des setters ? Plus j'y pense, plus c'est un conception-smell pour moi. À la limite quand j'ai des invariants qui s'expriment sur plusieurs données, où quand changer une donnée sans l'autre n'a pas de sens (typiquement -> numérateur & dénominateur sur des nombres rationnels) j'offre des mutateurs qui altèrent l'état qui s'implémente à partir de plusieurs attributs.
#9 Re : -1 » [C++][NTL]projet » Le 14/11/2011, à 16:23
- Luc Hermitte
- Réponses : 6
Non. Le tableau a une taille 1, pas 2.
#10 Re : -1 » Vim, snippets, LaTex » Le 28/11/2011, à 15:05
- Luc Hermitte
- Réponses : 8
Au mieux, tu peux tenter avec un mapping. Regarde si ton gestionnaire de templates exporte une :Commande qui permet de déclencher une expansion autrement qu'en mode insertion.
S'il rajoute un espace tout seul, il te faudra patcher son code -- j'ai vérifié, ce serait par exemple le cas avec mon mu-template (dans mon cas ce ne serait pas une modif très compliquée non plus, d'autant que j'ai déjà des mécanismes (cf p.ex. s:reindent) pour configurer chaque template/snippet).
#11 Re : -1 » Vim: sélectionner jusqu'à la ligne X (résolu) » Le 08/11/2011, à 18:13
- Luc Hermitte
- Réponses : 4
Alors
:.,98y+sera encore mieux si tu connais vraiment la ligne de fin. Bien souvent, je préfère ajuster d'abord avec Vap, Vi{, etc Il y a bien longtemps que je ne regarde plus les numéros des lignes pour mes manips.
#12 Re : -1 » [C++]Synchronisation de threads, sans utiliser de mutexs globaux » Le 04/11/2011, à 16:14
- Luc Hermitte
- Réponses : 2
Quand on peut, on évite de partager.
Je t'invite à consulter les moult articles d'Herb Sutter sur le MT. Ils sont visibles depuis son blog, et dispos sur le DDJ
#13 Re : -1 » [C++]volatile méthodes » Le 02/11/2011, à 11:16
- Luc Hermitte
- Réponses : 9
Je reviens sur 2-3 trucs.
Non en MT, il ne faut pas déclarer des variables volatiles. De base, cela n'apporte strictement rien d'utile (relativement au MT) (en dehors des derniers VC++). Je vous renvoie à d'autres discussions qui invalident la première partie de l'article.
- http://software.intel.com/en-us/blogs/2 … ogramming/
- http://www.alexonlinux.com/multithreade … -variables
L'article d'Andrei Alexandrescu démontre une utilisation détournée de volatile qui s'inspire de la const-correctness. const est un tag qui marque la non-mutabilité sémantique. AA, dans son article, propose la même chose avec volatile pour marquer les zones protégées contre les accès concurrents -- OK, cela va revenir à marquer quelques variables.
Tout surcharger ? Hum... Ce n'est probablement pas la bonne chose à faire. Ce n'est définitivement pas ce que l'on fait avec const. Quand on conçoit, on essaie de savoir ce que cela vaut pour le MT.
Dans un sujet très proche, Scott Meyers avait tenté une petite expérience pour faire de la preuve (en gros). C'est à dire pour tagguer les fonctions quant aux propriétés/garanties qu'elles offrent. Hormis les temps de compilation titanesques (sur une précédente génération de compilos), son expérience avait été concluante. On retrouverait pratiquement les même bonus qu'avec volatile (en cv-qualifier de fonctions membres), mais sans tagguer "volatile" les variables.
-> http://www.artima.com/cppsource/codefeatures.html
#14 Re : -1 » [C++]Statistiques sur les compilateurs les plus utilisés » Le 10/10/2011, à 13:00
- Luc Hermitte
- Réponses : 4
mingw, ce n'est jamais que gcc dans un environnement non POSIX -- a contrario de cygwin qui émule POSIX ("Linux" disent-ils maintenant)
Et sinon, effectivement, les plus utilisés sont VC++ et gcc (toutes plateformes confondues, dont mingw). À noter que gcc4 gagne du terrain. Le 3 reste surtout sur les distributions qui mettent 150ans à se mettre à jour.
#15 Re : -1 » [POO]Principe de substitution de Liskov » Le 13/10/2011, à 10:23
- Luc Hermitte
- Réponses : 6
Tu n'as pas forcément choisi le bon forum pour lancer ce genre de discussions. Tente le forum C++ de dvpz plutôt (n'hésite pas à donner un lien vers ici)
En attendant, les trucs à comprendre relativement au LSP et à cercle/ellipse c'est que l'héritage est valable si les objets sont immuables. On retrouve alors les objets mathématiques. Si on introduit des comportements dont la déformation, il n'y a plus d'héritage correct entre ces deux.
Le LSP nous pousse alors à extraire l'interface commune. Et pas vraiment le comportement commun.
- http://www.developpez.net/forums/d60768 … rectangle/
- http://www.developpez.net/forums/d64063 … on-liskov/
Ensuite entre template ou héritage, il y a deux mécanismes orthogonaux en jeu:
- le type de polymorphisme : inclusion ou paramétrique
- le dynamisme du polymorphisme : liaison tardive (/dynamique) ou liaison statique.
L'héritage en C++, c'est lié au polymorphisme d'inclusion, et le lien est dynamique.
Les templates en C++ sont liés au polymorphisme paramétrique, et le lien est statique.
En fin de compte, c'est souvent la nature du lien requis qui détermine la solution que l'on retient. S'il est impératif que le code sache s'adapter à l'exécution, on écarte les templates (ex: un logiciel de dessin type dia/visio/word/powerpoint qui permet d'altérer les formes déjà tracées). Si une liaison statique est acceptable et que l'on est plus dans le duck-typing (ce qui semble être une de tes interrogations) que dans le polymorphisme d'inclusion, les templates sont une bonne solution.
- http://cpp.developpez.com/faq/cpp/?page … EMENT_quoi
#16 Re : -1 » [Résolu] programmation c++ » Le 28/09/2011, à 00:45
- Luc Hermitte
- Réponses : 7
Le C++ est un mauvais langage pour commencer :
a- il est orienté objet,
b- mais il est tellement proche en apparence du C qu'il est souvent utilisé comme une simple extension de celui-ci.
c- De nombreux tutos font prendre de mauvaises habitudes.d-Tu devrais commencer par un langage moins ambivalent comme le C si tu préfère commencer par de la programmation procédurale de bas niveau
e- ou le Python pour la programmation objet. Si tu es à l'aise en anglais, le site pyton.org propose d'ailleurs un tuto officiel.
a- Aussi, mais c'est sans importance pour un premier langage. Car "aussi". Donc "pas que".
b- C'est une vraie plaie, oui.
c- C'est malheureusement vrai
d- Probablement le pire choix, après l'assembleur (j'ignore les langages à la noix comme le BF & cie)
e- Python est je pense un meilleur choix pour démarrer, et nul besoin non plus de le démarrer autrement qu'en procédural uniquement. Après on pourrait certainement lui faire des reproches et penser qu'il y a mieux. Je passe la main.
Si je ne rentre pas dans les détails, c'est parce que j'ai parfois l'impression de passer mon temps à radoter.
Pouf: http://www.siteduzero.com/forum-83-6881 … ation.html
#17 Re : -1 » [Résolu][C++]Operateur new et multithreading » Le 29/09/2011, à 14:24
- Luc Hermitte
- Réponses : 5
new et delete sont MT-safe normalement.
Jamais entendu parler de versions qui étaient à l'ouest.
#18 Re : -1 » C++ un problème que je ne trouve pas ! [RESOLU] » Le 05/09/2011, à 13:54
- Luc Hermitte
- Réponses : 13
Relis bien le texte que j'ai donné. Je n'y parle jamais de clear().
clear() c'est pour dire, "OK j'ai compris qu'il y avait eu des erreurs dans le passé sur le flux/OSEF, dans tous les cas repartons comme s'il n'y avait jamais eu de problème". Cela ne veut pas dire: ignorons ce qui reste jusqu'au prochain \n.
#19 Re : -1 » Vim: quelques questions » Le 05/09/2011, à 12:56
- Luc Hermitte
- Réponses : 16
Je n'ai pas la moindre idée de ce dont tu parles. C'est quoi un portview pour toi ?
(Dans le jargon vim, il y a fichier, buffer, window, et tab)
Sinon, je n'utilise (toujours) pas le plugin project, et je vais avoir du mal à t'aider (avec ce plugin)
#20 Re : -1 » Vim: quelques questions » Le 06/09/2011, à 14:16
- Luc Hermitte
- Réponses : 16
OK. C'est window le terme. Pas viewport.
Il n'y a pas de réponse simple.
Quand dans une seconde fenêtre j'ouvre un fichier qui appartient à un autre projet (répertoire), ma config (local_vimrc + BTW dont j'ai parlé plus haut) fait que la projet courant devient celui de la fenêtre dans laquelle je me trouve.
Si c'est un autre fichier du même projet, il est facile de le rattacher au même projet avec des outils comme local_vimrc (et probablement avec projet, que je n'utilise pas donc). Si c'est un fichier qui vient complètement d'ailleurs (autre hiérarchie/fichier temporaire pour un vimdiff depuis le HEAD d'un repository/...), cela devient vite beaucoup plus compliqué. On peut s'amuser à dire que les info du projet sont définies par une variable globale, mais ce n'est pas très propre, et c'est vite bourré d'effets de bords. Un fois de plus, il va falloir passer par local_vimrc (et peut-être project) pour faire de la mise à jour automatique de la variable globale sur changement de répertoire/projet.
#21 Re : -1 » Vim: quelques questions » Le 08/09/2011, à 15:54
- Luc Hermitte
- Réponses : 16
C'était du code tapé de mémoire. La fonction est exists() (:h exists())
NB: pour bien faire il faudrait rajouter des gardes anti-réinclusion. Bien faire au sens: ne pas tout recharger à chaque fois.
Sinon, ton besoin m'a donné des idées pour aller plus loin avec local_vimrc et BTW et définir une notion de projet principal (le premier chargé) et secondaires (les autres qui viendraient ensuite), et la possibilité de passer d'un projet à l'autre. Je vois ce qu'il faut faire mais malheureusement je ne vais pas avoir le temps avant un bon moment. 
#22 Re : -1 » Vim: quelques questions » Le 08/09/2011, à 19:15
- Luc Hermitte
- Réponses : 16
À chaque fois que tu vas mettre le focus sur une fenêtre de ton projet, le fichier _vimrc_local.vim va être rechargé (mets un <<:echomsg "encore!">> pour t'en rendre compte)
La bonne façon est d'utiliser des gardes anti-réinclusion. Cf les commentaires en début de fichier -- N.B.: mu-template génère automatiquement les squelettes vides de fichier _vimrc_local avec les vérifications qui vont bien.
Pour l'idée derrière le projet secondaire : Si tu charges un fichier d'un autre projet pour voir comment une fonction est réalisée afin de la copier. Si tu exécutes (/compile) depuis la fenêtre de ce fichier "externe", quel est le comportement attendu?
a- exécuter/compiler le projet en cours d'édition jusqu'à présent
b- exécuter/compiler le projet correspondant à la fenêtre courante ?
Avec le fonctionnement courant, c'est b- qui se passe.
Autres cas particuliers, un diff avec un scratch-buffer qui contient une révision autre du fichier qui se trouve sur un repository (git, svn, etc). L'exécution du projet, devrait bien correspondre au projet courant. Hors le scratch-buffer ne déclenche pas le chargement de _vimrc_local.
Même problème depuis la fenêtre quickfix contenant les résultats de compilation -- que j'ai résolu avec des feintes pour BuildToolsWrapper.
Pour ces cas particuliers, la notion de projet courant (en variable globale) a énormément de sens.
#23 Re : -1 » Vim: quelques questions » Le 08/09/2011, à 19:42
- Luc Hermitte
- Réponses : 16
Avec plaisir.
Bonne soirée à toi aussi.
#24 Re : -1 » [résolu] Vim - surlignage général en jaune non souhaité » Le 08/09/2011, à 10:55
- Luc Hermitte
- Réponses : 2
Tu voulais faire "dt." ou "df."
Sinon, tu peux:
- désactiver le surlignage du pattern cherché (":set hlsearch!" pour basculer l'état (chose que j'ai mappée sur F8), sinon, c'est nohlsearch)
- mais si tu préfères garder le surlignage, change juste le pattern cherché avec un '/' -- AMA, c'est ça que tu devrais faire.