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
| >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.
Détrompe-toi. Il ne suffit pas seulement d'avoir un champ lexical un peu au dessus de la moyenne -- nécessaire pour correctement lire « quatrevingt-treize » au lieu de « neuf trois. » Il est aussi important d'avoir une certaine pensée logique pour mener une argumentation, ou persuader un public. La rhétorique (eh oui, la vrai rhétorique, pas celle qui a acquis un sens péjoratif) en français s'appuie aussi sur une étude poussée du français. La même chose vaut si elle est faite en anglais ou en papoue. Si tu ne connais pas bien le medium, il est hautement possible que le message que tu veux transmettre se perde. Si tu as un avocat et que tu plaides devant une cour de justice française, il vaut mieux pour toi qu'en plus de faire preuve d'une démarche cartésienne il manie la langue de Molière avec une certaine aisance. Pour cela, il faut plus que vocabulaire + syntaxe.
-- Gaby
Fabien LE LEZ <gramster@gramster.com> writes:
[...]
| >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.
Détrompe-toi. Il ne suffit pas seulement d'avoir un champ lexical un
peu au dessus de la moyenne -- nécessaire pour correctement lire
« quatrevingt-treize » au lieu de « neuf trois. »
Il est aussi important d'avoir une certaine pensée logique pour mener
une argumentation, ou persuader un public.
La rhétorique (eh oui, la vrai rhétorique, pas celle qui a acquis un
sens péjoratif) en français s'appuie aussi sur une étude poussée du
français. La même chose vaut si elle est faite en anglais ou en
papoue. Si tu ne connais pas bien le medium, il est hautement possible
que le message que tu veux transmettre se perde. Si tu as un avocat et
que tu plaides devant une cour de justice française, il vaut mieux
pour toi qu'en plus de faire preuve d'une démarche cartésienne il
manie la langue de Molière avec une certaine aisance. Pour cela, il
faut plus que vocabulaire + syntaxe.
| >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.
Détrompe-toi. Il ne suffit pas seulement d'avoir un champ lexical un peu au dessus de la moyenne -- nécessaire pour correctement lire « quatrevingt-treize » au lieu de « neuf trois. » Il est aussi important d'avoir une certaine pensée logique pour mener une argumentation, ou persuader un public. La rhétorique (eh oui, la vrai rhétorique, pas celle qui a acquis un sens péjoratif) en français s'appuie aussi sur une étude poussée du français. La même chose vaut si elle est faite en anglais ou en papoue. Si tu ne connais pas bien le medium, il est hautement possible que le message que tu veux transmettre se perde. Si tu as un avocat et que tu plaides devant une cour de justice française, il vaut mieux pour toi qu'en plus de faire preuve d'une démarche cartésienne il manie la langue de Molière avec une certaine aisance. Pour cela, il faut plus que vocabulaire + syntaxe.
-- Gaby
Marc Boyer
Fabien LE LEZ 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
C'est aussi terrible que l'API Win32 ? ;-)
Aucune idée... L'API Win32, j'ai juste manipulé un peu les threads, jamais une IHM.
Marc Boyer -- Lying for having sex or lying for making war? Trust US presidents :-(
Fabien LE LEZ 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
C'est aussi terrible que l'API Win32 ? ;-)
Aucune idée... L'API Win32, j'ai juste manipulé
un peu les threads, jamais une IHM.
Marc Boyer
--
Lying for having sex or lying for making war? Trust US presidents :-(
hormis que le peu de XX1 que j'ai eut à faire m'a donnée envie de faire autre chose si c'était possible
C'est aussi terrible que l'API Win32 ? ;-)
Aucune idée... L'API Win32, j'ai juste manipulé un peu les threads, jamais une IHM.
Marc Boyer -- Lying for having sex or lying for making war? Trust US presidents :-(
Gabriel Dos Reis
Marc Boyer writes:
| Richard Delorme wrote: | >> On Tue, 07 Oct 2003 01:02:23 +0200, Richard Delorme | >> wrote: | >> Encore faut-il qu'il y ait un impact. | > | > Oui. Ça arrive. Par exemple : | > | > string prenom = "Richard"; | > string nom = "Delorme"; | > string nom_complet = prenom + ' ' + nom; | > | > est plus lent que d'écrire : | > | > string nom_complet = prenom; | > nom_complet += ' '; | > nom_complet += nom;
Chez moi
u += v; u += w;
est plus lent que
u = u + v + w;
lorsque u, v, et w sont des valarray. Et pourtant ...
| > | > 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 ?
Au delà de deux opérateurs, la NRVO a peu d'impact.
Mais, l'exemple de Richard ne me semble pas convaincant : il montre seulement qu'on peut écrire du code inefficace en C++. Il ne montre pas que le C++ conduit inévitablement à du code inefficace. On peut aussi écrire du code inefficace en C !
-- Gaby
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr> writes:
| 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.
| >
| > Oui. Ça arrive. Par exemple :
| >
| > string prenom = "Richard";
| > string nom = "Delorme";
| > string nom_complet = prenom + ' ' + nom;
| >
| > est plus lent que d'écrire :
| >
| > string nom_complet = prenom;
| > nom_complet += ' ';
| > nom_complet += nom;
Chez moi
u += v;
u += w;
est plus lent que
u = u + v + w;
lorsque u, v, et w sont des valarray. Et pourtant ...
| >
| > 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 ?
Au delà de deux opérateurs, la NRVO a peu d'impact.
Mais, l'exemple de Richard ne me semble pas convaincant : il montre
seulement qu'on peut écrire du code inefficace en C++. Il ne montre
pas que le C++ conduit inévitablement à du code inefficace.
On peut aussi écrire du code inefficace en C !
| Richard Delorme wrote: | >> On Tue, 07 Oct 2003 01:02:23 +0200, Richard Delorme | >> wrote: | >> Encore faut-il qu'il y ait un impact. | > | > Oui. Ça arrive. Par exemple : | > | > string prenom = "Richard"; | > string nom = "Delorme"; | > string nom_complet = prenom + ' ' + nom; | > | > est plus lent que d'écrire : | > | > string nom_complet = prenom; | > nom_complet += ' '; | > nom_complet += nom;
Chez moi
u += v; u += w;
est plus lent que
u = u + v + w;
lorsque u, v, et w sont des valarray. Et pourtant ...
| > | > 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 ?
Au delà de deux opérateurs, la NRVO a peu d'impact.
Mais, l'exemple de Richard ne me semble pas convaincant : il montre seulement qu'on peut écrire du code inefficace en C++. Il ne montre pas que le C++ conduit inévitablement à du code inefficace. On peut aussi écrire du code inefficace en C !
-- Gaby
Fabien LE LEZ
On 07 Oct 2003 14:43:18 +0200, Gabriel Dos Reis wrote:
Si tu as un avocat
Ah non ! Je refuse catégoriquement de confier quelque travail de programmation que ce soit à un avocat. Et la rédaction de spécifications encore moins... ;)
On 07 Oct 2003 14:43:18 +0200, Gabriel Dos Reis
<dosreis@cmla.ens-cachan.fr> wrote:
Si tu as un avocat
Ah non ! Je refuse catégoriquement de confier quelque travail de
programmation que ce soit à un avocat. Et la rédaction de
spécifications encore moins... ;)
On 07 Oct 2003 14:43:18 +0200, Gabriel Dos Reis wrote:
Si tu as un avocat
Ah non ! Je refuse catégoriquement de confier quelque travail de programmation que ce soit à un avocat. Et la rédaction de spécifications encore 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 :
Pourtant, j'ai donné quelques exemples, qu'est-ce qui ne va pas avec eux ?
-- Richard
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 :
Pourtant, j'ai donné quelques exemples, qu'est-ce qui ne va pas avec eux ?
| > 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 :
Pourtant, j'ai donné quelques exemples, qu'est-ce qui ne va pas avec eux ?
-- Richard
Richard Delorme
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.
Je n'ai pas toujours compris où tu veux en venir. J'ai l'impression que tu te contentes de subsituer une valeur à un paramètre générique, et hop, c'est bon, c'est optimisé pour cette valeur. Il faut aussi réécrire des routines pour ces cas particuliers il me semble.
La même chose vaut pour les structures de données.
Je ne vois rien de bien précis sur l'efficacité. Pour moi, l'efficacité se chronomètre. Si une fonction de style C est 4 fois plus rapide que l'algorithme générique équivalent, bien je garde mon algorithme en C, c'est tout.
-- Richard
Richard Delorme <abulmo@nospam.fr> writes:
|
| > 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.
Je n'ai pas toujours compris où tu veux en venir. J'ai l'impression que tu
te contentes de subsituer une valeur à un paramètre générique, et hop,
c'est bon, c'est optimisé pour cette valeur. Il faut aussi réécrire des
routines pour ces cas particuliers il me semble.
La même chose vaut pour les structures de données.
Je ne vois rien de bien précis sur l'efficacité. Pour moi, l'efficacité se
chronomètre. Si une fonction de style C est 4 fois plus rapide que
l'algorithme générique équivalent, bien je garde mon algorithme en C, c'est
tout.
| | > 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.
Je n'ai pas toujours compris où tu veux en venir. J'ai l'impression que tu te contentes de subsituer une valeur à un paramètre générique, et hop, c'est bon, c'est optimisé pour cette valeur. Il faut aussi réécrire des routines pour ces cas particuliers il me semble.
La même chose vaut pour les structures de données.
Je ne vois rien de bien précis sur l'efficacité. Pour moi, l'efficacité se chronomètre. Si une fonction de style C est 4 fois plus rapide que l'algorithme générique équivalent, bien je garde mon algorithme en C, c'est tout.
-- Richard
Gabriel Dos Reis
Richard Delorme writes:
| | > 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. | > | | Je n'ai pas toujours compris où tu veux en venir. J'ai l'impression que tu | te contentes de subsituer une valeur à un paramètre générique, et hop, | c'est bon, c'est optimisé pour cette valeur. Il faut aussi réécrire des | routines pour ces cas particuliers il me semble.
Non.
Ce que je dis, c'est que si tu parles d'écrire une routine générique, c'est que tu pars d'une situation concrête (voir les articles de Stepanov donnés en référence). Ensuite tu abstraits des propriétés spécifiques données. Puis, tu écris ta routine de manière paramétrée. Une fois que tu as ta routine paramétrée, tu fais un retour arrière pour confronter la théorie à la réalité : tu substitues des valeurs idioines aux paramètres, tu obtiens ainsi une spécialisation (i.e. une instantiation). Si cette spécialisation ne donne pas au moins la même efficicaté que la situtation concrête de départ alors tu n'as pas écrit une routine générique pour les critères fixés.
Tu le veux en langage des signes ?
| > La même chose vaut pour les structures de données. | > | > http://www.stlport.org/resources/StepanovUSA.html | > http://citeseer.nj.nec.com/musser88generic.html | | Je ne vois rien de bien précis sur l'efficacité.
Les deux articles en parlent explicitement. Prend ton temps pour les lire.
-- Gaby
Richard Delorme <abulmo@nospam.fr> writes:
|
| > Richard Delorme <abulmo@nospam.fr> writes:
| >
| > |
| > | > 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.
| >
|
| Je n'ai pas toujours compris où tu veux en venir. J'ai l'impression que tu
| te contentes de subsituer une valeur à un paramètre générique, et hop,
| c'est bon, c'est optimisé pour cette valeur. Il faut aussi réécrire des
| routines pour ces cas particuliers il me semble.
Non.
Ce que je dis, c'est que si tu parles d'écrire une routine générique,
c'est que tu pars d'une situation concrête (voir les articles de
Stepanov donnés en référence). Ensuite tu abstraits des propriétés
spécifiques données. Puis, tu écris ta routine de manière
paramétrée. Une fois que tu as ta routine paramétrée, tu fais un
retour arrière pour confronter la théorie à la réalité : tu substitues
des valeurs idioines aux paramètres, tu obtiens ainsi une
spécialisation (i.e. une instantiation). Si cette spécialisation ne
donne pas au moins la même efficicaté que la situtation concrête de
départ alors tu n'as pas écrit une routine générique pour les critères
fixés.
Tu le veux en langage des signes ?
| > La même chose vaut pour les structures de données.
| >
| > http://www.stlport.org/resources/StepanovUSA.html
| > http://citeseer.nj.nec.com/musser88generic.html
|
| Je ne vois rien de bien précis sur l'efficacité.
Les deux articles en parlent explicitement. Prend ton temps pour les lire.
| | > 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. | > | | Je n'ai pas toujours compris où tu veux en venir. J'ai l'impression que tu | te contentes de subsituer une valeur à un paramètre générique, et hop, | c'est bon, c'est optimisé pour cette valeur. Il faut aussi réécrire des | routines pour ces cas particuliers il me semble.
Non.
Ce que je dis, c'est que si tu parles d'écrire une routine générique, c'est que tu pars d'une situation concrête (voir les articles de Stepanov donnés en référence). Ensuite tu abstraits des propriétés spécifiques données. Puis, tu écris ta routine de manière paramétrée. Une fois que tu as ta routine paramétrée, tu fais un retour arrière pour confronter la théorie à la réalité : tu substitues des valeurs idioines aux paramètres, tu obtiens ainsi une spécialisation (i.e. une instantiation). Si cette spécialisation ne donne pas au moins la même efficicaté que la situtation concrête de départ alors tu n'as pas écrit une routine générique pour les critères fixés.
Tu le veux en langage des signes ?
| > La même chose vaut pour les structures de données. | > | > http://www.stlport.org/resources/StepanovUSA.html | > http://citeseer.nj.nec.com/musser88generic.html | | Je ne vois rien de bien précis sur l'efficacité.
Les deux articles en parlent explicitement. Prend ton temps pour les lire.
-- Gaby
Gabriel Dos Reis
Richard Delorme writes:
| | > Richard Delorme 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 : | | Pourtant, j'ai donné quelques exemples, qu'est-ce qui ne va pas avec eux ?
Moi aussi j'ai donné un exemple. Qu'est-ce qui ne va pas avec ?
-- Gaby
Richard Delorme <abulmo@nospam.fr> writes:
|
| > 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 :
|
| Pourtant, j'ai donné quelques exemples, qu'est-ce qui ne va pas avec eux ?
Moi aussi j'ai donné un exemple. Qu'est-ce qui ne va pas avec ?
| | > Richard Delorme 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 : | | Pourtant, j'ai donné quelques exemples, qu'est-ce qui ne va pas avec eux ?
Moi aussi j'ai donné un exemple. Qu'est-ce qui ne va pas avec ?
-- Gaby
Laurent Deniau
Gabriel Dos Reis wrote:
Marc Boyer writes:
| Richard Delorme wrote: | >> On Tue, 07 Oct 2003 01:02:23 +0200, Richard Delorme | >> wrote: | >> Encore faut-il qu'il y ait un impact. | > | > Oui. Ça arrive. Par exemple : | > | > string prenom = "Richard"; | > string nom = "Delorme"; | > string nom_complet = prenom + ' ' + nom; | > | > est plus lent que d'écrire : | > | > string nom_complet = prenom; | > nom_complet += ' '; | > nom_complet += nom;
Chez moi
u += v; u += w;
est plus lent que
u = u + v + w;
lorsque u, v, et w sont des valarray. Et pourtant ...
C'est un peu capilotracte... C'est parce que la STL a un probleme de conception due a son anciennete par rapport aux techniques misent en oeuvre dans valarray.
a+, ld.
-- [ Laurent Deniau -- Scientific Computing & Data Analysis ] [ CERN -- European Center for Nuclear Research ] [ - http://cern.ch/Laurent.Deniau ] [ -- One becomes old when dreams become regrets -- ]
Gabriel Dos Reis wrote:
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr> writes:
| 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.
| >
| > Oui. Ça arrive. Par exemple :
| >
| > string prenom = "Richard";
| > string nom = "Delorme";
| > string nom_complet = prenom + ' ' + nom;
| >
| > est plus lent que d'écrire :
| >
| > string nom_complet = prenom;
| > nom_complet += ' ';
| > nom_complet += nom;
Chez moi
u += v;
u += w;
est plus lent que
u = u + v + w;
lorsque u, v, et w sont des valarray. Et pourtant ...
C'est un peu capilotracte... C'est parce que la STL a un probleme de conception
due a son anciennete par rapport aux techniques misent en oeuvre dans valarray.
a+, ld.
--
[ Laurent Deniau -- Scientific Computing & Data Analysis ]
[ CERN -- European Center for Nuclear Research ]
[ Laurent.Deniau@cern.ch - http://cern.ch/Laurent.Deniau ]
[ -- One becomes old when dreams become regrets -- ]
| Richard Delorme wrote: | >> On Tue, 07 Oct 2003 01:02:23 +0200, Richard Delorme | >> wrote: | >> Encore faut-il qu'il y ait un impact. | > | > Oui. Ça arrive. Par exemple : | > | > string prenom = "Richard"; | > string nom = "Delorme"; | > string nom_complet = prenom + ' ' + nom; | > | > est plus lent que d'écrire : | > | > string nom_complet = prenom; | > nom_complet += ' '; | > nom_complet += nom;
Chez moi
u += v; u += w;
est plus lent que
u = u + v + w;
lorsque u, v, et w sont des valarray. Et pourtant ...
C'est un peu capilotracte... C'est parce que la STL a un probleme de conception due a son anciennete par rapport aux techniques misent en oeuvre dans valarray.
a+, ld.
-- [ Laurent Deniau -- Scientific Computing & Data Analysis ] [ CERN -- European Center for Nuclear Research ] [ - http://cern.ch/Laurent.Deniau ] [ -- One becomes old when dreams become regrets -- ]
Eye
Ce que je dis, c'est que si tu parles d'écrire une routine générique, c'est que tu pars d'une situation concrête (voir les articles de Stepanov donnés en référence). Ensuite tu abstraits des propriétés spécifiques données. Puis, tu écris ta routine de manière paramétrée. Une fois que tu as ta routine paramétrée, tu fais un retour arrière pour confronter la théorie à la réalité : tu substitues des valeurs idioines aux paramètres, tu obtiens ainsi une spécialisation (i.e. une instantiation). Si cette spécialisation ne donne pas au moins la même efficicaté que la situtation concrête de départ alors tu n'as pas écrit une routine générique pour les critères fixés.
Je suis d'accord avec ta vision des choses, mais du coup il me semble que l'ecriture d'une routine generique pour des criteres fixees n'est pas forcement realisable.
Eye
Ce que je dis, c'est que si tu parles d'écrire une routine générique,
c'est que tu pars d'une situation concrête (voir les articles de
Stepanov donnés en référence). Ensuite tu abstraits des propriétés
spécifiques données. Puis, tu écris ta routine de manière
paramétrée. Une fois que tu as ta routine paramétrée, tu fais un
retour arrière pour confronter la théorie à la réalité : tu substitues
des valeurs idioines aux paramètres, tu obtiens ainsi une
spécialisation (i.e. une instantiation). Si cette spécialisation ne
donne pas au moins la même efficicaté que la situtation concrête de
départ alors tu n'as pas écrit une routine générique pour les critères
fixés.
Je suis d'accord avec ta vision des choses, mais du coup il me semble que
l'ecriture d'une routine generique pour des criteres fixees n'est pas
forcement realisable.
Ce que je dis, c'est que si tu parles d'écrire une routine générique, c'est que tu pars d'une situation concrête (voir les articles de Stepanov donnés en référence). Ensuite tu abstraits des propriétés spécifiques données. Puis, tu écris ta routine de manière paramétrée. Une fois que tu as ta routine paramétrée, tu fais un retour arrière pour confronter la théorie à la réalité : tu substitues des valeurs idioines aux paramètres, tu obtiens ainsi une spécialisation (i.e. une instantiation). Si cette spécialisation ne donne pas au moins la même efficicaté que la situtation concrête de départ alors tu n'as pas écrit une routine générique pour les critères fixés.
Je suis d'accord avec ta vision des choses, mais du coup il me semble que l'ecriture d'une routine generique pour des criteres fixees n'est pas forcement realisable.
