Lorsque je crée une fonction qui prend un entier en paramètre je fais quelque chose du genre:
int Double( int x)
{
return 2*x;
}
Je me demande s'il il n'est pas plus sage de faire
int Double( const int x)
{
return 2*x;
}
dans la mesure ou je n'ai pas l'intention de modifier x dans le corps.
Cela permettrait d'eviter certaines erreurs (comme affecter x par erreur), par exemple :
int Rapport(const int a,const int b)
{
bool bDivisionParZero = ( b = 0);
if (bDivisionParZero )
{
//exception
}
else
{
return a / b;
}
}
Si b est declare const ce code ne compile pas.
ou alors
int rapport(const int nombreElements,Truc * Tableau)
{
for (;nombreElements >0; nombreElements--)
{
...
}
//renvoyer le nombre d'elements traites
return nombreElements;
}
Que les développeur C++ sont plus habitués à penser sémantique avant de penser optimisation ?
<troll> Que quand on appelle pleins de constructeurs inutiles partout, on est plus à une instruction en trop ? </troll>
Qu'un compilo C++ a déja tellement d'optimisation intelligente à faire qu'on peut s'attendre à ce qu'il sache faire une aussi simple ?
Ou plus prêt de mon point de vue d'enseignant, qu'un débutant ayant suivit un cours de C++ peut ne pas avoir vu << comme opérateur de décalage binaire, et que c'est peut-être plus rare pour du C.
Marc Boyer -- Si tu peux supporter d'entendre tes paroles Travesties par des gueux pour exiter des sots IF -- Rudyard Kipling (Trad. Paul Éluard)
Le 06-03-2006, Gabriel Dos Reis <gdr@integrable-solutions.net> a écrit :
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> writes:
Que les développeur C++ sont plus habitués à penser
sémantique avant de penser optimisation ?
<troll>
Que quand on appelle pleins de constructeurs inutiles
partout, on est plus à une instruction en trop ?
</troll>
Qu'un compilo C++ a déja tellement d'optimisation
intelligente à faire qu'on peut s'attendre à ce qu'il
sache faire une aussi simple ?
Ou plus prêt de mon point de vue d'enseignant, qu'un
débutant ayant suivit un cours de C++ peut ne pas avoir
vu << comme opérateur de décalage binaire, et que c'est
peut-être plus rare pour du C.
Marc Boyer
--
Si tu peux supporter d'entendre tes paroles
Travesties par des gueux pour exiter des sots
IF -- Rudyard Kipling (Trad. Paul Éluard)
Que les développeur C++ sont plus habitués à penser sémantique avant de penser optimisation ?
<troll> Que quand on appelle pleins de constructeurs inutiles partout, on est plus à une instruction en trop ? </troll>
Qu'un compilo C++ a déja tellement d'optimisation intelligente à faire qu'on peut s'attendre à ce qu'il sache faire une aussi simple ?
Ou plus prêt de mon point de vue d'enseignant, qu'un débutant ayant suivit un cours de C++ peut ne pas avoir vu << comme opérateur de décalage binaire, et que c'est peut-être plus rare pour du C.
Marc Boyer -- Si tu peux supporter d'entendre tes paroles Travesties par des gueux pour exiter des sots IF -- Rudyard Kipling (Trad. Paul Éluard)
Fabien LE LEZ
On 06 Mar 2006 15:43:15 +0100, Gabriel Dos Reis :
| > ce bavardage (ou avis très personnel) m'amuse un peu, si un codeur C ne | > sait pas lire "x << n" je lui conseillerais humblement de commencer à | > s'initier au langage qu'il pense utiliser ou de passer à autre chose. | | Et s'il faisait du C++ justement ?
Cela change-t-il quelque chose ?
Je pense que oui.
Il me semble qu'en C on a plus le réflexe "assembleur" : bidouillage de bits et compagnie. Je ne dis pas que c'est une bonne idée, mais un programmeur C a sans doute déjà vu ça.
En C++, la situation est différente : d'une part, en voyant un "<<", on pense immédiatement aux iostream ; d'autre part, il me semble qu'en C++ on a un réflexe "généricité" : si je dois multiplier x par 2, j'écris x*2 sans me préoccuper de savoir de quel type est x (D'ailleurs, je ne le sais pas forcément) ; c'est au compilateur de savoir quelle surcharge de operator* utiliser. Du coup, on rencontre moins souvent ce genre d'"optimisation sauvage".
On 06 Mar 2006 15:43:15 +0100, Gabriel Dos Reis :
| > ce bavardage (ou avis très personnel) m'amuse un peu, si un codeur C ne
| > sait pas lire "x << n" je lui conseillerais humblement de commencer à
| > s'initier au langage qu'il pense utiliser ou de passer à autre chose.
|
| Et s'il faisait du C++ justement ?
Cela change-t-il quelque chose ?
Je pense que oui.
Il me semble qu'en C on a plus le réflexe "assembleur" : bidouillage
de bits et compagnie. Je ne dis pas que c'est une bonne idée, mais un
programmeur C a sans doute déjà vu ça.
En C++, la situation est différente : d'une part, en voyant un "<<",
on pense immédiatement aux iostream ; d'autre part, il me semble qu'en
C++ on a un réflexe "généricité" : si je dois multiplier x par 2,
j'écris x*2 sans me préoccuper de savoir de quel type est x
(D'ailleurs, je ne le sais pas forcément) ; c'est au compilateur de
savoir quelle surcharge de operator* utiliser. Du coup, on rencontre
moins souvent ce genre d'"optimisation sauvage".
| > ce bavardage (ou avis très personnel) m'amuse un peu, si un codeur C ne | > sait pas lire "x << n" je lui conseillerais humblement de commencer à | > s'initier au langage qu'il pense utiliser ou de passer à autre chose. | | Et s'il faisait du C++ justement ?
Cela change-t-il quelque chose ?
Je pense que oui.
Il me semble qu'en C on a plus le réflexe "assembleur" : bidouillage de bits et compagnie. Je ne dis pas que c'est une bonne idée, mais un programmeur C a sans doute déjà vu ça.
En C++, la situation est différente : d'une part, en voyant un "<<", on pense immédiatement aux iostream ; d'autre part, il me semble qu'en C++ on a un réflexe "généricité" : si je dois multiplier x par 2, j'écris x*2 sans me préoccuper de savoir de quel type est x (D'ailleurs, je ne le sais pas forcément) ; c'est au compilateur de savoir quelle surcharge de operator* utiliser. Du coup, on rencontre moins souvent ce genre d'"optimisation sauvage".
Gabriel Dos Reis
Fabien LE LEZ writes:
| On 06 Mar 2006 15:43:15 +0100, Gabriel Dos Reis : | | >| > ce bavardage (ou avis très personnel) m'amuse un peu, si un codeur C ne | >| > sait pas lire "x << n" je lui conseillerais humblement de commencer à | >| > s'initier au langage qu'il pense utiliser ou de passer à autre chose. | >| | >| Et s'il faisait du C++ justement ? | > | >Cela change-t-il quelque chose ? | | Je pense que oui. | | Il me semble qu'en C on a plus le réflexe "assembleur" : bidouillage | de bits et compagnie. Je ne dis pas que c'est une bonne idée, mais un | programmeur C a sans doute déjà vu ça.
Mon analyse est que ce reflexe se retrouve bien des deux côtés avec une acuité encore plus forte en C++ -- où il est souvent question de « performance » maximum au détriment de la justesse et de la robustesse.
| En C++, la situation est différente : d'une part, en voyant un "<<", | on pense immédiatement aux iostream ;
pas moi ; et les programmeurs C++ que je connais (et que respecte progeondément) lisent « << » dans le contexte.
| d'autre part, il me semble qu'en C++ on a un réflexe "généricité" : | si je dois multiplier x par 2,
justement si on parle de genéricité, alors « << » veut dire « << » et pas multiplier par deux. « x << y » fait ce que « << » est défini de faire dans le contexte d'utilisation : si « x » est un stream alors c'est probablement une insertion, si c'est un entier c'est probablement un shift. En géneral « x << y » fait ce que « << » est défini dans le contexte de « x » et « y ». La généricité, justement d'avoir du code « symbolique », dont les interprétations dans différents contextes donnent les algorithmes initiaux et que le tout reste compréhensible dans le contexte d'utilisation.
| c'est justement | j'écris x*2 sans me préoccuper de savoir de quel type est x
si on ne doit pas se préoccuper de quel type est x et qu'on écrit « x << 2 », je ne comprends pas pourquoi tu devrais croire que c'est une multiplication par deux -- de fait tu as dejà fait une hypothèse sur le type de « x ».
Je présume que ce que je veux dire, c'est que tout est question de contexte. Dans les tous les cas, je ne souscris pas au fanatisme que certains passeraient sous le vocable « professionnalisme. » (Selon le lemme de McCain il paraît que ce qui en parle le plus en font le moins).
-- Gaby
Fabien LE LEZ <gramster@gramster.com> writes:
| On 06 Mar 2006 15:43:15 +0100, Gabriel Dos Reis :
|
| >| > ce bavardage (ou avis très personnel) m'amuse un peu, si un codeur C ne
| >| > sait pas lire "x << n" je lui conseillerais humblement de commencer à
| >| > s'initier au langage qu'il pense utiliser ou de passer à autre chose.
| >|
| >| Et s'il faisait du C++ justement ?
| >
| >Cela change-t-il quelque chose ?
|
| Je pense que oui.
|
| Il me semble qu'en C on a plus le réflexe "assembleur" : bidouillage
| de bits et compagnie. Je ne dis pas que c'est une bonne idée, mais un
| programmeur C a sans doute déjà vu ça.
Mon analyse est que ce reflexe se retrouve bien des deux côtés avec
une acuité encore plus forte en C++ -- où il est souvent question de
« performance » maximum au détriment de la justesse et de la
robustesse.
| En C++, la situation est différente : d'une part, en voyant un "<<",
| on pense immédiatement aux iostream ;
pas moi ; et les programmeurs C++ que je connais (et que respecte
progeondément) lisent « << » dans le contexte.
| d'autre part, il me semble qu'en C++ on a un réflexe "généricité" :
| si je dois multiplier x par 2,
justement si on parle de genéricité, alors « << » veut dire « << » et
pas multiplier par deux. « x << y » fait ce que « << » est défini de
faire dans le contexte d'utilisation : si « x » est un stream alors
c'est probablement une insertion, si c'est un entier c'est
probablement un shift. En géneral « x << y » fait ce que « << » est
défini dans le contexte de « x » et « y ». La généricité, justement
d'avoir du code « symbolique », dont les interprétations dans
différents contextes donnent les algorithmes initiaux et que le tout
reste compréhensible dans le contexte d'utilisation.
| c'est justement
| j'écris x*2 sans me préoccuper de savoir de quel type est x
si on ne doit pas se préoccuper de quel type est x et qu'on écrit
« x << 2 », je ne comprends pas pourquoi tu devrais croire que c'est
une multiplication par deux -- de fait tu as dejà fait une hypothèse
sur le type de « x ».
Je présume que ce que je veux dire, c'est que tout est question de
contexte. Dans les tous les cas, je ne souscris pas au fanatisme
que certains passeraient sous le vocable « professionnalisme. »
(Selon le lemme de McCain il paraît que ce qui en parle le plus en font
le moins).
| On 06 Mar 2006 15:43:15 +0100, Gabriel Dos Reis : | | >| > ce bavardage (ou avis très personnel) m'amuse un peu, si un codeur C ne | >| > sait pas lire "x << n" je lui conseillerais humblement de commencer à | >| > s'initier au langage qu'il pense utiliser ou de passer à autre chose. | >| | >| Et s'il faisait du C++ justement ? | > | >Cela change-t-il quelque chose ? | | Je pense que oui. | | Il me semble qu'en C on a plus le réflexe "assembleur" : bidouillage | de bits et compagnie. Je ne dis pas que c'est une bonne idée, mais un | programmeur C a sans doute déjà vu ça.
Mon analyse est que ce reflexe se retrouve bien des deux côtés avec une acuité encore plus forte en C++ -- où il est souvent question de « performance » maximum au détriment de la justesse et de la robustesse.
| En C++, la situation est différente : d'une part, en voyant un "<<", | on pense immédiatement aux iostream ;
pas moi ; et les programmeurs C++ que je connais (et que respecte progeondément) lisent « << » dans le contexte.
| d'autre part, il me semble qu'en C++ on a un réflexe "généricité" : | si je dois multiplier x par 2,
justement si on parle de genéricité, alors « << » veut dire « << » et pas multiplier par deux. « x << y » fait ce que « << » est défini de faire dans le contexte d'utilisation : si « x » est un stream alors c'est probablement une insertion, si c'est un entier c'est probablement un shift. En géneral « x << y » fait ce que « << » est défini dans le contexte de « x » et « y ». La généricité, justement d'avoir du code « symbolique », dont les interprétations dans différents contextes donnent les algorithmes initiaux et que le tout reste compréhensible dans le contexte d'utilisation.
| c'est justement | j'écris x*2 sans me préoccuper de savoir de quel type est x
si on ne doit pas se préoccuper de quel type est x et qu'on écrit « x << 2 », je ne comprends pas pourquoi tu devrais croire que c'est une multiplication par deux -- de fait tu as dejà fait une hypothèse sur le type de « x ».
Je présume que ce que je veux dire, c'est que tout est question de contexte. Dans les tous les cas, je ne souscris pas au fanatisme que certains passeraient sous le vocable « professionnalisme. » (Selon le lemme de McCain il paraît que ce qui en parle le plus en font le moins).
| <troll> | Que quand on appelle pleins de constructeurs inutiles | partout, on est plus à une instruction en trop ? | </troll> | | Qu'un compilo C++ a déja tellement d'optimisation | intelligente à faire qu'on peut s'attendre à ce qu'il | sache faire une aussi simple ?
La dernière fois que j'ai vérifié sur les compilateurs auxquels j'ai accès, la notion de « simple » selon l'écrivain du compilateur diffère de celui du programmeur. Alors les théoriciens nous disent qui peut le plus peut le moins. Et si on n'est pas d'accord c'est qu'on n'est pas professionenel. Soit.
| Ou plus prêt de mon point de vue d'enseignant, qu'un | débutant ayant suivit un cours de C++ peut ne pas avoir | vu << comme opérateur de décalage binaire, et que c'est | peut-être plus rare pour du C.
Definis « débutant. »
Très certainement, nous attendons de l'étudiant « electrical engineer » ou « computer engineer » qui prend le cours de C++ 101 de savoir ce qu'est le décalage binaire et comment cela s'écrit en C++.
-- Gaby
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> writes:
| <troll>
| Que quand on appelle pleins de constructeurs inutiles
| partout, on est plus à une instruction en trop ?
| </troll>
|
| Qu'un compilo C++ a déja tellement d'optimisation
| intelligente à faire qu'on peut s'attendre à ce qu'il
| sache faire une aussi simple ?
La dernière fois que j'ai vérifié sur les compilateurs auxquels j'ai
accès, la notion de « simple » selon l'écrivain du compilateur diffère
de celui du programmeur. Alors les théoriciens nous disent qui peut le
plus peut le moins. Et si on n'est pas d'accord c'est qu'on n'est pas
professionenel. Soit.
| Ou plus prêt de mon point de vue d'enseignant, qu'un
| débutant ayant suivit un cours de C++ peut ne pas avoir
| vu << comme opérateur de décalage binaire, et que c'est
| peut-être plus rare pour du C.
Definis « débutant. »
Très certainement, nous attendons de l'étudiant « electrical engineer » ou
« computer engineer » qui prend le cours de C++ 101 de savoir ce
qu'est le décalage binaire et comment cela s'écrit en C++.
| <troll> | Que quand on appelle pleins de constructeurs inutiles | partout, on est plus à une instruction en trop ? | </troll> | | Qu'un compilo C++ a déja tellement d'optimisation | intelligente à faire qu'on peut s'attendre à ce qu'il | sache faire une aussi simple ?
La dernière fois que j'ai vérifié sur les compilateurs auxquels j'ai accès, la notion de « simple » selon l'écrivain du compilateur diffère de celui du programmeur. Alors les théoriciens nous disent qui peut le plus peut le moins. Et si on n'est pas d'accord c'est qu'on n'est pas professionenel. Soit.
| Ou plus prêt de mon point de vue d'enseignant, qu'un | débutant ayant suivit un cours de C++ peut ne pas avoir | vu << comme opérateur de décalage binaire, et que c'est | peut-être plus rare pour du C.
Definis « débutant. »
Très certainement, nous attendons de l'étudiant « electrical engineer » ou « computer engineer » qui prend le cours de C++ 101 de savoir ce qu'est le décalage binaire et comment cela s'écrit en C++.
| Qu'un compilo C++ a déja tellement d'optimisation | intelligente à faire qu'on peut s'attendre à ce qu'il | sache faire une aussi simple ?
La dernière fois que j'ai vérifié sur les compilateurs auxquels j'ai accès, la notion de « simple » selon l'écrivain du compilateur diffère de celui du programmeur. Alors les théoriciens nous disent qui peut le plus peut le moins. Et si on n'est pas d'accord c'est qu'on n'est pas professionenel. Soit.
La différence entre la théorie et la pratique, c'est qu'en théorie, il n'y en a pas.
| Ou plus prêt de mon point de vue d'enseignant, qu'un | débutant ayant suivit un cours de C++ peut ne pas avoir | vu << comme opérateur de décalage binaire, et que c'est | peut-être plus rare pour du C.
Definis « débutant. »
Diplomé en informatique depuis moins de 3 ans ?
Très certainement, nous attendons de l'étudiant « electrical engineer » ou « computer engineer » qui prend le cours de C++ 101 de savoir ce qu'est le décalage binaire et comment cela s'écrit en C++.
C'est vrai ? Et dire que mes étudiants me trouvent exigeants...
Qu'un informaticien sache ce qu'est un décalage, c'est une exigence que je partage. Qu'il se ne souvienne pas comment cela se note en C (ou en C++ ou en Java), je juge cela moins grave. Qu'il ne sache pas si un décalage à droite correspond à une multiplication par deux en complément à 1 ou non, ça me semble aussi acceptable.
J'ai prété mon "Accelerated C++", donc je ne peux pas dire s'il le présente. Un grep sur les sources semble montrer qu'il n'utilise "<<" que pour des E/S ostream.
Marc Boyer -- Si tu peux supporter d'entendre tes paroles Travesties par des gueux pour exiter des sots IF -- Rudyard Kipling (Trad. Paul Éluard)
Le 06-03-2006, Gabriel Dos Reis <gdr@integrable-solutions.net> a écrit :
| Qu'un compilo C++ a déja tellement d'optimisation
| intelligente à faire qu'on peut s'attendre à ce qu'il
| sache faire une aussi simple ?
La dernière fois que j'ai vérifié sur les compilateurs auxquels j'ai
accès, la notion de « simple » selon l'écrivain du compilateur diffère
de celui du programmeur. Alors les théoriciens nous disent qui peut le
plus peut le moins. Et si on n'est pas d'accord c'est qu'on n'est pas
professionenel. Soit.
La différence entre la théorie et la pratique, c'est qu'en
théorie, il n'y en a pas.
| Ou plus prêt de mon point de vue d'enseignant, qu'un
| débutant ayant suivit un cours de C++ peut ne pas avoir
| vu << comme opérateur de décalage binaire, et que c'est
| peut-être plus rare pour du C.
Definis « débutant. »
Diplomé en informatique depuis moins de 3 ans ?
Très certainement, nous attendons de l'étudiant « electrical engineer » ou
« computer engineer » qui prend le cours de C++ 101 de savoir ce
qu'est le décalage binaire et comment cela s'écrit en C++.
C'est vrai ?
Et dire que mes étudiants me trouvent exigeants...
Qu'un informaticien sache ce qu'est un décalage, c'est une
exigence que je partage.
Qu'il se ne souvienne pas comment cela se note en C (ou en C++ ou
en Java), je juge cela moins grave.
Qu'il ne sache pas si un décalage à droite correspond à une
multiplication par deux en complément à 1 ou non, ça me
semble aussi acceptable.
J'ai prété mon "Accelerated C++", donc je ne peux pas
dire s'il le présente. Un grep sur les sources semble montrer
qu'il n'utilise "<<" que pour des E/S ostream.
Marc Boyer
--
Si tu peux supporter d'entendre tes paroles
Travesties par des gueux pour exiter des sots
IF -- Rudyard Kipling (Trad. Paul Éluard)
| Qu'un compilo C++ a déja tellement d'optimisation | intelligente à faire qu'on peut s'attendre à ce qu'il | sache faire une aussi simple ?
La dernière fois que j'ai vérifié sur les compilateurs auxquels j'ai accès, la notion de « simple » selon l'écrivain du compilateur diffère de celui du programmeur. Alors les théoriciens nous disent qui peut le plus peut le moins. Et si on n'est pas d'accord c'est qu'on n'est pas professionenel. Soit.
La différence entre la théorie et la pratique, c'est qu'en théorie, il n'y en a pas.
| Ou plus prêt de mon point de vue d'enseignant, qu'un | débutant ayant suivit un cours de C++ peut ne pas avoir | vu << comme opérateur de décalage binaire, et que c'est | peut-être plus rare pour du C.
Definis « débutant. »
Diplomé en informatique depuis moins de 3 ans ?
Très certainement, nous attendons de l'étudiant « electrical engineer » ou « computer engineer » qui prend le cours de C++ 101 de savoir ce qu'est le décalage binaire et comment cela s'écrit en C++.
C'est vrai ? Et dire que mes étudiants me trouvent exigeants...
Qu'un informaticien sache ce qu'est un décalage, c'est une exigence que je partage. Qu'il se ne souvienne pas comment cela se note en C (ou en C++ ou en Java), je juge cela moins grave. Qu'il ne sache pas si un décalage à droite correspond à une multiplication par deux en complément à 1 ou non, ça me semble aussi acceptable.
J'ai prété mon "Accelerated C++", donc je ne peux pas dire s'il le présente. Un grep sur les sources semble montrer qu'il n'utilise "<<" que pour des E/S ostream.
Marc Boyer -- Si tu peux supporter d'entendre tes paroles Travesties par des gueux pour exiter des sots IF -- Rudyard Kipling (Trad. Paul Éluard)
Fabien LE LEZ
On 06 Mar 2006 16:31:53 +0100, Gabriel Dos Reis :
si on ne doit pas se préoccuper de quel type est x et qu'on écrit « x << 2 »,
J'imagine que tu voulais écrire "x*2" ici ?
je ne comprends pas pourquoi tu devrais croire que c'est une multiplication par deux -- de fait tu as dejà fait une hypothèse sur le type de « x ».
Mon hypothèse de travail est qu'il n'y a pas d'abus de surcharge, et qu'un operator* (à deux arguments) signifie bien quelque chose qui ressemble fort à une multiplication.
Je présume que ce que je veux dire, c'est que tout est question de contexte.
En partie seulement. Si je vois un "++", je sais qu'il s'agit soit d'une addition (type numérique), soit d'un passage à l'élément suivant (itérateur). Si "++" sert à multiplier par 3, je vais finir par le découvrir, mais ça prendra plus de temps.
En résumé, quand je cherche à comprendre ce qu'une expression signifie, je commence par la lire. Si c'est insuffisant, alors je m'intéresse au contexte.
On 06 Mar 2006 16:31:53 +0100, Gabriel Dos Reis
<gdr@integrable-solutions.net>:
si on ne doit pas se préoccuper de quel type est x et qu'on écrit
« x << 2 »,
J'imagine que tu voulais écrire "x*2" ici ?
je ne comprends pas pourquoi tu devrais croire que c'est
une multiplication par deux -- de fait tu as dejà fait une hypothèse
sur le type de « x ».
Mon hypothèse de travail est qu'il n'y a pas d'abus de surcharge, et
qu'un operator* (à deux arguments) signifie bien quelque chose qui
ressemble fort à une multiplication.
Je présume que ce que je veux dire, c'est que tout est question de
contexte.
En partie seulement. Si je vois un "++", je sais qu'il s'agit soit
d'une addition (type numérique), soit d'un passage à l'élément suivant
(itérateur). Si "++" sert à multiplier par 3, je vais finir par le
découvrir, mais ça prendra plus de temps.
En résumé, quand je cherche à comprendre ce qu'une expression
signifie, je commence par la lire. Si c'est insuffisant, alors je
m'intéresse au contexte.
si on ne doit pas se préoccuper de quel type est x et qu'on écrit « x << 2 »,
J'imagine que tu voulais écrire "x*2" ici ?
je ne comprends pas pourquoi tu devrais croire que c'est une multiplication par deux -- de fait tu as dejà fait une hypothèse sur le type de « x ».
Mon hypothèse de travail est qu'il n'y a pas d'abus de surcharge, et qu'un operator* (à deux arguments) signifie bien quelque chose qui ressemble fort à une multiplication.
Je présume que ce que je veux dire, c'est que tout est question de contexte.
En partie seulement. Si je vois un "++", je sais qu'il s'agit soit d'une addition (type numérique), soit d'un passage à l'élément suivant (itérateur). Si "++" sert à multiplier par 3, je vais finir par le découvrir, mais ça prendra plus de temps.
En résumé, quand je cherche à comprendre ce qu'une expression signifie, je commence par la lire. Si c'est insuffisant, alors je m'intéresse au contexte.
Fabien LE LEZ
On 06 Mar 2006 16:38:59 +0100, Gabriel Dos Reis :
| Que les développeur C++ sont plus habitués à penser | sémantique avant de penser optimisation ?
comme le montre la bibliothèque standard de C++ ?
La SL est à mi-chemin entre le compilateur et un programme "normal" : elle doit être optimisée pour que justement le programmeur n'ait pas à se préoccuper d'optimisation.
Par exemple, dans std::vector<>, il y a un algorithme pour calculer la taille "idéale"[*] du bloc de mémoire alloué (i.e. ce que capacity() renvoie), pour que le programmeur lambda puisse balancer des machins dedans à grands coups de push_back() sans se poser de questions.
[*] suivant certains critères -- il s'agit bien sûr d'un compromis.
On 06 Mar 2006 16:38:59 +0100, Gabriel Dos Reis
<gdr@integrable-solutions.net>:
| Que les développeur C++ sont plus habitués à penser
| sémantique avant de penser optimisation ?
comme le montre la bibliothèque standard de C++ ?
La SL est à mi-chemin entre le compilateur et un programme "normal" :
elle doit être optimisée pour que justement le programmeur n'ait pas à
se préoccuper d'optimisation.
Par exemple, dans std::vector<>, il y a un algorithme pour calculer la
taille "idéale"[*] du bloc de mémoire alloué (i.e. ce que capacity()
renvoie), pour que le programmeur lambda puisse balancer des machins
dedans à grands coups de push_back() sans se poser de questions.
[*] suivant certains critères -- il s'agit bien sûr d'un compromis.
| Que les développeur C++ sont plus habitués à penser | sémantique avant de penser optimisation ?
comme le montre la bibliothèque standard de C++ ?
La SL est à mi-chemin entre le compilateur et un programme "normal" : elle doit être optimisée pour que justement le programmeur n'ait pas à se préoccuper d'optimisation.
Par exemple, dans std::vector<>, il y a un algorithme pour calculer la taille "idéale"[*] du bloc de mémoire alloué (i.e. ce que capacity() renvoie), pour que le programmeur lambda puisse balancer des machins dedans à grands coups de push_back() sans se poser de questions.
[*] suivant certains critères -- il s'agit bien sûr d'un compromis.
Gabriel Dos Reis
Fabien LE LEZ writes:
| On 06 Mar 2006 16:38:59 +0100, Gabriel Dos Reis | : | | >| Que les développeur C++ sont plus habitués à penser | >| sémantique avant de penser optimisation ? | > | >comme le montre la bibliothèque standard de C++ ? | | La SL est à mi-chemin entre le compilateur et un programme "normal" : | elle doit être optimisée pour que justement le programmeur n'ait pas à | se préoccuper d'optimisation.
je parle de l'initerface utilisateur -- pas de son implémentation. L'optimisation a pris le dessus sur la sémantique.
| | Par exemple, dans std::vector<>,
Très bon exemple : std::vector<>::operator[].
-- Gaby
Fabien LE LEZ <gramster@gramster.com> writes:
| On 06 Mar 2006 16:38:59 +0100, Gabriel Dos Reis
| <gdr@integrable-solutions.net>:
|
| >| Que les développeur C++ sont plus habitués à penser
| >| sémantique avant de penser optimisation ?
| >
| >comme le montre la bibliothèque standard de C++ ?
|
| La SL est à mi-chemin entre le compilateur et un programme "normal" :
| elle doit être optimisée pour que justement le programmeur n'ait pas à
| se préoccuper d'optimisation.
je parle de l'initerface utilisateur -- pas de son implémentation.
L'optimisation a pris le dessus sur la sémantique.
| On 06 Mar 2006 16:38:59 +0100, Gabriel Dos Reis | : | | >| Que les développeur C++ sont plus habitués à penser | >| sémantique avant de penser optimisation ? | > | >comme le montre la bibliothèque standard de C++ ? | | La SL est à mi-chemin entre le compilateur et un programme "normal" : | elle doit être optimisée pour que justement le programmeur n'ait pas à | se préoccuper d'optimisation.
je parle de l'initerface utilisateur -- pas de son implémentation. L'optimisation a pris le dessus sur la sémantique.
| | Par exemple, dans std::vector<>,
Très bon exemple : std::vector<>::operator[].
-- Gaby
Gabriel Dos Reis
Fabien LE LEZ writes:
| On 06 Mar 2006 16:31:53 +0100, Gabriel Dos Reis | : | | >si on ne doit pas se préoccuper de quel type est x et qu'on écrit | >« x << 2 », | | J'imagine que tu voulais écrire "x*2" ici ?
Non.
| > je ne comprends pas pourquoi tu devrais croire que c'est | >une multiplication par deux -- de fait tu as dejà fait une hypothèse | >sur le type de « x ». | | Mon hypothèse de travail est qu'il n'y a pas d'abus de surcharge, et
pour moi « abus de surcharge » avant même d'avoir explorer le domaine d'utilisation et les alternatives est un non-argument : c'est du fanatisme.
| qu'un operator* (à deux arguments) signifie bien quelque chose qui | ressemble fort à une multiplication. | | >Je présume que ce que je veux dire, c'est que tout est question de | >contexte. | | En partie seulement. Si je vois un "++", je sais qu'il s'agit soit | d'une addition (type numérique), soit d'un passage à l'élément suivant | (itérateur). Si "++" sert à multiplier par 3, je vais finir par le
Si « multiplier par 3 » est *l'implémentation* de passer à l'élement suivant, alors on est bon pour la guillotine aussi ?
-- Gaby
Fabien LE LEZ <gramster@gramster.com> writes:
| On 06 Mar 2006 16:31:53 +0100, Gabriel Dos Reis
| <gdr@integrable-solutions.net>:
|
| >si on ne doit pas se préoccuper de quel type est x et qu'on écrit
| >« x << 2 »,
|
| J'imagine que tu voulais écrire "x*2" ici ?
Non.
| > je ne comprends pas pourquoi tu devrais croire que c'est
| >une multiplication par deux -- de fait tu as dejà fait une hypothèse
| >sur le type de « x ».
|
| Mon hypothèse de travail est qu'il n'y a pas d'abus de surcharge, et
pour moi « abus de surcharge » avant même d'avoir explorer le domaine
d'utilisation et les alternatives est un non-argument : c'est du
fanatisme.
| qu'un operator* (à deux arguments) signifie bien quelque chose qui
| ressemble fort à une multiplication.
|
| >Je présume que ce que je veux dire, c'est que tout est question de
| >contexte.
|
| En partie seulement. Si je vois un "++", je sais qu'il s'agit soit
| d'une addition (type numérique), soit d'un passage à l'élément suivant
| (itérateur). Si "++" sert à multiplier par 3, je vais finir par le
Si « multiplier par 3 » est *l'implémentation* de passer à l'élement
suivant, alors on est bon pour la guillotine aussi ?
| On 06 Mar 2006 16:31:53 +0100, Gabriel Dos Reis | : | | >si on ne doit pas se préoccuper de quel type est x et qu'on écrit | >« x << 2 », | | J'imagine que tu voulais écrire "x*2" ici ?
Non.
| > je ne comprends pas pourquoi tu devrais croire que c'est | >une multiplication par deux -- de fait tu as dejà fait une hypothèse | >sur le type de « x ». | | Mon hypothèse de travail est qu'il n'y a pas d'abus de surcharge, et
pour moi « abus de surcharge » avant même d'avoir explorer le domaine d'utilisation et les alternatives est un non-argument : c'est du fanatisme.
| qu'un operator* (à deux arguments) signifie bien quelque chose qui | ressemble fort à une multiplication. | | >Je présume que ce que je veux dire, c'est que tout est question de | >contexte. | | En partie seulement. Si je vois un "++", je sais qu'il s'agit soit | d'une addition (type numérique), soit d'un passage à l'élément suivant | (itérateur). Si "++" sert à multiplier par 3, je vais finir par le
Si « multiplier par 3 » est *l'implémentation* de passer à l'élement suivant, alors on est bon pour la guillotine aussi ?