/* Topic des codeurs couche-tard [2] */

gnuuat · Le 13/11/2010, à 02:11

Exactement, bingo bongo \o/ .
Pour le this (2 réponses car j'ai interprété de deux manières ta remarque) : il était important de l'utiliser pour faire le segfault et je préfère l'utiliser dans les méthodes car cela permet de différencier les attributs des variables. Question de lisibilité.

std::endl : c'est vrai, ça ne m'était pas venu à l'esprit que ça puisse être inutile sur la sortie standart.

En tout cas, c'est excellent le mangling en C++ ^^ . Avant de le connaitre, je pensais que la structure contenait des pointeurs sur fonctions, mais que dalle !

nesthib · Le 13/11/2010, à 02:14

plop

grim7reaper · Le 13/11/2010, à 02:28

gnuuat a écrit :

il était important de l'utiliser pour faire le segfault

Tu en es sûr ?
Je ne vois pas pourquoi (chez moi ça plante sans), il me semble qu'il n'y a pas de différence entre les deux mais je peux me tromper car je ne suis pas encore au top niveau là dessus.

et je préfère l'utiliser dans les méthodes car cela permet de différencier les attributs des variables. Question de lisibilité.

Oui, c'est ce que je disais : question d'esthétique (et de conventions de codage) .

Dernière modification par grim7reaper (Le 13/11/2010, à 04:01)

compte supprimé · Le 13/11/2010, à 02:36

Bn;

Кຼزດ · Le 13/11/2010, à 04:00

Points.

samυncle · Le 13/11/2010, à 04:00

nesthib · Le 13/11/2010, à 04:13

cm-t · Le 13/11/2010, à 04:24

'Nuit;

Compteur du TdCCT · Le 13/11/2010, à 08:42

Scores totaux, depuis le début :

1) 1837    nesthib
2) 1756    samuncle
3) 1491    Pylade
4) 1109    Кຼزດ
5) 915    cm-t
6) 779+5  grim7reaper /* ./viewtopic.php?pid=3486252#p3486252 */
7) 682    \\Ouranos//
8) 680    Р☢w ! ✰ :mad: ✰ (эй !)
9) 636    helly
10) 385    Lagierl
11) 354    gnuuat
12) 267    tshirtman
13) 167    Kanor
14) 166    Askelon
15) 122    nathéo
16) 121    ǤƦƯƝƬ
17) 93    petifrancais
18) 78    edge_one
19) 70    gulp
20) 66    pierguiard
21) 59    kamui57
22) 53    The Uploader
23) 37    ilagas
24) 30    keny
25) 27    Le Rouge
26) 25    GentooUser
27) 24    ไ୦บเઢ'
28) 20    Morgiver
28) 20    CROWD
30) 19    xapantu
31) 18    Ph3nix_
32) 15    timsy
33) 14    kouskous
34) 12    stratoboy
34) 12    sailing
36) 11    alexises
36) 11    Crocoii
38) 10    Toineo
38) 10    NutMotion
38) 10    pseudovingtcinqcaracteres
38) 10    pfriedZ
42) 8    Mornagest
43) 7    Vista
44) 6    Zeibux
44) 6    ubuntlin
44) 6    asma.geek
47) 5    tendances-tdct
48) 4    danychou56
48) 4    Neros
48) 4    Biaise
48) 4    totoflute
48) 4    pinballyoda ㋛
53) 2    SoJaS
53) 2    ceric
55) 1    geenux

chart?chs=675x280&cht=p3&chco=d80020,d88000,ffd840,20d820,2080ff,101080,a020d8&chf=bg,s,fbf9f4&chl=00h%20-%2000h59|01h%20-%2001h59|03h%20-%2003h59|07h%20-%2007h59|16h%20-%2016h59|17h%20-%2017h59|18h%20-%2018h59|19h%20-%2019h59|21h%20-%2021h59|22h%20-%2022h59&chd=t:1,6,4,2,8,10,1,1,1,4&chp=1.6&chtt=R%C3%A9partition%20des%20posts&chts=606060,16

Compteur du TdCCT · Le 13/11/2010, à 08:42

Scores de la période en cours :

1) 116    nesthib
2) 101    grim7reaper
3) 96    samuncle
4) 90    nathéo
5) 86    Кຼزດ
6) 69    cm-t
7) 65    gnuuat
8) 56    Pylade
9) 36    Askelon
10) 28    \\Ouranos//
11) 25    Lagierl
12) 11    tshirtman
13) 4    Р☢w ! ✰ :mad: ✰ (эй !)
14) 3    Kanor
14) 3    The Uploader
16) 1    xapantu

Elzen · Le 13/11/2010, à 16:42

Hmm, à destination de ceux qui me disaient que les parenthèses après sizeof n'étaient pas requises :

ListMixt *createTrieMixt(int row) {
    ListMixt *lm;
    
    lm = malloc(sizeof ListMixt);
    
    /* (…) */
    
    return lm;
}

seth@fadreils: tp1$  make all
(…)
gcc -Wall -c triMixt.c
triMixt.c: In function 'createTrieMixt':
triMixt.c:8: error: expected expression before 'ListMixt'
make: *** [triMixt] Erreur 1
seth@fadreils: tp1$

Tandis que

ListMixt *createTrieMixt(int row) {
    ListMixt *lm;
    
    lm = malloc(sizeof(ListMixt));
    
    /* (…) */
    
    return lm;
}

seth@fadreils: tp1$  make all
(…)
gcc -Wall -pedantic -c triMixt.c
rm *.o    
seth@fadreils: tp1$

Entre vous et gcc, j'suis désolé, mais je crois quand même plus gcc

Pylades · Le 13/11/2010, à 16:59

Nan, mais là tu utilise sizeof sur un type. Là, ouais, t'as besoin de faire une sorte de cast, c'est moche. Mais il y a beaucoup plus malin, c'est d'utiliser sizeof sur une variable ou une expression ; là sizeof se comporte comme n'importe quel autre opérateur. C'est plus propre et plus logique.

lm = malloc(sizeof *lm);

gnuuat · Le 13/11/2010, à 17:22

Après, comme on l'a déjà dit, c'est une histoire de préférences personnelles, si tu préfères avoir toujours le même comportement (parenthèses au sizeof, en utilisant des types ou des noms de variables), ou si tu préfères t'adapter au cas, c'est à toi de voir.

Personnellement, j'utilise les parenthèses pour rester cohérent avec ma norme, mais je n'utilise que des noms de variables dans le sizeof...

@[Pil]grim(7r)[fath](eap)er : euh du coup j'ai un doute, je regarderais ça de plus près pour l'obligation du this quant à la provocation du segfault.

Elzen · Le 13/11/2010, à 17:43

Bah pour moi, la version type et parenthèses est franchement plus lisible :

ListMixt *lm = malloc(sizeof(ListMixt)); veut dire « lm étant de type ListMixt, on a besoin de créer en mémoire l'espace requis pour une structure de ce type, et une fois cet espace alloué, on référence son emplacement dans la mémoire ».
Pour moi, c'est ce qui correspond plus à ce qui se passe vraiment.

La version « sizeof *lm » a l'air plus déconnectée de la réalité : on demande la taille d'un truc qui n'existe pas encore, puisqu'on fait précisément cet appel dans la fonction censée réserver l'espace pour sa création.
Et puis, ça me fait plus penser aux langages comme JavaScript, PHP ou Pyhton, où une variable peut recevoir à peu près n'importe quoi, et passer par exemple d'un entier à un tableau comme ça. C étant à mon sens plutôt un langage fortement typé, ça me paraît plus logique d'utiliser le type.

Enfin, chacun son point de vue.

Pylades · Le 13/11/2010, à 17:59

Mais pas du tout ! Avec lm = malloc(sizeof (ListMixt));, tu alloues un espace à un pointeur alors qu'il n'est pas certain que ça soit l'espace utilisé par son type. Avec lm = malloc(sizeof *lm);, tu en es certain, c'est bien l'espace utilisé par son type qui sera alloué. C'est plus propre, et justement plus typé : tu es sûr que l'opération effectuée est correcte en fonction du type du pointeur, qui lui existe déjà, et pointe sur un espace de taille bien définie, cet espace étant connu par sizeof *lm, c'est à dire la taille de l'objet pointé par lm.
Et puis ça évite de modifier le code un peu partout — voire de se retrouver avec des bugs difficilement compréhensibles — au cas où tu choisirais de changer ListMixt pour autre chose (même si c'est peu probable dans ton cas)…

Dernière modification par Pylade (Le 13/11/2010, à 18:13)

grim7reaper · Le 13/11/2010, à 18:04

gnuuat a écrit :

@[Pil]grim(7r)[fath](eap)er : euh du coup j'ai un doute, je regarderais ça de plus près pour l'obligation du this quant à la provocation du segfault.

Je ne suis pas sûr non plus, mais il me semble bien que le this (dans ce cas) ne change rien.

@ArkSeth : lisible, pas lisible : chacun vois midi à sa porte.

L'avantage d'utiliser notre méthode (à Pylade et moi) c'est que si un jour tu changes de type tu n'as qu'une modification à faire au lieu de deux dans ton cas. En plus, si tu oublies la seconde modif ça va bien compiler et ça ne planteras peut-être même pas, mais ton code sera faux.
Et puis c'est pas forcément déconnecté de la réalité, question de lecture. Moi quand je vois ça je lis : je déclare un pointeur de type T et je réserve une zone mémoire de la taille de T (*T donc contenu du pointeur donc T => le type pointé). Ça me semble logique et je ne demande pas la taille d'un truc qui n'existe pas vu que mon type existe et est défini.
Sinon, je ne vois pas ce que vient faire là l'allusion à Python, PHP & cie.

Je vois pas le rapport avec le reste

Mais bon, les 2 syntaxes sont valides donc il n'y en a pas une meilleure que l'autre (juste une qui est plus sûre).

Édit : encore grillé par Pylade (qui a mieux expliqué le coup du type que moi )

Dernière modification par grim7reaper (Le 13/11/2010, à 18:06)

Elzen · Le 13/11/2010, à 18:26

Certes, mais d'un autre côté, si tu changes la variable de type, c'est quand même largement plus propre de réécrire entièrement son code d'allocation et d'initialisation. Changer juste le type dans la déclaration et ne changer strictement rien au code qu'il y a en dessous, c'est juste atroce
(D'ailleurs, c'est encore mieux, pour la sécurité, de changer le nom de la variable avec, comme ça tu es davantage sûr d'avoir une erreur de compil' si tu oublies de corriger un des anciens emplois).

L'allusion aux autres langages vient du fait que dans mon esprit, il y en a de deux sortes différentes : ceux qui sont fortement typés, et donc où tu manipules des variables qui sont des représentants d'un type prédéfini, et ceux qui ne le sont pas, et où une variable est juste un nom qui peut pointer sur n'importe quoi.

PHP, Python et JavaScript sont dans le second cas : tu peux réaffecter indéfiniment une variable en changeant son type à chaque fois, d'où, quand tu as besoin de savoir exactement ce qu'il y a dedans (pour voir la taille que ça prend, par exemple), la nécessité d'utiliser le nom de la variable elle-même, parce que c'est le seul moyen de remonter à son type.

A contrario, dans les langages du premier cas, comme Java, il y a une identité clairement définie entre la variable et son type. Si tu déclares au début z comme étant de type Z, tu es sûr et certain que z sera de type Z à chaque fois que tu l'utiliseras plus tard (même si tu peux éventuellement le caster en cas de type dérivé, mais c'est un autre problème).
Par conséquent, pour chaque opération portant sur le type Z et non pas sur la variable z particulière, il est possible et beaucoup plus propre d'utiliser directement ce type plutôt que la variable qui en est une représentante.

Et C étant assez strict sur l'utilisation des variables, ne permettant entre autres pas de la changer de type en cours de route, il est pour moi dans le premier cas, et donc il m'apparaît comme plus propre d'utiliser le type quand ce que l'on fait est une opération sur ce type, comme c'est le cas pour une allocation.
En gros, je vois le var = malloc comme étant l'opération « on crée un espace mémoire de tel type, et on donne à cet espace mémoire particulier le nom var », et non pas « on crée une variable var, et on réserve en mémoire l'espace requis pour son type actuel ».

Après, ce n'est que mon avis… et ça vient peut-être aussi de l'habitude d'utiliser des langages objets, voire orientés objets, dans lesquels le nom du type apparaît souvent explicitement dans le nom du constructeur ^^

Dernière modification par ArkSeth (Le 13/11/2010, à 18:29)

Pylades · Le 13/11/2010, à 18:45

ArkSeth a écrit :

Certes, mais d'un autre côté, si tu changes la variable de type, c'est quand même largement plus propre de réécrire entièrement son code d'allocation et d'initialisation. Changer juste le type dans la déclaration et ne changer strictement rien au code qu'il y a en dessous, c'est juste atroce

Et dans le cas d'un changement de long vers int ?

ArkSeth a écrit :

(D'ailleurs, c'est encore mieux, pour la sécurité, de changer le nom de la variable avec, comme ça tu es davantage sûr d'avoir une erreur de compil' si tu oublies de corriger un des anciens emplois).
[…]

Dans ce cas notre méthode est plus sûre. Et puis il y a sed -i, c'est très pratique.

ArkSeth a écrit :

[…]
Par conséquent, pour chaque opération portant sur le type Z et non pas sur la variable z particulière, il est possible et beaucoup plus propre d'utiliser directement ce type plutôt que la variable qui en est une représentante.

Pas d'accord.

ArkSeth a écrit :

Et C étant assez strict sur l'utilisation des variables, ne permettant entre autres pas de la changer de type en cours de route, il est pour moi dans le premier cas, et donc il m'apparaît comme plus propre d'utiliser le type quand ce que l'on fait est une opération sur ce type, comme c'est le cas pour une allocation.

Pas d'accord.
En fait, une variable a un type. C'est une de ses propriétés. Quand tu as besoin de son type, ou d'une des propriétés de son type, comme l'espace mémoire occupé, tu peux les récupérer avec le nom de la variable. Et c'est une bonne chose.
Alors que lorsque tu donnes le nom du type, tu perds le lien avec ta variable, tu perds en cohésion et ce n'est pas beau, je trouve. Car dans le cas qui nous occupe, tu ne bosses pas sur le type, mais bien sur la variable !

ArkSeth a écrit :

En gros, je vois le var = malloc comme étant l'opération « on crée un espace mémoire de tel type, et on donne à cet espace mémoire particulier le nom var ».
Après, ce n'est que mon avis… et ça vient peut-être aussi de l'habitude d'utiliser des langages objets, voire orientés objets, dans lesquels le nom du type apparaît souvent explicitement dans le nom du constructeur ^^

Attention, là on n'est pas dans un constructeur, mais dans une allocation. Dans une allocation, tu alloues un espace à un pointeur, donc à une variable. Dans ton constructeur, rien ne t'empêche de faire apparaître le nom du type, et c'est même hautement recommandé ! ^^

grim7reaper · Le 13/11/2010, à 18:46

ArkSeth a écrit :

[…]
Changer juste le type dans la déclaration et ne changer strictement rien au code qu'il y a en dessous, c'est juste atroce

Si, par exemple, j'ai un tableau d'int et que je le change en float il n'y a rien à modifier dans le code du dessous (test de validité, etc), je ne vois rien d'atroce O_o".
Le prototype de la fonction va peut-être changer, mais le code d'allocation non (ou très peu selon les cas et s'il est bien codé).

(D'ailleurs, c'est encore mieux, pour la sécurité, de changer le nom de la variable avec, comme ça tu es davantage sûr d'avoir une erreur de compil' si tu oublies de corriger un des anciens emplois).

Le typage statique fais déjà pas mal de retour d'erreur à ce niveau-là. Mais bon, pourquoi pas…

[…]
Et C étant assez strict sur l'utilisation des variables, ne permettant entre autres pas de la changer de type en cours de route, il est pour moi dans le premier cas, et donc il m'apparaît comme plus propre d'utiliser le type quand ce que l'on fait est une opération sur ce type, comme c'est le cas pour une allocation.
[…]

Je suis d'accord, sauf que jusqu'à preuve du contraire, l'opération tu la fais bien sur ta variable et non pas sur ton type (tu ne modifie pas le type où un truc du genre, c'est bien la variable la première concernée dans cette histoire).

Dernière modification par grim7reaper (Le 13/11/2010, à 18:47)

Pylades · Le 13/11/2010, à 18:49

Encore grillé pour dire à peu près la même chose. ^^

grim7reaper · Le 13/11/2010, à 18:52

Ouais, je peux prendre ma retraite.
La relève est assurée ^_^

Pylades · Le 13/11/2010, à 18:54

Roh…
J'ai encore besoin de tes pavés !

Elzen · Le 13/11/2010, à 19:02

Pylade a écrit :

Attention, là on n'est pas dans un constructeur, mais dans une allocation. Dans une allocation, tu alloues un espace à un pointeur, donc à une variable. Dans ton constructeur, rien ne t'empêche de faire apparaître le nom du type, et c'est même hautement recommandé ! ^^

Le constructeur étant juste la fonction qui appelle l'allocation et provoque l'initialisation…

Pylade a écrit :

Et dans le cas d'un changement de long vers int ?

Bonne question. Je crois que je n'ai jamais rencontré de cas où on tel changement s'imposait… mais il faut dire que mes besoins en types de base sont généralement assez limités.

Pylade a écrit :

Dans ce cas notre méthode est plus sûre.

Dans le cas où tu changes le nom de la variable, les deux méthodes se vallent puisque tu devras réécrire la ligne de toute façon.
(Et faire un search&replace (par sed ou par quoi que ce soit d'autre) sur un fichier de code de taille conséquente reste relativement dangereux)

Pylade a écrit :

En fait, une variable a un type. C'est une de ses propriétés. Quand tu as besoin de son type, ou d'une des propriétés de son type, comme l'espace mémoire occupé, tu peux les récupérer avec le nom de la variable. Et c'est une bonne chose.
Alors que lorsque tu donnes le nom du type, tu perds le lien avec ta variable, tu perds en cohésion et ce n'est pas beau, je trouve. Car dans le cas qui nous occupe, tu ne bosses pas sur le type, mais bien sur la variable !

C'est précisément là le nœud du problème : soit tu considères que le type est une propriété d'une variable, auquel cas tous tes arguments sont parfaitement valables et difficilement réfutables, soit tu considères qu'une variable est une représentante d'un type (façon allégorie de la caverne), et ce sont les miens qui le sont.
Le problème de l'œuf et de la poule, quoi.

Et en ce qui me concerne, j'applique ma vision des choses et mon raisonnement à tous les langages pour lesquels la propriété "type" de la variable est en readonly, et la tienne à tous ceux pour lesquels elle est en read-write. Ç't'un moyen de trancher comme un autre ^^

(Et pour grim7reaper, je maintiens que dans la vision « variable comme représentante d'un type », l'allocation est une opération portant sur le type et pas sur la variable : tu crées un espace mémoire requis pour utiliser un représentant de ce type, et ensuite tu références cet espace mémoire comme étant désigné par le nom de la variable.
Dans la caverne de Platon, le type étant l'objet lui-même et la variable son ombre sur le mur, la place que prend une ombre sur le mur dépend de l'objet qui la projette et pas du nom que tu lui as donné).

(Et on trolle, on trolle, et avec tout ça j'ai quasiment pas avancé sur le code)

grim7reaper · Le 13/11/2010, à 19:12

Pylade a écrit :

Roh…
J'ai encore besoin de tes pavés !

Ouais, jpeux encore être utile dans ce domaine là ^^.

ArkSeth a écrit :

(Et pour grim7reaper, je maintiens que dans la vision « variable comme représentante d'un type », l'allocation est une opération portant sur le type et pas sur la variable : tu crées un espace mémoire requis pour utiliser un représentant de ce type, et ensuite tu références cet espace mémoire comme étant désigné par le nom de la variable.
Dans la caverne de Platon, le type étant l'objet lui-même et la variable son ombre sur le mur, la place que prend une ombre sur le mur dépend de l'objet qui la projette et pas du nom que tu lui as donné).

Dans ta vision des choses oui, peut-être (j'ai du mal à adhérer à ta vision ^^).

Par contre la phras en gras est fausse. Le nom désigne le pointeur et pas l'espace mémoire : je peux tout à fait faire des choses avec mon pointeur sans modifier ma zone mémoire (et inversement).

Elzen · Le 13/11/2010, à 19:28

C'est vrai que j'ai un peu maladroitement raccourcis.

Je voulais dire que tu réserves l'espace mémoire requis pour un représentant de ce type, et qu'ensuite seulement tu fais en sorte que le pointeur (que tu avais préalablement créé et alloué) pointe sur cet espace.
Et l'espace en question ne dépend que du type, indépendamment du nombre de pointeurs qui pointent dessus, qui ne sont que des moyens d'accéder au machin et pas le machin lui-même.
Ce qui confirme ce que je disais plus tôt, d'ailleurs :

grim7reaper a écrit :

Ça me semble logique et je ne demande pas la taille d'un truc qui n'existe pas vu que mon type existe et est défini.

le pointeur existe bien, le type existe bien, mais le truc pointé par ce pointeur n'existe pas encore (à moins que le pointeur n'ait déjà été utilisé précédemment).
Donc quand tu fais sizeof(ListMixt), tu demandes la taille d'un truc qui existe, quand tu fais sizeof lm aussi, mais quand tu fais sizeof *lm, tu demandes la taille d'un truc qui n'existe pas encore

Après, j'veux pas vous convaincre, hein. D'autant que comme je l'ai dit, dans certains cas, je préfère votre vision des choses. C'est juste que pour le C, c'est l'autre qui me paraît plus adaptée.

Dernière modification par ArkSeth (Le 13/11/2010, à 19:30)

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1276 Le 13/11/2010, à 02:11

Re : /* Topic des codeurs couche-tard [2] */

#1277 Le 13/11/2010, à 02:14

Re : /* Topic des codeurs couche-tard [2] */

#1278 Le 13/11/2010, à 02:28

Re : /* Topic des codeurs couche-tard [2] */

#1279 Le 13/11/2010, à 02:36

Re : /* Topic des codeurs couche-tard [2] */

#1280 Le 13/11/2010, à 04:00

Re : /* Topic des codeurs couche-tard [2] */

#1281 Le 13/11/2010, à 04:00

Re : /* Topic des codeurs couche-tard [2] */

#1282 Le 13/11/2010, à 04:13

Re : /* Topic des codeurs couche-tard [2] */

#1283 Le 13/11/2010, à 04:24

Re : /* Topic des codeurs couche-tard [2] */

#1284 Le 13/11/2010, à 08:42

Re : /* Topic des codeurs couche-tard [2] */

#1285 Le 13/11/2010, à 08:42

Re : /* Topic des codeurs couche-tard [2] */

#1286 Le 13/11/2010, à 16:42

Re : /* Topic des codeurs couche-tard [2] */

#1287 Le 13/11/2010, à 16:59

Re : /* Topic des codeurs couche-tard [2] */

#1288 Le 13/11/2010, à 17:22

Re : /* Topic des codeurs couche-tard [2] */

#1289 Le 13/11/2010, à 17:43

Re : /* Topic des codeurs couche-tard [2] */

#1290 Le 13/11/2010, à 17:59

Re : /* Topic des codeurs couche-tard [2] */

#1291 Le 13/11/2010, à 18:04

Re : /* Topic des codeurs couche-tard [2] */

#1292 Le 13/11/2010, à 18:26

Re : /* Topic des codeurs couche-tard [2] */

#1293 Le 13/11/2010, à 18:45

Re : /* Topic des codeurs couche-tard [2] */

#1294 Le 13/11/2010, à 18:46

Re : /* Topic des codeurs couche-tard [2] */

#1295 Le 13/11/2010, à 18:49

Re : /* Topic des codeurs couche-tard [2] */

#1296 Le 13/11/2010, à 18:52

Re : /* Topic des codeurs couche-tard [2] */

#1297 Le 13/11/2010, à 18:54

Re : /* Topic des codeurs couche-tard [2] */

#1298 Le 13/11/2010, à 19:02

Re : /* Topic des codeurs couche-tard [2] */

#1299 Le 13/11/2010, à 19:12

Re : /* Topic des codeurs couche-tard [2] */

#1300 Le 13/11/2010, à 19:28

Re : /* Topic des codeurs couche-tard [2] */

Pied de page des forums