Contenu | Rechercher | Menus

Annonce

Si vous rencontrez des soucis à rester connecté sur le forum (ou si vous avez perdu votre mot de passe) déconnectez-vous et reconnectez-vous depuis cette page, en cochant la case "Me connecter automatiquement lors de mes prochaines visites".
Test de l'ISO d'Ubuntu francophone : nous avons besoin de testeurs pour la version francophone d'Ubuntu 14.04. Liens et informations ici.

Attention, une faille de sécurité dans bash a récemment été rapportée, il est recommandé de mettre à jour son système (plus de détails) *** mise à jour 12/10/2014 ***

nombre réponses : 25

#0 Re : -1 »  Configuration de mutt » Le 22/08/2014, à 09:49

Luc Hermitte
Réponses : 29

Il y a très longtemps j'avais donné une présentation de ma config de mutt, et les morceaux de conf associées.
Je ne garantis pas de savoir la redécrypter aujourd'hui. Mais à tout hasard, c'était par là : http://hermitte.free.fr/mutt/

Dans mes souvenirs, le plus difficile est de trouver comment le serveur IMAP s'attaque (si je peux donner un conseil, évite pop3).

#1 Re : -1 »  [C++] Taille d'un tableau par un pointeur. » Le 18/08/2014, à 12:09

Luc Hermitte
Réponses : 10

Hello.

Ne JAMAIS utiliser la notation avec sizeof(jespere_un_tableau)/sizeof(jespere_un_tableau[0]) en C++ -- en C, il n'y a pas le choix, c'est une autre histoire. Grâce aux templates, il y a moyen d'obtenir l'information sur les tableaux et de recevoir un message d'erreur sur les pointeurs -- ce que ne permet donc pas le C.

Je déterre un bon vieux code pour l'histoire : http://hermitte.free.fr/Info/C++/libs/l … p.hpp.html En C++11, on pourra tout "simplement" utiliser std::extend<decltype(jespere_un_tableau)>::value qui est fait pour ça -- OK, la syntaxe est pourrie, c'est pour ça que j'ai un snippet pour vim qui se charge de s'en souvenir pour moi ^^'

Sinon, si tu te retrouves à recevoir un pointeur, tu ne pourras rien faire à part faire circuler la taille via un autre chemin -- quitte à rendre la fonction template (cf le lien précédant pour la syntaxe) si tu cherches à faire circuler un tableaux statiques (BTW, std::array<> du C++11 c'est bien aussi). Mais ... si tu fais du C++ (et pas du C), je ne peux te conseiller vivement d'éviter les pointeurs bruts/nus, et d'utiliser la bibliothèque standard ici. Hormis les problèmes de gestion des durées de vies (on ne peut plus difficile/impossible à gérer correctement en présence d'exceptions), tu viens de rencontrer un autre problème, celui des conversions implicites des tableaux vers des pointeurs.

EDIT: Et à moins d'un exercice pour un prof qui ne vous a pas appris le C++ tel qu'il devrait être utilisé (i.e. il ne vous a pas montré std::vector<>), ne t'amuse pas à réinventer la roue pour autre chose que l'exercice de savoir comment elle est faite. I.e. si ton objectif est d'écrire un programme qui gère des ensembles de choses (même si c'est un exo), alors utilises std::vector<> ; si ton objectif est de voir comment un vecteur ça marche dedans, alors fais cet exo et nul autre, il est déjà suffisamment riche par lui-même)

#2 Re : -1 »  [Résolu] C++: Impossible de faire une template... » Le 23/06/2014, à 11:06

Luc Hermitte
Réponses : 4

Réponse dans la FAQ C++ de dvpz (et à peu près toutes les autres en fait tongue)
http://cpp.developpez.com/faq/cpp/?page … -des-liens

#3 Re : -1 »  java vs c++ » Le 24/07/2013, à 14:17

Luc Hermitte
Réponses : 38
GangsterAutorisé a écrit :

Bon je reviens avec des stats sur le nb de progs libres par langage (source sourceforge) :
java aurait 25% d'avance sur c++, tout type de prog confondus. Java surpasse de 60% (plus du double) C++ pour les logiciels de dev. Il n'y a qu'un domaine où c++ est meilleur c'est la vidéo et l'audio, la 3d. Même dans la prog scientifique java est devant. A noter que pour la sécurité et l'administration système c'est le C qui est devant.

Les sources des sondages & cie ... Tiens il y a ohloh aussi -> https://www.ohloh.net/languages/compare … mit=Update
Je ne vois pas 25% d'écart. Je ne sais pas qu'elles autres forges SF a intégré dans ses calculs. Tandis que ohloh/Black Duck vit du référencement de projets libres toute forge confondue. Je les soupçonne un chouilla plus proches de la réalité des projets ouverts.

Sinon, dans un de ses premiers posts Haleth a dit un truc que je soupçonne être passé à la trappe chez la majorité: dans un bon code C++ (i.e., maintenable, robuste, et qui fasse son taf'), les pointeurs (nus/bruts), on les évite comme la peste. La gestion manuelle des ressources, ça ne scale pas du tout en C++ (à cause des exceptions). Et tant que les préjugés: "C++ ? Donc on gère la mémoire à la main et on a peur des pointeurs" perdureront, on ne sera pas sortis de l'auberge. Quelques liens:
- http://lazarenko.me/2013/03/03/automati … anagement/
- http://alexandre-laurent.developpez.com … xceptions/ (à la fin, deux codes: celui correct en C sur la gauche et le correct (qui fait la même chose) en C++ sur la gauche ; notez l'absence de pointeurs nus et autres delete, et pourtant ce code est juste et robuste)

Sur un autre sujet, celui des parts de marché et des applications, cela fait plusieurs fois que je vois passer des posts de gens qui conseillent le C++ pour le développement sur mobiles (car ca serait plus facilement portable que le Java, pour une fois...).
- http://www.framehawk.com/the-return-of-c/
- http://blog.algolia.com/need-performanc … use-c-cpp/

#4 Re : -1 »  java vs c++ » Le 05/08/2013, à 10:21

Luc Hermitte
Réponses : 38
kboo a écrit :

C++
grande rapidité (pas autant que le c et asm)

C'est faux. Le C++ est au moins aussi performant que le C.
Si un truc propre au C est plus rapide que l'équivalent C++ (ex typique les flux VS stdio), il suffit de l'utiliser. Quand une chose propre au C++ est plus rapide  (p.ex. std::sort vs qsort ; ou propagation (correcte) des problèmes en situation nominale via exception VS un if toute les deux lignes), on l'utilise.
Les compilos C d'aujourd'hui sont des compilos C++. Ce ne sont pas des choses différentes.

#5 Re : -1 »  java vs c++ » Le 23/09/2013, à 13:53

Luc Hermitte
Réponses : 38

@GangsterAutorisé, Avec sa machine virtuelle, Java est un mini-OS. Là où l'on pouvait cibler des OS, on peut maintenant cibler Java qui est très répandu. Chose qui est très attrayante. De plus, dans les entreprises, ou sur des machines en production, les montées de versions ne se font pas tous les quatre matins. Car sur les machines en production, l'environnement est figé pour des années et des années. Car toute montée de version peut vouloir dire régression, et donc si elle est faite et pas accompagnée par les développeurs du logiciel (qui tourne en Java), pas sûr que les garanties & cie s'appliquent immédiatement. Bref, une montée de version, ça a un coût, et donc ce n'est pas systématisé sur les postes clients -- après cela peut varier d'un projet/client à l'autre.

Après, c'est lié qu'il y a des failles partout, et vu le style du C++ dans JNI, le style du C++ dans le reste ne doit pas être terrible AMA. Et de fait, ben .. il y a bien plus de failles que ce qu'il pourrait y avoir dans un soft écrit en C++ moderne. Et vu qu'il y a beaucoup de lignes de code, j'imagine, ben il y a des failles. Suffit aux spécialistes de les trouver.

@Haleth, On pourrait faire les mêmes reproches au C++ : non interprété, et il faut savoir à qui on envoie les messages -- hormis le duck typing offert par les templates, mais si tu as un peu suivi l'actualité, tu auras vu que la communauté C++ recherche à avoir un équivalent aux interfaces : les concepts, chose que l'on connait (même si non vérifiée automatiquement par les compilateurs) depuis la STL historique. Et ça serait la même chose pour Eiffel : on sait ce que l'on émet et à qui. Personnellement, je préfère 100 fois un typage fort qui oblige les développeurs à réfléchir à ce qu'ils font plutôt que de balancer des messages dans la nature pour les laisser attraper par qui veut bien le faire, et que d'écrire 150 TU qu'un couple compilo+typage renforcé rend obsolètes.
À propos des interfaces, à la Java/COM/CORBA/..., je trouve qu'elles ne vont pas assez loin, car elles n'offrent rien pour faire de la PpC (sans passer par des préprocesseurs ou assimilé). Eiffel a ça en natif. C++ le permet en natif (via le pattern NVI). D, je ne sais plus.

Relativement aux getters & setters, ils sont dans la tradition orientée données et non orientée objets. Au lieu de réfléchir aux services rendus, on continue à réfléchir aux données stockées, et on les manipule directement au lieu de laisser les objets englobant les gérer -- et on viole au passage la Loi de Déméter. C'est comme si on allait à une blanchisserie, et que l'on manipulait soi même les détergents et les machines. Ca s'appelle une laverie automatique (orienté données), pas une blanchisserie (orienté services/objets).
Bref, plein de littérature sur "why setters are evil?". Cette approche un attribut == un getter+un setter est plus endémique en Java à cause des Beans, et d'IDE qui les génèrent automatiquement. Du coup, c'est rentré dans les mœurs, sous prétexte "et si jamais il fallait faire une vérification ou autre?", chose qui contredit instantanément la sémantique du verbe "to set", car nous avons un "set if" (cf l'article d'Emmanuel Deloget sur son blog). En C++, les setters se font tirer à vu sur les forums francophones comme dvpz, sdz/oc.

#7 Re : -1 »  Quitter SublimeText pour ... ? » Le 12/02/2014, à 13:17

Luc Hermitte
Réponses : 6

Mon environnement pour faire du C++ (et du viml) essentiellement est ici: http://code.google.com/p/lh-vim/
Pour l'installer, il vaut mieux passer par vim-addon-manager, qui contrairement à pathogen gère les dépendances.

Rajouter à tout cela: pyclewn pour intégrer un débuggueur, et youcompleteme pour avoir une vrai complétion intelligente pour les langages supportés par clang.

unite a le vent en poupe également.

Pour les snippets/template, voir ici pour une grille comparative: http://vim-wiki.mawercer.de/wiki/topic/ … lates.html

Côté outil, j'ai abandonné vim assez vite, et il y a longtemps pour gvim -- histoire que le clavier soit tout le temps bien géré.

#9 Re : -1 »  [C++] Quelques petites questions » Le 28/11/2013, à 20:24

Luc Hermitte
Réponses : 10

1) const bool sain = a >=3;

2) Etrangement, l'opérateur ternaire permet de meilleures optimisations. Les compilos ne cherchent pas à reconnaitre les cas d'équivalence.
Sinon, L'opérateur ternaire permet de définir des variables constantes, ce qui est un plus (toujours faire en sorte que nos variables soient déclarées et construites à une valeur pertinente (i.e. elles ne doivent pas pouvoir exister dans un état intermédiaire qu'il soit neutre, ou pire indéterminé), de préférence définitive. D'où ma réponse au 1) qui diverge de celle de pingouinux.

Le if ne permet pas non plus d'écrire des fonctions constexpr en C++11 (car la seule chose autorisée dans ces fonctions est de renvoyer une expression). Il devrait y avoir un patch en C++14 ou 17  pour autoriser for, if et d'autres choses il me semble.

3) En termes d'optimisation, rajouter const à une variable qui sera évaluée dynamiquement apporte normalement que dalle, malgré ce qu'en disent les légendes urbaines -- ce n'est pas parce qu'un truc est vu const à un endroit qu'il ne peut pas changer depuis un autre contexte.
Ca reste préférable comme cela a été dit.

En revanche, les constexpr du C++11 offrent de vraies optimisations.


Concernant les fonctions virtuelles: il est idiot de déclarer virtuelle une fonction qui ne correspond pas à un point de variation. Cela impacte les perfs pour un besoin inexistant. Si point de variation dynamique il doit y avoir, alors les fonctions virtuelles sont un des mécanismes les plus efficace à notre disposition.

5) Où ? Quand ?
Hors cas de bloating, les templates améliorent généralement les performances.

9) std::copy pourrait reconnaitre qu'il y a un POD et tutti-quanti pour se voir remplacer automagiquement par un memcpy, mais je ne crois pas qu'il y ait d'implémentation de la SL qui prenne la peine de vérifier cela, ce qui est bien dommage car memcpy et memset déchirent en termes de perfs.

10) Si si. and, bitand et cie existent -> §2.6/2, §2.12/2, ...
Bref, dans tous les cas je dirais de préférer &&, &, et cie.

#10 Re : -1 »  [C++] Quelques petites questions » Le 28/11/2013, à 22:37

Luc Hermitte
Réponses : 10

1- Ici, passer par une variable intermédiaire pour stocker le booléen ne changera rien. Dans le cas d'objets plus complexes, les mots clés sont copy elision, RVO, et RNVO (ou NRVO, je me plante tout le temps).
Sinon, passer par un if pour stocker le résultat d'une expression booléenne (i.e. if (expr) v = true; else v=false;) est totalement ridicule. Sincèrement. expr est déjà un booléen.

5- C'est bien ça. Il ne parle pas d'optimisation. Mais il sous-entend des conséquences dont le mot clé pour google est "template code bloat". C'est une question d'équilibre. Dans tous les cas, ça ne sera jamais pire que du copier-coller.

(10- Déjà répondu. C'est dans la norme, mais en général on évite -- de vieux soucis avec certains compilos, IIRC)

#11 Re : -1 »  [Résolu] Qt 5 et C++11 » Le 16/08/2013, à 18:36

Luc Hermitte
Réponses : 5

Une macro ? Pour définir une constante ? Mais quelle idée !
Pourquoi n'utilises-tu pas const ? Il est fait pour ça.

#12 Re : -1 »  [Résolu] Qt 5 et C++11 » Le 19/08/2013, à 10:25

Luc Hermitte
Réponses : 5

const sert à deux choses.
A définir des variables immuables quand elles sont le résultat d'une expression qui ne peut pas être évaluée à la compilation (attention,constexpr en C++11 permet de définir des expressions évaluables à la compilation toujours plus complexes)
Et à définir des constantes de compilations.

En général, les cours de C++ disent de virer toutes les macros qui peuvent l'être quand on peut à la place soit utiliser const, soit des fonctions inlines, éventuellement templates.

Quant à math.h, c'est du C. Pas du C++. Et je doute au passage que M_E soit standard.

#13 Re : -1 »  [RÉSOLU]c++: try catch.. je galère... » Le 24/07/2013, à 13:56

Luc Hermitte
Réponses : 7

Les exceptions, c'est fait pour traiter les erreurs de contexte, fichier corrompu, sockets fermée, saisie utilisateur invalide, etc.
Elles sont inadaptées aux erreurs de programmation car elles perdent le contexte des erreurs. Un coredump est notre meilleur ami pour traquer les erreurs de programmation (assisté par des assert s'il le faut).

Sinon, dans ton cas, je peux aussi te recommander l'option -fsanatize de clang (gcc 4.8 l'offre aussi dans mes souvenirs) -> http://blog.llvm.org/2013/03/testing-li … tizer.html

#14 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/

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

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

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

#18 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

#19 Re : -1 »  Discussion autour du concept de la POO » Le 26/01/2012, à 15:14

Luc Hermitte
Réponses : 83
Smon a écrit :

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

#20 Re : -1 »  Discussion autour du concept de la POO » Le 27/01/2012, à 16:13

Luc Hermitte
Réponses : 83
Mathieu147 a écrit :

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

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

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

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

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