OVH Cloud OVH Cloud

parametres simples en const ?

70 réponses
Avatar
JBB
Bonjour

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;
}

Est ce une pratique courrante?

10 réponses

3 4 5 6 7
Avatar
Gabriel Dos Reis
Marc Boyer writes:

| Le 04-03-2006, Sylvain a écrit :
| > Alexandre wrote on 04/03/2006 16:52:
| > acte 2: "x << 1" serait /moins lisible/ que "2 * x"
| >
| > 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 ?

-- Gaby
Avatar
Marc Boyer
Le 06-03-2006, Gabriel Dos Reis a écrit :
Marc Boyer writes:

| Le 04-03-2006, Sylvain a écrit :
| > Alexandre wrote on 04/03/2006 16:52:
| > acte 2: "x << 1" serait /moins lisible/ que "2 * x"
| >
| > 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 ?


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)

Avatar
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".

Avatar
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
Avatar
Gabriel Dos Reis
Marc Boyer writes:

| Le 06-03-2006, Gabriel Dos Reis a écrit :
| > Marc Boyer writes:
| >
| >| Le 04-03-2006, Sylvain a écrit :
| >| > Alexandre wrote on 04/03/2006 16:52:
| >| > acte 2: "x << 1" serait /moins lisible/ que "2 * x"
| >| >
| >| > 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 ?
|
| 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++ ?

| <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
Avatar
Marc Boyer
Le 06-03-2006, Gabriel Dos Reis a écrit :
Marc Boyer writes:
| Le 06-03-2006, Gabriel Dos Reis a écrit :
| > Marc Boyer writes:
| >| Le 04-03-2006, Sylvain a écrit :
| >| > Alexandre wrote on 04/03/2006 16:52:
| >| > acte 2: "x << 1" serait /moins lisible/ que "2 * x"
| >| >
| >| > 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 ?
|
| 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++ ?


Aucune idée.

| 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)

Avatar
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.

Avatar
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.

Avatar
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
Avatar
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
3 4 5 6 7