Livello di programmazione con vari linguaggi, allocazione dinamica della memoria

Originariamente inviato da Fx

giusto per esser preciso:

se vuoi vado avanti

se consideri l'insulto in senso stretto, tipo "sei un cretino", beh, c'è pure questo, da "sei solo un poverccio" in poi

se invece, come ritengo più corretto, si considera l'insulto in senso lato, metà delle parole che hai scritte le hai spese così, per dire - estrapolandone il succo - che gli altri sono cretini

comunque, chiuso il discorso,

Per l'appunto... nessuno di quelli che hai citato sono insulti volgari... quelli che tu chiami "insulti in senso lato" sono semplici considerazioni personali, assolutamente non volgari.
Inoltre ti consiglio di far caso a chi ha iniziato ad attaccare per primo l'interlocutore sul piano personale... ti consiglio di rileggere nuovamente il mio post #15 in modo da evitare di continuare questa sterile conversazione.

sarei curioso di vedere un po' di codice php scritto da te

Credo sia una curiosità condivisibile.

[cionci]

A tutti: per favore smettiamola...

[-fidel-]

Mi piace giocare con i puntatori

Originariamente inviato da 71104

e siccome (se la memoria non m'inganna) il compilatore non permette di addizionare due puntatori (che nell'esempio del B-albero sarebbero un indirizzo base e un offset), è necessario prima convertire a interi (possibilmente senza segno) e poi di nuovo a puntatori

Non t'inganna infatti, il compilatore non permette di addizionare direttamente due puntatori, però puoi fare il tutto senza passaggi intermedi, con un bel cast ad 'unsigned long int'.
Es:

#define UINT unsigned long int
...
char *pointer1, *pointer2;
UINT result;
...
result = (UINT)pointer1 + (UINT)pointer2;

Si può anche "estremizzare" il tutto:

#define UINT unsigned long int
...
char *pointer1, *pointer2, *respointer;
...
(UINT)respointer = (UINT)pointer1 + (UINT)pointer2;

In quest'ultimo esempio, però, il compilatore (testato con gcc 3.3.3) tira fuori il seguente warning:
warning: use of cast expressions as lvalues is deprecated
deprecato, ma funziona Di solito evito però questo secondo approccio.

EDIT: nel secondo approccio, si può togliere (seguendo il warning) il cast di respointer, salvo poi avere un warning diverso:
warning: assignment makes pointer from integer without a cast
Eh per forza....

[-fidel-]

Originariamente inviato da marco.r

Uhm, non lo considererei un leak, in fondo la memoria non viene persa, viene semplicemente messa da parte nella speranza che questo porti qualche vantaggio. Se quel metodo viene chiamata qualche decina di volte al secondo per file di dimensioni costanti, quella memoria è tutt'altro che inutilizzata. Dipende dall'uso che se ne fa.

Per questa considerazione ti riporto ai post precedenti

[-fidel-]

Originariamente inviato da 71104

be' ma non capisco tutta questa stranezza e insolitudine nel considerare il linguaggio Bash un linguaggio di programmazione... è talmente potente (per essere una shell) che ci si possono fare una miriade di cose che su Windows devono essere realizzate con necessariamente programmi appositi; gli script in Bash sono veri e propri programmi (interpretati naturalmente) che possono essere anche molto lunghi; per esempio al nostro corso il primo esonero consisteva nel creare esclusivamente in linguaggio Bash un clone del comando rsync... io vabbè non l'ho fatto perché ho fatto l'esame in modalità esame (non esoneri), però ho visto quello di un mio compagno (visto che tanto all'orale il prof mi deve fare un didietro così su Bash ) ed ammontava a un paio di centinaia di righe se ricordo bene. direi che il look and feel del linguaggio di programmazione c'è tutto

Sì, come detto prima, se la metti sul piano semantico e funzionale, bash è paragonabile ad un linguaggio di programmazione, come altri linguaggi scripting del resto. Il discorso che facevo io era un po' più sottile, semplicemente rimarcavo la differenza tra traduttore ed interprete. Bash infatti, giustamente si appoggia su comandi esterni precompilati (spesso di default in una installazione Unix, ma non sempre), tranne che per alcune funzioni built-in, ma come "modo di programmare" e come funzionalità convengo. A questo punto, come esempio ancora più calzante prenderei il TCL, che pur essendo interpretato, nasce come linguaggio di programmazione, con librerie e tutto. Lo stesso interprete TCL può essere usato come libreria C... E' solo una questione di terminologia, normalmente cerco di essere preciso per evitare fraintesi

[-fidel-]

Ancora sui "memory leaks" in Java. Spulciando tra la mia documentazione, cartacea e non, sull'argomento, mi sono imbattuto in questo post (preso da forum.java.sun.com) molto significativo, che parla proprio di come normalmente si intende il "memory leak" in java (non proprio in senso "tradizionale"). Ammetto che l'autore di questo testo possiede un dono di sintesi migliore del mio ():

Striktly speaking there could be no memory leaks in java than those known from C/C++.
A java "memory leak" is more like holding a strong reference to an object though i would never be needed anymore. The fact that you hold a strong reference to an object prevents the GC from deallocating it.
Think of an array of objects, think of a get/put protocoll on that array (stack like). You would have something like a highwater mark on your stack.
Say you have a (sketched) get method like

public Object get() {
    highWaterMark--;
    return stackArray[highWaterMark];
}

what happens after 5 inserts and 3 gets...
You have a situation like this in your stackArray.
stackArray[0] = obj0
stackArray[1] = obj1
stackArray[2] = obj2 <- highWaterMark
stackArray[3] = obj3
stackArray[4] = obj4

Note that indexes 2,3 and 4 still reference objects because our get method has not cleared those array members.
Although no other party might have a strong reference to those objects the GC can't collect them because the array is still holding a strong reference.

The rule is: In any composed object free, i.e. set to null, all references to part objects as soon as possible.

"Correct" version of our stack's get method is:

public Object get() {
    highWaterMark--;
    final Object result = stackArray[highWaterMark];
    stackArray[highWaterMark] = null; //clearing a strong reference
    return result;
}

EDIT: Si potrebbe risolvere penso anche utilizzando diversi tipi di reference oltre quello strong tramite il package 'java.lang.ref'.

[mjordan]

Fidel prima hai postato dei link riguardo ai memory leak in Java per caso? Ora non ho troppo tempo di leggere, mica me li potresti raggruppare in un post?
Grazie.

[-fidel-]

Originariamente inviato da mjordan

Fidel prima hai postato dei link riguardo ai memory leak in Java per caso? Ora non ho troppo tempo di leggere, mica me li potresti raggruppare in un post?
Grazie.

Certo, non c'è problema

Ho iniziato con questo:
http://www-128.ibm.com/developerworks/library/j-leaks/

per me è un buon articolo, anche se un po' datato (2001).

Poi ho fatto un altro esempio che avevo studiato dai vari whitepapers IBM che mi arrivano su CD, e cionci ha trovato il link al sito IBM che li contiene:

http://www-128.ibm.com/developerwork...-jtp01246.html

Da quel sito è possibile anche "saltare" ad altri articoli che trattano lo stesso tema, con soluzioni diverse.

Inserisco anche il link del manuale del package 'java.lang.ref', che fornisce metodi piuttosto raffinati per evitare i "memory leaks" java (influenzando limitatamente il GC):

http://java.sun.com/j2se/1.4.2/docs/...e-summary.html

Questo invece è l'indirizzo di un thread di un forum Java che tempo fa ho salvato su HD. Meno male che mi segno gli indirizzi Ho provato ed è ancora online:

http://forum.java.sun.com/thread.jsp...art=0&tstart=0

Mi pare siano tutti.
Ciao

EDIT: per tutti, sempre da forum sul sito della Sun, c'è anche quest'altro bel thread sui memory leaks Java:
http://forum.java.sun.com/thread.jsp...hreadID=446934
Fossi in voi lo leggerei davvero un caso "malefico"

[mjordan]

Originariamente inviato da -fidel-

Certo, non c'è problema

Ho iniziato con questo:
http://www-128.ibm.com/developerworks/library/j-leaks/

per me è un buon articolo, anche se un po' datato (2001).

Poi ho fatto un altro esempio che avevo studiato dai vari whitepapers IMB che mi arrivano su CD, e cionci ha trovato il link al sito IBM che li contiene:

http://www-128.ibm.com/developerwork...-jtp01246.html

Da quel sito è possibile anche "saltare" ad altri articoli che trattano lo stesso tema, con soluzioni diverse.

Inserisco anche il link del manuale del package 'java.lang.ref', che fornisce metodi piuttosto raffinati per evitare i "memory leaks" java (influenzando limitatamente il GC):

http://java.sun.com/j2se/1.4.2/docs/...e-summary.html

Questo invece è l'indirizzo di un thread di un forum Java che tempo fa ho salvato su HD. Meno male che mi segno gli indirizzi Ho provato ed è ancora online:

http://forum.java.sun.com/thread.jsp...art=0&tstart=0

Mi pare siano tutti.
Ciao

EDIT: per tutti, sempre da forum sul sito della Sun, c'è anche quest'altro bel thread sui memory leaks Java:
http://forum.java.sun.com/thread.jsp...hreadID=446934
Fossi in voi lo leggerei davvero un caso "malefico"

Ottimo grazie mille.

[^TiGeRShArK^]

Originariamente inviato da -fidel-

Ancora sui "memory leaks" in Java. Spulciando tra la mia documentazione, cartacea e non, sull'argomento, mi sono imbattuto in questo post (preso da forum.java.sun.com) molto significativo, che parla proprio di come normalmente si intende il "memory leak" in java (non proprio in senso "tradizionale"). Ammetto che l'autore di questo testo possiede un dono di sintesi migliore del mio ():

mmm...
cmq secondo me sono sempre dovuti ad errori concettuali...
a me ad esempio non sarebbe mai venuto in mente di usare un array per memorizzare degli oggetti il cui numero non è noto a priori, ma anzi tende a variare col passare del tempo...
la prima cosa che mi verrebbe in mente è utilizzare un ArrayList e usare i metodi get e remove...
un'implementazione ancora migliore è però ovviamente di usare la classe stack che è già fornita da java
in questo modo si risolve alla base il problema del memory leak e si evita lo sbattimento di reiplementare codice già esistente

[-fidel-]

Originariamente inviato da ^TiGeRShArK^

mmm...
cmq secondo me sono sempre dovuti ad errori concettuali...
a me ad esempio non sarebbe mai venuto in mente di usare un array per memorizzare degli oggetti il cui numero non è noto a priori, ma anzi tende a variare col passare del tempo...
la prima cosa che mi verrebbe in mente è utilizzare un ArrayList e usare i metodi get e remove...
un'implementazione ancora migliore è però ovviamente di usare la classe stack che è già fornita da java
in questo modo si risolve alla base il problema del memory leak e si evita lo sbattimento di reiplementare codice già esistente

Vero, ma il problema è che memory leaks e simili sono sempre errori di programmazione o di design (a meno che non sono buggate le librerie o nel caso di Java la JVM). Poi ci sono modi di programmare che portano più facilmente ad errori di memoria ed altri meno secondo me

[^TiGeRShArK^]

Originariamente inviato da -fidel-

Vero, ma il problema è che memory leaks e simili sono sempre errori di programmazione o di design (a meno che non sono buggate le librerie o nel caso di Java la JVM). Poi ci sono modi di programmare che portano più facilmente ad errori di memoria ed altri meno secondo me

yes.. ma in C ci sono molti piu' modi per capitare in un memory leak senza nemmeno rendertene conto...
in java quelli ke hai portato fino ad ora come esempio li avrei evitati di default, senza nemmeno fare considerazioni sul memory leak, per come sono abituato a programmare.....
in C onestamente qalke difficoltà in + c'è

[-fidel-]

Originariamente inviato da ^TiGeRShArK^

yes.. ma in C ci sono molti piu' modi per capitare in un memory leak senza nemmeno rendertene conto...
in java quelli ke hai portato fino ad ora come esempio li avrei evitati di default, senza nemmeno fare considerazioni sul memory leak, per come sono abituato a programmare.....
in C onestamente qalke difficoltà in + c'è

Questo è poco ma sicuro! Non a caso ci sono diverse librerie C++ che implementano i GC per semplificarti la vita, oppure in modo più semplice senza usare un GC ci sono gli smart pointer (il template auto_ptr in testa).
Anch'io in Java normalmente non faccio "memory leaks", ma in un paio di occasioni mi è capitato, niente di gravissimo trattando con sistemi da un Giga di memoria, ma ad alto rischio considerando che erano applicazioni eseguite h24... Purtroppo capita anche quello (ah, gli esempi riportati erano "memory leaks" particolarmente evidenti eh! )