Marc Boyer a écrit le mardi 16 Novembre 2004 09:15 :Fabien wrote:C'est que cette solution ne doit pas être des plus mauvaises...
J'avoue qu'en fait, je rève d'un bel IDE qui masque un peut
tout ce sucre: je sélectionne une classe, j'accède à sa définition,
son implémentation, ses spécialisation, tout ça bien rangé...
Il y a sourcenav qui est pas mal dans le genre :
http://sourcenav.sourceforge.net/
Marc Boyer a écrit le mardi 16 Novembre 2004 09:15 :
Fabien wrote:
C'est que cette solution ne doit pas être des plus mauvaises...
J'avoue qu'en fait, je rève d'un bel IDE qui masque un peut
tout ce sucre: je sélectionne une classe, j'accède à sa définition,
son implémentation, ses spécialisation, tout ça bien rangé...
Il y a sourcenav qui est pas mal dans le genre :
http://sourcenav.sourceforge.net/
Marc Boyer a écrit le mardi 16 Novembre 2004 09:15 :Fabien wrote:C'est que cette solution ne doit pas être des plus mauvaises...
J'avoue qu'en fait, je rève d'un bel IDE qui masque un peut
tout ce sucre: je sélectionne une classe, j'accède à sa définition,
son implémentation, ses spécialisation, tout ça bien rangé...
Il y a sourcenav qui est pas mal dans le genre :
http://sourcenav.sourceforge.net/
Marc Boyer writes:wrote:Ça donne surtout un très fort couplage des fichiers, ce qui devient vite
insoutenable dans les grands projets.
Tu peux préciser ?
Si tu inclus l'implémentation dans l'en-tête, cela rend le code
client dépendant non seulement de l'interface de la classe, mais
également de son implémentation. L'idiome du Pimpl pousse plus loin
ce raisonnement en s'affranchissant de la dépendance à la définition
complète de la classe. Il transfère pour cela les membres privés dans
une tierce classe.
Si je me souviens bien du contexte, il est question de modèles, et
tu inclus de toute façon l'implémentation dans l'en-tête. Même dans
ce cas, je te conseille de séparer (cmme tu sembles d'ailleurs le
faire) l'en-tête de l'implémentation, et d'inclure celle-ci dans
celui-là.
Moi, déjà, si je pouvais voir la signature de ma classe rapidement
(sans avoir à passer par doxygen puis à revenir à xemacs...) se
serait pas mal.
EBrowse ou ECB pourraient t'intéresser.
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> writes:
kanze@gabi-soft.fr wrote:
Ça donne surtout un très fort couplage des fichiers, ce qui devient vite
insoutenable dans les grands projets.
Tu peux préciser ?
Si tu inclus l'implémentation dans l'en-tête, cela rend le code
client dépendant non seulement de l'interface de la classe, mais
également de son implémentation. L'idiome du Pimpl pousse plus loin
ce raisonnement en s'affranchissant de la dépendance à la définition
complète de la classe. Il transfère pour cela les membres privés dans
une tierce classe.
Si je me souviens bien du contexte, il est question de modèles, et
tu inclus de toute façon l'implémentation dans l'en-tête. Même dans
ce cas, je te conseille de séparer (cmme tu sembles d'ailleurs le
faire) l'en-tête de l'implémentation, et d'inclure celle-ci dans
celui-là.
Moi, déjà, si je pouvais voir la signature de ma classe rapidement
(sans avoir à passer par doxygen puis à revenir à xemacs...) se
serait pas mal.
EBrowse ou ECB pourraient t'intéresser.
Marc Boyer writes:wrote:Ça donne surtout un très fort couplage des fichiers, ce qui devient vite
insoutenable dans les grands projets.
Tu peux préciser ?
Si tu inclus l'implémentation dans l'en-tête, cela rend le code
client dépendant non seulement de l'interface de la classe, mais
également de son implémentation. L'idiome du Pimpl pousse plus loin
ce raisonnement en s'affranchissant de la dépendance à la définition
complète de la classe. Il transfère pour cela les membres privés dans
une tierce classe.
Si je me souviens bien du contexte, il est question de modèles, et
tu inclus de toute façon l'implémentation dans l'en-tête. Même dans
ce cas, je te conseille de séparer (cmme tu sembles d'ailleurs le
faire) l'en-tête de l'implémentation, et d'inclure celle-ci dans
celui-là.
Moi, déjà, si je pouvais voir la signature de ma classe rapidement
(sans avoir à passer par doxygen puis à revenir à xemacs...) se
serait pas mal.
EBrowse ou ECB pourraient t'intéresser.
writes:
Ce serait interessant de voir quelles seraient les reactions
maintenant. Et aussi de voir comment ca se combime avec la
proposition de David sur les modules.
Elle m'a l'air -- je n'ai fait que survoler -- d'aller dans le sens
d'une fusion interface/implementation comme en Java. Je ne suis pas
sur que j'aime cette caracteristique:
- le fichier d'interface est trop souvent la seule documentation,
l'enlever me gene et devoir chercher ce qui sera eparpille dans
le fichier d'implementation ne m'attire pas.
- il est relativement courant d'avoir plusieurs implementations
pour la meme interface, partager le meme fichier definissant
celle-ci permet au compilateur de s'assurer de la coherence
kanze@gabi-soft.fr writes:
Ce serait interessant de voir quelles seraient les reactions
maintenant. Et aussi de voir comment ca se combime avec la
proposition de David sur les modules.
Elle m'a l'air -- je n'ai fait que survoler -- d'aller dans le sens
d'une fusion interface/implementation comme en Java. Je ne suis pas
sur que j'aime cette caracteristique:
- le fichier d'interface est trop souvent la seule documentation,
l'enlever me gene et devoir chercher ce qui sera eparpille dans
le fichier d'implementation ne m'attire pas.
- il est relativement courant d'avoir plusieurs implementations
pour la meme interface, partager le meme fichier definissant
celle-ci permet au compilateur de s'assurer de la coherence
writes:
Ce serait interessant de voir quelles seraient les reactions
maintenant. Et aussi de voir comment ca se combime avec la
proposition de David sur les modules.
Elle m'a l'air -- je n'ai fait que survoler -- d'aller dans le sens
d'une fusion interface/implementation comme en Java. Je ne suis pas
sur que j'aime cette caracteristique:
- le fichier d'interface est trop souvent la seule documentation,
l'enlever me gene et devoir chercher ce qui sera eparpille dans
le fichier d'implementation ne m'attire pas.
- il est relativement courant d'avoir plusieurs implementations
pour la meme interface, partager le meme fichier definissant
celle-ci permet au compilateur de s'assurer de la coherence
Jean-Marc Bourguet wrote:writes:
Ce serait interessant de voir quelles seraient les reactions
maintenant. Et aussi de voir comment ca se combime avec la
proposition de David sur les modules.
Elle m'a l'air -- je n'ai fait que survoler -- d'aller dans le sens
d'une fusion interface/implementation comme en Java. Je ne suis pas
sur que j'aime cette caracteristique:
Jean-Marc Bourguet wrote:
kanze@gabi-soft.fr writes:
Ce serait interessant de voir quelles seraient les reactions
maintenant. Et aussi de voir comment ca se combime avec la
proposition de David sur les modules.
Elle m'a l'air -- je n'ai fait que survoler -- d'aller dans le sens
d'une fusion interface/implementation comme en Java. Je ne suis pas
sur que j'aime cette caracteristique:
Jean-Marc Bourguet wrote:writes:
Ce serait interessant de voir quelles seraient les reactions
maintenant. Et aussi de voir comment ca se combime avec la
proposition de David sur les modules.
Elle m'a l'air -- je n'ai fait que survoler -- d'aller dans le sens
d'une fusion interface/implementation comme en Java. Je ne suis pas
sur que j'aime cette caracteristique:
Si tu regardes comment bossent les grands groupes d'édition de
logiciels (génère du code natif JNI par exemple ou ouvre le src
d'Apache HTTP Server), tu verras que tout le monde y va à grand coup
de #define. C'est que cette solution ne doit pas être des plus
mauvaises...
Si tu regardes comment bossent les grands groupes d'édition de
logiciels (génère du code natif JNI par exemple ou ouvre le src
d'Apache HTTP Server), tu verras que tout le monde y va à grand coup
de #define. C'est que cette solution ne doit pas être des plus
mauvaises...
Si tu regardes comment bossent les grands groupes d'édition de
logiciels (génère du code natif JNI par exemple ou ouvre le src
d'Apache HTTP Server), tu verras que tout le monde y va à grand coup
de #define. C'est que cette solution ne doit pas être des plus
mauvaises...
"Marc Boyer" a écrit dans le
message de news:cncj0u$l3m$In article <4199c5be$0$3315$, K. Ahausse
wrote:
VI[M]|[X]emacs + etags|ctags
Peut-on classer ce bel assemblage dans la catégorie IDE ?
C'est sensé faire exactement ça.
Ca marchait très bien en C, comme ce n'est pas exactement mon
besoin, je n'ai pas regardé pour C++.
Désolé, mais ce que j'indiquais n'est pas QUE sensé marcher, cela
fonctionne parfaitement, avec souplesse, sans distinction C/C++. Ce
qu'il y manque c'est la mise au point aisée comme sous Windows.Enfin bon, VC++ ne cache donc pas tout le sucre des templates.
Effectivement, 'tout' n'est pas gérer, cela va de soi Nul n'est obligé
apprécier VC++, cela va de soi.
Si une solution, au moins équivalente à VC++, existe sous Linux, un
énorme merci à celui qui pourrait la dévoiler.
"Marc Boyer" <Marc.Boyer@enseeiht.yahoo.fr.invalid> a écrit dans le
message de news:cncj0u$l3m$4@news.cict.fr...
In article <4199c5be$0$3315$8fcfb975@news.wanadoo.fr>, K. Ahausse
wrote:
VI[M]|[X]emacs + etags|ctags
Peut-on classer ce bel assemblage dans la catégorie IDE ?
C'est sensé faire exactement ça.
Ca marchait très bien en C, comme ce n'est pas exactement mon
besoin, je n'ai pas regardé pour C++.
Désolé, mais ce que j'indiquais n'est pas QUE sensé marcher, cela
fonctionne parfaitement, avec souplesse, sans distinction C/C++. Ce
qu'il y manque c'est la mise au point aisée comme sous Windows.
Enfin bon, VC++ ne cache donc pas tout le sucre des templates.
Effectivement, 'tout' n'est pas gérer, cela va de soi Nul n'est obligé
apprécier VC++, cela va de soi.
Si une solution, au moins équivalente à VC++, existe sous Linux, un
énorme merci à celui qui pourrait la dévoiler.
"Marc Boyer" a écrit dans le
message de news:cncj0u$l3m$In article <4199c5be$0$3315$, K. Ahausse
wrote:
VI[M]|[X]emacs + etags|ctags
Peut-on classer ce bel assemblage dans la catégorie IDE ?
C'est sensé faire exactement ça.
Ca marchait très bien en C, comme ce n'est pas exactement mon
besoin, je n'ai pas regardé pour C++.
Désolé, mais ce que j'indiquais n'est pas QUE sensé marcher, cela
fonctionne parfaitement, avec souplesse, sans distinction C/C++. Ce
qu'il y manque c'est la mise au point aisée comme sous Windows.Enfin bon, VC++ ne cache donc pas tout le sucre des templates.
Effectivement, 'tout' n'est pas gérer, cela va de soi Nul n'est obligé
apprécier VC++, cela va de soi.
Si une solution, au moins équivalente à VC++, existe sous Linux, un
énorme merci à celui qui pourrait la dévoiler.
wrote:Marc Boyer wrote in message
news:<cna0hv$4qo$...une petite question sur vos pratiques d'édition.
Pour écrire la définition de code de classe template, j'aimerais
bien séparer l'interface de l'implémentation.
Mais ça devient très lourd, du genre
template <class T>
typename X<T>::iterator X<T>::first_with(typename X<T>::cond& c){
....
}
C'est lourd. Le C++ exige en effet beaucoup de boilerplate.
Note toutefois qu'un peu de rédondance n'est pas forcement une
mauvaise chose.
Je vois bien que tout est important dans tout cela, mais dans un
contexte donné, ça fait redondance.
alors que si je laisse dans la déclaration de la classe, ça donne
iterator first_with(cond& c);
Ça donne surtout un très fort couplage des fichiers, ce qui devient
vite insoutenable dans les grands projets.
Tu peux préciser ?
Je m'en sort à grands coups de
#define X_TEMPLATE template<class T>
#define X X<T>
#define iterator typename X<T>::iterator
#define cond typename X<T>::cond
J'espère que non. J'appelle ça l'obfuscation.
Fabien semblait dire que j'étais pas le seul.
mais c'est lourd.
Vous faites comment vous ? Un super éditeur/IDE qui cache tout le
sucre ?
Je ne sais pas si c'est un super éditeur, mais les deux éditeurs
dont je me sers (vim et emacs) ont tous les deux l'achevement
automatique des mots, ce qui réduit de beaucoup le nombre de
caractères à entrée. Sinon, les deux supportent aussi la
copier/coller, et l'enregistrement d'un bout de texte dans un
régistre nommé, quand j'ai une suite de fonctions avec un en-tête en
commun.
C'est pas tellement la frappe qui me dérange que la relecture.
Et sinon, pourquoi les classes (enfin, mon compilo) ne permettent
elle pas de faire
class X {
void foo(); // Déclaration
...
void foo(){...}; // Implementation
}
Parce que ça n'apportera rien, dans la mésure où le but, c'est que
l'implémentation et la définition de la classe soient dans des
fichiers distincts.
Moi, déjà, si je pouvais voir la signature de ma classe rapidement
(sans avoir à passer par doxygen puis à revenir à xemacs...) se serait
pas mal.
Ce que j'avais suggéré, à une époque, c'est la possibilité de
définir des portées d'implémentations, quelque chose du genre :
implement class X {
// ...
}
où toutes les fonctions définies dans la portée aurait appartenues à
class X. Étendu à ton exemple, ça aurait donné :
implement template< typename T > class X< T >
{
iterator first_with( cond& c ) { ... }
}
(À l'époque où j'y avais pensé, il n'y avait pas encore le typename
dans les templates.)
Je ne sais pas quels problèmes cela introduirait, mais ça
résoudrait les miens ;-)
kanze@gabi-soft.fr wrote:
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> wrote in message
news:<cna0hv$4qo$2@news.cict.fr>...
une petite question sur vos pratiques d'édition.
Pour écrire la définition de code de classe template, j'aimerais
bien séparer l'interface de l'implémentation.
Mais ça devient très lourd, du genre
template <class T>
typename X<T>::iterator X<T>::first_with(typename X<T>::cond& c){
....
}
C'est lourd. Le C++ exige en effet beaucoup de boilerplate.
Note toutefois qu'un peu de rédondance n'est pas forcement une
mauvaise chose.
Je vois bien que tout est important dans tout cela, mais dans un
contexte donné, ça fait redondance.
alors que si je laisse dans la déclaration de la classe, ça donne
iterator first_with(cond& c);
Ça donne surtout un très fort couplage des fichiers, ce qui devient
vite insoutenable dans les grands projets.
Tu peux préciser ?
Je m'en sort à grands coups de
#define X_TEMPLATE template<class T>
#define X X<T>
#define iterator typename X<T>::iterator
#define cond typename X<T>::cond
J'espère que non. J'appelle ça l'obfuscation.
Fabien semblait dire que j'étais pas le seul.
mais c'est lourd.
Vous faites comment vous ? Un super éditeur/IDE qui cache tout le
sucre ?
Je ne sais pas si c'est un super éditeur, mais les deux éditeurs
dont je me sers (vim et emacs) ont tous les deux l'achevement
automatique des mots, ce qui réduit de beaucoup le nombre de
caractères à entrée. Sinon, les deux supportent aussi la
copier/coller, et l'enregistrement d'un bout de texte dans un
régistre nommé, quand j'ai une suite de fonctions avec un en-tête en
commun.
C'est pas tellement la frappe qui me dérange que la relecture.
Et sinon, pourquoi les classes (enfin, mon compilo) ne permettent
elle pas de faire
class X {
void foo(); // Déclaration
...
void foo(){...}; // Implementation
}
Parce que ça n'apportera rien, dans la mésure où le but, c'est que
l'implémentation et la définition de la classe soient dans des
fichiers distincts.
Moi, déjà, si je pouvais voir la signature de ma classe rapidement
(sans avoir à passer par doxygen puis à revenir à xemacs...) se serait
pas mal.
Ce que j'avais suggéré, à une époque, c'est la possibilité de
définir des portées d'implémentations, quelque chose du genre :
implement class X {
// ...
}
où toutes les fonctions définies dans la portée aurait appartenues à
class X. Étendu à ton exemple, ça aurait donné :
implement template< typename T > class X< T >
{
iterator first_with( cond& c ) { ... }
}
(À l'époque où j'y avais pensé, il n'y avait pas encore le typename
dans les templates.)
Je ne sais pas quels problèmes cela introduirait, mais ça
résoudrait les miens ;-)
wrote:Marc Boyer wrote in message
news:<cna0hv$4qo$...une petite question sur vos pratiques d'édition.
Pour écrire la définition de code de classe template, j'aimerais
bien séparer l'interface de l'implémentation.
Mais ça devient très lourd, du genre
template <class T>
typename X<T>::iterator X<T>::first_with(typename X<T>::cond& c){
....
}
C'est lourd. Le C++ exige en effet beaucoup de boilerplate.
Note toutefois qu'un peu de rédondance n'est pas forcement une
mauvaise chose.
Je vois bien que tout est important dans tout cela, mais dans un
contexte donné, ça fait redondance.
alors que si je laisse dans la déclaration de la classe, ça donne
iterator first_with(cond& c);
Ça donne surtout un très fort couplage des fichiers, ce qui devient
vite insoutenable dans les grands projets.
Tu peux préciser ?
Je m'en sort à grands coups de
#define X_TEMPLATE template<class T>
#define X X<T>
#define iterator typename X<T>::iterator
#define cond typename X<T>::cond
J'espère que non. J'appelle ça l'obfuscation.
Fabien semblait dire que j'étais pas le seul.
mais c'est lourd.
Vous faites comment vous ? Un super éditeur/IDE qui cache tout le
sucre ?
Je ne sais pas si c'est un super éditeur, mais les deux éditeurs
dont je me sers (vim et emacs) ont tous les deux l'achevement
automatique des mots, ce qui réduit de beaucoup le nombre de
caractères à entrée. Sinon, les deux supportent aussi la
copier/coller, et l'enregistrement d'un bout de texte dans un
régistre nommé, quand j'ai une suite de fonctions avec un en-tête en
commun.
C'est pas tellement la frappe qui me dérange que la relecture.
Et sinon, pourquoi les classes (enfin, mon compilo) ne permettent
elle pas de faire
class X {
void foo(); // Déclaration
...
void foo(){...}; // Implementation
}
Parce que ça n'apportera rien, dans la mésure où le but, c'est que
l'implémentation et la définition de la classe soient dans des
fichiers distincts.
Moi, déjà, si je pouvais voir la signature de ma classe rapidement
(sans avoir à passer par doxygen puis à revenir à xemacs...) se serait
pas mal.
Ce que j'avais suggéré, à une époque, c'est la possibilité de
définir des portées d'implémentations, quelque chose du genre :
implement class X {
// ...
}
où toutes les fonctions définies dans la portée aurait appartenues à
class X. Étendu à ton exemple, ça aurait donné :
implement template< typename T > class X< T >
{
iterator first_with( cond& c ) { ... }
}
(À l'époque où j'y avais pensé, il n'y avait pas encore le typename
dans les templates.)
Je ne sais pas quels problèmes cela introduirait, mais ça
résoudrait les miens ;-)
En ce qui concerne les autres fonctionalités, ça ne m'interesse en rien
de pouvoir lancer le déboggueur directement depuis l'éditeur. En
revanche, il faudrait que le « IDE » s'integre bien avec le système de
gestion des versions. Il y a des packages emacs qui le font, par
exemple, au moins pour des outils de gestion des versions qui fonction
un peu comme CVS.
Ce que je peux dire, c'est qu'évaluer tout ce qui existe coûte cher en
temps.
Et que donc, du coup, du moment qu'on a quelque chose qui marche,
même si ce n'est pas optimal, on se contente.
En ce qui concerne les autres fonctionalités, ça ne m'interesse en rien
de pouvoir lancer le déboggueur directement depuis l'éditeur. En
revanche, il faudrait que le « IDE » s'integre bien avec le système de
gestion des versions. Il y a des packages emacs qui le font, par
exemple, au moins pour des outils de gestion des versions qui fonction
un peu comme CVS.
Ce que je peux dire, c'est qu'évaluer tout ce qui existe coûte cher en
temps.
Et que donc, du coup, du moment qu'on a quelque chose qui marche,
même si ce n'est pas optimal, on se contente.
En ce qui concerne les autres fonctionalités, ça ne m'interesse en rien
de pouvoir lancer le déboggueur directement depuis l'éditeur. En
revanche, il faudrait que le « IDE » s'integre bien avec le système de
gestion des versions. Il y a des packages emacs qui le font, par
exemple, au moins pour des outils de gestion des versions qui fonction
un peu comme CVS.
Ce que je peux dire, c'est qu'évaluer tout ce qui existe coûte cher en
temps.
Et que donc, du coup, du moment qu'on a quelque chose qui marche,
même si ce n'est pas optimal, on se contente.
En ce qui concerne les autres fonctionalités, ça ne m'interesse en rien
de pouvoir lancer le déboggueur directement depuis l'éditeur.
En ce qui concerne les autres fonctionalités, ça ne m'interesse en rien
de pouvoir lancer le déboggueur directement depuis l'éditeur.
En ce qui concerne les autres fonctionalités, ça ne m'interesse en rien
de pouvoir lancer le déboggueur directement depuis l'éditeur.
Marc Boyer wrote in message
news:<cncftd$ku0$...wrote:C'est lourd. Le C++ exige en effet beaucoup de boilerplate.
Note toutefois qu'un peu de rédondance n'est pas forcement une
mauvaise chose.
Je vois bien que tout est important dans tout cela, mais dans un
contexte donné, ça fait redondance.
Je ne le conteste pas. J'ai simplement dit que toute rédondance n'est
pas forcement mauvaise. En général, dans un gros projet, les définitions
de classe ne sont pas écrites par la même personne qui en programme
l'implémentation. Sur un projet plus petit, la personne est peut-être la
même, mais elle ne le fait pas au même moment ; elle porte des chapeaux
différents selon qu'elle fasse la conception (la définition des classes)
ou l'implémentation.
Dans ce contexte, un peu de rédondance entre le fichier avec la
définition de classe et le fichier avec l'implémentation n'est pas
forcément une mauvaise chose. Un peu -- je suis d'accord que le fait qui
faut dupliquer toutes les informations à chaque définition d'une
fonction va un peu loin.
alors que si je laisse dans la déclaration de la classe, ça donne
iterator first_with(cond& c);
Ça donne surtout un très fort couplage des fichiers, ce qui devient
vite insoutenable dans les grands projets.
Tu peux préciser ?
Voir ci-dessus. En gros, la définition de la classe fait partie de la
conception, et a lieu bien avant l'implémentation.
Je m'en sort à grands coups de
#define X_TEMPLATE template<class T>
#define X X<T>
#define iterator typename X<T>::iterator
#define cond typename X<T>::cond
J'espère que non. J'appelle ça l'obfuscation.
Fabien semblait dire que j'étais pas le seul.
Que tu n'es pas le seul à pratiquer l'obfuscation, c'est fort
possible:-).
C'est pas tellement la frappe qui me dérange que la relecture.
Au contraire. C'est à la rélecture que je trouve que la rédondance a des
avantages. Je sais exactement et complétement ce auquel j'ai affaire
sans avoir besoin de régarder ailleurs.
Moi, déjà, si je pouvais voir la signature de ma classe rapidement
(sans avoir à passer par doxygen puis à revenir à xemacs...) se serait
pas mal.
Comme j'ai dit dans un autre posting, je travaille en général avec un
écran divisé, avec la définition de la classe en haut, et
l'implémentation des fonctions en bas. Tous les éditeurs dont je me sers
(emacs et vim) supporte ça.
Je ne sais pas quels problèmes cela introduirait, mais ça
résoudrait les miens ;-)
Je ne sais pas si c'était parce que les gens voyaient des problèmes, ou
parce qu'ils ne voyaient pas d'avantages. Mais personellement, je trouve
encore que l'idée était bonne. Seulement, elle n'intéressait personne
d'autre à l'époque.
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> wrote in message
news:<cncftd$ku0$1@news.cict.fr>...
kanze@gabi-soft.fr wrote:
C'est lourd. Le C++ exige en effet beaucoup de boilerplate.
Note toutefois qu'un peu de rédondance n'est pas forcement une
mauvaise chose.
Je vois bien que tout est important dans tout cela, mais dans un
contexte donné, ça fait redondance.
Je ne le conteste pas. J'ai simplement dit que toute rédondance n'est
pas forcement mauvaise. En général, dans un gros projet, les définitions
de classe ne sont pas écrites par la même personne qui en programme
l'implémentation. Sur un projet plus petit, la personne est peut-être la
même, mais elle ne le fait pas au même moment ; elle porte des chapeaux
différents selon qu'elle fasse la conception (la définition des classes)
ou l'implémentation.
Dans ce contexte, un peu de rédondance entre le fichier avec la
définition de classe et le fichier avec l'implémentation n'est pas
forcément une mauvaise chose. Un peu -- je suis d'accord que le fait qui
faut dupliquer toutes les informations à chaque définition d'une
fonction va un peu loin.
alors que si je laisse dans la déclaration de la classe, ça donne
iterator first_with(cond& c);
Ça donne surtout un très fort couplage des fichiers, ce qui devient
vite insoutenable dans les grands projets.
Tu peux préciser ?
Voir ci-dessus. En gros, la définition de la classe fait partie de la
conception, et a lieu bien avant l'implémentation.
Je m'en sort à grands coups de
#define X_TEMPLATE template<class T>
#define X X<T>
#define iterator typename X<T>::iterator
#define cond typename X<T>::cond
J'espère que non. J'appelle ça l'obfuscation.
Fabien semblait dire que j'étais pas le seul.
Que tu n'es pas le seul à pratiquer l'obfuscation, c'est fort
possible:-).
C'est pas tellement la frappe qui me dérange que la relecture.
Au contraire. C'est à la rélecture que je trouve que la rédondance a des
avantages. Je sais exactement et complétement ce auquel j'ai affaire
sans avoir besoin de régarder ailleurs.
Moi, déjà, si je pouvais voir la signature de ma classe rapidement
(sans avoir à passer par doxygen puis à revenir à xemacs...) se serait
pas mal.
Comme j'ai dit dans un autre posting, je travaille en général avec un
écran divisé, avec la définition de la classe en haut, et
l'implémentation des fonctions en bas. Tous les éditeurs dont je me sers
(emacs et vim) supporte ça.
Je ne sais pas quels problèmes cela introduirait, mais ça
résoudrait les miens ;-)
Je ne sais pas si c'était parce que les gens voyaient des problèmes, ou
parce qu'ils ne voyaient pas d'avantages. Mais personellement, je trouve
encore que l'idée était bonne. Seulement, elle n'intéressait personne
d'autre à l'époque.
Marc Boyer wrote in message
news:<cncftd$ku0$...wrote:C'est lourd. Le C++ exige en effet beaucoup de boilerplate.
Note toutefois qu'un peu de rédondance n'est pas forcement une
mauvaise chose.
Je vois bien que tout est important dans tout cela, mais dans un
contexte donné, ça fait redondance.
Je ne le conteste pas. J'ai simplement dit que toute rédondance n'est
pas forcement mauvaise. En général, dans un gros projet, les définitions
de classe ne sont pas écrites par la même personne qui en programme
l'implémentation. Sur un projet plus petit, la personne est peut-être la
même, mais elle ne le fait pas au même moment ; elle porte des chapeaux
différents selon qu'elle fasse la conception (la définition des classes)
ou l'implémentation.
Dans ce contexte, un peu de rédondance entre le fichier avec la
définition de classe et le fichier avec l'implémentation n'est pas
forcément une mauvaise chose. Un peu -- je suis d'accord que le fait qui
faut dupliquer toutes les informations à chaque définition d'une
fonction va un peu loin.
alors que si je laisse dans la déclaration de la classe, ça donne
iterator first_with(cond& c);
Ça donne surtout un très fort couplage des fichiers, ce qui devient
vite insoutenable dans les grands projets.
Tu peux préciser ?
Voir ci-dessus. En gros, la définition de la classe fait partie de la
conception, et a lieu bien avant l'implémentation.
Je m'en sort à grands coups de
#define X_TEMPLATE template<class T>
#define X X<T>
#define iterator typename X<T>::iterator
#define cond typename X<T>::cond
J'espère que non. J'appelle ça l'obfuscation.
Fabien semblait dire que j'étais pas le seul.
Que tu n'es pas le seul à pratiquer l'obfuscation, c'est fort
possible:-).
C'est pas tellement la frappe qui me dérange que la relecture.
Au contraire. C'est à la rélecture que je trouve que la rédondance a des
avantages. Je sais exactement et complétement ce auquel j'ai affaire
sans avoir besoin de régarder ailleurs.
Moi, déjà, si je pouvais voir la signature de ma classe rapidement
(sans avoir à passer par doxygen puis à revenir à xemacs...) se serait
pas mal.
Comme j'ai dit dans un autre posting, je travaille en général avec un
écran divisé, avec la définition de la classe en haut, et
l'implémentation des fonctions en bas. Tous les éditeurs dont je me sers
(emacs et vim) supporte ça.
Je ne sais pas quels problèmes cela introduirait, mais ça
résoudrait les miens ;-)
Je ne sais pas si c'était parce que les gens voyaient des problèmes, ou
parce qu'ils ne voyaient pas d'avantages. Mais personellement, je trouve
encore que l'idée était bonne. Seulement, elle n'intéressait personne
d'autre à l'époque.
