Ah non, () ça n'a strictement rien à voir ! () ne contient aucune information (c'est stocké dans 0 bits de mémoire, puisque tu aimes les chiffres et les implémentations), alors que None contient une information qui le différencie de Some ptr...
), alors que None contient une information qui le différencie de Some ptr...Pas du tout !
Certes, pour des raisons évidentes d'optimisation, le codage de () est souvent omis dans l'implémentation : les fonctions unit->truc n'attendent pas d'argument, les fonctions truc->unit ne renvoient rien (enfin j'imagine).
En revanche, si tu déclares une value de type unit, style :
let x=();;
Ben () est bien stocké en mémoire sur 31 bits, avec une valeur binaire égale à 0 (puisque c'est la première alternative du type somme unit), ou encore sur 32 bits avec une valeur binaire égale à 1, d'après le Très Saint Manuel.
C'est à dire qu'il est stocké exactement comme None.
Yoshi Diabolique (./539) :
Hippo> J'ai vraiment pas envie de répondre Point Par Point à tes Attaques Personnelles ©, si t'as un point particulier auquel tu veux que je réponde dis-le...
Bah je trolle, mais pourquoi est ce qu'on trollait déjà?
De même que dans un langage comme caml une chaîne et un tableau n'ont rien à voir, et pourtant en bas niveau ils sont représentés absolument pareil...
Ben en caml, non.
Une chaîne n'est pas codée comme un tableau de caractères
Non, add ne peut jamais renvoyer null (et l'addition en C non plus[*]).
[*] bien sûr c'est tout à fait possible qu'un compilo donné le fasse, mais comme c'est une undefined behaviour le programme pourrait très bien se mettre à planter à cause de ça par la suite...
Oui d'accord, mais moi je trouve ça rigolo parce qu'on fait un modèle abstrait qui ne correspond pas à la réalité : Peut-on trouver un compilo C qui fait le test de telle manière que add ne renvoie jamais null?
