j'ai entendu que les jeux videos de nos jours, sont toujours concu en c
et non en c++,
ma quesiton est POUrquoi??, le c++ a quand meme beaucoup plus d'avantage
que le c non
merci
Ps: ceci n'est pas un troll; je suis en premiere année informatique, et
je commence a apprendre le c++, et les differences du c, et etant
passionné de jeu (c'est la dedans que j'aimerais travailler) je me
posait cette question
Laurent DELEPINE wrote in message news:<3f817fa4$0$10423$...
Mais ma reaction concernait l'informatique en général, pas les jeux en particulier, ou il est de bon ton de dire que les maths sont indispensables alors qu'ils ne sont nécessaires que dans quelques cas particuliers. Ce qui est vraiment nécessaire, c'est la logique.
Si tu régardes toutes tes études, combien te sert directement dans la programmation ? Le but de la plupart des études, ce n'est pas tellement acquisition des connaissances précises, mais l'acquisition d'une façon de penser.
Si la plupart d'entre nous n'ont pas besoin d'un niveau élevé de maths, du point de vue des connaissances, on a bien besoin d'un façon mathématique de penser, et la façon la plus facile de l'acquérir, c'est bien d'étudier des maths. Jusqu'à un niveau assez évelé.
La même chose vaut pour le français, d'ailleurs.
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
Laurent DELEPINE <newsgroup@webiologie.org> wrote in message
news:<3f817fa4$0$10423$626a54ce@news.free.fr>...
Mais ma reaction concernait l'informatique en général, pas les jeux en
particulier, ou il est de bon ton de dire que les maths sont
indispensables alors qu'ils ne sont nécessaires que dans quelques cas
particuliers. Ce qui est vraiment nécessaire, c'est la logique.
Si tu régardes toutes tes études, combien te sert directement dans la
programmation ? Le but de la plupart des études, ce n'est pas tellement
acquisition des connaissances précises, mais l'acquisition d'une façon
de penser.
Si la plupart d'entre nous n'ont pas besoin d'un niveau élevé de maths,
du point de vue des connaissances, on a bien besoin d'un façon
mathématique de penser, et la façon la plus facile de l'acquérir, c'est
bien d'étudier des maths. Jusqu'à un niveau assez évelé.
La même chose vaut pour le français, d'ailleurs.
--
James Kanze GABI Software mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
Laurent DELEPINE wrote in message news:<3f817fa4$0$10423$...
Mais ma reaction concernait l'informatique en général, pas les jeux en particulier, ou il est de bon ton de dire que les maths sont indispensables alors qu'ils ne sont nécessaires que dans quelques cas particuliers. Ce qui est vraiment nécessaire, c'est la logique.
Si tu régardes toutes tes études, combien te sert directement dans la programmation ? Le but de la plupart des études, ce n'est pas tellement acquisition des connaissances précises, mais l'acquisition d'une façon de penser.
Si la plupart d'entre nous n'ont pas besoin d'un niveau élevé de maths, du point de vue des connaissances, on a bien besoin d'un façon mathématique de penser, et la façon la plus facile de l'acquérir, c'est bien d'étudier des maths. Jusqu'à un niveau assez évelé.
La même chose vaut pour le français, d'ailleurs.
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
kanze
Gabriel Dos Reis wrote in message news:...
Frederic Py writes:
| Fabien LE LEZ said on 10/06/03 14:33: | > On Mon, 6 Oct 2003 13:55:52 +0200, "Fred" wrote:
| >>char* monBeauTableau=new char[2];
| >>C'est du C++
| > Sans doute. Mais c'est une structure rarement utilisée. En fait, | > il m'arrive d'allouer des objets directement par new, mais je ne | > sais pas si new[] a réellement une utilité.
| Ca permet toutefois de creer un tableau "a la C" et de pouvoir | l'exploiter dans des fonctions "C" et donc offrir une interface | C++-C ou C->C++. Ce qui peut etre utile pour ouvrir une bibliotheque | C++ au C ou exploiter une bibliotheque C en C++ ... Mais en dehors | de ca je vois pas l'interet vu que dans ces deux cas on pourrait se | tourner vers calloc afin d'eviter certains soucis (?)
Pourquoi veux-tu te tourner vers calloc ?
Pour avoir la fausse impression de faire comme vector<T>.
Si j'écris « std::vector<int> vi(10) », les dix int sont initialisés à 0. De même quand j'écris « calloc( 10 * sizeof( int ) ) ».
En revanche, si j'écris « std::vector< double > vd( 10 ) », les dix double sont bien initialisés à 0.0, tandis que si j'écris « calloc( 10 * sizeof( double ) ) », il n'y a aucune initialisation qui ne vaut de façon garantie et portable.
Du coup, calloc c'est plutôt une piège que d'autre chose. AMHA, évidemment.
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
Gabriel Dos Reis <dosreis@cmla.ens-cachan.fr> wrote in message
news:<flsmm61kim.fsf@sel.cmla.ens-cachan.fr>...
Frederic Py <fpy.nospam@laas.rf> writes:
| Fabien LE LEZ said on 10/06/03 14:33:
| > On Mon, 6 Oct 2003 13:55:52 +0200, "Fred" <no.spam@spam.no> wrote:
| >>char* monBeauTableau=new char[2];
| >>C'est du C++
| > Sans doute. Mais c'est une structure rarement utilisée. En fait,
| > il m'arrive d'allouer des objets directement par new, mais je ne
| > sais pas si new[] a réellement une utilité.
| Ca permet toutefois de creer un tableau "a la C" et de pouvoir
| l'exploiter dans des fonctions "C" et donc offrir une interface
| C++-C ou C->C++. Ce qui peut etre utile pour ouvrir une bibliotheque
| C++ au C ou exploiter une bibliotheque C en C++ ... Mais en dehors
| de ca je vois pas l'interet vu que dans ces deux cas on pourrait se
| tourner vers calloc afin d'eviter certains soucis (?)
Pourquoi veux-tu te tourner vers calloc ?
Pour avoir la fausse impression de faire comme vector<T>.
Si j'écris « std::vector<int> vi(10) », les dix int sont initialisés à
0. De même quand j'écris « calloc( 10 * sizeof( int ) ) ».
En revanche, si j'écris « std::vector< double > vd( 10 ) », les dix
double sont bien initialisés à 0.0, tandis que si j'écris « calloc( 10 *
sizeof( double ) ) », il n'y a aucune initialisation qui ne vaut de
façon garantie et portable.
Du coup, calloc c'est plutôt une piège que d'autre chose. AMHA,
évidemment.
--
James Kanze GABI Software mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
| Fabien LE LEZ said on 10/06/03 14:33: | > On Mon, 6 Oct 2003 13:55:52 +0200, "Fred" wrote:
| >>char* monBeauTableau=new char[2];
| >>C'est du C++
| > Sans doute. Mais c'est une structure rarement utilisée. En fait, | > il m'arrive d'allouer des objets directement par new, mais je ne | > sais pas si new[] a réellement une utilité.
| Ca permet toutefois de creer un tableau "a la C" et de pouvoir | l'exploiter dans des fonctions "C" et donc offrir une interface | C++-C ou C->C++. Ce qui peut etre utile pour ouvrir une bibliotheque | C++ au C ou exploiter une bibliotheque C en C++ ... Mais en dehors | de ca je vois pas l'interet vu que dans ces deux cas on pourrait se | tourner vers calloc afin d'eviter certains soucis (?)
Pourquoi veux-tu te tourner vers calloc ?
Pour avoir la fausse impression de faire comme vector<T>.
Si j'écris « std::vector<int> vi(10) », les dix int sont initialisés à 0. De même quand j'écris « calloc( 10 * sizeof( int ) ) ».
En revanche, si j'écris « std::vector< double > vd( 10 ) », les dix double sont bien initialisés à 0.0, tandis que si j'écris « calloc( 10 * sizeof( double ) ) », il n'y a aucune initialisation qui ne vaut de façon garantie et portable.
Du coup, calloc c'est plutôt une piège que d'autre chose. AMHA, évidemment.
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
kanze
Marc Boyer wrote in message news:<blrajt$gvt$...
ricky wrote:
toutefois, dans ce cadre, t si ta recherche est la performance d'affichage, les routines internes sont plutot ecrites en c, lie a de l'assembleur pour les plus petites routines les plus demandeurs...
Hum ? Des références ? Une argumentation ? Je ne vois pas bien pourquoi le C serait plus rapide que le C++ à fonctionnalités équivalentes.
Si les deux compilateurs étaient indépendants, fournis par deux sociétés différentes, et représentaient à peu près la même investissement pour chacune des sociétés, il est probable que le compilateur C serait nettement plus fort en optimisation. Avec des ressources finies, on ne fait pas tout ce qu'on veut, et les ressources que le fournisseur du compilateur C++ a mises à l'implémentation des templates, etc., le fournisseur du compilateur C les a mises à l'optimisation.
Mais c'est un cas de figure que je n'ai jamais vu. En général, le compilateur C et le compilateur C++ vient ensemble, et partage le même optimisateur et le même back-end. Et que souvent, même, c'est le compilateur C++ qui porte le drapeau, et qui reçoit la plupart des efforts. Du coup, à code égal, il n'y a pas de différence.
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr> wrote in message
news:<blrajt$gvt$2@news.cict.fr>...
ricky wrote:
toutefois, dans ce cadre, t si ta recherche est la performance
d'affichage, les routines internes sont plutot ecrites en c, lie a
de l'assembleur pour les plus petites routines les plus
demandeurs...
Hum ? Des références ? Une argumentation ? Je ne vois pas bien
pourquoi le C serait plus rapide que le C++ à fonctionnalités
équivalentes.
Si les deux compilateurs étaient indépendants, fournis par deux sociétés
différentes, et représentaient à peu près la même investissement pour
chacune des sociétés, il est probable que le compilateur C serait
nettement plus fort en optimisation. Avec des ressources finies, on ne
fait pas tout ce qu'on veut, et les ressources que le fournisseur du
compilateur C++ a mises à l'implémentation des templates, etc., le
fournisseur du compilateur C les a mises à l'optimisation.
Mais c'est un cas de figure que je n'ai jamais vu. En général, le
compilateur C et le compilateur C++ vient ensemble, et partage le même
optimisateur et le même back-end. Et que souvent, même, c'est le
compilateur C++ qui porte le drapeau, et qui reçoit la plupart des
efforts. Du coup, à code égal, il n'y a pas de différence.
--
James Kanze GABI Software mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
toutefois, dans ce cadre, t si ta recherche est la performance d'affichage, les routines internes sont plutot ecrites en c, lie a de l'assembleur pour les plus petites routines les plus demandeurs...
Hum ? Des références ? Une argumentation ? Je ne vois pas bien pourquoi le C serait plus rapide que le C++ à fonctionnalités équivalentes.
Si les deux compilateurs étaient indépendants, fournis par deux sociétés différentes, et représentaient à peu près la même investissement pour chacune des sociétés, il est probable que le compilateur C serait nettement plus fort en optimisation. Avec des ressources finies, on ne fait pas tout ce qu'on veut, et les ressources que le fournisseur du compilateur C++ a mises à l'implémentation des templates, etc., le fournisseur du compilateur C les a mises à l'optimisation.
Mais c'est un cas de figure que je n'ai jamais vu. En général, le compilateur C et le compilateur C++ vient ensemble, et partage le même optimisateur et le même back-end. Et que souvent, même, c'est le compilateur C++ qui porte le drapeau, et qui reçoit la plupart des efforts. Du coup, à code égal, il n'y a pas de différence.
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
Gabriel Dos Reis
Richard Delorme writes:
| | > Richard Delorme writes: | > | > | > La généricité, c'est écrire du code général *pour un ensemble de | > | > critères données*. En particulier, lorsqu'on spécialise on doit | > | > retrouver au moins la même performance que si on avait écrit le code | > | > directement. | > | > | > | > [...] | > | | > | Je ne dit pas le contraire, mais la spécialisation n'est qu'une méthode, | > | peut-être élégante, de réécrire le code. | > | > Ce que j'appelle spécialisation dans la phrase ci-dessus, c'est | > l'action de substituer des valeurs aux paramètres génériques. | | C'est-à-dire ?
(1) Tu écris ton template. (2) Tu subtitues des valeurs aux paramètres génériques -- qui correspondent à cas particuliers. (3) si la substitution ne te donne pas au moins la même efficacité que la routine écrite sans considération de template, alors il faut revoir la copie : ce n'est pas une rouotine générique.
La même chose vaut pour les structures de données.
|
| > Richard Delorme <abulmo@nospam.fr> writes:
| >
| > | > La généricité, c'est écrire du code général *pour un ensemble de
| > | > critères données*. En particulier, lorsqu'on spécialise on doit
| > | > retrouver au moins la même performance que si on avait écrit le code
| > | > directement.
| > | >
| > | > [...]
| > |
| > | Je ne dit pas le contraire, mais la spécialisation n'est qu'une méthode,
| > | peut-être élégante, de réécrire le code.
| >
| > Ce que j'appelle spécialisation dans la phrase ci-dessus, c'est
| > l'action de substituer des valeurs aux paramètres génériques.
|
| C'est-à-dire ?
(1) Tu écris ton template.
(2) Tu subtitues des valeurs aux paramètres génériques -- qui
correspondent à cas particuliers.
(3) si la substitution ne te donne pas au moins la même efficacité
que la routine écrite sans considération de template, alors
il faut revoir la copie : ce n'est pas une rouotine générique.
La même chose vaut pour les structures de données.
| | > Richard Delorme writes: | > | > | > La généricité, c'est écrire du code général *pour un ensemble de | > | > critères données*. En particulier, lorsqu'on spécialise on doit | > | > retrouver au moins la même performance que si on avait écrit le code | > | > directement. | > | > | > | > [...] | > | | > | Je ne dit pas le contraire, mais la spécialisation n'est qu'une méthode, | > | peut-être élégante, de réécrire le code. | > | > Ce que j'appelle spécialisation dans la phrase ci-dessus, c'est | > l'action de substituer des valeurs aux paramètres génériques. | | C'est-à-dire ?
(1) Tu écris ton template. (2) Tu subtitues des valeurs aux paramètres génériques -- qui correspondent à cas particuliers. (3) si la substitution ne te donne pas au moins la même efficacité que la routine écrite sans considération de template, alors il faut revoir la copie : ce n'est pas une rouotine générique.
La même chose vaut pour les structures de données.
La raison est que quand on utilise l'opérateur+, il y a création/destruction de variables temporaires, pas quand on utilise +=. Ça peut avoir une importance dans du code critique.
J'ai l'impression que tu prends le problème dans le mauvais sens. Optimiser dès le début me paraît discutable, même pour les jeux. Mieux vaut faire rapidement un programme fiable (ce que permet le C++), ce qui laisse du temps pour tester le programme et repérer, pendant l'exécution, les goulots d'étranglement qu'il faudra effectivement optimiser.
Je n'ai jamais dit le contraire. La question initiale était « Je ne vois pas bien pourquoi le C serait plus rapide que le C++ à fonctionnalités équivalentes. » je me suis contenté de glisser quelques pistes. En résumé, le C++ offre quelques facilités, « à fonctionnalités équivalentes », mais de moindre performance. En C, on n'a souvent qu'une manière de procéder, la bonne, et le problème se pose moins.
-- Richard
On Tue, 07 Oct 2003 01:02:23 +0200, Richard Delorme <abulmo@nospam.fr>
wrote:
Comme on ne voit pas les appels au constructeurs/destructeurs, on a
tendance à en minimiser l'impact.
La raison est que quand on utilise l'opérateur+, il y a création/destruction
de variables temporaires, pas quand on utilise +=. Ça peut avoir une
importance dans du code critique.
J'ai l'impression que tu prends le problème dans le mauvais sens.
Optimiser dès le début me paraît discutable, même pour les jeux. Mieux
vaut faire rapidement un programme fiable (ce que permet le C++), ce
qui laisse du temps pour tester le programme et repérer, pendant
l'exécution, les goulots d'étranglement qu'il faudra effectivement
optimiser.
Je n'ai jamais dit le contraire. La question initiale était « Je ne vois pas
bien pourquoi le C serait plus rapide que le C++ à fonctionnalités
équivalentes. » je me suis contenté de glisser quelques pistes. En résumé,
le C++ offre quelques facilités, « à fonctionnalités équivalentes », mais
de moindre performance. En C, on n'a souvent qu'une manière de procéder, la
bonne, et le problème se pose moins.
La raison est que quand on utilise l'opérateur+, il y a création/destruction de variables temporaires, pas quand on utilise +=. Ça peut avoir une importance dans du code critique.
J'ai l'impression que tu prends le problème dans le mauvais sens. Optimiser dès le début me paraît discutable, même pour les jeux. Mieux vaut faire rapidement un programme fiable (ce que permet le C++), ce qui laisse du temps pour tester le programme et repérer, pendant l'exécution, les goulots d'étranglement qu'il faudra effectivement optimiser.
Je n'ai jamais dit le contraire. La question initiale était « Je ne vois pas bien pourquoi le C serait plus rapide que le C++ à fonctionnalités équivalentes. » je me suis contenté de glisser quelques pistes. En résumé, le C++ offre quelques facilités, « à fonctionnalités équivalentes », mais de moindre performance. En C, on n'a souvent qu'une manière de procéder, la bonne, et le problème se pose moins.
-- Richard
Fabien LE LEZ
On 7 Oct 2003 04:08:04 -0700, wrote:
Si la plupart d'entre nous n'ont pas besoin d'un niveau élevé de maths, du point de vue des connaissances, on a bien besoin d'un façon mathématique de penser, et la façon la plus facile de l'acquérir, c'est bien d'étudier des maths. Jusqu'à un niveau assez évelé.
Je confirme : c'est en cours de maths (après le bac bien sûr) que j'ai appris la rigueur nécessaire à la programmation en C++.
La même chose vaut pour le français, d'ailleurs.
C'est différent : dans le français, c'est bien les connaissances (vocabulaire, syntaxe, etc.) qui te servent pour t'exprimer, tandis que dans les maths, c'est plus la tournure d'esprit qui s'avère utile.
On 7 Oct 2003 04:08:04 -0700, kanze@gabi-soft.fr wrote:
Si la plupart d'entre nous n'ont pas besoin d'un niveau élevé de maths,
du point de vue des connaissances, on a bien besoin d'un façon
mathématique de penser, et la façon la plus facile de l'acquérir, c'est
bien d'étudier des maths. Jusqu'à un niveau assez évelé.
Je confirme : c'est en cours de maths (après le bac bien sûr) que j'ai
appris la rigueur nécessaire à la programmation en C++.
La même chose vaut pour le français, d'ailleurs.
C'est différent : dans le français, c'est bien les connaissances
(vocabulaire, syntaxe, etc.) qui te servent pour t'exprimer, tandis
que dans les maths, c'est plus la tournure d'esprit qui s'avère utile.
Si la plupart d'entre nous n'ont pas besoin d'un niveau élevé de maths, du point de vue des connaissances, on a bien besoin d'un façon mathématique de penser, et la façon la plus facile de l'acquérir, c'est bien d'étudier des maths. Jusqu'à un niveau assez évelé.
Je confirme : c'est en cours de maths (après le bac bien sûr) que j'ai appris la rigueur nécessaire à la programmation en C++.
La même chose vaut pour le français, d'ailleurs.
C'est différent : dans le français, c'est bien les connaissances (vocabulaire, syntaxe, etc.) qui te servent pour t'exprimer, tandis que dans les maths, c'est plus la tournure d'esprit qui s'avère utile.
| > J'ai l'impression que tu prends le problème dans le mauvais sens. | > Optimiser dès le début me paraît discutable, même pour les jeux. Mieux | > vaut faire rapidement un programme fiable (ce que permet le C++), ce | > qui laisse du temps pour tester le programme et repérer, pendant | > l'exécution, les goulots d'étranglement qu'il faudra effectivement | > optimiser. | | Je n'ai jamais dit le contraire.
La question n'est pas tant le fait que tu aies dit le contraire de quelque chose. La question porte plutôt sur le bien fondé de tes affirmations :
| La question initiale était « Je ne vois pas | bien pourquoi le C serait plus rapide que le C++ à fonctionnalités | équivalentes. » je me suis contenté de glisser quelques pistes. En résumé, | le C++ offre quelques facilités, « à fonctionnalités équivalentes », mais | de moindre performance. En C, on n'a souvent qu'une manière de procéder, la | bonne, et le problème se pose moins.
-- Gaby
Richard Delorme <abulmo@nospam.fr> writes:
[...]
| > J'ai l'impression que tu prends le problème dans le mauvais sens.
| > Optimiser dès le début me paraît discutable, même pour les jeux. Mieux
| > vaut faire rapidement un programme fiable (ce que permet le C++), ce
| > qui laisse du temps pour tester le programme et repérer, pendant
| > l'exécution, les goulots d'étranglement qu'il faudra effectivement
| > optimiser.
|
| Je n'ai jamais dit le contraire.
La question n'est pas tant le fait que tu aies dit le contraire de
quelque chose. La question porte plutôt sur le bien fondé de tes
affirmations :
| La question initiale était « Je ne vois pas
| bien pourquoi le C serait plus rapide que le C++ à fonctionnalités
| équivalentes. » je me suis contenté de glisser quelques pistes. En résumé,
| le C++ offre quelques facilités, « à fonctionnalités équivalentes », mais
| de moindre performance. En C, on n'a souvent qu'une manière de procéder, la
| bonne, et le problème se pose moins.
| > J'ai l'impression que tu prends le problème dans le mauvais sens. | > Optimiser dès le début me paraît discutable, même pour les jeux. Mieux | > vaut faire rapidement un programme fiable (ce que permet le C++), ce | > qui laisse du temps pour tester le programme et repérer, pendant | > l'exécution, les goulots d'étranglement qu'il faudra effectivement | > optimiser. | | Je n'ai jamais dit le contraire.
La question n'est pas tant le fait que tu aies dit le contraire de quelque chose. La question porte plutôt sur le bien fondé de tes affirmations :
| La question initiale était « Je ne vois pas | bien pourquoi le C serait plus rapide que le C++ à fonctionnalités | équivalentes. » je me suis contenté de glisser quelques pistes. En résumé, | le C++ offre quelques facilités, « à fonctionnalités équivalentes », mais | de moindre performance. En C, on n'a souvent qu'une manière de procéder, la | bonne, et le problème se pose moins.
-- Gaby
Marc Boyer
Richard Delorme wrote:
On Tue, 07 Oct 2003 01:02:23 +0200, Richard Delorme wrote: Encore faut-il qu'il y ait un impact.
La raison est que quand on utilise l'opérateur+, il y a création/destruction de variables temporaires, pas quand on utilise +=. Ça peut avoir une importance dans du code critique.
Parce que ton compilateur ne sais pas appliquer la NRVO ?
Marc Boyer -- Lying for having sex or lying for making war? Trust US presidents :-(
Richard Delorme wrote:
On Tue, 07 Oct 2003 01:02:23 +0200, Richard Delorme <abulmo@nospam.fr>
wrote:
Encore faut-il qu'il y ait un impact.
La raison est que quand on utilise l'opérateur+, il y a création/destruction
de variables temporaires, pas quand on utilise +=. Ça peut avoir une
importance dans du code critique.
Parce que ton compilateur ne sais pas appliquer la NRVO ?
Marc Boyer
--
Lying for having sex or lying for making war? Trust US presidents :-(
La raison est que quand on utilise l'opérateur+, il y a création/destruction de variables temporaires, pas quand on utilise +=. Ça peut avoir une importance dans du code critique.
Parce que ton compilateur ne sais pas appliquer la NRVO ?
Marc Boyer -- Lying for having sex or lying for making war? Trust US presidents :-(
Mickael Pointier
toutefois, dans ce cadre, t si ta recherche est la performance d'affichage, les routines internes sont plutot ecrites en c, lie a de l'assembleur pour les plus petites routines les plus demandeurs...
Hum ? Des références ? Une argumentation ? Je ne vois pas bien pourquoi le C serait plus rapide que le C++ à fonctionnalités équivalentes.
Si les deux compilateurs étaient indépendants, fournis par deux sociétés différentes, et représentaient à peu près la même investissement pour chacune des sociétés, il est probable que le compilateur C serait nettement plus fort en optimisation. Avec des ressources finies, on ne fait pas tout ce qu'on veut, et les ressources que le fournisseur du compilateur C++ a mises à l'implémentation des templates, etc., le fournisseur du compilateur C les a mises à l'optimisation.
Mais c'est un cas de figure que je n'ai jamais vu. En général, le compilateur C et le compilateur C++ vient ensemble, et partage le même optimisateur et le même back-end. Et que souvent, même, c'est le compilateur C++ qui porte le drapeau, et qui reçoit la plupart des efforts. Du coup, à code égal, il n'y a pas de différence.
Oui mais dans ce cas ce n'est plus le C et le C+ que l'on compare, mais juste une implémentation d'un compilateur C "X" par rapport à l'implémentation d'un compilateur C++ "Y"...
Mike
toutefois, dans ce cadre, t si ta recherche est la performance
d'affichage, les routines internes sont plutot ecrites en c, lie a
de l'assembleur pour les plus petites routines les plus
demandeurs...
Hum ? Des références ? Une argumentation ? Je ne vois pas bien
pourquoi le C serait plus rapide que le C++ à fonctionnalités
équivalentes.
Si les deux compilateurs étaient indépendants, fournis par deux
sociétés différentes, et représentaient à peu près la même
investissement pour chacune des sociétés, il est probable que le
compilateur C serait nettement plus fort en optimisation. Avec des
ressources finies, on ne fait pas tout ce qu'on veut, et les
ressources que le fournisseur du compilateur C++ a mises à
l'implémentation des templates, etc., le fournisseur du compilateur C
les a mises à l'optimisation.
Mais c'est un cas de figure que je n'ai jamais vu. En général, le
compilateur C et le compilateur C++ vient ensemble, et partage le même
optimisateur et le même back-end. Et que souvent, même, c'est le
compilateur C++ qui porte le drapeau, et qui reçoit la plupart des
efforts. Du coup, à code égal, il n'y a pas de différence.
Oui mais dans ce cas ce n'est plus le C et le C+ que l'on compare, mais
juste une implémentation d'un compilateur C "X" par rapport à
l'implémentation d'un compilateur C++ "Y"...
toutefois, dans ce cadre, t si ta recherche est la performance d'affichage, les routines internes sont plutot ecrites en c, lie a de l'assembleur pour les plus petites routines les plus demandeurs...
Hum ? Des références ? Une argumentation ? Je ne vois pas bien pourquoi le C serait plus rapide que le C++ à fonctionnalités équivalentes.
Si les deux compilateurs étaient indépendants, fournis par deux sociétés différentes, et représentaient à peu près la même investissement pour chacune des sociétés, il est probable que le compilateur C serait nettement plus fort en optimisation. Avec des ressources finies, on ne fait pas tout ce qu'on veut, et les ressources que le fournisseur du compilateur C++ a mises à l'implémentation des templates, etc., le fournisseur du compilateur C les a mises à l'optimisation.
Mais c'est un cas de figure que je n'ai jamais vu. En général, le compilateur C et le compilateur C++ vient ensemble, et partage le même optimisateur et le même back-end. Et que souvent, même, c'est le compilateur C++ qui porte le drapeau, et qui reçoit la plupart des efforts. Du coup, à code égal, il n'y a pas de différence.
Oui mais dans ce cas ce n'est plus le C et le C+ que l'on compare, mais juste une implémentation d'un compilateur C "X" par rapport à l'implémentation d'un compilateur C++ "Y"...
Mike
Fabien LE LEZ
On 7 Oct 2003 09:00:38 GMT, Marc Boyer wrote:
hormis que le peu de XX1 que j'ai eut à faire m'a donnée envie de faire autre chose si c'était possible
