Livello di programmazione con vari linguaggi, allocazione dinamica della memoria

[^TiGeRShArK^]

Originariamente inviato da -fidel-

Con piacere, domattina però, adesso sto uscendo Ciao!

ok a domani allora

[-fidel-]

Originariamente inviato da ^TiGeRShArK^

non scompaiono TOTALMENTE, però ti assicuro ke è molto piu' facile lavorare con un GC ke faccia il lavoro sporco, mentre tu ti puoi impegnare di piu' nella scrittura nel codice vero e proprio...

Questo è poco ma sicuro, poi dipende anche dai casi, se allochi molti blocchi piccoli di memoria o pochi blocchi grandi (per l'efficienza dell'applicazione intendo), oppure se devi preoccuparti che il GC è asincrono.

Originariamente inviato da ^TiGeRShArK^

a proposito.. io sapevo ke solo nel caso dei riferimenti circolari il GC veniva messo in crisi (e cmq quello di Java, quello di C# era esente da questo problema) in quali altri casi il GC in java non svolge il suo compito (a parte quando non effettui una close() ovviamente.. ma quella mi sa ke è la base della programmazione....)

il GC di .NET non è di tipo tracing, non reference counting (ecco perchè non soffre del problema delle liste circolari come Java). Però appunto, avevo sentito che c'è un modo di creare (ad esempio) una lista circolare in Java senza mettere in crisi il suo GC. Si parlava di "etichettamenti" di puntatori, di cui ti faccio un esempio domani, però volevo approfondire, dal momento che in Java il GC lo devi usare "per forza"

[71104]

premesso che purtroppo conosco molto poco C# e .NET:

Originariamente inviato da -fidel-

Quindi stai dicendo che un GC evita sempre i memory leaks?

quasi sempre perché alla fine molti tipi di leak (non tutti) si traducono sempre in memory leaks; per es. in Win32 un handle leak sempre un memory leak è. però diciamo che il Garbage Collector nel 90% dei casi si, mi evita i memory leak.

ma volendo addirittura fare un discorso tecnicamente più preciso, la risposta è definitivamente si, in un linguaggio dotato di Garbage Collector come Java è sempre impossibile commettere memory leaks e sai perché? perché per commetterli devi per forza usare una libreria esterna (OpenAL nel caso di Diamond Crush)

Ma bash è un LINGUAGGIO SCRIPT!!

è un linguaggio di programmazione; ed è di alto livello.

Questo va ad inficiare tutto il tuo discorso successivo....

non vedo in che modo, a me pare che fili tutto; spiegati meglio e sarò felice di ricredermi (o di contraddirti )

Non obietto, è proprio sbagliato!

come sopra; e comunque guarda che rimane sempre l'esempio alternativo con Java

Spero tu stia scherzando!!

esempio di buffer overflow in Java puro senza uso di JNI o librerie esterne? ho controllato proprio adesso e col JDK 1.5 questo codice lancia un'eccezione, avvisando quindi il programmatore dell'overflow e rendendo impossibile la continuazione silenziosa del codice vulnerabile:

int v[] = new int[5];
for (int i = 0; i < 6; i++) {
	int j = v[i];
}

se riesci a scrivermi un programma Java che fa un buffer overflow o un overrun hai tutta la mia stima
e in Java puro, perché se l'overflow lo fa una libreria nativa scritta in C++ a cui accedi da Java con JNI allora grazie al
e tante volte non riuscissi a scrivermi tale codice, dichiarami un doppio puntatore a una variabile membro come si fa? in altre parole traducimi questo:

class Foo {
public:
	int bar;
	int *pbar;
	int **ppbar;
	Foo() {
		pbar = &bar;
		ppbar = &pbar;
	}
};

e scusa ma anche senza arrivare al doppio puntatore penso che avresti difficoltà anche col puntatore singolo...

[71104]

Originariamente inviato da ekerazha

Ti prego 71104 non rispondergli!!

ops

[cionci]

Ragazzi...ho visto il mio primo flame in Programmazione... Cerchiamo di darci una calmata...

Originariamente inviato da 71104

è possibile allocare e deallocare a piacere, è possibile creare dangling pointers facendo addizioni, castando a int, maneggiando a piacere e ri-castando a puntatore, eccetera eccetera;

Certo che programmare così in C++ è un po' da matti Ti posso capire con il C in cui c'è una certa "tradizione", ma il C++ anche se ti "offre" comunque questi strumenti, li vedrai messi in opera raramente in un programma serio...

Originariamente inviato da -fidel-

Mi prendi in giro sì? Per essere chiari riquoto

No

Mi pare chiaro, se l'italiano è ancora una lingua "esatta", che ho voluto dire "il GC è fatto per deallocare automaticamente memoria, ma giacché non sempre lo fa bene, in alcuni casi devo agire manualmente. Quali sono questi casi?" Se vuoi avere il controllo completo, il GC neanche lo usi, ma se lo usi, non puoi farci affidamento totale e quindi meglio sapere i casi in cui commette errori. Comunque non mi sembrava il caso che (io) precisassi, sarei curioso di vedere dove mi avresti "attaccato". Me lo dici martedì.
Per ora in bocca al lupo per l'esame!

Riquotiamo questa parte...

mi incasino nel capire se quella memoria verrà liberata e quindi quando mi devo preoccupare e quando no

Tu ti devi preoccupare SEMPRE di liberare la memoria, non solo quando pensi che il GC lo possa fare al posto tuo. Per l'appunto l'italiano mi sembra abbastanza "esatto"

Originariamente inviato da ^TiGeRShArK^

ehm....scusa se torno a ropetermi...
ma come fai a deallocare la memoria in java???
ogni oggetto, come ho già detto prima, non è altro ke un "puntatore" all'heap....
Tu al massimo puoi scrivere object = null; ma questo non equivale a deallocare la memoria, serve a eleiminare il riferimento in modo ke il GC possa deallocare la memoria.
Ma tu non PUOI deallocare la memoria manualmente, al max puoi lanciare un esecuzione del GC subito dopo aver posto l'oggetto a null, ma questa è una pratica ke, tranne in casi particolari, è FORTEMENTE sconsigliata, perchè il GC agisce già di suo, se ti metti ad invocarlo troppe volte non farai altro ke peggiorare le prestazioni del tuo programma dato ke il GC dovrà girare piu' volte e occuperà risorse sulla tua makkina....

Se rileggi bene ho precisato "quando non esistono limiti intrinseci del linguaggio".
Comunque come dice -fidel- è probabilmente comunque possibile (JNI rules ), anche se forse è un po' una forzatura.

P.S.
Torno a ripassare che alle 16.30 ho l'esame

[rdefalco]

Originariamente inviato da ekerazha

Tu ti devi preoccupare SEMPRE di liberare la memoria, non solo quando pensi che il GC lo possa fare al posto tuo. Per l'appunto l'italiano mi sembra abbastanza "esatto"

Non capisco perché ostinarsi su questa questione, sia da una parte che dall'altra Uno dei falsi miti sui Garbage Collector è proprio il fatto di credere che una gestione manuale sia sicuramente più efficiente. Ovviamente, qualora il programmatore scelga di usare un GC, conoscerne le funzionalità e i limiti sarà l'unico modo per poter prevenire i casi in cui questo metodo non può funzionare. Da qui a dire che bisogna sembre liberare manualmente la memoria ne passa di acqua. Nella mia opinione, naturalmente.

[rdefalco]

P.S. e pure in bocca al lupo per l'esame, và

[-fidel-]

Originariamente inviato da 71104

premesso che purtroppo conosco molto poco C# e .NET:

quasi sempre perché alla fine molti tipi di leak (non tutti) si traducono sempre in memory leaks; per es. in Win32 un handle leak sempre un memory leak è. però diciamo che il Garbage Collector nel 90% dei casi si, mi evita i memory leak.

ma volendo addirittura fare un discorso tecnicamente più preciso, la risposta è definitivamente si, in un linguaggio dotato di Garbage Collector come Java è sempre impossibile commettere memory leaks e sai perché? perché per commetterli devi per forza usare una libreria esterna (OpenAL nel caso di Diamond Crush)

Se parli di 90 % sono d'accordo, se parli di "definitivamente sì" non lo sono più. Parlando nello specifico di Java, volendo fare un discorso "tecnicamente più preciso" come dici tu, puoi leggere questo articolo. Ovvio che i GC riducono i memory leaks, è uno dei motivi per cui sono stati pensati, ma non li eliminano del tutto (magari!).

Originariamente inviato da 71104

è un linguaggio di programmazione; ed è di alto livello.

non vedo in che modo, a me pare che fili tutto; spiegati meglio e sarò felice di ricredermi (o di contraddirti )

Su Java sei più ferrato, su bash molto meno a quanto pare... Ti consiglio di leggere qui per farti un'idea più precisa. Nella prima riga leggerai:
Bash is the GNU shell, or command language interpreter.
che vuol dire che bash è un linguaggio script, alla carlona lo puoi pensare come una estensione (ampia) dei file batch del DOS. Il suo linguaggio può sempbrare quello di un linguaggio di programmazione (come semantica) ma non lo è, quindi non lo puoi assolutamente paragonare al C++ o al Java quanto parli di "livelli" di linguaggio.

Originariamente inviato da 71104

come sopra; e comunque guarda che rimane sempre l'esempio alternativo con Java

Sì infatti inficiavi fino a questo punto, se parli di Java il discorso cambia e ne possiamo discutere

Originariamente inviato da 71104

esempio di buffer overflow in Java puro senza uso di JNI o librerie esterne? ho controllato proprio adesso e col JDK 1.5 questo codice lancia un'eccezione, avvisando quindi il programmatore dell'overflow e rendendo impossibile la continuazione silenziosa del codice vulnerabile:
--cut--

Avevo capito male. Io mi riferivo anche ai buffer overflow interni alla JVM, non causati dal codice In java la JVM mette in pratica diversi meccanismi per evitare il buffer overflow (non a caso non ci sono mai riuscito a fare dei bof con il java), però leggevo sul sito dlla IBM che:
"Java rende quasi impossibile il buffer overflow". Si riferiscono al fatto che tali meccanismi di controllo possono fallire, non a caso neanche la Sun si azzarda a dire che il suoi meccanismi di bof checking sono infallibili. Ovviamente da programmatore Java, scrivo un programma pensando che il bof sia impossibile, avendo in mente
"se il bof checking fallisce che ci posso fare?", ma proprio ad essere super scrupolosi quando mi accorgo che ci puo' essere un bof lo correggo subito Poi con la JNI puoi fare un po' di tutto, ma questo esula dal Java puro che tu, da quello che ho capito ora, volevi trattare. Cmq il tuo ragionamento è esatto, avevo proprio travisato io

[-fidel-]

Originariamente inviato da ekerazha

Tu ti devi preoccupare SEMPRE di liberare la memoria, non solo quando pensi che il GC lo possa fare al posto tuo. Per l'appunto l'italiano mi sembra abbastanza "esatto"

No se estrapoli una frase da una frase più lunga o da un discorso. Questo è lavoro da politici. Il ragionamento che facevo è chiaro, si parlava di GC ed era per far capire che volevo sapere quando un GC fallisce. Quindi non fare giochini di estrapolazione per avere necessariamente ragione anche quando non ce l'hai

[-fidel-]

Originariamente inviato da rdefalco

Non capisco perché ostinarsi su questa questione, sia da una parte che dall'altra Uno dei falsi miti sui Garbage Collector è proprio il fatto di credere che una gestione manuale sia sicuramente più efficiente. Ovviamente, qualora il programmatore scelga di usare un GC, conoscerne le funzionalità e i limiti sarà l'unico modo per poter prevenire i casi in cui questo metodo non può funzionare. Da qui a dire che bisogna sembre liberare manualmente la memoria ne passa di acqua. Nella mia opinione, naturalmente.

Sì ma infatti il discorso è stato spostato da tutt'altra parte: ovviamente estrapolando singole frasi è ovvio che accade questo. Inizialmente io volevo proprio, citandoti:

Originariamente inviato da rdefalco

conoscerne le funzionalità e i limiti

Le funzionalità già le conosco (a volte uso il GC di .NET), volevo approfondirne i limiti.

Originariamente inviato da -fidel-

No se estrapoli una frase da una frase più lunga o da un discorso. Questo è lavoro da politici. Il ragionamento che facevo è chiaro, si parlava di GC ed era per far capire che volevo sapere quando un GC fallisce. Quindi non fare giochini di estrapolazione per avere necessariamente ragione anche quando non ce l'hai

La prima volta ho quotato tutta la frase (o meglio ho detto il numero del post) ma tu non hai capito, allora per semplificarti la comprensione ho estrapolato solo la frase "saliente" (frase che hai detto tu... di certo non l'ho inventata io).

Rianalizziamola per bene:

E' per questo che sono restio ad usare i GC,

Appurato che sei "restio", veniamo al suo perchè, che hai subito specificato:

mi incasino nel capire se quella memoria verrà liberata e quindi quando mi devo preoccupare e quando no!

Appurato che ti incasini "nel capire se quella memoria verrà liberata" ti chiedi quando te ne devi preoccupare e quando no (cosa ribadita anche nel #35, che non quoterò per evitare che tu dica che "estrapolo per sfalsare la realtà")... e la risposta sarebbe appunto *SEMPRE*, come ho già detto... non è una scelta (se non per l'eccezione di cui ho già parlato di limiti intrinseci al linguaggio).

Mi sa che me li devo studiare in modo più approfondito, al momento non ho tutti gli argomenti per valutare

Nuovamente bravo

[k0nt3]

Originariamente inviato da ^TiGeRShArK^

ancora mi sfugge cosa si intende per medio livello...
ke io sappia assembly e codice in linguaggio makkina sono programmazione a basso livello...
poi ci sono subito sopra C --> C++ --> Java, C# --> Python, ruby almeno per come la vedo io una classificazione....
ma comunque tutti i linguaggi sopra il C (ke in particolari versioni se non erro è un pò a metà strada) sono ad alto livello... forse si possono definire ad altissimo livello quelli come python e ruby tnt x enfatizzare la distinzione.... ma medio livello non l'avevo mai sentito fino ad oggi...

quoto! se uno definisce il "medio livello" dovrebbe scrivere un libro

[k0nt3]

Originariamente inviato da -fidel-

Personalmente faccio notare, quando alcuni dicono che in C puoi fare cose che in altri linguaggi non puoi fare, che l'idea non è corretta.

basta pensare al C# che ti permette di usare i puntatori! la maggiorparte della gente pensa che col C# non si possono fare le porcherie del C ! comunque sarebbe quantomeno stupido usare il C# in quel modo se c'è una strada alternativa..

[k0nt3]

Originariamente inviato da ekerazha

Appurato che ti incasini "nel capire se quella memoria verrà liberata" ti chiedi quando te ne devi preoccupare e quando no (cosa ribadita anche nel #35, che non quoterò per evitare che tu dica che "estrapolo per sfalsare la realtà")... e la risposta sarebbe appunto *SEMPRE*, come ho già detto... non è una scelta (se non per l'eccezione di cui ho già parlato di limiti intrinseci al linguaggio).

il tuo "sarebbe appunto *SEMPRE*" vuol dire "dovrebbe essere sempre"? sai.. non voglio fraintendere di nuovo!
vai a chiedere ai programmatori di eclipse o di azureus se il GC li ha liberati totalmente dalla gestione della memoria! chissà che tipo di ottimizzazioni si usano in programmi di grandi dimensioni... non a caso si può avere un certo controllo sul GC via codice.. mi pare che il .NET permette di fare qualcosa in più di java però!

[-fidel-]

Originariamente inviato da ^TiGeRShArK^

ecco perfetto.. mi sfuggiva il termine
cmq.... in ke senso li puoi "etikettare" in java???
puoi fare qualke esempio?
finora non ho mai visto niente di simile....
sempre se ho capito quello ke intendi...

Ok mi spiego meglio. Grazie al package "java.lang.ref" puoi fare in modo di trattare i riferimenti ad oggetti in modo "personalizzato", così da influenzare (limitatamente) il GC di Java. La trattazione di tale package è un po' lunga, quindi ti rimando alla documentazione ufficiale sul sito della Sun:

Documentazione del package java.lang.ref

Il lavoro che sto facendo, e sul quale cercavo maggiori informazioni per sbrigarmi () è come usare efficacemente questo package.
Per il momento, sono arrivato a questo (è solo un esmpio dell'uso del package):

import java.lang.ref.*;

public class References {
  public static void main(String[] args) {
    Object weakObj, phantomObj;
    Reference ref;
    WeakReference weakRef;
    PhantomReference phantomRef;
    ReferenceQueue weakQueue, phantomQueue;

    weakObj    = new String("Weak Reference");
    phantomObj = new String("Phantom Reference");
    weakQueue    = new ReferenceQueue();
    phantomQueue = new ReferenceQueue();
    weakRef    = new WeakReference(weakObj, weakQueue);
    phantomRef = new PhantomReference(phantomObj, phantomQueue);

    // Mi accerto dell'esistenza dei "puntatori". Quello di tipo phantom
    // dovrebbe restituire "null" dal momento che è inaccessibile.
    System.out.println("Weak Reference: " + weakRef.get());
    System.out.println("Phantom Reference: " + phantomRef.get());

    // Annullo i riferimenti strong (gli oggetti allocati con 'new')
    weakObj    = null;
    phantomObj = null;

    // Chiamo il GC esplicitamente, per accodare tali riferimenti nel GC
    System.gc();

    // Controllo se il GC ha effetivamente accodato i references
    System.out.println("Weak accodato: " + weakRef.isEnqueued());
    // Provo a finalizzare il phantom reference, se non è stato già fatto
    if(!phantomRef.isEnqueued()) {
      System.out.println("Richiesta finalizzazione.");
      System.runFinalization();
    }
    System.out.println("Phantom accodato: " + phantomRef.isEnqueued());

    // Aspetto fino a quando il weak reference è in coda e lo rimuovo
    try {
      ref = weakQueue.remove();
      // 'ref' dovrebbe essere 'null'
      System.out.println("Weak Reference: " + ref.get());
      // Aspetto fino a quando il phantom reference è in coda e lo rimuovo
      ref = phantomQueue.remove();
      System.out.println("Phantom Reference: " + ref.get());
      // Devo cancellare anche il phantom referent, anche se la
      // get() ritorna 'null'
      ref.clear();
    } catch(InterruptedException e) {
      e.printStackTrace();
      return;
    }
  }
}

EDIT: questo per influenzare la "reachability" dei riferimenti per il GC.

[k0nt3]

Originariamente inviato da rdefalco

Non capisco perché ostinarsi su questa questione, sia da una parte che dall'altra Uno dei falsi miti sui Garbage Collector è proprio il fatto di credere che una gestione manuale sia sicuramente più efficiente. Ovviamente, qualora il programmatore scelga di usare un GC, conoscerne le funzionalità e i limiti sarà l'unico modo per poter prevenire i casi in cui questo metodo non può funzionare. Da qui a dire che bisogna sembre liberare manualmente la memoria ne passa di acqua. Nella mia opinione, naturalmente.

la gestione manuale "permette" di raggiungere l'ottimo! dico tra " perchè è ovvio che lo si può raggiungere solo in programma di 10righe ! invece con il GC rinunci a cercare l'ottimo in cambio di un ottimo compromesso tra gestione della memoria e semplificazione del codice.. e avere un codice più facile da leggere senz'altro aiuta a commettere meno errori! e questo compensa un pochino, ma di sicuro esiste una gestione manuale migliore da quella effettuata dal GC! guarda come è pesante eclipse o azureus per rendertene conto (anche se lì non influisce solo il GC ovviamente)...

[-fidel-]

Originariamente inviato da ekerazha

Appurato che ti incasini "nel capire se quella memoria verrà liberata" ti chiedi quando te ne devi preoccupare e quando no (cosa ribadita anche nel #35, che non quoterò per evitare che tu dica che "estrapolo per sfalsare la realtà")... e la risposta sarebbe appunto *SEMPRE*, come ho già detto... non è una scelta (se non per l'eccezione di cui ho già parlato di limiti intrinseci al linguaggio).

Hai fatto bene ad analizzare. La risposta alla mia domanda è quindi per te *SEMPRE*. Questo denota la tua scarsa competenza dell'argomento, e non ti voglio prendere in giro come hai fatto tu. Almeno potrei prenderti in giro sui fatti, a differenza tua che hai inventato, e questo post lo dimostra.
Anzi, potrebbe essere un'occasione per te di imparare cose nuove, sempre che non pensi di sapere già tutto sull'informatica eh! Ti prego NON rientriamo in polemica, ma ti faccio notare questo dal momento che mi hai offeso su basi inesistenti.
Forse è meglio che ti fermi...

[-fidel-]

Originariamente inviato da k0nt3

basta pensare al C# che ti permette di usare i puntatori! la maggiorparte della gente pensa che col C# non si possono fare le porcherie del C ! comunque sarebbe quantomeno stupido usare il C# in quel modo se c'è una strada alternativa..

Beh questo è sicuro