Newsgroup: it.comp.java
Titolo: Distinguere assenza di valore per un dato int

Salve, ho due costruttori:
pippo(int i){variaibile int interna = i;}
pippo(){???}
Mi sarebbe utile poter distinguere tra il caso in cui ho assegnato un valore 
a variabile int interna e quando non l'avessi fatto.. leggo sulla doc. che 
esistono valori quali NaN o altro.. come si fa e cosa si fa solitamente 
quando non si vuole assegnare un valore numerico pur inizializzando il dato 
in modo da renderlo utilizzabile .. io sono solito assegnare "null" ma con i 
dati int non è possibile mi pare...
Scusate la crassa ignoranza ma vorrei cercare di essere rigoroso nella 
stesura del codice.

beh tipicamente per le variabili intere potresti inizializzare la
variabile con uno zero, ma dipende l'utilizzo che devi fare di quella
variabile, quindi potresti inizializzarla con Integer.MAX_VALUE o
MIN_VALUE ad esempio, che sono valori molto grandi o piccoli....
Ciriciao White Tiger


 writes:
WT> beh tipicamente per le variabili intere potresti inizializzare la
WT> variabile con uno zero
Se non ricordo  male, ogni variabile numerica viene  inizializzata a 0
per default (le booleane a false).
-- 
 /\           ___
/___/\_|_|\_|__|___Gian Uberto Lauri_____
  //--\| | \|  |   Integralista GNUslamico
\/                 e coltivatore diretto di Software

 
http://csvtosql.sourceforge.net
Metalegge di Cooper: Una proliferazione di nuove leggi crea una
proliferazione di nuove scappatoie.

 per default (le booleane a false).
Attenzione: questo è generalmente falso.

> 0 per default (le booleane a false).
g> Attenzione: questo è generalmente falso.
Vero, non  ricordavo bene,  la cosa vale  per le variabili  di classe,
istanza e  per gli  elementi degli array,  per le variabili  locali il
compilatore  ti  urla dietro  se  provi  ad  usare una  variabile  non
inizializzata.
Per il  problema iniziale, non c'è  modo di sapere  in generale (salvo
per le  variabili locali)  se una  variabile di un  tipo nativo  ha un
valore  diverso da  quello  iniziale  o no  perché  contiene sempre  e
comunque  un valore valido  per quel  tipo, dipende  dalla particolare
situazione  l'assunto che un  valore sia  possibile o  no in  un certo
punto del programma.
Il consiglio di  usare una classe wrapper è non  male. Oppure usare il
LISP :).


 dati int non è possibile mi pare...
Di solito si opera in questo modo: se esiste un valore che non è
significativo (es. 0 o -1) si usa quello, magari identificandolo con
una costante. Se tutti i valori sono significativi allora si utilizza
la classe wrapper e il valore il null per il non-assegnato.
Con Java 1.5 puoi usare direttamente la seconda opzione perchè l'uso
dei wrapper l'hanno "accrocchiato" (mi si perdoni il termine) per
renderlo parzialmente trasparente.

 Attenzione: questo è generalmente falso.
Da quando?

> Attenzione: questo è generalmente falso.
VV> Da quando?
Non è  vero per le variabili locali  di un metodo che  vanno per forza
inizializzate per non far arrabbiare il compilatore :).


 inizializzate per non far arrabbiare il compilatore :).
Non significa che è "generalmente falso".
La regola dove è applicata è vera. Le variabili e le reference locali
non sono inizializzate, non è che sono inizializzate in modo diverso.

> inizializzate per non far arrabbiare il compilatore :).
VV> Non significa che è "generalmente falso".
Probabilmente  avrà scritto  in  vita sua  solo  codice con  variabili
allocate sullo stack :)


 > > > > per default (le booleane a false).
Considerando solo l'oggetto del ricordo l'affermazione nella sua generalità
è falsa: vale solo per casi specifici, mentre per altri - quelli di cui si è
già
parlato - non vale. Intendevo dire semplicemente questo.
Penso che l'equivoco nasca dall'interpretazione di "generalmente" che
non va inteso come "in tutti i casi" ma, come appunto sopra riporto,
"nella sua generalità": cioè non "l'affermazione è falsa in tutti i casi"
ma "l'affermazione intesa per tutti i casi è falsa".
A meno, naturalmente, che tu non mi contestassi l'affermazione intesa a
commento dell'intera frase "Se non ricordo male...": in questo caso avresti
ragione tu perchè, ricordandosi egli effettivamente male, l'implicazione in
sè risultava corretta.
;)
Saluti