Logo GNT
Actualités Tests & Guides Bons Plans
Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11
Entraide Développement Développement Langage C int **foo est-il équivalent à &foo du C++

int **foo est-il équivalent à &foo du C++

17 réponses
Avatar
xylo
bonjour =E0 tous,

je me pose une question concernant le double r=E9f=E9rencement d'une
variable en C:
peut-on consid=E9rer que un pointeur d'un pointeur (en C) est =E9quivalent
(au moins dans l'esprit) =E0 la notion de r=E9f=E9rence en C++

int **foo(C) =3D?=3D int & foo(C++)
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
1 2
Avatar
Jean-Marc Bourguet
xylo writes:

bonjour à tous,

je me pose une question concernant le double référencement d'une
variable en C:
peut-on considérer que un pointeur d'un pointeur (en C) est équivalent
(au moins dans l'esprit) à la notion de référence en C++

int **foo(C) =?= int & foo(C++)



Non. Tu peux en premiere approximation considerer une reference C++ comme
un pointeur dereference automatiquement.

A+

--
Jean-Marc
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Avatar
Charlie Gordon
"Jean-Marc Bourguet" a écrit dans le message de news:

xylo writes:

bonjour à tous,

je me pose une question concernant le double référencement d'une
variable en C:
peut-on considérer que un pointeur d'un pointeur (en C) est équivalent
(au moins dans l'esprit) à la notion de référence en C++

int **foo(C) =?= int & foo(C++)



Non. Tu peux en premiere approximation considerer une reference C++ comme
un pointeur dereference automatiquement.



En d'autres termes, on pourrait imaginer la réécriture suivante :

// en C++
int foo(int& xref) {
/* code utilisant xref par reference */
}

/* en C */
int foo(int *xref__) {
#define xref (*xref__)
/* le meme code */
#undef xref
}

Les références sont une fausse bonne idée. Elles permettent d'alléger
l'écriture au prix d'une plus grande incertitude sur la semantique réelle du
code : le lecteur du code C++ peut plus facilement se tromper sur la
signification du code dont les effets de bord sont moins visibles. Elles
sont cependant nécessaires pour certaines constructions de surcharge des
opérateurs.
Mais elles n'ont pas l'élégance des n-uplets : la possibilité pour une
fonction de retourner efficacement plusieurs valeurs, comme
pointeur+longueur, pointeur+indication de succès... Cette construction
n'existe ni en C, ni en C++. L'alternative consistant à retouner une
structure est lourdingue, aussi bien pour la syntaxe que pour
l'implementation, alors que le nombre de registres des processeurs
augmentant, une ABI efficace est possible pour retourner plusieurs valeurs
dont certaines seront ignorées.

--
Chqrlie.
Avatar
Jean-Marc Bourguet
"Charlie Gordon" writes:

Les références sont une fausse bonne idée.



Pas d'accord. C'est quelque chose dont on peut abuser -- mais on considere
que la possibilite d'un abus doit condamner une feature, on n'est pas dans
le bon groupe.

Elles permettent d'alléger l'écriture au prix d'une plus grande
incertitude sur la semantique réelle du code : le lecteur du code C++
peut plus facilement se tromper sur la signification du code dont les
effets de bord sont moins visibles.



Ca ne m'a jamais pose un probleme. En C++ ou dans les autres langages qui
ont le meme non-probleme de ne pas marquer a l'appel les parametres out ou
in out. (Au contraire, je trouve problematique de prendre l'adresse d'une
variable locale et les references me permettent un style ou ce n'est jamais
necessaire -- en fait c'est un de mes criteres pour choisir entre une
reference ou un pointeur).

Mais elles n'ont pas l'élégance des n-uplets



J'ai du mal a voir le rapport entre les n-uplets et les references. (En
passant, rien n'empeche d'avoir une ABI permettant le passage et le retour
de petites structures par les registres -- ca m'etonnerait qu'il n'y en ait
pas d'ailleurs).

A+

--
Jean-Marc
FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Avatar
Charlie Gordon
"Jean-Marc Bourguet" a écrit dans le message de news:

"Charlie Gordon" writes:

Les références sont une fausse bonne idée.



Pas d'accord. C'est quelque chose dont on peut abuser -- mais on
considere
que la possibilite d'un abus doit condamner une feature, on n'est pas dans
le bon groupe.



Baliser les écueils est toujours une bonne chose.
Interdire les plus dangereux est souhaitable : gets, strncpy...

Elles permettent d'alléger l'écriture au prix d'une plus grande
incertitude sur la semantique réelle du code : le lecteur du code C++
peut plus facilement se tromper sur la signification du code dont les
effets de bord sont moins visibles.



Ca ne m'a jamais pose un probleme. En C++ ou dans les autres langages qui
ont le meme non-probleme de ne pas marquer a l'appel les parametres out ou
in out. (Au contraire, je trouve problematique de prendre l'adresse d'une
variable locale et les references me permettent un style ou ce n'est
jamais
necessaire -- en fait c'est un de mes criteres pour choisir entre une
reference ou un pointeur).



Plutôt que "fausse bonne idée", j'aurais dû écrire "pas la panacée". Outre
la possibilité de retourner des lvalues, cette notation est utilisée pour
permettre de modifier des variables 'in/out', qui sont souvent une mauvaise
idée, ou des variables 'out' qui ne peuvent effectivement pas être déclarées
commes telles dans le prototype de la fonction. L'utilisation de références
présente certains avantages comme l'allègement de la syntaxe, la non nullité
implicite, mais rendent le code potentiellement plus facile à mal
interpréter. Je ne dis pas qu'elles n'ont pas leur utilité, juste qu'elle
ne sont pas une solution idéale.

Mais elles n'ont pas l'élégance des n-uplets



J'ai du mal a voir le rapport entre les n-uplets et les references. (En
passant, rien n'empeche d'avoir une ABI permettant le passage et le retour
de petites structures par les registres -- ca m'etonnerait qu'il n'y en
ait
pas d'ailleurs).



Les n-uplets sont une methode pour retourner plusieurs valeurs qui a
l'avantage d'utiliser une notation fonctionnelle et d'éviter l'ambiguité des
paramètres passés par reference ou par pointeur dont on ne sait pas dire
qu'ils sont "out" ou "in/out". En C il faut soit avoir recours à des
pointeurs, soit retourner des structures, en C++ on peut utiliser des
references plutôt que des pointeurs. Les ABI courantes permettent
effectivement souvent de passer les petites structures en parametres et en
valeur de retour dans des registres, mais la syntaxe reste lourde : il faut
stocker le resultat dans une structure pour en utiliser les champs dans une
instruction separee. Avec des n-uplets, on peut plus facilement ignorer
certaines valeurs de retour et ne stocker que celles qui sont utiles ou les
reutiliser directement dans l'expression englobant l'appel de fonction. Les
references seront peut-etre incluses dans la prochaine revision du Standard
C1x, en revanche les n-uplets ont peu de chances d'y parvenir, donc cette
discussion est un peu vaine.

--
Chqrlie.
Avatar
Antoine Leca
En news:ge9l45$csm$, Charlie Gordon va
escriure:
[Les références] n'ont pas l'élégance des n-uplets : la possibilité
pour une fonction de retourner efficacement plusieurs valeurs, comme
pointeur+longueur, pointeur+indication de succès... Cette construction
n'existe ni en C, ni en C++. L'alternative consistant à retouner une
structure est lourdingue, aussi bien pour la syntaxe que pour
l'implementation,



Tsk tsk. Cela dépend complètement de l'ABI sous-jacente.
Si tu as une ABI qui permet de retourner facilement n (n>1) registres depuis
l'appelé vers l'appelant, il n'y a aucune raison (autre que des compilateurs
mal programmés) pour qu'une fonction qui retourne une structure constituée
de p (n>=p>1) « éléments » (ici, taille, pointeur, indicateur) ne puisse pas
être implémentée de manière simple et efficace en C/C++/langage machin.
Si par contre tu n'as pas cette ABI (cas fréquent ;-)), alors tes n-uplets
vont faire appel sous la ceinture à un mécanisme strictement identique à
celui utilisé par les compilos C, en général pointeur caché et/ou mémoire
allouée dynamiquement sur la pile, autrement dit cela va gâcher des cycles
*et* des octets à répéter du code.


alors que le nombre de registres des processeurs
augmentant, une ABI efficace est possible pour retourner plusieurs
valeurs dont certaines seront ignorées.



C'est peut-être possible mais ce n'est pas fréquent ! et de toute manière
c'est pas vraiment le sujet de ce groupe, n'est-ce pas ?


Antoine
Avatar
xylo
On 29 oct, 16:28, "Charlie Gordon" wrote:
"Jean-Marc Bourguet" a écrit dans le message de new s:


> "Charlie Gordon" writes:

>> Les références sont une fausse bonne idée.

> Pas d'accord. C'est quelque chose dont on peut abuser -- mais on
> considere
> que la possibilite d'un abus doit condamner une feature, on n'est pas d ans
> le bon groupe.

Baliser les écueils est toujours une bonne chose.
Interdire les plus dangereux est souhaitable : gets, strncpy...

>> Elles permettent d'alléger l'écriture au prix d'une plus grande
>> incertitude sur la semantique réelle du code : le lecteur du code C+ +
>> peut plus facilement se tromper sur la signification du code dont les
>> effets de bord sont moins visibles.

> Ca ne m'a jamais pose un probleme. En C++ ou dans les autres langages qui
> ont le meme non-probleme de ne pas marquer a l'appel les parametres out ou
> in out. (Au contraire, je trouve problematique de prendre l'adresse d' une
> variable locale et les references me permettent un style ou ce n'est
> jamais
> necessaire -- en fait c'est un de mes criteres pour choisir entre une
> reference ou un pointeur).

Plutôt que "fausse bonne idée", j'aurais dû écrire "pas la panac ée". Outre
la possibilité de retourner des lvalues, cette notation est utilisée pour
permettre de modifier des variables 'in/out', qui sont souvent une mauvai se
idée, ou des variables 'out' qui ne peuvent effectivement pas être d éclarées
commes telles dans le prototype de la fonction. L'utilisation de réf érences
présente certains avantages comme l'allègement de la syntaxe, la non nullité
implicite, mais rendent le code potentiellement plus facile à mal
interpréter. Je ne dis pas qu'elles n'ont pas leur utilité, juste qu 'elle
ne sont pas une solution idéale.

>> Mais elles n'ont pas l'élégance des n-uplets

> J'ai du mal a voir le rapport entre les n-uplets et les references. (E n
> passant, rien n'empeche d'avoir une ABI permettant le passage et le ret our
> de petites structures par les registres -- ca m'etonnerait qu'il n'y en
> ait
> pas d'ailleurs).

Les n-uplets sont une methode pour retourner plusieurs valeurs qui a
l'avantage d'utiliser une notation fonctionnelle et d'éviter l'ambiguit é des
paramètres passés par reference ou par pointeur dont on ne sait pas d ire
qu'ils sont "out" ou "in/out".



const char * => ne peut pas être in est C tout.

pointeurs, soit retourner des structures, en C++ on peut utiliser des
references plutôt que des pointeurs. Les ABI courantes permettent
effectivement souvent de passer les petites structures en parametres et e n
valeur de retour dans des registres, mais la syntaxe reste lourde : il fa ut
stocker le resultat dans une structure pour en utiliser les champs dans u ne
instruction separee. Avec des n-uplets, on peut plus facilement ignorer
certaines valeurs de retour et ne stocker que celles qui sont utiles ou l es
reutiliser directement dans l'expression englobant l'appel de fonction. Les
references seront peut-etre incluses dans la prochaine revision du Standa rd
C1x, en revanche les n-uplets ont peu de chances d'y parvenir, donc cette
discussion est un peu vaine.

--
Chqrlie.


Avatar
Charlie Gordon
"xylo" a écrit dans le message de news:


const char * => ne peut pas être in est C tout.



En l'occurrence, const char * ne peut être QUE "in".

Le probleme est en effet qu'un parametre char * peut être in/out ou out,
voire les deux ou d'autres possibilités moins régulières encore. Par
exemple les arguments de scanf sont out mais peuvent ne pas être modifiés si
le flux ne correspond pas ou seulement partiellement au format. Ce type de
semantique est une source d'erreurs courante, meme pour des programmeurs
chevronnés. L'ambiguité entre in et in/out ne permet pas au compilateur de
detecter et signaler les cas de variables non initialisés qui causent des
bugs erratiques parfois difficiles à trouver. Les n-uplets ne sont pas une
solution pour scanf, dont la semantique est problematique à plus d'un titre,
mais ils seraient une alternative interessantes pour des cas plus simples,
et encourageraient des API plus regulières et moins risquées.

Bref, on est un peu hors sujet sur ce forum, mais on peut rêver un peu de
faire évoluer le langage ;-)

--
Chqrlie.
Avatar
xylo
Le Wed, 29 Oct 2008 23:00:13 +0100, Charlie Gordon a écrit:

"xylo" a écrit dans le message de news:


const char * => ne peut pas être in est C tout.



En l'occurrence, const char * ne peut être QUE "in".



oui bien sure, j'ai posté un peu vite ce matin...

--
http://jm.marino.free.fr
Avatar
espie
In article <ge9ve9$616$,
Charlie Gordon wrote:
"Jean-Marc Bourguet" a écrit dans le message de news:

"Charlie Gordon" writes:

Les références sont une fausse bonne idée.



Pas d'accord. C'est quelque chose dont on peut abuser -- mais on
considere
que la possibilite d'un abus doit condamner une feature, on n'est pas dans
le bon groupe.



Baliser les écueils est toujours une bonne chose.
Interdire les plus dangereux est souhaitable : gets, strncpy...



Analogie douteuse ! il y a quand meme un monde entre les references et gets,
heureusement.

Elles permettent d'alléger l'écriture au prix d'une plus grande
incertitude sur la semantique réelle du code : le lecteur du code C++
peut plus facilement se tromper sur la signification du code dont les
effets de bord sont moins visibles.



Ca ne m'a jamais pose un probleme. En C++ ou dans les autres langages qui
ont le meme non-probleme de ne pas marquer a l'appel les parametres out ou
in out. (Au contraire, je trouve problematique de prendre l'adresse d'une
variable locale et les references me permettent un style ou ce n'est
jamais
necessaire -- en fait c'est un de mes criteres pour choisir entre une
reference ou un pointeur).



Plutôt que "fausse bonne idée", j'aurais dû écrire "pas la panacée". Outre
la possibilité de retourner des lvalues, cette notation est utilisée pour
permettre de modifier des variables 'in/out', qui sont souvent une mauvaise
idée, ou des variables 'out' qui ne peuvent effectivement pas être déclarées
commes telles dans le prototype de la fonction. L'utilisation de références
présente certains avantages comme l'allègement de la syntaxe, la non nullité
implicite, mais rendent le code potentiellement plus facile à mal
interpréter. Je ne dis pas qu'elles n'ont pas leur utilité, juste qu'elle
ne sont pas une solution idéale.

Mais elles n'ont pas l'élégance des n-uplets



J'ai du mal a voir le rapport entre les n-uplets et les references. (En
passant, rien n'empeche d'avoir une ABI permettant le passage et le retour
de petites structures par les registres -- ca m'etonnerait qu'il n'y en
ait
pas d'ailleurs).



Les n-uplets sont une methode pour retourner plusieurs valeurs qui a
l'avantage d'utiliser une notation fonctionnelle et d'éviter l'ambiguité des
paramètres passés par reference ou par pointeur dont on ne sait pas dire
qu'ils sont "out" ou "in/out".



En C++, l'utilisation rationnelle du const permet d'eviter un gros ensemble
de ces soucis.

Toujours en C++, il y a des templates fort sympathiques, comme make_pair,
qui te fabriquent des struct `a la volee' sans avoir a rien declarer.
(et vu la facon dont c'est implemente, en general, c'est aussi efficace
que ce que tu voudrais).

Bref, en C++, ils y sont, tes n-uplets, et d'ailleurs les gens s'en servent.
Apres, tu peux decreter que, comme ca ne fait pas partie du langage de base,
ca n'est pas la, mais les mecanismes specifiques aux C++: templates, references,
et fonctions inline (bon d'accord, c'est aussi en C maintenant) permettent
d'etendre le langage de maniere elegante et raisonnablement propre (comparer
au preprocesseur du C, qui lui est purement syntaxique et se fout de la
semantique du langage).

Apres, tous ces mecanismes sont dangereux, parce qu'extremement puissants.

L'allocation memoire et les pointeurs sont dangereux pour un programmeur C
*debutant*, est-ce pour autant une raison de les bannir du langage ?

Voir pour les references uniquement le cote `passage de parametres
modifiables' me fait dire que tu as une vision un peu archaique du C++...
c'est clair qu'il traine encore plein de code qui exploite ce style, et ecrit
par des gens maitrisant mal le langage, mais celui-ci a fait quelques progres
depuis... suffit de regarder ce qu'il y a dans boost pour s'en convaincre..
Avatar
Marc Boyer
On 2008-10-29, xylo wrote:
Les n-uplets sont une methode pour retourner plusieurs valeurs qui a
l'avantage d'utiliser une notation fonctionnelle et d'éviter l'ambiguité des
paramètres passés par reference ou par pointeur dont on ne sait pas dire
qu'ils sont "out" ou "in/out".



const char * => ne peut pas être in est C tout.



Dans ce cas facile, oui. Regardons d'un peu plus prêt.

typedef struct cel {
int value;
struct cel* next;
} cel;

typedef struct {
cel* first;
size_t size;
} list;

void promisJetoucheARien(const list* l){
if (l) {
l->value=0;
l->next= NULL;
}
}

Alors, il est in le paramètre ?


Marc Boyer
--
Si tu peux supporter d'entendre tes paroles
Travesties par des gueux pour exciter des sots
IF -- Rudyard Kipling (Trad. André Maurois)
1 2