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 cast de pointeur *, ** différence ?

cast de pointeur *, ** différence ?

114 réponses
Avatar
Nico
salut,

j'ai un petit code qui m'étonne... soit une fonction prenant un void*
en paramètre, lors de son appel, si je lui passe un double*, mon
compilateur dit rien... ok.
soit une fonction retournant un void *, lorsque j'assigne un double*
avec le retour de cette fonction, mon compilateur ne dit rien...

ici donc, pas besoin de caster ni le paramètre (en (void*)), ni le
retour de fonction (en (double*))...

maintenant, on prend les même et on recommence, à la différence près
que mon argument n'est plus un void* mais un void**, et mon retour
n'est plus un void* mais aussi un void **. là plus rien ne passe...
lors de l'appel de la fonction je suis obligé de caster mon double** en
void**, et lors du retour, je suis obligé de caster en double**,
pourquoi ?

pour un exemple plus parlant, considérez le code suivant :

void *
vect_new(size_t len, size_t size_type)
{
void *v = malloc(len * size_type);
return v;
}


void
vect_free(void *vect)
{
if(vect) free(vect);
}

/*declaration du vecteur...
pas besoin de faire un cast (double*)*/

double *vect = vect_new(3,sizeof(double));

/*appel sans probleme a la compilation :
pas besoin de faire (void*)vect*/
vect_free(vect);


et maintenant avec des void** :

void **
mat_new(unsigned int nrow, unsigned int ncol, size_t size_type)
{
int i,j;
void **m = malloc(nrow * size_type);
if(m)
{
for(i=0; i<nrow; i++)
{
m[i] = malloc(ncol * size_type);
if(!m[i])
{
for(j=0; j<=i; j++)
free(m[i]);
free(m);
m = NULL;
}
}
}
return m;
}

void
mat_free(void **m,unsigned int nrow)
{
int i;
if(m)
{
for(i=0; i<nrow; i++)
if(m[i])
free(m[i]);
free(m);
}
}

/*declaration de la matrice*/
double **matrice = (double**)mat_new(4,3,sizeof(double));

/*appel sans probleme a la compilation : */
mat_free((void**)matrice,4);

là si je cast pas l'un et l'autre... warning... où se situe la
différence avec le 1er exemple ?

merci de m'éclairer à ce propos.

--
Nico,
http://astrosurf.com/nicoastro
http://nicolas.aunai.free.fr
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
8 9 10 11 12
Avatar
Richard Delorme

La RFC dit "-- n"


Ne dit-elle pas plutôt "n-- n"?
Ou plutôt "rn-- rn", s'agissant de mail?

Et puis quelle RFC d'abord?


http://www.faqs.org/rfcs/rfc2646.html

4.3. Usenet Signature Convention

There is a convention in Usenet news of using "-- " as the separator
line between the body and the signature of a message. When
generating a Format=Flowed message containing a Usenet-style
separator before the signature, the separator line is sent as-is.
This is a special case; an (optionally quoted) line consisting of
DASH DASH SP is not considered flowed.

--
Richard


Avatar
Gabriel Dos Reis
Richard Delorme writes:

|
| >>La RFC dit "-- n"
| > Ne dit-elle pas plutôt "n-- n"?
| > Ou plutôt "rn-- rn", s'agissant de mail?
| > Et puis quelle RFC d'abord?
|
| http://www.faqs.org/rfcs/rfc2646.html
|
| 4.3. Usenet Signature Convention
|
| There is a convention in Usenet news of using "-- " as the separator
| line between the body and the signature of a message. When
| generating a Format=Flowed message containing a Usenet-style
| separator before the signature, the separator line is sent as-is.
| This is a special case; an (optionally quoted) line consisting of
| DASH DASH SP is not considered flowed.

Bien.

-- Gaby
Avatar
Charlie Gordon
"Emmanuel Delahaye" wrote in message
news:
Charlie Gordon wrote on 10/11/04 :
void *a = malloc (sizeof *a *taille)


C'est pas particulièrement lisible ;-)


C'est surtout faux.


T'as raison : il manque le ;


Oui

et taille est ambigu, on devrait mettre nombre.


Exact.

Mais le plus grave, c'est que le type de a étant void *, la taille de
*a n'a aucun sens (même si la syntaxe est acceptée par une extension
laxiste de gcc).


rodidju, c'était si gros que cela m'avait échappé !
quand la forme est peu lisible, les horreurs du fond sont mieux cachées ;-)

Chqrlie.

PS: l'extension gcc, qui marche aussi pour les pointeurs de fonctions, parmet de
faire de l'arithmetique sur les pointeurs void. La taille utilisée est 1, ce
qui revient à dire qu'il y a un cast implicite en pointeur de (unsigned) char.
C'est assez degueu, en effet, mais c'est cohérent avec les sémantiques de
memset(), memcpy(), et malloc().





Avatar
James Kanze
Jean-Marc Bourguet writes:

|> Gabriel Dos Reis writes:

|> > Jean-Marc Bourguet writes:

|> > | Yves ROMAN writes:

|> > | > > Je ne vois pas pourquoi. La seule contrainte c'est que void*
|> > | > > est capable de représenter précisément tous les types de
|> > | > > pointeurs.

|> > | > Peut on donc dire, pour tout type de donnée T, que :
|> > | > sizeof(void *) >= sizeof(T *) ?

|> > | Ce n'est pas formel mais je ne vois pas de plateforme ou il
|> > | aurait ete raisonnable que ce ne soit pas le cas.

|> > Je crois qu'il y a des indications dans la norme qu'on peut
|> > déduire

|> > sizeof (void*) == sizeof (char*)

|> Il me semble me souvenir de ca.

Même, je crois, que les void* et les char* ont la même représentation.

|> > && sizeof (void*) >= sizeof (T*)

|> Mais pas de ca. Mais je n'ai pas refais un exegese pour ces
|> reponses.

Ce qui est garanti, au moins, c'est que si p est un T*, (T*)(void*)p = p. Il faut donc qu'on peut convertir un T* en void* sans perte
d'information.

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

|> En , Emmanuel Delahaye va escriure:
|> > (Ton séparateur de .sig est invalide.

|> Tu veux dire que RFC 2822 ou je-ne-sais-laquelle interdit de mettre
|> deux tirets suivis d'un espace en tête de ligne, par exemple pour
|> simuler le tiret long qui nous est interdit dans cette hiérarchie ?

Je crois qu'il veut dire que le seul séparateur de .sig permis
(formellement) est deux tirets suivis d'un saut à la ligne. Et que chez
Gaby, le saut à la ligne manque.

--
James Kanze
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
Avatar
Emmanuel Delahaye
James Kanze wrote on 11/11/04 :
"Antoine Leca" writes:

En , Emmanuel Delahaye va
escriure: > (Ton séparateur de .sig est invalide.

Tu veux dire que RFC 2822 ou je-ne-sais-laquelle interdit de mettre
deux tirets suivis d'un espace en tête de ligne, par exemple pour
simuler le tiret long qui nous est interdit dans cette hiérarchie ?



Je crois qu'il veut dire que le seul séparateur de .sig permis
(formellement) est deux tirets suivis d'un saut à la ligne. Et que chez


Les deux tirets doivent être suivis d'un espace et d'un saut de ligne.

Gaby, le saut à la ligne manque.


Oui. Mais même une chose aussi simple et évidente donne lieu à
d'interminables sarcasmes... fatigant...

--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html

"C is a sharp tool"



Avatar
James Kanze
Nico writes:

|> ok j'ai bien compris le problème, le cast ne converti pas tout le
|> tableau...., mais je n'ai pas vu dans tous vos posts (ou peut-etre
|> est-ce moi qui ai du mal) la solution au problème ? (hormis de faire
|> l'hypothèse que sizeof(double*)==sizeof(void*))

double** p = malloc( sizeof( double* ) * i ) ;
for ( int i = 0 ; i < nbElems ; i ++ ) {
p[ i ] = malloc( sizeof( double ) * j ) ;
}

En général, quand tu utilises malloc, tu veux en fait un pointeur vers
un type donné. Et alors, la meilleur solution, c'est d'en convertir le
résultat tout de suite, et de ne travailler qu'en termes des pointeurs
correctement typés.

--
James Kanze
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
Avatar
Gabriel Dos Reis
Emmanuel Delahaye writes:

| > Gaby, le saut à la ligne manque.
|
| Oui. Mais même une chose aussi simple et évidente donne lieu à
| d'interminables sarcasmes... fatigant...

Si tu définis un entier comme une suite de chiffres décimaux, il te
faut de la détermination stupide pour dire que « foo9 » est un entier
invalide.

-- Gaby
Avatar
James Kanze
Gabriel Dos Reis writes:

|> Emmanuel Delahaye writes:

|> | > Gaby, le saut à la ligne manque.

|> | Oui. Mais même une chose aussi simple et évidente donne lieu à
|> | d'interminables sarcasmes... fatigant...

|> Si tu définis un entier comme une suite de chiffres décimaux, il te
|> faut de la détermination stupide pour dire que « foo9 » est un
|> entier invalide.

Je crois qu'il faisait référence à l'autre côté. Ou non -- d'une part,
je ne vois pas pourquoi tu veux être différent, quand il y a une norme,
mais de l'autre... Ça fait des années que je vois tes postings, je
connais plus ou moins les règles, et franchement, il y a des choses plus
importantes dans la vie. Tu fais ce que tu fais, et je ne vois pas où ça
pose un problème.

Et en fin de compte, moi non plus, je ne suis pas conforme, au moins
quand je poste du travail. Parce que là, pour des raisons techniques, je
dois insérer le séparateur manuelement, et je n'arrive pas à me rappeler
qu'il faut encore un espace que personne ne voit.

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

| Gabriel Dos Reis writes:
|
| |> Emmanuel Delahaye writes:
|
| |> | > Gaby, le saut à la ligne manque.
|
| |> | Oui. Mais même une chose aussi simple et évidente donne lieu à
| |> | d'interminables sarcasmes... fatigant...
|
| |> Si tu définis un entier comme une suite de chiffres décimaux, il te
| |> faut de la détermination stupide pour dire que « foo9 » est un
| |> entier invalide.
|
| Je crois qu'il faisait référence à l'autre côté. Ou non -- d'une part,
| je ne vois pas pourquoi tu veux être différent, quand il y a une norme,

Je ne veux pas être différent.

On appelle pas un chien un chat, juste parce qu'il a deux oreilles et
quatre pattes. Et un chien n'est pas un chat invalide.

-- Gaby
8 9 10 11 12