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

7 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
Charlie Gordon
"Marc Boyer" a écrit dans le message de
news:
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 ?



Erreur de syntaxe: list n'a pas ni champ value, ni next;

En revanche, tu souleves un point intéressant :

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

C'est effectivement une faiblesse de la semantique de const que la constness
ne se propage pas implicitement au delà de la premiere indirection. C'est
d'ailleurs la raison qui fait que le type char ** n'est pas compatible avec
const char ** et qui donne un des prototypes irreguliers aux fonctions de la
famille de strtol. Ce problème est réglé dans le langage D de Walter
Bright, mais la solution casserait trop de code à être transposée en C.

--
Chqrlie.
Avatar
Marc Boyer
On 2008-11-03, Charlie Gordon wrote:
"Marc Boyer" a écrit dans le message de
news:
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 ?



Erreur de syntaxe: list n'a pas ni champ value, ni next;



A oui.... A poster du code non compilé...

En revanche, tu souleves un point intéressant :

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

C'est effectivement une faiblesse de la semantique de const que la constness
ne se propage pas implicitement au delà de la premiere indirection. C'est
d'ailleurs la raison qui fait que le type char ** n'est pas compatible avec
const char ** et qui donne un des prototypes irreguliers aux fonctions de la
famille de strtol. Ce problème est réglé dans le langage D de Walter
Bright, mais la solution casserait trop de code à être transposée en C.



Je voulais juste souligner à xylo que le "const" du C n'est pas
équivalent au "in" algorithmique tel qu'il est souvent compris.

Marc Boyer
--
Si tu peux supporter d'entendre tes paroles
Travesties par des gueux pour exciter des sots
IF -- Rudyard Kipling (Trad. André Maurois)
Avatar
espie
In article ,
Marc Boyer wrote:
Je voulais juste souligner à xylo que le "const" du C n'est pas
équivalent au "in" algorithmique tel qu'il est souvent compris.



Le const du C est notoirement buggue, au niveau typage.

Rien que pour certaines fonctions de la bibliotheque standard: tu es
*oblige* de mettre des cast pour les implementer, sinon, c'est impossible.

(je pense typiquement a strstr ou strchr).
Avatar
Antoine Leca
En news:genc76$1jk2$, Marc Espie va escriure:
Le const du C est notoirement buggue, au niveau typage.

Rien que pour certaines fonctions de la bibliotheque standard: tu es
*oblige* de mettre des cast pour les implementer, sinon, c'est
impossible.
(je pense typiquement a strstr ou strchr).



C'est vrai, mais ce n'est pas forcément un bogue : je veux dire, il y a pas
mal de choses dans la bibliothèque standard que l'on ne peut pas écrire en
« C propre » ; en fait, c'est même une des raisons pour lesquelles le
concept même de bibliothèque standard existe dans la norme.

(Les autres raisons sont pour partager du code, la raison de base des
bibliothèques ; pour améliorer l'abstraction de l'environnement ; et pour
éviter des chausses-trappes, « ne pas réinventer le fil à couper le
beurre ».)


Antoine
Avatar
espie
In article <gendn2$1ac$,
Antoine Leca wrote:
En news:genc76$1jk2$, Marc Espie va escriure:
Le const du C est notoirement buggue, au niveau typage.

Rien que pour certaines fonctions de la bibliotheque standard: tu es
*oblige* de mettre des cast pour les implementer, sinon, c'est
impossible.
(je pense typiquement a strstr ou strchr).



C'est vrai, mais ce n'est pas forcément un bogue : je veux dire, il y a pas
mal de choses dans la bibliothèque standard que l'on ne peut pas écrire en
« C propre » ; en fait, c'est même une des raisons pour lesquelles le
concept même de bibliothèque standard existe dans la norme.



Je suis d'accord pour d'autres fonctions, mais la, c'est clairement un
probleme d'expressivite du typage du langage, qui t'interdit de dire `je
renvoie un truc qui en fait correspond a la meme zone qu'un de mes parametres,
et je ne l'ai pas modifie, donc si celui-ci etait vraiment const, alors le
resultat doit etre const, et sinon, ah ben non').

Parce que l'air de rien, tu peux ecrire

char *a = strchr("bonjour", 'b');
*a = 'a'; // OOPS

sans que ton langage te dise qu'il y a un souci...
Avatar
Charlie Gordon
"Marc Espie" a écrit dans le message de news:
genjoh$1kfu$
In article <gendn2$1ac$,
Antoine Leca wrote:
En news:genc76$1jk2$, Marc Espie va escriure:
Le const du C est notoirement buggue, au niveau typage.

Rien que pour certaines fonctions de la bibliotheque standard: tu es
*oblige* de mettre des cast pour les implementer, sinon, c'est
impossible.
(je pense typiquement a strstr ou strchr).



C'est vrai, mais ce n'est pas forcément un bogue : je veux dire, il y a
pas
mal de choses dans la bibliothèque standard que l'on ne peut pas écrire en
« C propre » ; en fait, c'est même une des raisons pour lesquelles le
concept même de bibliothèque standard existe dans la norme.



Je suis d'accord pour d'autres fonctions, mais la, c'est clairement un
probleme d'expressivite du typage du langage, qui t'interdit de dire `je
renvoie un truc qui en fait correspond a la meme zone qu'un de mes
parametres,
et je ne l'ai pas modifie, donc si celui-ci etait vraiment const, alors le
resultat doit etre const, et sinon, ah ben non').

Parce que l'air de rien, tu peux ecrire

char *a = strchr("bonjour", 'b');
*a = 'a'; // OOPS

sans que ton langage te dise qu'il y a un souci...



Tout à fait d'accord.

C'est bien dommage que le comité ne soit toujours pas enclin à combler cette
lacune en introduisant dans la prochaine norme une forme même très primitive
de surcharge qui permette de déclarer les fonctions de la librairie comme
ceci:

char *strchr(char *, int);
const char *strchr(const char *, int);

long strtol(char *, char **, int);
long strtol(const char*, const char **, int);

etc.

On pourrait aussi imaginer une syntaxe qui permette de definir la constness
du resultat en fonction de celle effective d'un des parametres, ou une forme
encore plus elaboree de specification de contraintes sur les parametres et
le resultat, mais tout cela est hors d'atteinte :-(

--
Chqrlie.
Avatar
Antoine Leca
En news:genjoh$1kfu$, Marc Espie va escriure:
Je suis d'accord pour d'autres fonctions, mais la, c'est clairement un
probleme d'expressivite du typage du langage



Oui. Le vrai problème, c'est le sens réel de const, qui est un poil trop
simpliste pour beaucoup des usages qu'on voudrait lui voir jouer (tout en
étant, à l'égal des prototypes, un énorme progrès sur ce que l'on avait
avant...)


Antoine
1 2