Adresse d'un tableau de char

[invitea29b3af3]

Bonjour,

Je me demandais une chose. Quand je fais le code suivant en C++

#include <iostream>
using namespace std;

int main() {
	int x[] = {3,2,4,1};
	char c[] = "salut";
	char * c2 = "coucou";
	cout << x << endl;
	cout << c << endl;
	cout << c2 << endl;
	return 0;
}

ça sort ça:

0x22f2c
salut
coucou

comment est-ce que le compilateur choisit d'afficher par exemple "salut" au lieu de l'adresse du premier élément de c. Je veux bien que je peux faire &c[0] pour ça, mais pourquoi le compilateur choisit de ne pas faire ça pour c. Merci d'avance
-----

[Jack]

Il faut peut-être voir du côté de la classe ostream, pour voir comment est surchargé l'opérateur <<. Selon le type d'opérande, une ou l'autre fonction définissant la surcharge sera utilisée par le compilateur.

A+

[invitea29b3af3]

Bonjour,
Ok d'accord, je vais voir ça. Merci bien.

[polo974]

Et tu fais quelle différence entre c et &c[0] ? ? ? (avec char c[] = "salut")

Si tu veux afficher la valeur du pointeur, il faut faire un cast:
(unsigned int) c

[A voir en vidéo sur Futura]

[invitea29b3af3]

Et tu fais quelle différence entre c et &c[0] ? ? ? (avec char c[] = "salut")

Euh.. justement je n'en fais aucune. C'est faux?
Je pars du principe (juste ou faux) qu'un pointeur contient une adresse et que donc, quel que soit le type de la variable vers laquelle pointe le pointeur, si on fait....

cout << pointeur << endl;

... on devrait de toute façon voir s'afficher une adresse. Mais apparemment c'est faux.

[inviteb9f49292]

Ca a à voir avec la signature d'une fonction qui est constituée du nom de la fonction, mais également du type de retour et du nombre et types des arguments d'entrés. Comme le C++ autorise la surcharge, le nom de la fonction dans le source n'est plus le même que celui dans le code objet pour que l'éditeur de lien trouve le bon symbole. Ce qui n'est pas nécessaire en C où la surcharge est inderdite. fait un "nm" sur un fichier objet en C puis en C++ pour t'en convaincre. Et ce qui explique la nécessité d'entourer les déclarations des fonctions C par une directive du compliateur lorsqu'elles sont compilées par un compilateur C++.

[invitea29b3af3]

Ok merci. Je crois comprendre plus ou moins l'idée. Juste une question encore:

fait un "nm" sur un fichier objet en C puis en C++ pour t'en convaincre

C'est quoi un "nm" ?

[inviteb9f49292]

C'est quoi un "nm"

"nm" est un programme qui affiche tous les symboles présents dans un fichier objet, c'est un utilitaire standard sous UNIX, donc je pense qu'il existe si tu utilises cygwin pour compiler sous windows. Sinon j'imagine qu'il existe un équivalent dans le monde de windows mais c'est en dehors de ma juridiction...

[invitea29b3af3]

D'accord, merci bien

[polo974]

Euh.. justement je n'en fais aucune. C'est faux?
Je pars du principe (juste ou faux) qu'un pointeur contient une adresse et que donc, ...

là, il faut faire attention à une difficulté du C:
int c[]; // ou int *c;
est une variable pointeur sur int, on peut positionner sa valeur

int c[5];
est un tableau et c est une constante pointant sur ce tableau

et donc quand on voit:
c[i] = 0;
on ne sait pas pour c si on a affaire à une constante pointant sur un tableau ou à une variable pointeur qui a OBLIGATOIREMENT été initialisée pour pointer sur le tableau.

quel que soit le type de la variable vers laquelle pointe le pointeur, si on fait....

cout << pointeur << endl;

... on devrait de toute façon voir s'afficher une adresse. Mais apparemment c'est faux.

si pointeur pointe sur une chaine de caractère, il sortira la chaine (sinon comment sortir une chaine dont on n'a qu'un pointeur...)
d'ailleurs, ça doit être vrai pour pas mal de pointeurs (sur des types standards (int, float, ...)).
Et là, il faut voir les prototypes.

Donc il faut faire un cast explicite (il faut toujours le faire quand on n'est pas sûr (et qu'on a la flemme de chercher dans la doc (oups)), de toute façon, soit il le fera de façon implicite, soit ça buguera...).

[invitea29b3af3]

D'accord, merci, c'est plus clair maintenant. Merci à tous.