Pourquoi devez-vous spécifier le type de données lors de la déclaration des variables?
Dans la plupart des langages de codage (sinon tous), vous devez déclarer des variables. Par exemple en C # si c'est un champ numérique alors
int PhoneNumber
Si j'utilise la langue anglaise normale, je n'ai pas besoin de déclarer PhoneNumber comme int pour l'utiliser. Par exemple, si je demande à mon ami Sam de me donner son numéro de téléphone, je dis:
"Sam, donne-moi le numéro de téléphone"
Je ne dirais pas
"Char (20) Sam donne moi le numéro de téléphone int"
Pourquoi devons-nous spécifier un type de données?
Dans la plupart des langages de codage (sinon tous), vous devez déclarer des variables.
[…]
Pourquoi devons-nous spécifier un type de données?
Ce sont deux questions indépendantes:
- Pourquoi devons-nous déclarer des variables?
- Pourquoi devons-nous déclarer des types?
Soit dit en passant, la réponse aux deux est: nous ne le faisons pas.
Il existe de nombreux langages de programmation typés statiquement où vous n'avez pas besoin de déclarer de types. Le compilateur peut déduire les types du contexte environnant et de l'utilisation.
Par exemple, dans Scala vous pouvez dire
val age: Int = 23
ou vous pourriez simplement dire
val age = 23
Les deux sont exactement équivalents: le compilateur déduira le type à Int de l'expression d'initialisation 23.
De même, en C♯, vous pouvez dire l'un ou l'autre, et ils signifient tous deux exactement la même chose:
int age = 23;
var age = 23;
Cette fonctionnalité est appelée inférence de type, et de nombreux langages en plus Scala et C♯ l'ont: Haskell, Kotlin, Ceylon, ML, F♯, C++, vous l'appelez Même Java a des formes limitées d'inférence de type.
Dans les langages de programmation typés dynamiquement, les variables n'ont même pas de types. Les types n'existent que dynamiquement au moment de l'exécution, pas statiquement. Seules les valeurs et les expressions ont des types et uniquement à l'exécution, les variables n'ont pas de types.
Par exemple. dans ECMAScript:
const age = 23;
let age = 23;
Et enfin, dans de nombreux langages, vous n'avez même pas besoin de déclarer de variables. par exemple. en Ruby:
age = 23
En fait, ce dernier exemple est valable dans un certain nombre de langages de programmation. La même ligne de code exacte fonctionnerait également en Python, par exemple.
Donc,
- même dans les langages typés statiquement où les variables ont des types, vous n'avez pas nécessairement à les déclarer,
- dans les langages typés dynamiquement, les variables n'ont pas de types, donc évidemment ne peut pas même les déclarer,
- dans de nombreuses langues, vous n'avez même pas à déclarer de variables
Lorsque vous utilisez le langage naturel pour faire référence à des informations, elles ne sont pas très précises et, en particulier, ne communiquent pas beaucoup aux autres votre intention. Des problèmes similaires se produisent lorsque vous essayez de faire des mathématiques en langage naturel: ce n'est tout simplement pas assez précis.
La programmation est complexe; les erreurs sont trop faciles à trouver. Les types font partie d'un système de vérifications conçu pour empêcher les états de programme illégaux, en détectant les conditions d'erreur. Différentes langues utilisent les types différemment: certaines langues utilisent fortement les types pour détecter les erreurs au moment de la compilation. Presque toutes les langues ont une notion de types incompatibles comme une erreur d'exécution. Habituellement, une erreur de type indique un bogue quelconque dans le programme. Lorsque nous permettons aux programmes de continuer malgré les erreurs, nous obtenons probablement de très mauvaises réponses. Nous préférons arrêter le programme plutôt que d'obtenir des réponses mauvaises ou incorrectes.
Autrement dit, les types expriment des contraintes sur le comportement du programme. Les contraintes, lorsqu'elles sont appliquées par un mécanisme, fournissent des garanties. De telles garanties limitent la quantité de raisonnement nécessaire pour penser au programme, simplifiant ainsi la tâche de lecture et de maintenance du programme pour les programmeurs. Sans types, et leur implication d'outils (c'est-à-dire le compilateur) qui détectent les erreurs de type, la charge de programmation est considérablement plus élevée et donc plus coûteuse.
Il est vrai que (de nombreux) humains font facilement la distinction entre un numéro de téléphone européen, américain et international. Cependant, l'ordinateur ne "pense" pas vraiment et, s'il le disait, composerait un numéro de téléphone américain en Europe, ou vice versa. Les types, par exemple, sont un bon moyen de faire la distinction entre ces cas, sans avoir à enseigner à l'ordinateur comment "penser". Dans certaines langues, nous pouvons obtenir une erreur de temps de compilation pour essayer de mélanger un numéro de téléphone européen sur un système téléphonique américain. Cette erreur nous indique que nous devons modifier notre programme (peut-être en convertissant le numéro de téléphone en une séquence de numérotation internationale, ou, en utilisant le numéro de téléphone en Europe à la place), avant même d'essayer d'exécuter le programme.
De plus, comme l'ordinateur ne le pense pas, le nom du champ ou de la variable (par exemple phonenumber), ne signifie rien pour l'ordinateur. Pour l'ordinateur, ce nom de champ/variable est simplement "blah123". Pensez à ce que serait votre programme si toutes les variables étaient "blahxxx". Oui. Eh bien, c'est ce que voit l'ordinateur. Fournir un type donne à l'ordinateur une idée de la signification de la variable qu'il ne peut tout simplement pas déduire de son seul nom.
De plus, comme le dit @Robert, dans de nombreux langages modernes, nous n'avons pas à spécifier autant de types que nous le faisions autrefois, car des langages comme C # effectuent une "inférence de type", qui est un ensemble de règles pour déterminer le type approprié. pour une variable en contexte. C # fournit uniquement l'inférence de type sur les variables locales, mais pas sur les paramètres formels, ni sur les champs de classe ou d'instance.
En plus des autres réponses, il y a une chose qui devrait être incluse. N'oubliez pas que les ordinateurs ne sont que des bits. Disons que je vous donne les octets:
26 3A 00 FF
Qu'est-ce que cela signifie? Il est stocké de cette façon par l'ordinateur, mais sans aucune interprétation, c'est juste des bits. Il peut s'agir de 4 caractères ascii. Ce pourrait être un entier. Il peut s'agir de quelques octets dans un tableau. Cela pourrait faire partie d'un objet. Cela pourrait être un pointeur vers l'endroit où cette vidéo de chat est mise en mémoire tampon. Presque tous les langages de programmation de Assembly on up ont besoin quelque chose pour savoir comment interpréter les bits pour leur faire faire un calcul significatif.
Et puisque l'ordinateur ne peut pas connaître la signification de ces bits, il a besoin que vous le lui disiez - soit explicitement via des annotations de type, soit implicitement via des mécanismes d'inférence de type mentionnés dans les autres réponses.
La réponse à pourquoi les ordinateurs ont besoin de cette information a à voir avec représentation des données.
Le nom du "type de données" est une référence à des règles qui aident l'ordinateur à stocker et à récupérer des informations à partir de son état brut de 0 et de 1 dans la mémoire de l'ordinateur.
Par exemple, votre caractère 8 bits ASCII normal serait stocké dans la mémoire de l'ordinateur (soit RAM ou disque) comme 01000001 (le caractère majuscule "A", ASCII code 65) ou 00001000 (le signe de pourcentage), ou toute combinaison de 0 et de 1 dans ces 8 bits.
Pour un autre exemple, un entier non signé de 8 bits peut être stocké en tant que 00000101 (le chiffre 5) ou 00001000 (le chiffre 8)
Remarquez comment la représentation binaire de 8 et le caractère% peuvent être identiques, mais ils signifient des choses différentes parce que leurs types sont différents.
Même les langues qui déduisent le type de données, elles peuvent ne pas avoir la règle selon laquelle "tous les types de variables doivent être déclarés par le programmeur", elles ont des règles comme "si votre série de caractères est entourée de guillemets, c'est une chaîne" et beaucoup plus de règles pour chaque type de données.
Donc, même ceux-ci ont besoin de types de données pour comprendre ce que signifient les 0 et les 1, afin qu'ils puissent, par exemple, faire la fonction de concaténation de chaînes si vous essayez "d'ajouter" deux caractères, ou faire un ajout d'entier si vous essayez d'ajouter deux entiers .
Dans votre histoire aussi, disons que vous n'avez pas demandé le numéro de téléphone à Sam, mais Sam vous donne un morceau de papier sur lequel est écrit "1123581321". Vous ne pouvez pas être certain que Sam est juste un fan des huit premiers numéros de Fibonacci, ou si c'est un numéro de téléphone. Pour faire une supposition, vous devrez prendre en compte le contexte et les indices dont vous disposez, comme peut-être vous avez demandé à Sam un numéro de téléphone il y a un jour, ou la note dit "Appelez-moi", ou si vous comptez les chiffres et trouvez il correspond aux modèles de la plupart des numéros de téléphone. Ce n'est qu'alors que vous saurez que c'est un numéro de téléphone que vous pouvez appeler et non pas des chiffres que vous taperez dans une calculatrice.
Notez comment ces conseils qui vous ont amené à deviner que le numéro était un numéro de téléphone sont similaires à la façon dont les conseils mènent à un langage informatique qui ne nécessite pas de déclaration pour déduire le type d'une valeur.
Dans certaines langues, vous n'avez pas besoin de spécifier le type de données.
Les langues qui prennent en charge l'inférence de type peuvent généralement déterminer le type de données à partir de votre utilisation. Par exemple,
var name = "ALi"
est typé en interne sous forme de chaîne, car la valeur est entourée de guillemets.
Certaines langues n'exigent pas non plus que vous déclariez la variable; la variable est créée lors de sa première utilisation. Cependant, il est considéré comme une meilleure pratique de déclarer spécifiquement vos variables, pour un certain nombre de raisons importantes; principalement parce que cela exprime mieux votre intention.
Parce que c'est ce que spécifie la conception du langage. Donc, pour répondre à votre question, nous devons examiner l'intention derrière la saisie explicite dans des langages comme C # et C++. (Eh bien, C # le fait parce que C++ le fait parce que C le fait, nous devons donc regarder le chemin intentionnel à l'époque).
Tout d'abord, le typage explicite et statique fournit une rigueur dans le codage - spécifier une variable comme un entier signifie que le compilateur et le logiciel doivent être surpris et lancer une erreur lorsque vous affectez un caractère ou une chaîne à la variable. La frappe dynamique peut causer des maux de tête aux imprudents (regardez simplement PHP ou approche javascripts pour la véracité de choses comme les tableaux et les chaînes vides).
Vous pouvez avoir de la statique avec une frappe implicite - l'initialisation d'une variable sous forme de chaîne signifie que la variable ne devrait être qu'une chaîne, mais j'ai le sentiment que cela peut causer des problèmes aux humains qui lisent le code (j'ai tendance à supposer une frappe dynamique lorsqu'il y a une frappe implicite ).
De plus, il est possible, dans certains langages, d'écrire quelque chose comme ce pseudocode pour initialiser une classe à partir d'une entrée de chaîne:
PhoneNumber phoneNumber = "(61) 8 8000 8123";
Deuxièmement, le typage explicite va également de pair avec l'allocation de mémoire. Un int est toujours autant d'octets. Un PhoneNumber est autant d'octets. Le compilateur peut affecter un bloc de mémoire de taille appropriée qui peut ensuite être utilisé plus tard sans avoir à voir l'espace dont il aura besoin lorsque vous affectez une valeur.
PhoneNumber phoneNumber;
...
phoneNumber = "some value from somewhere";
Enfin, cela supprime la confusion ... 123 est-il un entier ou un entier non signé? Ils ont besoin du même nombre d'octets, mais la valeur maximale stockée dans les variables de chaque type est très différente ...
Cela ne veut pas dire qu'explicite vaut mieux qu'implicite - mais la conception du langage repose sur ce type de choix, et C # fonctionnerait différemment avec le typage implicite. PHP et javascript fonctionneraient différemment avec une saisie explicite.
Parce que Sam est plus intelligent que les compilateurs. Par exemple, lorsque vous dites me donner le numéro de téléphone, vous ne spécifiez pas si vous voulez le préfixe du pays ou l'indicatif régional si c'est le numéro de travail où seuls les 4 derniers chiffres sont requis. De plus, si vous demandez le numéro de la pizzeria locale, vous pourrez traiter la réponse "pizza4u".
Sam, le chiffre à partir du contexte. Bien que le compilateur puisse également le comprendre à partir du contexte, Sam sera meilleur dans ce domaine (et est capable d'interrompre le processus pour demander des éclaircissements).
Il existe deux approches de base pour les types et les variables, soit la variable a un type, auquel cas les actions qui ne sont pas autorisées par le type sont interdites et empêchent la compilation, soit la valeur a un type et les actions qui ne sont pas autorisées par le sont capturés lors de l'exécution.
Chaque approche a ses avantages et ses inconvénients. En général, les rédacteurs du compilateur essaient de minimiser les inconvénients et de maximiser les avantages. C'est pourquoi C #, par exemple, autorise var phoneNumber = GetPhoneNumber(); et déduira le type de phoneNumber de la signature de GetPhoneNumber. Cela signifie que vous devez déclarer le type de la méthode, mais pas la variable qui reçoit le résultat. D'un autre côté, il existe différents types de projets d'indication/d'application pour javascript. Tout est un compromis.
C'est une question de la façon dont les données sont stockées. Votre interaction avec Sam ferait une meilleure comparaison si vous posiez la question afin que vous puissiez l'écrire mais qu'il n'y avait que huit caractères de papier.
"Sam, donne-moi le numéro de téléphone."
"5555555555"
"Oh non, je n'ai plus de papier. Si seulement j'avais su à l'avance combien de données je demandais j'aurais pu mieux préparer!"
Donc, à la place, la plupart des langues vous font déclarer un type, donc il saura et se préparera à l'avance:
"Sam, combien de temps dure un numéro de téléphone?"
"Dix personnages."
"Ok, alors laisse-moi prendre un plus gros morceau de papier. Maintenant, donne-moi le numéro de téléphone."
"5555555555"
"J'ai compris! Merci Sam!"
Cela devient encore plus poilu lorsque vous examinez les moyens fondamentaux réels de stockage des données. Si vous êtes comme moi, vous avez un cahier avec des notes diverses, des chiffres juste griffonnés, pas de contexte ou d'étiquetage pour quoi que ce soit, et vous n'avez aucune idée de ce que cela signifie trois jours plus tard. C'est également un problème pour les ordinateurs. Beaucoup de langues ont des types "int" (int, long, short, byte) et "float" (float, double). Pourquoi est-ce nécessaire?
Eh bien, regardons d'abord comment un entier est stocké et généralement représenté dans l'ordinateur. Vous savez probablement qu'au niveau de base, tout est binaire (1 et 0). Le binaire est en fait un système numérique qui fonctionne exactement comme notre système numérique décimal. En décimal, vous comptez de 0 à 9 (avec des zéros non significatifs implicites infinis que vous n'écrivez pas), puis vous revenez à 0 et incrémentez le chiffre suivant pour en avoir 10. Vous répétez jusqu'à ce que vous passiez de 19 à 20, répétez jusqu'à ce que vous passiez de 99 à 100, et ainsi de suite.
Le binaire n'est pas différent, sauf qu'au lieu de 0 à 9, vous comptez de 0 à 1. 0, 1, 10, 11, 100, 101, 110, 111, 1000. Ainsi, lorsque vous tapez 9, dans la mémoire qui est enregistrée en binaire comme 1001. Il s'agit d'un nombre réel. Il peut être ajouté, soustrait, multiplié, etc., exactement sous cette forme. 10 + 1 = 11. 10 + 10 = 100 (passez de 1 à 0 et emportez le 1). 11 x 10 = 110 (et de manière équivalente, 11 + 11 = 110).
Maintenant dans la mémoire réelle (registres inclus), il y a une liste, un tableau, peu importe comment vous voulez l'appeler, de bits (potentiels 1 ou 0 ') juste à côté les uns des autres, c'est ainsi qu'il garde ces bits organisés de manière logique pour créer un nombre supérieur à 1. Le problème est, que faites-vous avec les décimales? Vous ne pouvez pas simplement insérer un morceau de matériel entre les deux bits du registre, et cela coûterait beaucoup trop cher d'ajouter des "bits décimaux" entre chaque paire de bits. Alors que faire?
Vous l'encodez. Généralement, l'architecture du CPU ou du logiciel déterminera comment cela se fait, mais une façon courante consiste à stocker un signe (+ ou -, généralement 1 est négatif) dans le premier bit du registre, un mantisse (votre nombre a changé autant de fois qu'il faut pour se débarrasser de la décimale) pour le nombre X de bits suivant, et un exposant (le nombre de fois où vous avez dû le décaler) pour le reste. C'est similaire à la notation scientifique.
La saisie permet au compilateur de savoir ce qu'il regarde. Imaginez que vous ayez stocké la valeur 1,3 dans le registre 1. Nous allons juste trouver notre propre schéma de codage sophistiqué ici, 1 bit pour le signe, 4 pour la mantisse, 3 pour l'exposant (1 bit pour le signe, 2 pour la magnitude). C'est un nombre positif, donc le signe est positif (0). Notre mantisse serait 13 (1101) et notre exposant serait -1 (101 (1 pour négatif, 01 = 1)). Donc, nous stockons 01101101 dans le registre 1. Maintenant, nous n'avons pas tapé cette variable, donc quand le runtime va l'utiliser, il dit "bien sûr, c'est un entier pourquoi pas" donc quand il affiche la valeur que nous voyons 109 (64 + 32 + 8 + 4 + 1), ce qui n'est évidemment pas correct.
Cependant, toutes les langues ne vous obligent pas à taper explicitement. C # a un mot clé "var" qui provoque l'interprétation du type d'une variable au moment de la compilation, et d'autres langages comme Javascript sont typés de manière totalement dynamique, au point que vous pouvez stocker un entier dans une variable, puis l'affecter à un booléen, puis affectez-le à nouveau à une chaîne et la langue garde une trace de tout cela.
Mais c'est beaucoup plus facile pour le compilateur, l'interpréteur ou l'exécution - et se traduit souvent par un programme plus rapide car il n'a pas à dépenser de précieuses ressources pour trier tout en tapant - pour vous demander, le programmeur, quel type de les données que vous lui donnez.
Il existe des langages de programmation où vous ne le faites pas devez déclarer des types de données pour vos variables. Il existe même des langages de programmation où vous n'avez pas à déclarer de variables au préalable; vous pouvez juste utiliser eux, immédiatement.
Le problème avec la non déclaration des noms de variables est que si vous mal orthographiez accidentellement le nom d'une variable, vous avez maintenant accidentellement créé une nouvelle variable complètement indépendante. Donc, lorsque vous exécutez votre programme, vous ne pouvez pas comprendre pourquoi la variable enfer que vous définissez soudainement ne contient rien ... Jusqu'à ce que, après plusieurs heures de débogage, vous réalisiez que vous avez tapé le nom putain de mal! GRRR !!
Ils l'ont donc fait donc vous devez - déclarer les noms de variables que vous allez utiliser au préalable. Et maintenant, lorsque vous tapez un nom incorrect, vous obtenez une erreur de compilation, qui vous indique immédiatement exactement où se trouve le bogue, avant même que votre programme ne s'exécute. N'est-ce pas tellement plus facile?
Même chose avec les types de données. Il existe des langages de programmation où vous ne le faites pas devez déclarer de quel type les choses devraient être. Si vous avez une variable customer qui n'est en fait que le nom d'un client, pas l'objet client entier, essayer de récupérer l'adresse client à partir d'une chaîne ordinaire ... ne fonctionnera pas. Le point entier du typage statique est que le programme ne compilera pas; il se plaindra bruyamment, indiquant l'endroit exact où se situe le problème. C'est beaucoup plus rapide que d'exécuter votre code et d'essayer de comprendre pourquoi diable cela ne fonctionne pas.
Toutes ces fonctionnalités sont destinées à dire au compilateur ce que vous étiez intention à faire, afin qu'il puisse vérifier ce que vous en fait avez fait et vous assurer que cela a du sens. Cela permet au compilateur de automatiquement localiser les bogues pour vous, ce qui est une grosse affaire.
(Loin dans un passé lointain, vous n'aviez pas à déclarer sous-programmes. Vous devez simplement GOSUB à un numéro de ligne particulier. Si vous souhaitez transmettre des informations entre des sous-programmes, vous devez définir des variables globales particulières, appeler votre sous-programme, puis inspecter d'autres variables lorsque le sous-programme revient. Mais cela rend incroyablement facile pour oublier d'initialiser l'un des paramètres. Alors maintenant, presque tous les langages de programmation modernes exigent que vous déclariez quels paramètres réels un sous-programme prend, afin que nous puissions vérifier que vous les avez tous spécifiés.)
Si j'utilise la langue anglaise normale, je n'ai pas besoin de déclarer PhoneNumber comme int pour l'utiliser. Par exemple, si je demande à mon ami Sam de me donner son numéro de téléphone, je dis:
"Sam, donne-moi le numéro de téléphone"
Je ne dirais pas>
"Char (20) Sam donne moi le numéro de téléphone int"
Pourquoi devons-nous spécifier un type de données?
Passez à MathOverflow ou Computer Science théorique et lisez pendant un moment pour avoir une idée de la façon dont les humains communiquent les alogrithmes entre eux lorsqu'ils veulent s'assurer qu'il n'y a aucune possibilité de malentendu. Ou lisez la norme pour certains langages de programmation matures.
Vous constaterez que la définition des types de valeurs autorisées pour un terme fait partie intégrante d'une pratique de communication très précise, même entre humains.
Ce que vous avez remarqué, c'est que les interactions quotidiennes sont assez régulières et que les humains sont assez tolérants aux fautes, de sorte qu'un malentendu sur les numéros de téléphone est généralement évité par la connaissance partagée des participants.
Mais avez-vous déjà essayé de prendre un numéro de téléphone pour quelqu'un dans un autre pays? Vous ont-ils dit explicitement combien de fois Pousser zéro pour accéder à l'adressage international? Vous ont-ils dit leur code de pays? L'avez-vous reconnu comme tel? À combien de chiffres vous attendiez-vous? Combien avez-vous obtenu? Saviez-vous comment regrouper les chiffres? Ou même si le regroupement a une signification?
Soudain, le problème est beaucoup plus difficile et vous avez probablement pris beaucoup plus de soin de vérifier explicitement que le numéro reçu était compris de la façon dont l'expéditeur le voulait.
Une autre raison pour déclarer des types est l'efficacité. Alors qu'un entier peut être stocké dans 1 octet, ou 2 octets, ou 4, un programme utilisant un très grand nombre de variables peut utiliser 4 fois la mémoire nécessaire, selon ce qui est fait. Seul le programmeur sait si un espace de stockage plus petit est viable, il peut donc le dire en déclarant le type.
De plus, les objets typés dynamiquement permettent de nombreux types possibles à la volée. Cela pourrait entraîner des frais généraux "sous le capot", ce qui ralentirait le programme par rapport à rester avec un seul type tout au long.
Un certain nombre de premiers langages de programmation (en particulier Fortran) ne vous obligeait pas à déclarer des variables avant utilisation.
Cela a conduit à un certain nombre de problèmes. Un élément vraiment évident est que le compilateur ne peut plus détecter les erreurs typographiques simples de manière aussi fiable. Si vous avez du code qui est censé modifier une variable existante, mais qui a une faute de frappe, vous avez toujours un code parfaitement légitime qui vient de créer (et d'affecter une valeur à) une nouvelle variable:
longVariableName = 1
// ...
longVaraibleName = longvariableName + anotherLongVariableName
Maintenant, en examinant cela isolément, alors que j'ai déjà mentionné une faute de frappe comme source du problème, il est probablement assez facile de trouver la faute de frappe et le problème ici. Dans un programme long, où cela est enterré au milieu de beaucoup d'autres codes, c'est beaucoup plus facile à manquer.
Même actuellement avec de nombreuses langues typées dynamiquement, vous pouvez toujours obtenir le même problème de base assez facilement. Certains ont une certaine facilité pour vous avertir si vous attribuez à une variable, mais ne la lisez jamais (ce qui heuristique heureusement pas mal de problèmes comme celui-ci) les deux autres n'ont pas de telles choses.
Lorsque vous déclarez une variable, un espace est alloué dans la mémoire, mais la machine (l'ordinateur dans ce cas) ne sait pas déjà combien d'espace doit être alloué pour cette variable.
Exemple: - vous créez un programme qui demande à l'utilisateur d'entrer n'importe quel nombre, dans ce cas, vous devez spécifier un type de données pour stocker ce numéro, sinon la machine ne peut pas juger par elle-même qu'elle doit allouer 2 octets ou 2 gigaoctets, s'il essaie de faire l'allocation par lui-même, cela peut entraîner une utilisation inefficace de la mémoire. Si vous spécifiez le type de données dans votre programme, après la compilation, la machine allouera l'espace approprié en fonction des besoins.