alors que si je laisse dans la déclaration de la classe, ça donne
iterator first_with(cond& c);
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
mais c'est lourd.
Vous faites comment vous ? Un super éditeur/IDE qui cache tout le sucre ?
Et sinon, pourquoi les classes (enfin, mon compilo) ne permettent elle pas
de faire
class X {
void foo(); // Déclaration
...
void foo(){...}; // Implementation
}
Marc Boyer
--
Je ne respecte plus le code de la route à vélo depuis une double fracture
due au fait que j'étais le seul à le respecter.
Loïc Joly wrote in message news:<419d058d$0$6781$...
wrote:
Oui. Et qu'est-ce que veut dire « integrated development environment » ? À part ce que le marketing veut que ça signifie ?
D'après les mots anglais, je m'attendrais à ce que ce soit un environment d'où tu peux faire toutes les tâches nécessaires au développement, sans avoir besoin d'aller dans un autre environment pour les faire. Le shell Unix, par exemple:-).
Je pense que ça va un peu plus loin. Pour moi, le intergrated, ça signifie que les différents éléments sont prévus pour fonctionner ensemble, et sont cohérents en terme de données de configuration, de raccourcis clavier, de look and feel,...
Entendu. Ça n'écarte toujours pas un shell Unix : il n'y a que tu as défini comme raccourcis, le look and feel est on ne peut plus cohérent, que de l'ASCII, etc. Et je crois que c'est Unix qui a inventé le concepte des composants divers qui travaille ensemble (plutôt que des gros monolithes).
J'imagine qu'après avoir installé Rose, Clearcase, Sniff+, etc. sous Visual Studios, il doit y avoir les mêmes différences que sous un shell Unix. Plus même, parce qu'avec un GUI, il y a plus d'endroits où on peut ne pas être cohérent.
Mais mon propos n'était pas de défendre Unix, en tant que tel. Je voulais simplement démander réelement ce qu'on s'entendait par IDE, en disant que ça doit être plus que la signification simple des mots, dans la mésure qu'un shell de Unix correspondait aussi à la signification simple de mot (et ce qui me semblait évident, c'est que la plupart des gens ne considère pas le shell de Unix un IDE).
-- James Kanze GABI Software http://www.gabi-soft.fr Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Loïc Joly <loic.actarus.joly@wanadoo.fr> wrote in message
news:<419d058d$0$6781$8fcfb975@news.wanadoo.fr>...
kanze@gabi-soft.fr wrote:
Oui. Et qu'est-ce que veut dire « integrated development environment » ?
À part ce que le marketing veut que ça signifie ?
D'après les mots anglais, je m'attendrais à ce que ce soit un
environment d'où tu peux faire toutes les tâches nécessaires au
développement, sans avoir besoin d'aller dans un autre environment
pour les faire. Le shell Unix, par exemple:-).
Je pense que ça va un peu plus loin. Pour moi, le intergrated, ça
signifie que les différents éléments sont prévus pour fonctionner
ensemble, et sont cohérents en terme de données de configuration, de
raccourcis clavier, de look and feel,...
Entendu. Ça n'écarte toujours pas un shell Unix : il n'y a que tu as
défini comme raccourcis, le look and feel est on ne peut plus cohérent,
que de l'ASCII, etc. Et je crois que c'est Unix qui a inventé le
concepte des composants divers qui travaille ensemble (plutôt que des
gros monolithes).
J'imagine qu'après avoir installé Rose, Clearcase, Sniff+, etc. sous
Visual Studios, il doit y avoir les mêmes différences que sous un shell
Unix. Plus même, parce qu'avec un GUI, il y a plus d'endroits où on peut
ne pas être cohérent.
Mais mon propos n'était pas de défendre Unix, en tant que tel. Je
voulais simplement démander réelement ce qu'on s'entendait par IDE, en
disant que ça doit être plus que la signification simple des mots, dans
la mésure qu'un shell de Unix correspondait aussi à la signification
simple de mot (et ce qui me semblait évident, c'est que la plupart des
gens ne considère pas le shell de Unix un IDE).
--
James Kanze GABI Software http://www.gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Loïc Joly wrote in message news:<419d058d$0$6781$...
wrote:
Oui. Et qu'est-ce que veut dire « integrated development environment » ? À part ce que le marketing veut que ça signifie ?
D'après les mots anglais, je m'attendrais à ce que ce soit un environment d'où tu peux faire toutes les tâches nécessaires au développement, sans avoir besoin d'aller dans un autre environment pour les faire. Le shell Unix, par exemple:-).
Je pense que ça va un peu plus loin. Pour moi, le intergrated, ça signifie que les différents éléments sont prévus pour fonctionner ensemble, et sont cohérents en terme de données de configuration, de raccourcis clavier, de look and feel,...
Entendu. Ça n'écarte toujours pas un shell Unix : il n'y a que tu as défini comme raccourcis, le look and feel est on ne peut plus cohérent, que de l'ASCII, etc. Et je crois que c'est Unix qui a inventé le concepte des composants divers qui travaille ensemble (plutôt que des gros monolithes).
J'imagine qu'après avoir installé Rose, Clearcase, Sniff+, etc. sous Visual Studios, il doit y avoir les mêmes différences que sous un shell Unix. Plus même, parce qu'avec un GUI, il y a plus d'endroits où on peut ne pas être cohérent.
Mais mon propos n'était pas de défendre Unix, en tant que tel. Je voulais simplement démander réelement ce qu'on s'entendait par IDE, en disant que ça doit être plus que la signification simple des mots, dans la mésure qu'un shell de Unix correspondait aussi à la signification simple de mot (et ce qui me semblait évident, c'est que la plupart des gens ne considère pas le shell de Unix un IDE).
-- James Kanze GABI Software http://www.gabi-soft.fr Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Arnaud Meurgues
Jean-Marc Bourguet wrote:
Ce qui est intéressant, c'est que le prix du développement jusqu'au déployement n'était pas plus cher. Faire correctement ne coûte pas plus cher au début, et nettement moins cher à la longue. Mais il y a encore beaucoup de boîtes qui ne l'ont pas compris. Ce n'est pas plus cher, mais est-ce que c'est plus long ?
Pour arriver a quoi?
À ce dont parlait James.
Au deployement dans quel etat?
Je n'en sais rien. Dans l'état dont parle James. Il dit que ça ne coûte pas moins cher. Je demande ce qu'il en est pour le temps nécessaire à "faire les choses correctement".
Mais effectivement, des détails sur l'état de ce qui est déployé sont intéressant. -- Arnaud (Supprimez les geneurs pour me répondre)
Jean-Marc Bourguet wrote:
Ce qui est intéressant, c'est que le prix du développement
jusqu'au déployement n'était pas plus cher. Faire correctement ne
coûte pas plus cher au début, et nettement moins cher à la
longue. Mais il y a encore beaucoup de boîtes qui ne l'ont pas
compris.
Ce n'est pas plus cher, mais est-ce que c'est plus long ?
Pour arriver a quoi?
À ce dont parlait James.
Au deployement dans quel etat?
Je n'en sais rien. Dans l'état dont parle James. Il dit que ça ne coûte
pas moins cher. Je demande ce qu'il en est pour le temps nécessaire à
"faire les choses correctement".
Mais effectivement, des détails sur l'état de ce qui est déployé sont
intéressant.
--
Arnaud
(Supprimez les geneurs pour me répondre)
Ce qui est intéressant, c'est que le prix du développement jusqu'au déployement n'était pas plus cher. Faire correctement ne coûte pas plus cher au début, et nettement moins cher à la longue. Mais il y a encore beaucoup de boîtes qui ne l'ont pas compris. Ce n'est pas plus cher, mais est-ce que c'est plus long ?
Pour arriver a quoi?
À ce dont parlait James.
Au deployement dans quel etat?
Je n'en sais rien. Dans l'état dont parle James. Il dit que ça ne coûte pas moins cher. Je demande ce qu'il en est pour le temps nécessaire à "faire les choses correctement".
Mais effectivement, des détails sur l'état de ce qui est déployé sont intéressant. -- Arnaud (Supprimez les geneurs pour me répondre)
kanze
Loïc Joly wrote in message news:<419d2c98$0$14664$...
Jean-Marc Bourguet wrote:
Loïc Joly writes:
wrote:
Oui. Et qu'est-ce que veut dire « integrated development environment » ? À part ce que le marketing veut que ça signifie ? D'après les mots anglais, je m'attendrais à ce que ce soit un environment d'où tu peux faire toutes les tâches nécessaires au développement, sans avoir besoin d'aller dans un autre environment pour les faire. Le shell Unix, par exemple:-).
Je pense que ça va un peu plus loin. Pour moi, le intergrated, ça signifie que les différents éléments sont prévus pour fonctionner ensemble, et sont cohérents en terme de données de configuration, de raccourcis clavier, de look and feel,...
En quoi n'est-ce pas le cas du shell?
En ce que les différents outils que l'on a besoin d'appeler à partir du shell pour développer ont été conçus pas des équipes différentes qui n'avaient pas forcément comme objectif d'être cohérents avec les autres outils (voire même qui n'imaginaient même pas que ces autres outils puissent exister).
Mais c'est justement la force du shell de Unix -- que des éléments puissent s'y integrer parfaitement sans en connaître l'existance des autres.
Sa faiblesse, évidemment, c'est que ceci impose un philosophie un peu « least common denominator » -- pas de GUI, la communication entre éléments par de l'ASCII non formatté, etc. Et personne ne met en doute sa puissance, je crois, ni sa souplesse.
-- James Kanze GABI Software http://www.gabi-soft.fr Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Loïc Joly <loic.actarus.joly@wanadoo.fr> wrote in message
news:<419d2c98$0$14664$8fcfb975@news.wanadoo.fr>...
Jean-Marc Bourguet wrote:
Loïc Joly <loic.actarus.joly@wanadoo.fr> writes:
kanze@gabi-soft.fr wrote:
Oui. Et qu'est-ce que veut dire « integrated development
environment » ? À part ce que le marketing veut que ça signifie ?
D'après les mots anglais, je m'attendrais à ce que ce soit un
environment d'où tu peux faire toutes les tâches nécessaires au
développement, sans avoir besoin d'aller dans un autre environment
pour les faire. Le shell Unix, par exemple:-).
Je pense que ça va un peu plus loin. Pour moi, le intergrated, ça
signifie que les différents éléments sont prévus pour fonctionner
ensemble, et sont cohérents en terme de données de configuration, de
raccourcis clavier, de look and feel,...
En quoi n'est-ce pas le cas du shell?
En ce que les différents outils que l'on a besoin d'appeler à partir
du shell pour développer ont été conçus pas des équipes différentes
qui n'avaient pas forcément comme objectif d'être cohérents avec les
autres outils (voire même qui n'imaginaient même pas que ces autres
outils puissent exister).
Mais c'est justement la force du shell de Unix -- que des éléments
puissent s'y integrer parfaitement sans en connaître l'existance des
autres.
Sa faiblesse, évidemment, c'est que ceci impose un philosophie un peu
« least common denominator » -- pas de GUI, la communication entre
éléments par de l'ASCII non formatté, etc. Et personne ne met en doute
sa puissance, je crois, ni sa souplesse.
--
James Kanze GABI Software http://www.gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Loïc Joly wrote in message news:<419d2c98$0$14664$...
Jean-Marc Bourguet wrote:
Loïc Joly writes:
wrote:
Oui. Et qu'est-ce que veut dire « integrated development environment » ? À part ce que le marketing veut que ça signifie ? D'après les mots anglais, je m'attendrais à ce que ce soit un environment d'où tu peux faire toutes les tâches nécessaires au développement, sans avoir besoin d'aller dans un autre environment pour les faire. Le shell Unix, par exemple:-).
Je pense que ça va un peu plus loin. Pour moi, le intergrated, ça signifie que les différents éléments sont prévus pour fonctionner ensemble, et sont cohérents en terme de données de configuration, de raccourcis clavier, de look and feel,...
En quoi n'est-ce pas le cas du shell?
En ce que les différents outils que l'on a besoin d'appeler à partir du shell pour développer ont été conçus pas des équipes différentes qui n'avaient pas forcément comme objectif d'être cohérents avec les autres outils (voire même qui n'imaginaient même pas que ces autres outils puissent exister).
Mais c'est justement la force du shell de Unix -- que des éléments puissent s'y integrer parfaitement sans en connaître l'existance des autres.
Sa faiblesse, évidemment, c'est que ceci impose un philosophie un peu « least common denominator » -- pas de GUI, la communication entre éléments par de l'ASCII non formatté, etc. Et personne ne met en doute sa puissance, je crois, ni sa souplesse.
-- James Kanze GABI Software http://www.gabi-soft.fr Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Jean-Marc Bourguet
Arnaud Meurgues writes:
Au deployement dans quel etat?
Je n'en sais rien. Dans l'état dont parle James. Il dit que ça ne coûte pas moins cher. Je demande ce qu'il en est pour le temps nécessaire à "faire les choses correctement".
Mais effectivement, des détails sur l'état de ce qui est déployé sont intéressant.
Le seul gain de temps que je vois n'est pas a etat equivalent.
Mais etre le premier sur le marche meme avec un produit de qualite moindre peut etre ce qui fait le succes du projet. Pas les domaines favoris de James, mais dans le mien, c'est pire.
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
Je n'en sais rien. Dans l'état dont parle James. Il dit que ça ne
coûte pas moins cher. Je demande ce qu'il en est pour le temps
nécessaire à "faire les choses correctement".
Mais effectivement, des détails sur l'état de ce qui est déployé sont
intéressant.
Le seul gain de temps que je vois n'est pas a etat equivalent.
Mais etre le premier sur le marche meme avec un produit de qualite
moindre peut etre ce qui fait le succes du projet. Pas les domaines
favoris de James, mais dans le mien, c'est pire.
A+
--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Je n'en sais rien. Dans l'état dont parle James. Il dit que ça ne coûte pas moins cher. Je demande ce qu'il en est pour le temps nécessaire à "faire les choses correctement".
Mais effectivement, des détails sur l'état de ce qui est déployé sont intéressant.
Le seul gain de temps que je vois n'est pas a etat equivalent.
Mais etre le premier sur le marche meme avec un produit de qualite moindre peut etre ce qui fait le succes du projet. Pas les domaines favoris de James, mais dans le mien, c'est pire.
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
Arnaud Meurgues
Jean-Marc Bourguet wrote:
Le seul gain de temps que je vois n'est pas a etat equivalent.
C'est le sens de ma question. James dit que produire du code de qualité (sans bug ou avec moins de bug) n'est "pas plus cher".
Si le "pas plus cher" implique "pas plus long", alors ça m'intéresse.
Mais etre le premier sur le marche meme avec un produit de qualite moindre peut etre ce qui fait le succes du projet.
C'est exactement pour ça que je posais la question.
Pas les domaines favoris de James, mais dans le mien, c'est pire.
"pire" ? Qu'entends-tu par là ?
-- Arnaud (Supprimez les geneurs pour me répondre)
Jean-Marc Bourguet wrote:
Le seul gain de temps que je vois n'est pas a etat equivalent.
C'est le sens de ma question. James dit que produire du code de qualité
(sans bug ou avec moins de bug) n'est "pas plus cher".
Si le "pas plus cher" implique "pas plus long", alors ça m'intéresse.
Mais etre le premier sur le marche meme avec un produit de qualite
moindre peut etre ce qui fait le succes du projet.
C'est exactement pour ça que je posais la question.
Pas les domaines
favoris de James, mais dans le mien, c'est pire.
"pire" ? Qu'entends-tu par là ?
--
Arnaud
(Supprimez les geneurs pour me répondre)
Le seul gain de temps que je vois n'est pas a etat equivalent.
C'est le sens de ma question. James dit que produire du code de qualité (sans bug ou avec moins de bug) n'est "pas plus cher".
Si le "pas plus cher" implique "pas plus long", alors ça m'intéresse.
Mais etre le premier sur le marche meme avec un produit de qualite moindre peut etre ce qui fait le succes du projet.
C'est exactement pour ça que je posais la question.
Pas les domaines favoris de James, mais dans le mien, c'est pire.
"pire" ? Qu'entends-tu par là ?
-- Arnaud (Supprimez les geneurs pour me répondre)
Jean-Marc Bourguet
Arnaud Meurgues writes:
Jean-Marc Bourguet wrote:
Le seul gain de temps que je vois n'est pas a etat equivalent.
Ce n'est pas clair, il manque "pour une version << vite fait mal fait >> "
C'est le sens de ma question. James dit que produire du code de qualité (sans bug ou avec moins de bug) n'est "pas plus cher".
Si le "pas plus cher" implique "pas plus long", alors ça m'intéresse.
Ce n'est pas plus long si on a un minimum de qualité.
Mais etre le premier sur le marche meme avec un produit de qualite moindre peut etre ce qui fait le succes du projet.
C'est exactement pour ça que je posais la question.
Travailler sans rigueur permets d'arriver plus vite à la démo. J'en suis sur.
Je ne sais pas si ça permet d'arriver plus vite à la mise sur le marché. Il y a quand même un minimum de qualité et en pratique les équipes les moins rigoureuses ont du plus de retard que les équipes plus rigoureuses (mais d'autres part leurs estimations sont souvent inférieures à celles des équipes rigoureuses pour ce qui semble être les mêmes taches, savoir s'ils sont simplement besoin de mieux estimer ou pas est difficile).
Et puis il faut considérer l'effet sur le cyle: en travaillant sans rigueur tu passes le temps qui devrait être consacré au développement de la release suivante à fixer les problèmes de la release précédante.
Pas les domaines favoris de James, mais dans le mien, c'est pire.
"pire" ? Qu'entends-tu par là ?
Je ne sais plus exactement, à force de modifier la formulation j'ai écrit qqch d'incompréhensible.
Il y a beaucoup moins de rigueur dans mon environnement (même moi bien que je fasse partie d'une des équipes les plus rigoureuses de la boîte) que dans celui de James.
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
Le seul gain de temps que je vois n'est pas a etat equivalent.
Ce n'est pas clair, il manque "pour une version << vite fait
mal fait >> "
C'est le sens de ma question. James dit que produire du
code de qualité (sans bug ou avec moins de bug) n'est "pas
plus cher".
Si le "pas plus cher" implique "pas plus long", alors ça m'intéresse.
Ce n'est pas plus long si on a un minimum de qualité.
Mais etre le premier sur le marche meme avec un produit de qualite
moindre peut etre ce qui fait le succes du projet.
C'est exactement pour ça que je posais la question.
Travailler sans rigueur permets d'arriver plus vite à la
démo. J'en suis sur.
Je ne sais pas si ça permet d'arriver plus vite à la mise
sur le marché. Il y a quand même un minimum de qualité et
en pratique les équipes les moins rigoureuses ont du plus de
retard que les équipes plus rigoureuses (mais d'autres part
leurs estimations sont souvent inférieures à celles des
équipes rigoureuses pour ce qui semble être les mêmes
taches, savoir s'ils sont simplement besoin de mieux estimer
ou pas est difficile).
Et puis il faut considérer l'effet sur le cyle: en
travaillant sans rigueur tu passes le temps qui devrait être
consacré au développement de la release suivante à fixer les
problèmes de la release précédante.
Pas les domaines favoris de James, mais dans le mien,
c'est pire.
"pire" ? Qu'entends-tu par là ?
Je ne sais plus exactement, à force de modifier la
formulation j'ai écrit qqch d'incompréhensible.
Il y a beaucoup moins de rigueur dans mon environnement
(même moi bien que je fasse partie d'une des équipes les
plus rigoureuses de la boîte) que dans celui de James.
A+
--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Le seul gain de temps que je vois n'est pas a etat equivalent.
Ce n'est pas clair, il manque "pour une version << vite fait mal fait >> "
C'est le sens de ma question. James dit que produire du code de qualité (sans bug ou avec moins de bug) n'est "pas plus cher".
Si le "pas plus cher" implique "pas plus long", alors ça m'intéresse.
Ce n'est pas plus long si on a un minimum de qualité.
Mais etre le premier sur le marche meme avec un produit de qualite moindre peut etre ce qui fait le succes du projet.
C'est exactement pour ça que je posais la question.
Travailler sans rigueur permets d'arriver plus vite à la démo. J'en suis sur.
Je ne sais pas si ça permet d'arriver plus vite à la mise sur le marché. Il y a quand même un minimum de qualité et en pratique les équipes les moins rigoureuses ont du plus de retard que les équipes plus rigoureuses (mais d'autres part leurs estimations sont souvent inférieures à celles des équipes rigoureuses pour ce qui semble être les mêmes taches, savoir s'ils sont simplement besoin de mieux estimer ou pas est difficile).
Et puis il faut considérer l'effet sur le cyle: en travaillant sans rigueur tu passes le temps qui devrait être consacré au développement de la release suivante à fixer les problèmes de la release précédante.
Pas les domaines favoris de James, mais dans le mien, c'est pire.
"pire" ? Qu'entends-tu par là ?
Je ne sais plus exactement, à force de modifier la formulation j'ai écrit qqch d'incompréhensible.
Il y a beaucoup moins de rigueur dans mon environnement (même moi bien que je fasse partie d'une des équipes les plus rigoureuses de la boîte) que dans celui de James.
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
drkm
Marc Boyer writes:
In article , drkm wrote:
J'avais un moment pensé exporter des infos requeillies de GCC vers un format exploitable par Semantic.
Donc, tu te fais l'intégration à la main.
Je ne suis pas sûr de comprendre. Je précise que Semantic analyse déjà (plutôt bien, il me semble) le C++. Je voulais juste obtenir des infos *exactes* venues tout droit du compilo.
--drkm
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> writes:
In article <wk7joidaa5.fsf@fgeorges.org>, drkm wrote:
J'avais un moment pensé exporter des infos requeillies
de GCC vers un format exploitable par Semantic.
Donc, tu te fais l'intégration à la main.
Je ne suis pas sûr de comprendre. Je précise que Semantic analyse
déjà (plutôt bien, il me semble) le C++. Je voulais juste obtenir des
infos *exactes* venues tout droit du compilo.
J'avais un moment pensé exporter des infos requeillies de GCC vers un format exploitable par Semantic.
Donc, tu te fais l'intégration à la main.
Je ne suis pas sûr de comprendre. Je précise que Semantic analyse déjà (plutôt bien, il me semble) le C++. Je voulais juste obtenir des infos *exactes* venues tout droit du compilo.
--drkm
drkm
Arnaud Meurgues writes:
Si le "pas plus cher" implique "pas plus long", alors ça m'intéresse.
C'est en effet principalement comme cela que je l'ai compris. Quels pourraient être les autres coûts significatifs, sur un projet d'un certaine empleur ?
Si le "pas plus cher" implique "pas plus long", alors ça m'intéresse.
C'est en effet principalement comme cela que je l'ai compris. Quels
pourraient être les autres coûts significatifs, sur un projet d'un
certaine empleur ?
Si le "pas plus cher" implique "pas plus long", alors ça m'intéresse.
C'est en effet principalement comme cela que je l'ai compris. Quels pourraient être les autres coûts significatifs, sur un projet d'un certaine empleur ?
--drkm
drkm
Marc Boyer writes:
In article , drkm wrote:
Marc Boyer writes:
In article , drkm wrote:
Marc Boyer writes:
Oui, j'essaye de tout mettre dans un .cpp que le .hpp inclut. C'est plus lisible, je retrouve plus vite mes petits, tout ça.
Je suppose que tu parles d'un en-tête .hh, une implémentation des éléments non-template .cc, et une implémentation des templates .tcc.
Non, actuellement, ce sont des .hpp et des .cpp, mais bon, un petit find des familles pourra bouger tout ça...
« find des familles » ?
find . -name "*.h" -exec cp {} basename {}.hpp ;
Un truc du genre.
Je crains de ne toujours pas comprendre ...
En passant, j'ai l'impression que ton find est un peu bancal. Je n'en suis pas un expert, mais j'ai l'impression qu'il copie dans le répertoire courant tous les *.h des sous répertoires en y /ajoutant/ l'extension .hpp. Non ?
--drkm
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> writes:
In article <wkvfc3dmek.fsf@fgeorges.org>, drkm wrote:
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> writes:
In article <wk3bz85fwa.fsf@fgeorges.org>, drkm wrote:
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> writes:
Oui, j'essaye de tout mettre dans un .cpp que le .hpp inclut.
C'est plus lisible, je retrouve plus vite mes petits, tout ça.
Je suppose que tu parles d'un en-tête .hh, une implémentation des
éléments non-template .cc, et une implémentation des templates .tcc.
Non, actuellement, ce sont des .hpp et des .cpp, mais bon, un
petit find des familles pourra bouger tout ça...
« find des familles » ?
find . -name "*.h" -exec cp {} basename {}.hpp ;
Un truc du genre.
Je crains de ne toujours pas comprendre ...
En passant, j'ai l'impression que ton find est un peu bancal. Je
n'en suis pas un expert, mais j'ai l'impression qu'il copie dans le
répertoire courant tous les *.h des sous répertoires en y /ajoutant/
l'extension .hpp. Non ?
Oui, j'essaye de tout mettre dans un .cpp que le .hpp inclut. C'est plus lisible, je retrouve plus vite mes petits, tout ça.
Je suppose que tu parles d'un en-tête .hh, une implémentation des éléments non-template .cc, et une implémentation des templates .tcc.
Non, actuellement, ce sont des .hpp et des .cpp, mais bon, un petit find des familles pourra bouger tout ça...
« find des familles » ?
find . -name "*.h" -exec cp {} basename {}.hpp ;
Un truc du genre.
Je crains de ne toujours pas comprendre ...
En passant, j'ai l'impression que ton find est un peu bancal. Je n'en suis pas un expert, mais j'ai l'impression qu'il copie dans le répertoire courant tous les *.h des sous répertoires en y /ajoutant/ l'extension .hpp. Non ?
--drkm
Jean-Marc Bourguet
drkm writes:
Arnaud Meurgues writes:
Si le "pas plus cher" implique "pas plus long", alors ça m'intéresse.
C'est en effet principalement comme cela que je l'ai compris. Quels pourraient être les autres coûts significatifs, sur un projet d'un certaine empleur ?
Le nombre de personnes, plus il y a du monde, en théorie plus on va vite. Mais plus un groupe est nombreux, plus la proportion du temps passé en gestion augmente (et les chefs sont en plus mieux payé).
Puis un gros projet généralement vit, a plusieurs release. Fournir des versions intermédiaires pour fixer les bugs a un cout, le cout de les fixer, des les tester et de faire toute la gestion inhérente à une release.
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
Si le "pas plus cher" implique "pas plus long", alors ça m'intéresse.
C'est en effet principalement comme cela que je l'ai compris. Quels
pourraient être les autres coûts significatifs, sur un projet d'un
certaine empleur ?
Le nombre de personnes, plus il y a du monde, en théorie
plus on va vite. Mais plus un groupe est nombreux, plus la
proportion du temps passé en gestion augmente (et les chefs
sont en plus mieux payé).
Puis un gros projet généralement vit, a plusieurs release.
Fournir des versions intermédiaires pour fixer les bugs a un
cout, le cout de les fixer, des les tester et de faire toute
la gestion inhérente à une release.
A+
--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Si le "pas plus cher" implique "pas plus long", alors ça m'intéresse.
C'est en effet principalement comme cela que je l'ai compris. Quels pourraient être les autres coûts significatifs, sur un projet d'un certaine empleur ?
Le nombre de personnes, plus il y a du monde, en théorie plus on va vite. Mais plus un groupe est nombreux, plus la proportion du temps passé en gestion augmente (et les chefs sont en plus mieux payé).
Puis un gros projet généralement vit, a plusieurs release. Fournir des versions intermédiaires pour fixer les bugs a un cout, le cout de les fixer, des les tester et de faire toute la gestion inhérente à une release.
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
