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

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

ArkSeth a écrit :

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…
[…]

Mais ce n'est pas la même chose !

ArkSeth a écrit :

[…]
(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)

Ben dans le cas que tu semblait décrire… normalement pas de problème. Mais c'est sûr que quand je le fais, je me relie bien avant. (Et puis avec un logiciel de gestion de versions, t'as moyen de récupérer un correct dans le cas (très peu probable) où tu aurais tout cassé.

Bon sinon, évidemment, avec ton approche on a deux raisonnements incompatibles. Mais du coup, je pense que ce n'est peut-être pas pour toi, le C. Voir une variable comme projection d'un type, ce n'est pas très C, comme approche. Ça fait plus penser à Python ou un de ses cousins…

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

ArkSeth a écrit :

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

Ouais, c'est vraiment une question de lecture.
À force de lire du C, je dois pas le lire de la même manière que toi (jdois faire des raccourcis de manière inconsciente) .

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.

Ta vision des choses n'est pas fausse c'est un fait.
En revanche, le fait qu'elle soit plus adapté au C me semble bien moins sûr…

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

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

Pylade a écrit :

Ça fait plus penser à Python ou un de ses cousins…

Justement, moi c'est le contraire
Pour moi, quand tu déclares une variable comme étant d'un certain type avant de t'en servir, tu demandes un représentant de ce type et tu ne fais que lui donner un nom pour le retrouver, tandis que quand tu déclares une variable « en blanc » et que tu lui mets ce que tu veux dedans, c'est précisément comme ça que tu considères le type contenu comme une propriété de la variable.

(Et cherche pas à me dire que le C n'est pas pour moi précisément au moment où ça commence à pas mal me plaire Edit : et j'ajoute que si tu commences à me sortir qu'un truc n'est « pas pour moi » juste parce que nous n'avons pas la même sensibilité à le percevoir, tu baisses cruellement dans mon estime )

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

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

ArkSeth a écrit :

Pylade a écrit :
Ça fait plus penser à Python ou un de ses cousins…
Justement, moi c'est le contraire
Pour moi, quand tu déclares une variable comme étant d'un certain type avant de t'en servir, tu demandes un représentant de ce type et tu ne fais que lui donner un nom pour le retrouver, tandis que quand tu déclares une variable « en blanc » et que tu lui mets ce que tu veux dedans, c'est précisément comme ça que tu considères le type contenu comme une propriété de la variable.

Hum… On déclare une variable ; on instancie une classe. Je n'y peux rien.

ArkSeth a écrit :

(Et cherche pas à me dire que le C n'est pas pour moi précisément au moment où ça commence à pas mal me plaire Edit : et j'ajoute que si tu commences à me sortir qu'un truc n'est « pas pour moi » juste parce que nous n'avons pas la même sensibilité à le percevoir, tu baisses cruellement dans mon estime )

C'est juste que ta façon de voir les choses est assez peu commune, en C…

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

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

Pylade a écrit :

C'est juste que ta façon de voir les choses est assez peu commune, en C…

La façon de voir « c'est mieux sous licence libre » est assez peu commune en musique. Les artistes de Dogmazic ou Jamendo auraient mieux fait de faire autre chose ?

(Sinon, instancier une classe, c'est faire appel au constructeur. Comme tu viens de le dire, ce n'est pas la même chose L'instanciation et la déclaration sont deux étapes des opérations quelle que soit ta manière de voir les choses, c'est juste qu'en POO, la différence de vision se traduit par le fait de voir d'abord la variable qui référence l'instance d'une classe, ou l'instance d'une classe qui est référencée par la variable).

(Et puis si j'en juge par le fait que ma manière de voir les choses amène naturellement à sizeof(ListMixt), tandis que la tienne amène naturellement à sizeof *lm, et que les deux versions sont correctes, je pense pouvoir en déduire sans me planter que la mienne n'est pas si rare que ça et que les deux sont reconnues )

grim7reaper a écrit :

À force de lire du C, je dois pas le lire de la même manière que toi (jdois faire des raccourcis de manière inconsciente) .

Ça doit être ça aussi ^^
(Moi j'applique bêtement et logiquement ce que j'ai apprit : « *lm » désigne « ce qui est pointé par lm », et donc quand lm n'est pas encore initialisé ou est initialisé à NULL, « *lm » désigne « rien de précis », et donc « sizeof *lm » désigne « la taille de ce qui est pointé par lm », soit « la taille de rien de précis », donc dans le meilleur des cas, 0 )

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

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

ArkSeth a écrit :

[…] « *lm » désigne « ce qui est pointé par lm »[…]

Pas obligatoirement, c'est une question de contexte.

T *lm      => pointeur sur un objet de type T
*lm        => contenu de la zone mémoire pointé
sizeof *lm => taille du type pointé par lm

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

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

J'ai bien compris ^^

Mais tout de même, si les deux premiers cas me paraissent justifiés (encore qu'intuitivement, j'aurais peut-être plus marqué « T* lm » que « T *lm »… à voir), je trouve le fait de rajouter un troisième contexte pour l'utilisation de sizeof moins évidente.
D'autant qu'on peut imaginer des cas (probablement tarabiscotés, mais bon, pas pire que vos changements de type sans changement de corps de code ) où les deux utilisations « *lm » et « sizeof *lm » seraient appelées dans la même opération, ce qui serait un peu bizarre.

Enfin bref, on ne va pas passer la nuit là-dessus, l'important est que les deux façons de voir sont justifiées et que quoique difficilement compatibles, elles sont équivalentes ^^

Tiens, par contre, j'ai un doute : si j'ai un char* appelé w, quand je demande « w+X », ça me donne un pointeur sur la Xième lettre, ou bien la Xième lettre elle-même ? (Le premier me paraîtrait plus logique, mais je me souviens vaguement avoir déjà entendu dire que w+X et w[X] étaient équivalents, ce qui impliquerait donc que c'est l'autre )

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

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

ArkSeth a écrit :

Mais tout de même, si les deux premiers cas me paraissent justifiés (encore qu'intuitivement, j'aurais peut-être plus marqué « T* lm » que « T *lm »… à voir)

Moi aussi, mais là c'était pour insister.

pas pire que vos changements de type sans changement de corps de code

Tu es contre la généricité ?

Tiens, par contre, j'ai un doute : si j'ai un char* appelé w, quand je demande « w+X », ça me donne un pointeur sur la Xième lettre, ou bien la Xième lettre elle-même ? (Le premier me paraîtrait plus logique, mais je me souviens vaguement avoir déjà entendu dire que w+X et w[X] étaient équivalents, ce qui impliquerait donc que c'est l'autre )

Réponse 1, un pointeur.
L'équivalent de w[X] c'est *(w+X)

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

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

Bon, ça va, ma logique n'est pas trop maladaptée au C, alors

J'avais juste dû louper la moitié de la phrase en cours ce jour-là… faut dire que ça date de plusieurs années et que faire deux choses à la fois, ça peut parfois te faire louper quelques informations.

Pylades · Le 13/11/2010, à 20:56

ArkSeth a écrit :

Pylade a écrit :
C'est juste que ta façon de voir les choses est assez peu commune, en C…
La façon de voir « c'est mieux sous licence libre » est assez peu commune en musique. Les artistes de Dogmazic ou Jamendo auraient mieux fait de faire autre chose ?
[…]

T'es au courant que c'est spécieux, comme argument ?

ArkSeth a écrit :

[…]
(Et puis si j'en juge par le fait que ma manière de voir les choses amène naturellement à sizeof(ListMixt), tandis que la tienne amène naturellement à sizeof *lm, et que les deux versions sont correctes, je pense pouvoir en déduire sans me planter que la mienne n'est pas si rare que ça et que les deux sont reconnues )

Pas tout à fait. Si sizeof (Type) est correct, c'est pour lorsque l'on bosse sur un type.

ArkSeth a écrit :

(Moi j'applique bêtement et logiquement ce que j'ai apprit : « *lm » désigne « ce qui est pointé par lm », et donc quand lm n'est pas encore initialisé ou est initialisé à NULL, « *lm » désigne « rien de précis », et donc « sizeof *lm » désigne « la taille de ce qui est pointé par lm », soit « la taille de rien de précis », donc dans le meilleur des cas, 0 )

Non, dans ce cas là, c'est en fonction du contexte. Ça peut permettre de récupérer la taille de l'objet pointé par lm, ou envoyer un SIGSEGV s'il y a déférencement. Mais ça n'est pas « rien de précis ».

ArkSeth a écrit :

[…] (encore qu'intuitivement, j'aurais peut-être plus marqué « T* lm » que « T *lm »… à voir) […]

Là on se rejoint !

Elzen · Le 13/11/2010, à 21:03

Pylade a écrit :

Non, dans ce cas là, c'est en fonction du contexte. Ça peut permettre de récupérer la taille de l'objet pointé par lm, ou envoyer un SIGSEGV s'il y a déférencement. Mais ça n'est pas « rien de précis ».

Si le pointeur vaut null, y a pas d'objet pointé, donc la taille de l'objet pointé, c'est 0
(et si le pointeur n'est pas initialisé, ça dépend de ce qu'il y avait avant à cet endroit-là de la mémoire, d'où mon « rien de précis »)

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

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

ArkSeth a écrit :

Si le pointeur vaut null, y a pas d'objet pointé, donc la taille de l'objet pointé, c'est 0

*PAN*

ArkSeth a écrit :

(et si le pointeur n'est pas initialisé, ça dépend de ce qu'il y avait avant à cet endroit-là de la mémoire, d'où mon « rien de précis »)

*PAN*

grim7reaper · Le 13/11/2010, à 21:27

Tu nous as habitué à mieux niveau argumentation

Pylades · Le 13/11/2010, à 21:36

Non, mais à un moment, il faut savoir tuer le troll.

nathéo · Le 13/11/2010, à 23:10

char points = 10;

Elzen · Le 13/11/2010, à 23:31

Pylade a écrit :

Non, mais à un moment, il faut savoir tuer le troll.

Me tirer dessus n'abrégera pas la vie de cette pauvre petite bête

Ceci dit, je veux bien que tu m'expliques ce qu'il y avait de faux dans les deux assertions ayant provoqué tes tirs : quand le pointeur est initialisé à NULL, il ne pointe en pratique sur rien, non ? Donc même si la taille de l'objet sur lequel il pointe en théorie est toujours la même (à savoir sizeof(type), ou sizeof *ptr puisque sizeof prend la taille théorique), la taille de l'objet sur lequel il pointe en pratique est la taille de rien, donc 0.
Dans l'autre cas, quand une variable n'a pas été initialisée, son contenu réel n'est ce me semble pas défini, et contient donc un tas de bits laissés à 0 ou à 1 selon l'état dans lequel se trouvait cette zone avant qu'on décide de la réutiliser, et donc dans l'hypothèse où ce tas de bits indéfinis réussirait à former une adresse mémoire, il n'y aurait aucune assurance que cette adresse mémoire soit réellement allouée au type qu'on attendait, donc ça ne pointerait en pratique sur rien de précis.

J'admets volontiers que je te taquine un peu en parlant de la pratique alors que sizeof est prévu pour fonctionner avec la théorie (et j'veux même bien en présenter mes excuses si vraiment mon point de vue te fait faire des cauchemars ), mais franchement, si ce raisonnement est erroné, j'aimerais bien savoir en quoi.

compte supprimé · Le 14/11/2010, à 00:01

Crime +1 !

Pylades · Le 14/11/2010, à 00:10

nathéo a écrit :

char points = 10;

Tu ne va pas aller bien loin, comme ça.

@ArkSeth : si tu pointeur vaut NULL ou un truc bidon (pas initialisé), il n'empêche qu'il est tout de même typé, et qu'il pointe sur un objet particulier (un struct option, par exemple ), dont tu peux récupérer la taille par l'opérateur sizeof. Ça, tu ne peux pas le changer.
Après il est clair que si tu défères tu va avoir des problèmes, (SIGSEGV…), mais ça ne rend pas pour autant faux ce que j'ai dit plus haut.

Elzen · Le 14/11/2010, à 00:37

Pylade a écrit :

@ArkSeth : si tu pointeur vaut NULL ou un truc bidon (pas initialisé), il n'empêche qu'il est tout de même typé, et qu'il pointe sur un objet particulier (un struct option, par exemple ), dont tu peux récupérer la taille par l'opérateur sizeof. Ça, tu ne peux pas le changer.
Après il est clair que si tu défères tu va avoir des problèmes, (SIGSEGV…), mais ça ne rend pas pour autant faux ce que j'ai dit plus haut.

Je n'ai jamais remis ça en doute

Je dis juste (et j'en demande confirmation au cas où) que dans le cas où il n'est pas initialisé ou initialisé à null, ce sur quoi pointe effectivement l'adresse mémoire contenue dans la variable (si tant est que le contenu de la variable corresponde à une adresse mémoire, ce qui n'est pas gagné), c'est un grand n'importe quoi, et que donc en pratique la variable ne pointe sur rien de précis.
Et donc pour quelqu'un qui ne s'y connaît pas énormément, lire « sizeof *lm » avant toute affectation de lm peut donner l'impression (même si ce n'est absolument pas le cas, nous sommes d'accord (et j'vois même pas comment on pourrait ne pas être d'accord après avoir essayé au moins une fois)) qu'on demande la taille mémoire d'un truc qui au mieux n'existe pas.
Après, c'est sûr qu'on écrit pas forcément du code dans le but d'être lisible par un grand débutant, mais quand même.

(Ceci dit, je suggère une nouvelle fois de s'arrêter là, ça commence à faire beaucoup de littérature pour pas grand chose )

Pylades · Le 14/11/2010, à 00:49

Un pointeur pointe toujours sur un objet (défini par son type). Après, si le pointeur n'est pas initialisé, l'objet pointé correspond soit à un truc bidon, soit à rien du tout, mais ce n'est pas le problème…

Bon, j'arrête ici aussi.

Elzen · Le 14/11/2010, à 01:09

C'était quand même intéressant, mine de rien, parce qu'en trollant comme ça sans que ça serve à grand chose, on en arrive à réfléchir un peu à la manière dont on conçoit abstraitement la programmation (qui de la variable ou du type arrive en premier ?), ainsi qu'à ce qui se passe réellement en mémoire en bas niveau (que contient un pointeur non-initialisé ?)
Et ça ne fait jamais de mal de réviser un peu ces deux points-là.

(Moralité : parler de C, saybien, c'est même pour ça qu'il y a un TdCCT)

grim7reaper · Le 14/11/2010, à 01:16

Oui, enfin là c'est plus une discussion ou un débat qu'un troll quand même . Il y a des arguments valables de chaque côté et je n'ai pas vu de mauvaise fois apparente.
J'ai l'impression que l'on utilise de plus en plus le mot troll à tort et à travers, même pour désigner un simple débat comme ici…

Pylades · Le 14/11/2010, à 01:18

@ArkSeth :

@grim7reaper : disons que nous étions clairement assis sur nos convictions, et qu'il n'y a avait qu'un espoir infime de rallier l'autre à son point de vue. C'était débattre juste pour débattre. D'un certain point de vue, on peut considérer que ça commence à être du troll. Après, bien entendu ici on évite de faire preuve de trop de mauvaise foi, même si j'ai un peu exagéré avec mes « *PAN* ».

Dernière modification par Pylade (Le 14/11/2010, à 01:22)

grim7reaper · Le 14/11/2010, à 01:24

Dans la majorité (pas tous, certes…) des débats que j'ai vu/lu, les principaux protagonistes changent rarement d'avis (ou si peu).

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

Elzen · Le 14/11/2010, à 01:37

Disons que j'aurais qualifié ça de débat aussi, si Pylade n'avait pas sorti ses *PAN* et parlé de tuer le troll

Tiens, mince : j'essayais de mettre mes printf en couleur, et gcc -pedantic râle parce que \e ne fait pas partie de la norme Y a moyen de faire autrement ?

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1301 Le 13/11/2010, à 18:29

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

#1302 Le 13/11/2010, à 18:32

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

#1303 Le 13/11/2010, à 18:34

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

#1304 Le 13/11/2010, à 18:44

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

#1305 Le 13/11/2010, à 19:00

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

#1306 Le 13/11/2010, à 19:13

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

#1307 Le 13/11/2010, à 19:26

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

#1308 Le 13/11/2010, à 19:31

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

#1309 Le 13/11/2010, à 19:33

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

#1310 Le 13/11/2010, à 20:56

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

#1311 Le 13/11/2010, à 21:03

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

#1312 Le 13/11/2010, à 21:17

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

#1313 Le 13/11/2010, à 21:27

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

#1314 Le 13/11/2010, à 21:36

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

#1315 Le 13/11/2010, à 23:10

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

#1316 Le 13/11/2010, à 23:31

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

#1317 Le 14/11/2010, à 00:01

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

#1318 Le 14/11/2010, à 00:10

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

#1319 Le 14/11/2010, à 00:37

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

#1320 Le 14/11/2010, à 00:49

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

#1321 Le 14/11/2010, à 01:09

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

#1322 Le 14/11/2010, à 01:16

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

#1323 Le 14/11/2010, à 01:18

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

#1324 Le 14/11/2010, à 01:24

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

#1325 Le 14/11/2010, à 01:37

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

Pied de page des forums