Le Wed, 28 Jul 2004 19:55:25 +0200, Stephane Legras-Decussy a écrit :
on a dit un million de fois que sizeof(char) vaut *TOUJOURS* 1 ....
ya pas des masses de trucs toujours vrais, autant les connaitre... :-)
Oui d'ailleurs, pourquoi s'acharner sur ce détail ? On sait bien que sizeof(char) vaut toujours 1, mais n'est-ce pas plus lisible ?
Moi par exemple, quand j'alloue un tableau de char, je préfère toujours faire un truc du genre : bidule = (char*) malloc (longueur_de_bidule * sizeof(char));
C'est peut-être idiot, mais je trouve cela plus lisible.
-- Florent "flure" C. Décrypter l'@ pour répondre Coders don't die, they just JMP without RET !
Le Wed, 28 Jul 2004 19:55:25 +0200, Stephane Legras-Decussy a écrit :
on a dit un million de fois que sizeof(char)
vaut *TOUJOURS* 1 ....
ya pas des masses de trucs toujours vrais, autant les connaitre... :-)
Oui d'ailleurs, pourquoi s'acharner sur ce détail ? On sait bien que
sizeof(char) vaut toujours 1, mais n'est-ce pas plus lisible ?
Moi par exemple, quand j'alloue un tableau de char, je préfère toujours
faire un truc du genre :
bidule = (char*) malloc (longueur_de_bidule * sizeof(char));
C'est peut-être idiot, mais je trouve cela plus lisible.
--
Florent "flure" C.
Décrypter l'@ pour répondre
Coders don't die, they just JMP without RET !
Le Wed, 28 Jul 2004 19:55:25 +0200, Stephane Legras-Decussy a écrit :
on a dit un million de fois que sizeof(char) vaut *TOUJOURS* 1 ....
ya pas des masses de trucs toujours vrais, autant les connaitre... :-)
Oui d'ailleurs, pourquoi s'acharner sur ce détail ? On sait bien que sizeof(char) vaut toujours 1, mais n'est-ce pas plus lisible ?
Moi par exemple, quand j'alloue un tableau de char, je préfère toujours faire un truc du genre : bidule = (char*) malloc (longueur_de_bidule * sizeof(char));
C'est peut-être idiot, mais je trouve cela plus lisible.
-- Florent "flure" C. Décrypter l'@ pour répondre Coders don't die, they just JMP without RET !
Emmanuel Delahaye
Florent 'flure' C. wrote on 29/07/04 :
Moi par exemple, quand j'alloue un tableau de char, je préfère toujours faire un truc du genre : bidule = (char*) malloc (longueur_de_bidule * sizeof(char));
C'est peut-être idiot, mais je trouve cela plus lisible.
-- Emmanuel The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
"C is a sharp tool"
Florent 'flure' C. wrote on 29/07/04 :
Moi par exemple, quand j'alloue un tableau de char, je préfère toujours
faire un truc du genre :
bidule = (char*) malloc (longueur_de_bidule * sizeof(char));
C'est peut-être idiot, mais je trouve cela plus lisible.
Moi par exemple, quand j'alloue un tableau de char, je préfère toujours faire un truc du genre : bidule = (char*) malloc (longueur_de_bidule * sizeof(char));
C'est peut-être idiot, mais je trouve cela plus lisible.
-- Emmanuel The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
"C is a sharp tool"
Marc Boyer
Florent 'flure' C. wrote:
Oui d'ailleurs, pourquoi s'acharner sur ce détail ? On sait bien que sizeof(char) vaut toujours 1, mais n'est-ce pas plus lisible ?
Plus lisible ?
Moi par exemple, quand j'alloue un tableau de char, je préfère toujours faire un truc du genre : bidule = (char*) malloc (longueur_de_bidule * sizeof(char));
Ainsi, si un jour bidule devenait un pointeur sur des choses qui ne sont pas des char (genre unicode 16 bits), ça continue à être juste. Mais * par sizeof(char), non, aucun intérêt.
C'est peut-être idiot, mais je trouve cela plus lisible.
Si tu es le seul lecteur de ton code, tu fais comme tu veux ;-)
Marc Boyer -- La contractualisation de la recherche, c'est me donner de l'argent pour faire ce que je ne sais pas faire, que je fais donc mal, pendant que ce que je sais faire, je le fais sans moyens...
Florent 'flure' C. wrote:
Oui d'ailleurs, pourquoi s'acharner sur ce détail ? On sait bien que
sizeof(char) vaut toujours 1, mais n'est-ce pas plus lisible ?
Plus lisible ?
Moi par exemple, quand j'alloue un tableau de char, je préfère toujours
faire un truc du genre :
bidule = (char*) malloc (longueur_de_bidule * sizeof(char));
Ainsi, si un jour bidule devenait un pointeur sur des
choses qui ne sont pas des char (genre unicode 16 bits),
ça continue à être juste.
Mais * par sizeof(char), non, aucun intérêt.
C'est peut-être idiot, mais je trouve cela plus lisible.
Si tu es le seul lecteur de ton code, tu fais comme tu veux ;-)
Marc Boyer
--
La contractualisation de la recherche, c'est me donner de l'argent pour
faire ce que je ne sais pas faire, que je fais donc mal, pendant que ce
que je sais faire, je le fais sans moyens...
Oui d'ailleurs, pourquoi s'acharner sur ce détail ? On sait bien que sizeof(char) vaut toujours 1, mais n'est-ce pas plus lisible ?
Plus lisible ?
Moi par exemple, quand j'alloue un tableau de char, je préfère toujours faire un truc du genre : bidule = (char*) malloc (longueur_de_bidule * sizeof(char));
Ainsi, si un jour bidule devenait un pointeur sur des choses qui ne sont pas des char (genre unicode 16 bits), ça continue à être juste. Mais * par sizeof(char), non, aucun intérêt.
C'est peut-être idiot, mais je trouve cela plus lisible.
Si tu es le seul lecteur de ton code, tu fais comme tu veux ;-)
Marc Boyer -- La contractualisation de la recherche, c'est me donner de l'argent pour faire ce que je ne sais pas faire, que je fais donc mal, pendant que ce que je sais faire, je le fais sans moyens...
Antoine Leca
En 57QNc.1115$, Jacques Ichane va escriure:
sizeof d'une chaîne de caractères est censé donner quoi ? La même chose que strlen ?
Cela n'a rien à voir avec la question initiale (qui calculait la taille du pointeur vers une chaîne), mais la réponse est le nombre de caractères de la chaîne, plus 1 pour le ' ' final. C'est la taille du tableau (de char) qui contient entièrement la dite chaîne.
C'est différent de strlen(), non seulement parce que cela compte le ' ' final, mais aussi parce que si tu utilises strlen() sur une chaîne avec des au milieu (genre "Jacques Ichane"), strlen va s'arrêter au premier , tandis que sizeof va tout prendre en compte.
[ Enfin, sauf quand il y a un bogue dans le compilateur... Et en l'occurence, ceci est un test classique, et il se trouve que c'est un piège où tombe/tombait les compilos... ]
Antoine
En 57QNc.1115$qn2.785@nntpserver.swip.net, Jacques Ichane va escriure:
sizeof d'une chaîne de caractères est censé donner quoi ? La même
chose que strlen ?
Cela n'a rien à voir avec la question initiale (qui calculait la taille du
pointeur vers une chaîne), mais la réponse est le nombre de caractères de la
chaîne, plus 1 pour le ' ' final. C'est la taille du tableau (de char) qui
contient entièrement la dite chaîne.
C'est différent de strlen(), non seulement parce que cela compte le ' '
final, mais aussi parce que si tu utilises strlen() sur une chaîne avec des
au milieu (genre "Jacques Ichane"), strlen va s'arrêter au premier ,
tandis que sizeof va tout prendre en compte.
[ Enfin, sauf quand il y a un bogue dans le compilateur... Et en
l'occurence, ceci est un test classique, et il se trouve que c'est un piège
où tombe/tombait les compilos... ]
sizeof d'une chaîne de caractères est censé donner quoi ? La même chose que strlen ?
Cela n'a rien à voir avec la question initiale (qui calculait la taille du pointeur vers une chaîne), mais la réponse est le nombre de caractères de la chaîne, plus 1 pour le ' ' final. C'est la taille du tableau (de char) qui contient entièrement la dite chaîne.
C'est différent de strlen(), non seulement parce que cela compte le ' ' final, mais aussi parce que si tu utilises strlen() sur une chaîne avec des au milieu (genre "Jacques Ichane"), strlen va s'arrêter au premier , tandis que sizeof va tout prendre en compte.
[ Enfin, sauf quand il y a un bogue dans le compilateur... Et en l'occurence, ceci est un test classique, et il se trouve que c'est un piège où tombe/tombait les compilos... ]
Antoine
Alexandre Bacquart
Florent 'flure' C. wrote:
Oui d'ailleurs, pourquoi s'acharner sur ce détail ? On sait bien que sizeof(char) vaut toujours 1, mais n'est-ce pas plus lisible ?
Moi par exemple, quand j'alloue un tableau de char, je préfère toujours faire un truc du genre : bidule = (char*) malloc (longueur_de_bidule * sizeof(char));
Et tu trouves ça plus lisible que :
bidule = malloc(longueur_de_bidule);
???
C'est peut-être idiot, mais je trouve cela plus lisible.
Ha bon :)
Tu sais pourtant très bien qu'un char est un byte et que malloc alloue N bytes. En quoi est-ce plus lisible de rajouter 12 caractères qui ne font qu'indiquer une règle immuable de manière explicite ? Ce n'est que pédagogique, c'est tout. Il y a plein règles implicites et elles sont justement là pour alléger le code et de ce fait améliorer sa libilité.
-- Tek
Florent 'flure' C. wrote:
Oui d'ailleurs, pourquoi s'acharner sur ce détail ? On sait bien que
sizeof(char) vaut toujours 1, mais n'est-ce pas plus lisible ?
Moi par exemple, quand j'alloue un tableau de char, je préfère toujours
faire un truc du genre :
bidule = (char*) malloc (longueur_de_bidule * sizeof(char));
Et tu trouves ça plus lisible que :
bidule = malloc(longueur_de_bidule);
???
C'est peut-être idiot, mais je trouve cela plus lisible.
Ha bon :)
Tu sais pourtant très bien qu'un char est un byte et que malloc alloue N
bytes. En quoi est-ce plus lisible de rajouter 12 caractères qui ne font
qu'indiquer une règle immuable de manière explicite ? Ce n'est que
pédagogique, c'est tout. Il y a plein règles implicites et elles sont
justement là pour alléger le code et de ce fait améliorer sa libilité.
Oui d'ailleurs, pourquoi s'acharner sur ce détail ? On sait bien que sizeof(char) vaut toujours 1, mais n'est-ce pas plus lisible ?
Moi par exemple, quand j'alloue un tableau de char, je préfère toujours faire un truc du genre : bidule = (char*) malloc (longueur_de_bidule * sizeof(char));
Et tu trouves ça plus lisible que :
bidule = malloc(longueur_de_bidule);
???
C'est peut-être idiot, mais je trouve cela plus lisible.
Ha bon :)
Tu sais pourtant très bien qu'un char est un byte et que malloc alloue N bytes. En quoi est-ce plus lisible de rajouter 12 caractères qui ne font qu'indiquer une règle immuable de manière explicite ? Ce n'est que pédagogique, c'est tout. Il y a plein règles implicites et elles sont justement là pour alléger le code et de ce fait améliorer sa libilité.
-- Tek
Jean-Marc Bourguet
Alexandre Bacquart writes:
Florent 'flure' C. wrote:
[...] je préfère toujours faire un truc du genre : bidule = (char*) malloc (longueur_de_bidule * sizeof(char));
Et tu trouves ça plus lisible que :
bidule = malloc(longueur_de_bidule);
???
C'est peut-être idiot, mais je trouve cela plus lisible.
Ha bon :)
Tu sais pourtant très bien qu'un char est un byte et que malloc alloue N bytes. En quoi est-ce plus lisible de rajouter 12 caractères qui ne font qu'indiquer une règle immuable de manière explicite ?
Il y a au moins une chose que son ecriture fait et pas la tienne, c'est la verification du type de bidule. Naturellement je prefererais encapsuler tout ca dans une macro du genre
-- Jean-Marc FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc Site de usenet-fr: http://www.usenet-fr.news.eu.org
Alexandre Bacquart <tek512@hotmail.com> writes:
Florent 'flure' C. wrote:
[...]
je préfère toujours faire un truc du genre :
bidule = (char*) malloc (longueur_de_bidule * sizeof(char));
Et tu trouves ça plus lisible que :
bidule = malloc(longueur_de_bidule);
???
C'est peut-être idiot, mais je trouve cela plus lisible.
Ha bon :)
Tu sais pourtant très bien qu'un char est un byte et que malloc alloue N
bytes. En quoi est-ce plus lisible de rajouter 12 caractères qui ne font
qu'indiquer une règle immuable de manière explicite ?
Il y a au moins une chose que son ecriture fait et pas la tienne,
c'est la verification du type de bidule. Naturellement je prefererais
encapsuler tout ca dans une macro du genre
[...] je préfère toujours faire un truc du genre : bidule = (char*) malloc (longueur_de_bidule * sizeof(char));
Et tu trouves ça plus lisible que :
bidule = malloc(longueur_de_bidule);
???
C'est peut-être idiot, mais je trouve cela plus lisible.
Ha bon :)
Tu sais pourtant très bien qu'un char est un byte et que malloc alloue N bytes. En quoi est-ce plus lisible de rajouter 12 caractères qui ne font qu'indiquer une règle immuable de manière explicite ?
Il y a au moins une chose que son ecriture fait et pas la tienne, c'est la verification du type de bidule. Naturellement je prefererais encapsuler tout ca dans une macro du genre
int main (int argc, char *argv[]){ int N = (sizeof (argv[1])/sizeof(char));
N= 4
Bravo, bonne réponse de Jean-Pierre Liégeois,
notre sympathique lecteur de la Drôme...
Beuh ? il est plus dans le Var, Jean-Pierre ?
-- _/°< coin--;
-- Yves Kuhry
James Kanze
Jean-Marc Bourguet writes:
|> Alexandre Bacquart writes:
|> > Florent 'flure' C. wrote: |> > > [...] |> > > je préfère toujours faire un truc du genre : |> > > bidule = (char*) malloc (longueur_de_bidule * sizeof(char));
|> > Et tu trouves ça plus lisible que :
|> > bidule = malloc(longueur_de_bidule);
|> > ???
|> > > C'est peut-être idiot, mais je trouve cela plus lisible.
|> > Ha bon :)
|> > Tu sais pourtant très bien qu'un char est un byte et que malloc |> > alloue N bytes. En quoi est-ce plus lisible de rajouter 12 |> > caractères qui ne font qu'indiquer une règle immuable de manière |> > explicite ?
|> Il y a au moins une chose que son ecriture fait et pas la tienne, |> c'est la verification du type de bidule.
Au contraire. Le cast explicit supprime la vérification du type. En général, en C, il ne faut jamais caster le résultat de malloc. Si tu as oublié l'include, le type de retour de malloc est int (implicit). Sans le cast, le compilateur râle ; avec, il prend un int, et le convertit en pointeur. (Le problème était assez visible avec les Intel 16 bits, modèle large. Avec le cast, en l'absence de l'include, le compilateur prenait le contenu de AX avec comme segment 0. Sans le cast, il y avait une erreur de compilation, qui nous indiquait qu'on avait oublié l'include.)
-- James Kanze 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
|> > Florent 'flure' C. wrote:
|> > > [...]
|> > > je préfère toujours faire un truc du genre :
|> > > bidule = (char*) malloc (longueur_de_bidule * sizeof(char));
|> > Et tu trouves ça plus lisible que :
|> > bidule = malloc(longueur_de_bidule);
|> > ???
|> > > C'est peut-être idiot, mais je trouve cela plus lisible.
|> > Ha bon :)
|> > Tu sais pourtant très bien qu'un char est un byte et que malloc
|> > alloue N bytes. En quoi est-ce plus lisible de rajouter 12
|> > caractères qui ne font qu'indiquer une règle immuable de manière
|> > explicite ?
|> Il y a au moins une chose que son ecriture fait et pas la tienne,
|> c'est la verification du type de bidule.
Au contraire. Le cast explicit supprime la vérification du type. En
général, en C, il ne faut jamais caster le résultat de malloc. Si tu as
oublié l'include, le type de retour de malloc est int (implicit). Sans
le cast, le compilateur râle ; avec, il prend un int, et le convertit en
pointeur. (Le problème était assez visible avec les Intel 16 bits,
modèle large. Avec le cast, en l'absence de l'include, le compilateur
prenait le contenu de AX avec comme segment 0. Sans le cast, il y avait
une erreur de compilation, qui nous indiquait qu'on avait oublié
l'include.)
--
James Kanze
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
|> > Florent 'flure' C. wrote: |> > > [...] |> > > je préfère toujours faire un truc du genre : |> > > bidule = (char*) malloc (longueur_de_bidule * sizeof(char));
|> > Et tu trouves ça plus lisible que :
|> > bidule = malloc(longueur_de_bidule);
|> > ???
|> > > C'est peut-être idiot, mais je trouve cela plus lisible.
|> > Ha bon :)
|> > Tu sais pourtant très bien qu'un char est un byte et que malloc |> > alloue N bytes. En quoi est-ce plus lisible de rajouter 12 |> > caractères qui ne font qu'indiquer une règle immuable de manière |> > explicite ?
|> Il y a au moins une chose que son ecriture fait et pas la tienne, |> c'est la verification du type de bidule.
Au contraire. Le cast explicit supprime la vérification du type. En général, en C, il ne faut jamais caster le résultat de malloc. Si tu as oublié l'include, le type de retour de malloc est int (implicit). Sans le cast, le compilateur râle ; avec, il prend un int, et le convertit en pointeur. (Le problème était assez visible avec les Intel 16 bits, modèle large. Avec le cast, en l'absence de l'include, le compilateur prenait le contenu de AX avec comme segment 0. Sans le cast, il y avait une erreur de compilation, qui nous indiquait qu'on avait oublié l'include.)
-- James Kanze 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
Jean-Marc Bourguet
James Kanze writes:
Jean-Marc Bourguet writes:
|> Alexandre Bacquart writes:
|> > Florent 'flure' C. wrote: |> > > [...] |> > > je préfère toujours faire un truc du genre : |> > > bidule = (char*) malloc (longueur_de_bidule * sizeof(char));
|> > Et tu trouves ça plus lisible que :
|> > bidule = malloc(longueur_de_bidule);
|> > ???
|> > > C'est peut-être idiot, mais je trouve cela plus lisible.
|> > Ha bon :)
|> > Tu sais pourtant très bien qu'un char est un byte et que malloc |> > alloue N bytes. En quoi est-ce plus lisible de rajouter 12 |> > caractères qui ne font qu'indiquer une règle immuable de manière |> > explicite ?
|> Il y a au moins une chose que son ecriture fait et pas la tienne, |> c'est la verification du type de bidule.
Au contraire. Le cast explicit supprime la vérification du type.
La quelle?
Sans cast explicite, on detecte l'erreur d'avoir un malloc declare implicitement.
Avec un cast explicite, on detecte l'erreur d'avoir modifie le type de la variable sans avoir modifie l'allocation (je rappelle que je conseillais une macro pour que le type du cast soit bien celui du sizeof).
Comme la premiere erreur peut arriver pour d'autres fonctions, je prefere utiliser quelque chose de plus general pour la detecter, une option du compilateur par exemple.
Il y a un autre moyen de detecter la seconde -- utiliser sizeof (*bidule) plutot que sizeof (type) -- mais il ne s'etend pas aux cas ou on passe le resultat de malloc (ou plus souvent de la fonction qui encapsule malloc) a une fonction plutot que de l'assigner a une variable.
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
|> > Florent 'flure' C. wrote:
|> > > [...]
|> > > je préfère toujours faire un truc du genre :
|> > > bidule = (char*) malloc (longueur_de_bidule * sizeof(char));
|> > Et tu trouves ça plus lisible que :
|> > bidule = malloc(longueur_de_bidule);
|> > ???
|> > > C'est peut-être idiot, mais je trouve cela plus lisible.
|> > Ha bon :)
|> > Tu sais pourtant très bien qu'un char est un byte et que malloc
|> > alloue N bytes. En quoi est-ce plus lisible de rajouter 12
|> > caractères qui ne font qu'indiquer une règle immuable de manière
|> > explicite ?
|> Il y a au moins une chose que son ecriture fait et pas la tienne,
|> c'est la verification du type de bidule.
Au contraire. Le cast explicit supprime la vérification du type.
La quelle?
Sans cast explicite, on detecte l'erreur d'avoir un malloc declare
implicitement.
Avec un cast explicite, on detecte l'erreur d'avoir modifie le type de
la variable sans avoir modifie l'allocation (je rappelle que je
conseillais une macro pour que le type du cast soit bien celui du
sizeof).
Comme la premiere erreur peut arriver pour d'autres fonctions, je
prefere utiliser quelque chose de plus general pour la detecter, une
option du compilateur par exemple.
Il y a un autre moyen de detecter la seconde -- utiliser sizeof
(*bidule) plutot que sizeof (type) -- mais il ne s'etend pas aux cas
ou on passe le resultat de malloc (ou plus souvent de la fonction qui
encapsule malloc) a une fonction plutot que de l'assigner a une
variable.
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
|> > Florent 'flure' C. wrote: |> > > [...] |> > > je préfère toujours faire un truc du genre : |> > > bidule = (char*) malloc (longueur_de_bidule * sizeof(char));
|> > Et tu trouves ça plus lisible que :
|> > bidule = malloc(longueur_de_bidule);
|> > ???
|> > > C'est peut-être idiot, mais je trouve cela plus lisible.
|> > Ha bon :)
|> > Tu sais pourtant très bien qu'un char est un byte et que malloc |> > alloue N bytes. En quoi est-ce plus lisible de rajouter 12 |> > caractères qui ne font qu'indiquer une règle immuable de manière |> > explicite ?
|> Il y a au moins une chose que son ecriture fait et pas la tienne, |> c'est la verification du type de bidule.
Au contraire. Le cast explicit supprime la vérification du type.
La quelle?
Sans cast explicite, on detecte l'erreur d'avoir un malloc declare implicitement.
Avec un cast explicite, on detecte l'erreur d'avoir modifie le type de la variable sans avoir modifie l'allocation (je rappelle que je conseillais une macro pour que le type du cast soit bien celui du sizeof).
Comme la premiere erreur peut arriver pour d'autres fonctions, je prefere utiliser quelque chose de plus general pour la detecter, une option du compilateur par exemple.
Il y a un autre moyen de detecter la seconde -- utiliser sizeof (*bidule) plutot que sizeof (type) -- mais il ne s'etend pas aux cas ou on passe le resultat de malloc (ou plus souvent de la fonction qui encapsule malloc) a une fonction plutot que de l'assigner a une variable.
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
