Bonjour,
Sous XE3 et plus, est que les champs d'un record ont des valeurs par défaut sans passer par un constructeur ? ou faut il les initialiser ?
exemple : champ1: boolean à false, champs2: integer à 0, champ3: string à ''
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Discussion :
[XE3] Valeur par défaut des champs d'un record sans constructeur
Bonjour,
Sous XE3 et plus, est que les champs d'un record ont des valeurs par défaut sans passer par un constructeur ? ou faut il les initialiser ?
exemple : champ1: boolean à false, champs2: integer à 0, champ3: string à ''
Comme tous les types, ça dépend où il est utilisé. Oui si variable globale ou le champ d'un objet. Non pour une variable locale.
Il s'agit bien d'un champ de record. Donc ni une variable locale ni un champ d'une classe
Ce n'est pas ce qu'il fallait comprendre
si le record est un membre de classe, il sera mis à zéro parce que l'instance hote le videra
si le record est une variable locale, il prendra les valeurs en cours en mémoire à cette endroit dans la pile, sauf les string et array qui sont des types managés, ils seront vides.
si le record est une variable globale, j'aurais dit qu'il prend la valeur en cours en mémoire dans le tas mais Andnotor semble dire qu'il y a une valeur par défaut, je n'utilise quasiment jamais de variable globale, que j'initialise à nil (oui donc des objets pas de record)
Si tu veux être tranquille, soit tu fais un ZeroMemory systématique soit tu fais un constructeur qu'il faudra appeler explicitement.
Ou alors, tu maitrises parfaitement ton code et tu initialises le record comme il doit l'être.
Il faut savoir qu'initialiser à zéro une zone mémoire sous FastMM (je crois que XE3 est déjà en FastMM) est beaucoup plus lent que le temps d'allocation.
Un SetLength d'un tableau de 1Mo par exemple, prend 99% de son temps à écrire les zéro qu'à obtenir le pointeur, ... avant FastMM, l'allocation était très lente (encore plus la réallocation)
Donc forcer ton record à zéro, faut le faire à bon escient, cela dépend de sa taille, tu n'as pas trop d'inquiètude avec un record sous 1Ko (genre si tu as 200-1000 champs)
Aide via F1 - FAQ - Guide du développeur Delphi devant un problème - Pensez-y !
Attention Troll Méchant !
"Quand un homme a faim, mieux vaut lui apprendre à pêcher que de lui donner un poisson" Confucius
Mieux vaut se taire et paraître idiot, Que l'ouvrir et de le confirmer !
L'ignorance n'excuse pas la médiocrité !
L'expérience, c'est le nom que chacun donne à ses erreurs. (Oscar Wilde)
Il faut avoir le courage de se tromper et d'apprendre de ses erreurs
Effectivement je n'avais pas compris la 1ère réponse. Merci pour les précisions c'est plus clair
Il y a une règle en programmation: Toujours initialiser un objet créé!!!
On ne crée pas un objet quel qu’il soit sans lui fixer une valeur de départ: On déclare une variable globale? Un simple monString: string=(''); ou un monInteger:integer=(0); ne coûte rien et évite que la variable prenne au départ une valeur venu de nul part!!!
Rien ne s'y oppose mais c'est souvent inutile. Les champs d'un objet sont initialisés à zéro (nil, blabla) par la méthode TObject.InitInstance. Quant aux variables globales non initialisées, elles sont stockées dans la section BSS de l'exe et reportées dans une section initialisée du processus, c'est directement géré par l'OS.Envoyé par Anselme45
En résumé :
- champ d'un objet = initialisé
- variable globale = initialisée
- variable locale = non initialisée
Et enfin une remarque sur les types managés : ils sont initialisés pour autant qu'on passe par une déclaration de variable mais ne le sont plus si on alloue soi-même l'instance par GetMem. Dans ce cas AllocMem est obligatoire, sinon VA quasi assurée.
Répondre avec citation
Partager