Livello di programmazione con vari linguaggi, allocazione dinamica della memoria

[mjordan]

Originariamente inviato da k0nt3

comunque il C# è un linguaggio fantastico! peccato che lo ha acquistato MS

Il C# è uno standard ECMA. Quindi non è poi tanto diverso dal C o dal C++. Anzi, lo puoi considerare addirittura piu' liberale di Java. Peccato che non si possa dire lo stesso per le API chiaramente.

[mjordan]

Originariamente inviato da ekerazha

In C/C++ non ho mai scritto da solo programmi lunghi migliaia di righe, ma in altri linguaggi in cui "l'errore è sempre dietro l'angolo" si (come per il PHP le varie "sql injection", "directory transversal", "cross scripting" etc.) e sono abbastanza sicuro sul fatto che non contenessero falle di sicurezza, poichè quando sviluppo presto la massimo cura ed attenzione agli aspetti più svariati (efficienza, sicurezza, pulizia del codice), il che lascia davvero poco spazio ad errori di questo genere (ho detto "abbastanza" perchè certamente qualcuno può essermi sfuggito... quale essere umano sono ben lontano dalla divina perfezione, ma certamente mi considero notevolente più "attento" rispetto ad alcuni sviluppatori che ho avuto l'occasione di conoscere nella mia "giovane vita"). Come già detto (di nuovo) *nessuno* (spero) afferma che vi sia un programmatore che non commette alcun errore, ma sicuramente c'è chi ne commette di più e chi ne commette meno. Mi sembra un discorso ragionevole.

Come volevasi dimostrare
La "sicurezza" che hai proviene da due elementi di giudizio:

1) Sicurezza che in fondo non lo è.
2) Sicurezza certa dovuta a estrema semplicità del codice trattato.

Io credo che la tua sia un mix di entrambi i punti. 2000 righe di codice C/C++ inolte non sono proprio la stessa cosa che 2000 righe di codice PHP, vista "l'indulgenza sintattica" per cui questo linguaggio è famoso. Lo stesso dicasi per SQL.

[cionci]

mjordan: dai...non alimentiamo la polemica...ormai il discorso si era spostato su altri lidi

[-fidel-]

Originariamente inviato da cionci

mjordan: dai...non alimentiamo la polemica...ormai il discorso si era spostato su altri lidi

Tra l'altro un bel lido per questo thread. Allora ragazzi ci siamo? TigerShark, ti ritrovi sul "ridimensionamento"?

[mjordan]

Originariamente inviato da 71104

mi sono perso nel thread e non ho più capito chi aveva ragione e chi no :-|
comunque dico la mia:

1) secondo me un linguaggio in cui l'allocazione dinamica della memoria disponga di un sistema di garbage collection (Java e simili insomma ) permette per definizione al programmatore di strafregarsene di deallocare memoria e di non commettere leaks (è precisamente quello che stiamo facendo noi di Diamond Crush: mai deallocato un oggetto, mai nemmeno richiamato il metodo che si usa in Java per la finalizzazione; forse giusto in una classe, per chiudere le librerie sonore, ma in caso quello sarebbe un resource leak, non proprio un memory leak)

No? Leggi il link che ho postato dietro

2) la definizione del C come linguaggio di "medio livello" mi sembra buona, anche se (suppongo) inventata sul momento; faccio un esempio pratico per spiegare la mia visione e come mai ritengo che sia una definizione molto adatta:

No no affatto. In molti cercano di classificare il medio livello, invece, anche se non è mai entrato di fatto come "voce di catalogazione".

la motivazione mi sembra più che evidente no? non è solo un fatto di estetica sintattica e di parentesi graffe come scritto da mjordan: il C e il C++ si trovano a metà tra il bash e l'assembly perché permettono un controllo su diversi aspetti funzionali decisamente superiore a quello permesso dal bash e ma magari inferiore a quello dell'assembly (se escludiamo il caso in cui, tramite l'uso di estensioni sintattiche specifiche di un compilatore, un sorgente C/C++ contenga degli stub scritti in assembly).

Quindi Pascal che consente di manipolare i puntatori e di basso livello. . .

Esempio pratico: proprio la memoria dinamica e i puntatori. con linguaggi di medio livello (come C, C++, Delphi, e altri) è 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; col bash invece non posso fare alcunché di tutto ciò; o meglio, da quel poco che conosco di questo linguaggio sarebbe possibile banalmente tramite un altro programma (scritto magari in C o C++) ed eseguito da una shell bash, ma così ovviamente si rende necessario l'uso dell'altro linguaggio e quindi non possiamo considerarla tutta una potenzialità del bash.

Appunto... Delphi è di medio livello....

se mi obiettate che il bash non va bene come esempio di linguaggio di alto livello allora vi faccio immediatamente un altro esempio che secondo me (giudizio totalmente empirico) è ad un livello sempre alto, ma un po' più "basso" rispetto al bash: il Java. di nuovo, con Java non posso certo fare tanti bei giochetti coi puntatori che invece in C, C++ e Delphi posso fare tranquillamente (ed è proprio questa una delle caratteristiche migliori di Java: in Java praticamente i buffer overflow e i buffer overrun non esistono!).

Ok. Ma "il bash" non è un linguaggio. BASH significa Bourne Again SHell ed è una shell. E' semplicemente uno scripting language che è diverso da un linguaggio di programmazione.

[^TiGeRShArK^]

Originariamente inviato da cionci

Ma dov'era il apssaggio epr riferimento prima

riempiva l'array passandogli per valore la copia del riferimento della variabile di classe contenente l'array a quanto ho capito.....
infatti quella variabile era di tipo void...
in realtà avrebbe potuto semplicemente accedervi dal metodo ora ke ci penso senza passargli l'array poichè lo vedeva come variabile di classe se ricordo bene il codice...

[-fidel-]

Originariamente inviato da ^TiGeRShArK^

non lo puoi ridimensionare..
Puoi solo allocare un nuovo array della dimensione nuova perdendo il riferimento al vecchio....
Quello che dici tu lo puoi fare con arraylist, vector, e tutti gli oggetti di tipo collection.
gli Array in java sono infatti per definizione strutture a lunghezza fissa....

Per definizione sì, ma a runtime puoi renderli array dinamici, con il seguente semplice metodo:

int x[] = new int [20];
...
x = new int [40];

Ovviamente perdi il contenuto di x perchè x viene distrutto e riallocato.

[MenageZero]

Originariamente inviato da -fidel-

Hai ragione scusami, sono stato molto poco chiaro. Io (ma non solo io) lo chiamo ridimensionamento, e mi spiego meglio.
Nella funzione che ho scritto, quando la lunghezza del buffer non basta più, ho bisogno di crearne un altro più grande che andrà bene. Ora, se reinstanzio la stessa variabile, la vecchia memoria viene distrutta (perdendo tutto il contenuto) e viene riallocato con la nuova dimensione (ecco il ridimensionamento. Nell'esempio il problema sta nel fatto che, una volta riallocato, il buffer NON viene cancellato dal GC perchè il suo reference NON è nel metodo ma nella classe!

beh magari il gc non interviene sul "vecchio" array contestualmente alla nuova allocazione(dato che anch'essa è nel metodo) ma potrà farlo in qualunque momento futuro quando riterrà opportuno (al limite non mentre è in secuizione quel metodo se tu dici che c'è questo vincolo) se necessario anche prima che venga dereferenziato l'oggetto LeakyChekSum...

quindi non ho capito come nascerebbe un vero mem leaky, cioè cosa renderà inattaccabili dal gc le vecchie istanze di byteArray non più referenziate ?

[cionci]

Originariamente inviato da -fidel-

Ovviamente perdi il contenuto di x perchè x viene distrutto e riallocato.
Nell'esempio che ho fatto però, non viene distrutto...

Sì...viene distrutto... C'è anche scritto nel link...
At the very least, this puts pressure on the garbage collector and requires more frequent collections;

[mjordan]

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 ti riferisci al metodo finalize(), neanch'esso ti da la certezza di far entrare in azione il Garbage Collector. Esso in realtà stabilisce soltanto che il Garbage Collector debba tener conto di ciò forzatamente al momento della sua esecuzione, ma non è un richiamo "esplicito" di far entrare in funzione il Garbage Collector.
Il metodo finalize() infatti non fa entrare in azione il Garbage Collector come si pensa.
Una cosa importante da sapere è che finalize() viene chiamato solo PRIMA di essere eseguito il garbage collector e non quando un'oggetto esce dall'ambito. Quindi non c'è un modo esatto per sapere quando finalize() venga chiamato. E' una precisazione importante. finalize() non dev'essere considerato come un distruttore di classe, insomma.

Se non ti riferivi a finalize(), chiedo venia allora....

[-fidel-]

Originariamente inviato da MenageZero

beh magari il gc non interviene sul "vecchio" array contestualmente alla nuova allocazione(dato che anch'essa è nel metodo) ma potrà farlo in qualunque momento futuro quando riterrà opportuno (al limite non mentre è in secuizione quel metodo se tu dici che c'è questo vincolo) se necessario anche prima che venga dereferenziato l'oggetto LeakyChekSum...

quindi non ho capito come nascerebbe un vero mem leaky, cioè cosa renderà inattaccabili dal gc le vecchie istanze di byteArray non più referenziate ?

C'è una incomprensione di fondo. Il problema risiede nel fatto che, ad esempio:

1) istanzio 'byteArray' da 10 mega e la uso
2) ho bisogno di un buffer più grosso: reistanzio byteArray da 20 Mb. i 10 mega di prima vengono subito rimossi, e ne vengono riallocati 20.
3) il GC rimuoverà i 20 mega solo quando vado a cancellare la classe!

Non è un memory leak classico, viene chiamato memory leak di tipo "object loitering", quel buffer viene tranquillamente eliminato quando rimuovo l'intera classe, ma nel frattempo sta lì a rubare inutilmente memoria.

[cionci]

Originariamente inviato da MenageZero

quindi non ho capito come nascerebbe un vero mem leaky, cioè cosa renderà inattaccabili dal gc le vecchie istanze di byteArray non più referenziate ?

Da quello che ho capito questo memory leak...definito "object loitering"...cotinua a tenere allocata (e non raggiungibile dal GC, perchè sempre referenziata) l'istanza corrente del vettore...anche quando alla classe non serve più calcolare check sum...e rimarrà occupata fino a quando la classe stessa non verrà distrutta...

Secondo me non è definibile memory leak... E' come se io in C mi tenessi in una variabile globale un puntatore ad un vettore ottenuto con realloc...e poi quando non mi serve più non chiamo volutamente la free... A me sembra più un design non corretto...

[-fidel-]

Originariamente inviato da cionci

Sì...viene distrutto... C'è anche scritto nel link...
At the very least, this puts pressure on the garbage collector and requires more frequent collections;

Certo Come detto prima, ho studiato queste cose proprio da quei whitepapers.

[cionci]

Originariamente inviato da -fidel-

Certo Come detto prima, ho studiato queste cose proprio da quei whitepapers.

Cercavo solo di far capire agli altri la situazione...cioè qui si è cercato di fare un'ottimizzazione...rendendo sempre disponibile in cache il vettore (ogni nuova istanza si intende)... L'errore secondo me è qui: cercare di ottimizzare...

Se si cerca di ottimizzare allora bisogna ottimizzare anche LeakyCheckSum...in modo da rendere il suo ciclo di vita il più corto possibile...
Alla base c'è comunque un errato design e non un errore di coding...come per la maggior parte dei memory leak...

[MenageZero]

Originariamente inviato da -fidel-

Per definizione sì, ma a runtime puoi renderli array dinamici, con il seguente semplice metodo:

int x[] = new int [20];
...
x = new int [40];

Ovviamente perdi il contenuto di x perchè x viene distrutto e riallocato.

ma lo dici anche tu!

ripeto: "...riallocato"

anche se quando viene distrutto (dal gc) non lo sai a priori, la mem non più usata dal nuovo array, può essere "preda" del gc! e il leak ?(ovviamente riferito al famoso esempio dove il punto è lo stesso)

[-fidel-]

Originariamente inviato da cionci

Da quello che ho capito questo memory leak...definito "object loitering"...cotinua a tenere allocata (e non raggiungibile dal GC, perchè sempre referinziata) l'istanza corrente del vettore...anche quando alla classe non serve più calcolare check sum...e rimarrà occupata fino a quando la classe stessa non verrà distrutta...

Benissimo

Originariamente inviato da cionci

Secondo me non è definibile memory leak... E' come se io in C mi tenessi in una variabile globale un puntatore ad un vettore ottenuto con realloc...e poi quando non mi serve più mi scordo di chiamare la free... A me sembra più un design non corretto...

Non so cosa intendi per design non corretto, però può fare comodo, a livello di design, avere un buffer dichiarato non nel metodo (magari quando deve essere usato da più metodi e non vuoi che venga continuamente allocato e liberato). Poi però bisogna stare attenti! Questo era per far vedere che il GC non ti salva sempre dai problemi di memoria. Questo non è un memory leak "in senso stretto" della definizione, è solo di un tipo diverso, ma ti dà sempre grossi problemi. La differenza che ci vedo da un memry leak standard è che comunque, all'interno dell'applicazione, la memoria istanziata da quella classe è comunque raggiungibile (non a caso viene distrutta quando distruggo l'oggetto).

[-fidel-]

Originariamente inviato da MenageZero

ma lo dici anche tu!

ripeto: "...riallocato"

anche se quando viene distrutto (dal gc) non lo sai a priori, la mem non più usata dal nuovo array, può essere "preda" del gc! e il leak ?(ovviamente riferito al famoso esempio dove il punto è lo stesso)

Mi pare di averlo già detto... ok ripeto

Non è un leak "nel senso stretto" del termine, perchè comunque quella memoria prima o poi sarà raggiungibile dal GC (in particolare quando distruggo la classe), ma fino a quando quell'oggetto è istanziato, quel buffer rimane lì rubando inutilmente memoria (anche molta memoria...). E' un particolare tipo di memory leak, non meno pericoloso del leak "per definizione", chiamato "memory leak di tipo object loitering".

[cionci]

Originariamente inviato da -fidel-

Non so cosa intendi per design non corretto, però può fare comodo, a livello di design, avere un buffer dichiarato non nel metodo (magari quando deve essere usato da più metodi e non vuoi che venga continuamente allocato e liberato).

Design nel senso di "progettazione" della classe... E' chiaro che se serve a più metodi è utile...ma se serve ad un solo metodo e lo si fa per rendere l'applicazione l'0.5% (ho tirato a caso) più veloce perchè resta in cache...allora si parte da un presupposto errato...

[-fidel-]

Originariamente inviato da cionci

Se si cerca di ottimizzare allora bisogna ottimizzare anche LeakyCheckSum...in modo da rendere il suo ciclo di vita il più corto possibile...
Alla base c'è comunque un errato design e non un errore di coding...come per la maggior parte dei memory leak...

Straquoto. I memory leak (e simili) sono fondamentalmente "errori" (normalmente poco visibili), di programmazione, ed il povero GC poco ci può fare...

[-fidel-]

Originariamente inviato da cionci

Design nel senso di "progettazione" della classe... E' chiaro che se serve a più metodi è utile...ma se serve ad un solo metodo e lo si fa per rendere l'applicazione l'0.5% (ho tirato a caso) più veloce perchè resta in cache...allora si parte da un presupposto errato...

Capito ...e sono d'accordo con te.