[Java] indirizzo di un oggetto.

[D3stroyer]

ciao, sto approcciando java da poco tempo. Mi sono letto un libro di eckel (thinking in java 3rd), ma ora che mi metto a provare mi trovo in difficoltà su tante cose inutili. "Vengo" dal c++ e mi confondo qui..tante cose girano diverse.

Come posso avere in output l'indirizzo di un oggetto? In qualsiasi modo la giro mi da errori di compilazione!

Immaginate io abbia creato una istanza di un oggetto (una classe vuota ad esempio) e voglia il suo indirizzo in System.out.print() chiamata nel main.

cosa scrivo?

E' sicuramente una cavolata per voi, ma nemmeno google mi risponde

L'unico modo che compila è questo..ma non è un indirizzo quello! (l'output è "cane@187aeca")

import java.util.*;
import java.lang.*;

class cane {}

public class mio {
	public static void main(String[] Args) {
	cane uno = new cane();
	System.out.println(uno);
	}
}

[PGI-Bis]

Non c'è un indirizzo. Cioè c'è, perchè ogni variabile di tipo riferimento potrebbe essere un puntatore, ma non c'è modo di ottenere l'indirizzo di memoria puntato tramite Java.

[D3stroyer]

azz, così sbagliare con le map è ancora piu' facile :/ Forse perchè ancora non ho tutto chiaro. Troverò altri modi per verificare.

[PGI-Bis]

In che senso?

Se quello che ti serve è un identificatore dell'oggetto puntato allora puoi usare il metodo hashCode() che tutti gli oggetti possiedono in quanto figli di Object.

Il valore restituito non è necessariamente l'indirizzo dell'oggetto ma, per contratto, è univoco entro i limiti del possibile.

[71104]

Originariamente inviato da D3stroyer

azz, così sbagliare con le map è ancora piu' facile

perché mai dovresti "sbagliare con le map" se non hai accesso ai valori numerici dei puntatori di memoria? cosa dovresti sbagliare? provo a darti una spiegazione cercando di reinterpretare quello che scrivi. affinchè in una hash table il numero di collisioni sia minimizzato devi aver realizzato una buona funzione di hashing, cioè una funzione di hashing che per oggetti diversi (oggetti che il proprio metodo equals dichiarerebbe incompatibili) restituisca il più spesso possibile (anche sempre, possibilmente) hash codes diversi. fermo rimane però quanto richiesto dal contratto di hashCode: per oggetti che il metodo equals dichiarerebbe uguali il metodo hashCode deve restituire valori uguali.

il metodo hashCode della classe Object restituisce come hash code il valore numerico del puntatore nativo che punta all'oggetto (exploit tramite il quale potresti accedere ai puntatori) e questo assicura al 100% che non ci siano mai collisioni tra istanze diverse, ma il problema percui la stragrande maggioranza delle classi che vanno a finire in una HashMap sovrascrivono il metodo hashCode è che sovrascrivono anche il metodo equals, il quale a sua volta finisce spesso per dichiarare identiche due istanze diverse. un esempio lapalissiano: la classe Integer.

[PGI-Bis]

Originariamente inviato da 71104

il metodo hashCode della classe Object restituisce come hash code il valore numerico del puntatore nativo che punta all'oggetto (exploit tramite il quale potresti accedere ai puntatori)

Sarebbe vero se lo dicessero le specifiche del linguaggio (la classe Object è parte del linguaggio di programmazione Java). Lo dicono? Come diceva un mio professore, lo sdudende addendo bodrebbe ghiedere: e se il puntatore fosse a 64, 128, 256bit? Che faremmo?

[D3stroyer]

no perchè essendo impedito, quando chiamavo un oggetto tramite iteratore controllavo che l'indirizzo fosse uguale a quello della chiamata diretta di questo.

Lo facevo all'inizio per prendere la mano sui containers e qui ora devo inventarmi qualcosa. Provo a informarmi un po' su questo hashcode.

grazie

[71104]

Originariamente inviato da PGI-Bis

Sarebbe vero se lo dicessero le specifiche del linguaggio (la classe Object è parte del linguaggio di programmazione Java). Lo dicono?

lo suggeriscono

Come diceva un mio professore, lo sdudende addendo bodrebbe ghiedere: e se il puntatore fosse a 64, 128, 256bit? Che faremmo?

eh? :|

[PGI-Bis]

Originariamente inviato da 71104

lo suggeriscono

Come lo suggeriscono . No, non lo suggeriscono. Lo sdudende...eccetera: supponiamo che le specifiche dicano implicitamente o esplicitamente che il valore restituito da System.identyHashCode coincide con il valore del puntatore all'oggetto. Se così fosse, la possibilità di una corretta realizzazione del linguaggio di programmazione Java sarebbe limitata a sistemi in cui lo spazio di indirizzamento fosse minore di 2^32, essendo l'hash di un Object un valore a 32bit. Giusto?

[71104]

Originariamente inviato da PGI-Bis

Come lo suggeriscono . No, non lo suggeriscono.

a me questo sembrava un suggerimento:

As much as is reasonably practical, the hashCode method defined by class Object does return distinct integers for distinct objects. (This is typically implemented by converting the internal address of the object into an integer, but this implementation technique is not required by the JavaTM programming language.)

sta scritto nella documentazione del metodo Object.hashCode().

Lo sdudende...eccetera: supponiamo che le specifiche dicano implicitamente o esplicitamente che il valore restituito da System.identyHashCode coincide con il valore del puntatore all'oggetto. Se così fosse, la possibilità di una corretta realizzazione del linguaggio di programmazione Java sarebbe limitata a sistemi in cui lo spazio di indirizzamento fosse minore di 2^32, essendo l'hash di un Object un valore a 32bit. Giusto?

giusto, ma stando ai tuoi stessi pronostici non credo che Java vivrà abbastanza da vedere le macchine (se mai esisterà per l'uomo la necessità di crearle) con bus di indirizzi da 128 o 256 bit
poi sempre di un suggerimento si tratta: è chiaro che su una macchina a 64 bit non puoi usare tutto l'indirizzo dell'oggetto come hashCode, ma un metodo nativo può fare l'hashing del puntatore prendendo magari i bit che su una data architettura si sanno essere quelli più significativi per identificare un oggetto.

[PGI-Bis]

Per specifiche intendo le specifiche del linguaggio di programmazione Java, quelle che stabiliscono cosa è linguaggio di programmazione Java e cosa no.

Il mio timore è che citando la particolare versione del linguaggio (qual'è quella talvolta espressa nella documentazione delle librerie standard del JRE di Sun Microsystem) a qualcuno venga in mente di fare qualcosa con l'indirizzo del puntatore per poi scoprire che per una diversa versione di Java il proprio codice non funziona più e concludere che Java non è portabile. Come dire che siccome la moglie di Tizio tradisce suo marito allora Caio è cornuto. Facciamo attenzione, tutto qui.

[71104]

Originariamente inviato da PGI-Bis

Per specifiche intendo le specifiche del linguaggio di programmazione Java, quelle che stabiliscono cosa è linguaggio di programmazione Java e cosa no.

di sicuro la tua idea di specifiche include anche il reference delle classi standard e dei metodi visto ciò che scrivi:

Originariamente inviato da PGI-Bis

supponiamo che le specifiche dicano implicitamente o esplicitamente che il valore restituito da System.identyHashCode coincide con il valore del puntatore all'oggetto. [...]

[PGI-Bis]

La mia idea di specifiche include ed è limitata al libro che conosci. Per la cronaca raramente metto le parole a caso. Nella fattispecie il grassetto andava su "supponiamo che".

[71104]

Originariamente inviato da PGI-Bis

La mia idea di specifiche include ed è limitata al libro che conosci.

cioè quale?

Per la cronaca raramente metto le parole a caso. Nella fattispecie il grassetto andava su "supponiamo che".

dare per scontato un "supponiamo che esistano delle specifiche che contemplino l'esistenza di classi e metodi standard che in realtà non sono contemplate" mi pareva un po' troppo

[PGI-Bis]

The Java Language Specifications, terza edizione.

Non fare il glottologo! "Supponiamo che" da il via ad un discorso ipotetico: se nel discorso c'è qualcosa che non corrisponde alla realtà rientra nell'ipotesi. Se mancassero elementi privi di una controparte reale allora non supporremmo più un bel nulla: sarebbe così e basta.

[71104]

Originariamente inviato da PGI-Bis

The Java Language Specifications, terza edizione.

quella non è l'unica Bibbia di Java: non puoi dire che una cosa in merito a Java sarebbe vera solo se quel libro la dicesse. se vai nel reference delle classi standard ci trovi tutte cose altrettanto vere.

Non fare il glottologo!

che non so manco che è e perdona la mia limitatezza linguistica anche detta ignoranza

"Supponiamo che" da il via ad un discorso ipotetico: se nel discorso c'è qualcosa che non corrisponde alla realtà rientra nell'ipotesi.

si ma come dicevo nel mio post precedente, mi era sembrato che avessi messo nell'ipotesi cose un po' eccessive. allora supponiamo che la terra sia piatta e che due rette parallele si intersechino.

[^TiGeRShArK^]

Originariamente inviato da 71104

si ma come dicevo nel mio post precedente, mi era sembrato che avessi messo nell'ipotesi cose un po' eccessive. allora supponiamo che la terra sia piatta e che due rette parallele si intersechino.

Mi sa che quello che cercava di direti è che non è assolutamente garantito che sia il puntatore quello.
Un pò come il fatto che prima di Java 5 per quanto riguarda l'implementazione del Memory Manager vi era praticamente il vuoto e ognuno faceva un pò come cazz gli pareva.
Solo dalla versione 5 in poi è stata introdotta la relazione di ordering e la garanzia che le operazioni compiute seguissero una relazione di ordinamento (parziale).
Prima si andava solo a culo..
e se ti capitava un bug relativo a quel problema solo su certe implementazioni dela VM erano praticamente uccelli per diabetici

[PGI-Bis]

Le specifiche del linguaggio di programmazione Java, come tutte le specifiche di ogni linguaggio di programmazione, stabiliscono cosa sia "linguaggio Java" e cosa non lo sia.

Noi, in quanto studenti di quel linguaggio, dobbiamo valutare ogni affermazione alla luce di quel documento per decidere se sia o non sia riferibile al linguaggio di programmazione Java.

Se Tizio dicesse che il valore restituito dall'invocazione del metodo hashCode per un'istanza diretta di Object può essere cinque, direbbe una cosa ammissibile secondo le specifiche e, quindi, conforme a ciò che intendiamo con "linguaggio di programmazione Java"

Se Tizio dicesse che il valore restituito dall'invocazione di cui sopra è sempre cinque, direbbe una cosa non conforme alle specifiche vale a dire che starebbe parlando non del linguaggio di programmazione Java ma di qualcos'altro. Questo perchè l'hashCode di un'istanza diretta di Object è, per le specifiche, un qualsiasi valore di tipo int.

Nel nostro caso l'affermazione "il valore di hashCode() è quello del puntatore all'oggetto", a patto che il puntatore sia un valore non eccedente i 32 bit, è solo una delle possibilità consentite dalle specifiche. Più in generale, ogni regola che non contraddica alcuna norma indicata nelle specifiche del linguaggio X qualifica un'implementazione di X. Ecco che, allora, citare la faccenda del puntatore (che è verissima nel JRE a 32 bit di Sun), significa parlare non del linguaggio di programmazione Java ma di una concreta versione dello stesso. E non è una distinzione sottile perchè distinguere il linguaggio dalla sua implementazione significa anche poter distinguere tra programmi scritti in Java e programmi scritti in qualcos'altro: se io assumessi come vera l'affermazione secondo cui il valore di hashCode() corrisponde al valore del puntatore all'oggetto e scrivessi del codice che abbracci questa verità come sua precondizione otterrei codice non conforme alle specifiche e dunque non "Java".

Il glottologo è uno studioso di lingue: ti ho dato (amichevolmente&scherzosamente) del glottologo perchè ti impunti sui termini, a mo' di picchio. E picchiete picchiete picchiete... Lascia stare la parola e considera il senso del discorso. Altrimenti qui non ne saltiamo più fuori.

[71104]

Originariamente inviato da ^TiGeRShArK^

Mi sa che quello che cercava di direti è che non è assolutamente garantito che sia il puntatore quello.

ah ma lo so

[...] e se ti capitava un bug relativo a quel problema solo su certe implementazioni dela VM erano praticamente uccelli per diabetici

*volatili per diabetici