Discussion :

[thomas_strass]

Bonjour.
Je voulais savoir si avoir un objet

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Object object = null ;

et qui n'est jamais instanciée occupe de la mémoire, même infime ?

[Yoops]

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 !!

[thibaut]

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)...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
Calendar calendrier = null;
if (calendrier instanceof java.util.Calendar) {
}

ça ne passe pas dans le if:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

calendrier instanceof java.util.Calendar

renvoie false si calendrier est null, donc un objet null n'est pas typé !!!!!!

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+

[Pill_S]

et qui n'est jamais instanciée occupe de la mémoire, même infime ?

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)

[narkotik]

4 octets logiquement

[Glob]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
Calendar calendrier = null;
if (calendrier instanceof java.util.Calendar) {
}

ça ne passe pas dans le if:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

calendrier instanceof java.util.Calendar

renvoie false si calendrier est null, donc un objet null n'est pas typé !!!!!!

En fait, la ligne

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Calendar calendrier = null;

définit une-boîte-qu'on-peut-mettre-des-calendriers-dedans. Sauf qu'on y met rien.

La ligne

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

if (calendrier instanceof java.util.Calendar)

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.

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...

[Pill_S]

4 octets logiquement

SVP, tu pourrais approfondir ? en logique de quoi ?

[thibaut]

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.

Je pensais que pour renprendre ton exemple:

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 ) ...

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...)

[bulbo]

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

PS: C'est malin, maintenant j'ai faim ..

[narkotik]

Pill_S :
SVP, tu pourrais approfondir ? en logique de quoi ?

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 quoi

donc

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Object object = null ;

occupe 4 octets, ceux qui doivent contenir l'adresse mémoire d'un hypothétique futur objet

[Pill_S]

hors comme nous travaillons sur un systeme d'exploitation 32bits et que 1 octet = 8bits

OK, je savais pas que la taille des pointeurs était égale à la quantité de bits utilisés par le système

donc d'après toi quand on passera à Windows 64 la taille des pointeurs java va aussi doubler ?

[Glob]

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?


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...

[Fladnag]

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.

[Glob]

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 ?

Bah on va se retrouver sur le forum assembleur... J'ai eu ma dose d'offset:adresse, de mov DSX et de xor eax, merci

[thomas_strass]

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.