Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Développement Développement Langage C++ parametres simples en const ?

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?
Signaler un problème avec ce contenu

10 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
3 4 5 6 7
Avatar
Gabriel Dos Reis
Marc Boyer writes:

[...]

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

et quand ils sont en première année de fac (« freshmen »), il sont
pré^4 débutants ?

L'étudiant « electrical engineer » (et non « computer scientist ») qui
est nouveau C++ juste pour pouvoir écrire des drivers pour sa machine
et périphérique est n'est pas un débutant mais un « alien » ?

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

Oui.

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

le problème ici est qu'en France on a tendance à mettre un peu de tout
sous le vocable « informaticien », du mec qui pose les cables réseau
au mec qui fait de l'algèbre stellaire avec zéro expérience avec les
ordinateurs. De ce que je peux voir ici, les « electrical engineer »
sont probablement plus expérimentés en programmation que les «
computer scientists ». En fait, lorsque j'étais en France c'est aussi
vrai ; peut-être que c'est un phénomène général, j'en sais rien.

| Qu'il se ne souvienne pas comment cela se note en C (ou en C++ ou
| en Java), je juge cela moins grave.

De fait, ils n'ont plus de cours en C -- ils commencent direct avec le
C++.

Ceux qui utilisent sérieusement C++ dans les systèmes embarqués
(voir la page de BS pour plus d'info) et que j'ai rencontrés sont
contents de ne pas voir de « trous » laissés par C++ : ces gens là sont
en contact direct avec le hardware si je puis dire.

L'idée que le shift ne se verrait qu'en C -- soit disant que c'est le
truc de bas niveau -- me semble de la pure hérésie et en
contradiction avec l'un des critères de conceptions de C++ : ne
laisser partiquement aucune place entre le hardware et le programme
lorsque nécessaire (la seulee place, si est elle nécessaire d'être
occupée, est laissée à l'assembleur. Et tu remarqueras que le C++,
contrairement au C, a spécifiquement introduit un mot clé -- « asm »).

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

Oui, mais de là à en tirer une théroème universel et moraliser les
gens avec ça, il y a un pas que je me garderai de franchir. Il me
semble que le contexte est important.

-- Gaby
Avatar
Marc Boyer
Le 06-03-2006, Gabriel Dos Reis a écrit :
Marc Boyer writes:
| > Definis « débutant. »
|
| Diplomé en informatique depuis moins de 3 ans ?

et quand ils sont en première année de fac (« freshmen »), il sont
pré^4 débutants ?


A moins que débutant soit un opérateur idempotent.

L'étudiant « electrical engineer » (et non « computer scientist ») qui
est nouveau C++ juste pour pouvoir écrire des drivers pour sa machine
et périphérique est n'est pas un débutant mais un « alien » ?


Il est débutant en C++ et très fort dans d'autres domaines.

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

le problème ici est qu'en France on a tendance à mettre un peu de tout
sous le vocable « informaticien »,


Tout à fait.
Sans compter que les SSII embauchent des gends avec un DEA de
biologie ;-)

De ce que je peux voir ici, les « electrical engineer »
sont probablement plus expérimentés en programmation que les «
computer scientists ». En fait, lorsque j'étais en France c'est aussi
vrai ; peut-être que c'est un phénomène général, j'en sais rien.


Mon expérience locale ne corrobore pas ce point,
mais je suis peut-être sur une singularité.

Ceux qui utilisent sérieusement C++ dans les systèmes embarqués
(voir la page de BS pour plus d'info) et que j'ai rencontrés sont
contents de ne pas voir de « trous » laissés par C++ : ces gens là sont
en contact direct avec le hardware si je puis dire.


Que C++ offre un opérateur de décalage binaire me semble en
effet indispensable.

L'idée que le shift ne se verrait qu'en C -- soit disant que c'est le
truc de bas niveau -- me semble de la pure hérésie et en
contradiction avec l'un des critères de conceptions de C++ : ne
laisser partiquement aucune place entre le hardware et le programme
lorsque nécessaire (la seulee place, si est elle nécessaire d'être
occupée, est laissée à l'assembleur.


Nous sommes d'accord.
Je ne crois pas avoir dit le contraire d'ailleurs.

Et tu remarqueras que le C++,
contrairement au C, a spécifiquement introduit un mot clé -- « asm »).


Je ne l'avais pas noté.

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

Oui, mais de là à en tirer une théroème universel et moraliser les
gens avec ça, il y a un pas que je me garderai de franchir. Il me
semble que le contexte est important.


Nous sommes d'accord.

Je reviens quand même sur le contexte de cette discussion qui
était de la fonction int Double([const] int x); qui retourne
le double de x *devrait* se coder
return x<<1;

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
Laurent Deniau
Marc Boyer wrote:
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.


A tout prendre, je prefererais qu'il sache qu'un decalage a droite c'est
une *division* par deux sur un entier non signe et que c'est dependant
de l'implementation sur un entier signe.

a+, ld.

Avatar
Fabien LE LEZ
On 06 Mar 2006 16:31:53 +0100, Gabriel Dos Reis
:

[Je reviens sur ton message car j'avais cru, en première lecture, à
une faute de frappe.]

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


Je ne comprends pas non plus pourquoi je devrais croire qu'il s'agit
d'une multiplication par deux.

Et franchement, un "x << 2" qui veut dire "x*2", ça ressemble quand
même beaucoup à de l'obfuscation.

Avatar
Marc Boyer
Le 06-03-2006, Laurent Deniau a écrit :
Marc Boyer wrote:
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.


A tout prendre, je prefererais qu'il sache qu'un decalage a droite c'est
une *division* par deux sur un entier non signe et que c'est dependant
de l'implementation sur un entier signe.


Oui ;-)

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
Gabriel Dos Reis
Fabien LE LEZ writes:

[...]

| Et franchement, un "x << 2" qui veut dire "x*2", ça ressemble quand
| même beaucoup à de l'obfuscation.

Cela dépend du contexte. Si tu es en train de fournir la fonction
runtime qui fait « * », tu n'as probablement pas envie de définir
« x * 2 » par « x * 2 » :-)

Mais note bien le contexte de qualification.

-- Gaby
Avatar
Sylvain
Marc Boyer wrote on 06/03/2006 18:08:

Et tu remarqueras que le C++,
contrairement au C, a spécifiquement introduit un mot clé -- « asm »).
Je ne l'avais pas noté.



selon K&R, il était réservé (/réservé/ uniquement) par certaines
implémentations (de même que "fortran").

Je reviens quand même sur le contexte de cette discussion qui
était de la fonction int Double([const] int x); qui retourne
le double de x *devrait* se coder
return x<<1;


j'ai bien dit "devrait" (should) et non "doit" (shall).

cette remarque ne pouvait avoir de sens que dans un contexte un peu plus
précis, or ce n'était pas l'objet initial; de plus l'extrait (d'un post
annulé mais pas assez vite) ne reprenait que ce point alors que
l'élément discuté concernait "int Rapport(const int a,const int b)" qui
ne compilait pas.

profitant de votre fil posé et constructif, je préciserai que la réponse
"devrait" était un raccourci à "une telle fonction ne 'doit' jamais
exister" mais l'opération doit être inlinée (sinon le cout d'appel est
prohibitif par rapport au traitement) et ce codage selon l'opérande et
la famille de compilos visés pourra être "optimisé d'office" par un
shift si cela semble opportun.

or donc, la question concernait l'usage du modifier 'const' et non le
bien fondé d'une telle fonction, j'ai donc opté pour la version courte,
un peu pour voir ... et j'ai vu.


pour répondre à la remarque de l'autre post:

A tout prendre, je prefererais qu'il sache qu'un decalage
a droite c'est une *division* par deux sur un entier non
signe et que c'est dependant de l'implementation sur
un entier signe.


Oui ;-)


il a été rappellé que les opérateurs de décalage sont contextuels (ils
ne sont pas un codage fixe en asm); pour un décalage à droite, si le
type entier est signé, le compilo doit générer un décalage signé
(restauration du bit de signe, soit SAR sur Intel) tandis qu'un opérande
non signé subira un décalage non signé (injection de 0 à gauche, SHR sur
Intel).

Sylvain.


Avatar
Gabriel Dos Reis
Sylvain writes:

| Marc Boyer wrote on 06/03/2006 18:08:
| >
| >> Et tu remarqueras que le C++,
| >> contrairement au C, a spécifiquement introduit un mot clé -- « asm »).
| > Je ne l'avais pas noté.
|
| selon K&R, il était réservé (/réservé/ uniquement) par certaines
| implémentations (de même que "fortran").

C'est une extension courante, mais cela ne fait pas partie de la
définition officielle de C et nulle part dans la partie normative de
C, il est marqué que c'est un nom réservé. La norme C99 dit bien

J.5 Common extensions

[#1] The following extensions are widely used in many
systems, but are not portable to all implementations. The
inclusion of any extension that may cause a strictly
conforming program to become invalid renders an
implementation nonconforming. Examples of such extensions
are new keywords, extra library functions declared in
standard headers, or predefined macros with names that do
not begin with an underscore.


-- Gaby
Avatar
kanze
Fabien LE LEZ wrote:
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.


Même en C. On rencontre (ou on rencontrait) pas mal de
programmeurs C qui n'ont jamais eu à faire des manipulations des
bits, et qui donc n'ont pas l'habitude de voir de tels
opérateurs. On en rencontre même qui ne les ont jamais vu ; ce
n'est pas vraiment quelque chose de fondamental qui sert
partout.

--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34


Avatar
kanze
Gabriel Dos Reis wrote:
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.


C'est une attitude que j'ai vue dans les deux langages. Ce que
je constate, c'est que malgré cette attitude, leurs programmes
sont en général moins performants que ceux écris proprement.

En C++, la situation est différente : d'une part, en voyant
un "<<", on pense immédiatement aux iostream ;


pas moi ;


Tu n'es peut-être pas le programmeur C++ typique:-).

et les programmeurs C++ que je connais (et que respecte
profondément) lisent « << » dans le contexte.


Je crois que la clé, c'est que ce sont des programmeurs C++ ;
c-à-d plus ou moins spécialisé dans le C++. Il faut dire que la
majeur partie des programmeurs que je vois, ce sont des
programmeurs dans la bancaire, ou des programmeurs dans les
télécoms -- leur intérêt principal se situe à un autre niveau ;
pour eux, le C++ n'est qu'un outil (parmi d'autres), et leur
connaissances du langage proprement dit se bornent à ce qu'il
leur faut pour faire leur travail. (En général, si j'y suis,
c'est que la direction reconnaît qu'il faut de tout, et qu'il
faut au moins une personne avec une connaissance approfondie du
langage auxquels les autres peuvent s'adresser, le cas échéant.)

Dans les domaines où je travaille, très souvent, la seule
utilisation de <<, c'est pour les logs, et >> n'apparaît jamais.
(L'exception, évidemment, c'est dans les couches de certains
protocols. Mais c'est soit acheté de l'extérieur, soit
implémenté par une petite sous-équipe plus spécialisée.)

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.


Mais il a bien une sémantique (qui n'est pas celui de la
multiplication -- là on est bien d'accord). Ou plusieurs
sémantiques, selon le cas.

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


Et si c'est une classe utilisateur, on « dévine » sa
signification d'après l'abstraction qu'implémente la classe,
n'est-ce pas. C-à-d que si la classe implémente quelque chose
qui ressemble aux entiers (par exemple, s'il supporte aussi +,
-, *, / et % -- et surtout |, & et ~) on suppose décalage.
Tandis que si elle n'implémente que <<, et non d'autres
opérateurs, et que << est générique, de façon a accepter
pratiquement n'importe quel type à droit, je comprends
insertion. Et dans tout autre cas, je comprends que c'est un
abus de surcharge ?:-)

(En fait, le paragraphe ci-dessus doit être compris comme une
question. Je crois qu'il correspond à ce que tu dis, mais je ne
suis pas sûr.)

J'irais plus loin... Il y a entier et entier, et si je ne
m'intéresse qu'à la valeur numérique, et non à sa
représentation, ou des bits qui la soutendent, je ne m'attends
pas à un opérateur <<.

En géneral « x << y » fait ce que « << » est défini dans le
contexte de « x » et « y ».


C'est vrai pour n'importe quel opérateur C++, non ? C'est
seulement par convention qu'on s'attend à ce qu'un surcharge ait
une sémantique en quelque sort « apparentée » à la sémantique
sur les types de base.

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


La contexte ici, à laquelle Fabien répond, c'est que quelqu'un a
prétendu qu'écrire « x << 1 », quand on veut multiplier par
deux, c'est la signe d'un bon programmeur.

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


Il y a une ontologie professionnelle, que tu le veuilles ou non.
Pratiquer l'obfuscation exprès pour se rendre « nécessaire »
n'est pas un comportement « professionnel », quand même. Plus
généralement, il y a un certain minimum de qualité à respecter :
écrire exprès une expression de façon tordue et illisible, sans
motif valable, n'est pas professionnel ; ne pas utiliser les
outils disponibles à bonne échéance n'est pas professionnel ;
etc., etc.

--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34





3 4 5 6 7