Bonjour.
Je voulais savoir si avoir un objet
et qui n'est jamais instanciée occupe de la mémoire, même infime ?Code:Object object = null ;
Version imprimable
Bonjour.
Je voulais savoir si avoir un objet
et qui n'est jamais instanciée occupe de la mémoire, même infime ?Code:Object object = null ;
Oui je pense, mais vraiment maxi infime puisque ca doit juste être une adresse qui doit être mise à zéro.
Pourquoi cette question ? Simple curiosité ou optimisation ? Parce que si il s'agit d'optimisation je ne pense pas qu'il soit utile de pousser jusqu'a ce niveau !! :roll: :wink:
Par contre j'ai vu récemment quelquechose qui m'as grandement surpris:
Si tu fais :
(Calendar c'est une classe quelconque juste pour l'exemple)...
ça ne passe pas dans le if:Code:
2
3
renvoie false si calendrier est null, donc un objet null n'est pas typé !!!!!!Code:calendrier instanceof java.util.Calendar
Moi je pensai naïvement que le fait de définir un type même si il est nulle, il possédais une marque indiquant son type... En fait un objet doit être typé uniquement quand il est instancié !!!
A+
oui, tout a fait, il occupe l'espace pris par la référence (mais ça ne doit pas excéder quelques octets d'après moi)Citation:
Envoyé par thomas_strass
:wink:
4 octets logiquement :wink:
En fait, la ligneCitation:
Envoyé par thibaut
définit une-boîte-qu'on-peut-mettre-des-calendriers-dedans. Sauf qu'on y met rien.Code:Calendar calendrier = null;
La ligneteste si l'objet qui se trouve dans la boîte est de type calendrier. Or, la boîte est vide, la réponse est false.Code:if (calendrier instanceof java.util.Calendar)
C'est un peu le problème lorsque les pointeurs sont cachés, c'est qu'on ne sait pas toujours ce qui est interprété comme... heu.... "boîte" et ce qui est interprété comme objet ("conteneur=pointeur" vs. "contenu=objet référencé").
Mais bon... :roll:
SVP, tu pourrais approfondir ? en logique de quoi ?Citation:
Envoyé par narkotik
:wink:
Je pensais que pour renprendre ton exemple:Citation:
teste si l'objet qui se trouve dans la boîte est de type calendrier. Or, la boîte est vide, la réponse est false.
un boîte à gateaux qui même si elle est vide est toujours de par sa nature une boîte à gateaux et que même vide tu peux la différencier d'une boîte à sucre ou une boîte à idées (hum... hum... pourquoi pas :lol: ) ...
Mais je conçois tout à fait qu'un objet null ne soit pas typé, qui plus est ça me semble logique en fin de compte, car pourquoi apporter une information supplémentaire (information de type) à une entité qui n'en a pas besoin (à savoir le pointeur null) ???
Merci en tout cas pour ta réponse ... imagée (Miam, Miam...) :lol:
C'est du a la liaison dynamique, le type exact d'une variable n'est connu qu'a l'affectation d'un objet a cette variable..
Ta boite a gateau pourrait etre une boite de petit lu ou une boite de petit ecoliers avec l'heritage..
Et du point de vue logique c'est mieux ainsi car tu ne peux pas appeler les methodes de ta boite a gateau sur null donc null n'est pas une boite a gateau ..
Bulbo :wink:
PS: C'est malin, maintenant j'ai faim ..
qd un objet pointe vers null, aucune place en mémoire n'est réservée pour l'objet car le pointeur peut pointer vers n'importe quoi, donc seul le pointeur de l'objet prend de la place en mémoire, hors comme nous travaillons sur un systeme d'exploitation 32bits et que 1 octet = 8bits, le pointeur fait 4 octets donc une variable pointant vers null ne fait que 4 octets !! et par la meme occasion une variable pointant vers null n'est pas typée puisqu'elle peut pointer vers n'importe quoiCitation:
Pill_S :
SVP, tu pourrais approfondir ? en logique de quoi ?
donc
occupe 4 octets, ceux qui doivent contenir l'adresse mémoire d'un hypothétique futur objet :wink:Code:Object object = null ;
OK, je savais pas que la taille des pointeurs était égale à la quantité de bits utilisés par le système :wink:Citation:
Envoyé par narkotik
donc d'après toi quand on passera à Windows 64 la taille des pointeurs java va aussi doubler ?
Si la jvm est maligne, ne devrait-elle pas dynamiquement utiliser 1, 2 ou 4 bytes en fonction de la taille de mémoire max qui sera allouée à l'application?
Si on spécifie 32MB au maximum, y'a-t-il besoin de pointeurs aussi "longs" que pour 1GB?
:roll:
Sauf si y'a des raisons de performances (genre le proc il est 32b donc 4B), comme par exemple avec ces cartes graphiques qui utilisent de façon cachée des couleurs 32bits quand on les met en 24bits...
Peut etre, mais on en revient a ce probleme :
Vaut il mieux faire des optimisations memoire et obliger le PC a faire des ajustement d'adresse chaque fois qu'on demande une lecture/ecriture memoire ?
ou vaut il mieux utiliser plus de memoire et ne pas se préoccuper des ajustement d'adresse ?
On n'y gagne pas forcement...
A noter que sous windows (NT,XP,2000) les booleen du systeme sont codés sur 32 bits... alors qu'un bit suffit pour enregistrer vrai ou faux.
Bah on va se retrouver sur le forum assembleur... :roll: J'ai eu ma dose d'offset:adresse, de mov DS:DX et de xor eax, merci :wink:Citation:
Envoyé par Fladnag
Yop. Merci pour vos réponses, cest parce que j'ai une classe qui selon les cas initialise ou non certains champs.
Et comme le programme peut générer des centaines d'objets de cette classe, ca va me faire beaucoup de mémoire perdue
( 4 octets * beaucoup = beaucoup trop )
Donc je vais me créer une petite interface et des classes implémentant celle-ci.