Livello di programmazione con vari linguaggi, allocazione dinamica della memoria

[mjordan]

Originariamente inviato da ekerazha

Se rileggi bene potrai notare che il primo ad attaccare l'interlocutore (me) a livello personale è stato mjordan dicendo "che mi dovevo informare e che in vita mia avevo stampato al massimo gli elementi di un array": a quel punto mi sembrava doveroso comunicargli cosa vi fosse nella mia vita (che lui non può conoscere) e cioè che programmo da quando avevo 13 anni e sono studente di ingegneria informatica...

Certo, perchè se mi dici che i bug come buffer overflow e altri tipi di bug (per altro parlando di software programmati con l'ano riferendoti a Microsoft) derivano da persone che non sanno programmare, l'idea che dai con un simile commento è quella che invece tu in quei bug non ci sei incappato perchè non è che sai programmare, ma perchè non hai mai lavorato su niente di complesso. E' solo questo il punto. Su programmi di svariate milioni di righe di codice, anche gli sviluppatori top notch commettono centinaia di bug durante il ciclo di sviluppo. Quindi il discorso del non saper programmare non regge, visto che dal contesto stiamo parlando di software che per definizione, da gente che non sa programmare, non può essere proprio scritto. Il nocciolo della questione. Era diverso se parlavamo di programmi da qualche centinaia di righe. Allora ti potevo dare pure ragione.

[-fidel-]

Originariamente inviato da ekerazha

In seguito anche con -fidel- è partita una discussione ed anche qui il primo ad attaccare sul piano personale è stato lui con questa uscita "Dai non parlare di cose che non sai..." e precisamente nel post numero #76.

Però sei un po' permaloso!! Ti sei offeso per una cosa del genere? Ho letto quella affermazione sull'allocazione della memoria e ti ho risposto, ma se era un offesa sul piano personale... Che poi hai chiarito la tua posizione sull'argomento va bene, però dai, in quel post si capiva un'altra cosa non puoi non ammetterlo Se ti sei sentito attaccato sul piano personale da quella frase, scusami, ognuno ha una sensibilità diversa evidentemente

[mjordan]

Originariamente inviato da Fx

te lo dico da esterno, eh, perchè per quanto mi riguarda la tesi che alcuni studenti o laureati pensino di saper tutto perchè "l'hanno studiato" è stata abbondantemente dimostrata. ma d'altro canto ti potrei portare esempi su esempi vissuti sulla mia pelle.

per inciso, non ce l'ho con gli ingegneri in genere, eh, ben lungi da me l'idea. ce l'ho con ALCUNI ingegneri, o meglio, laureati in genere, i quali per aver fatto un esame si convincono di saper tutto di quella materia. con quelli normali invece ci vado molto d'accordo e ai quali ho dato volentieri una mano anche per gli studi, tant'è che ci sono tesi che sono più mie che di chi le ha esposte =)

Esatto. Soprattutto se si considera che un esame universitario non è nient'altro che l'ABC per poter cominciare a muovere i primi passi con una materia. Rapportando poi il discorso su campi dove chi ci lavora ha almeno 2 dottorati di ricerca in merito uniti a 30 anni di esperienza, fa capire come il tirare fuori il titolo sia quantomeno esilarante.
Io quando si parla di Microsoft mi vergognerei pure a dire che sono dottore...

[-fidel-]

Originariamente inviato da mjordan

Certo, perchè se mi dici che i bug come buffer overflow e altri tipi di bug (per altro parlando di software programmati con l'ano riferendoti a Microsoft) derivano da persone che non sanno programmare, l'idea che dai con un simile commento è quella che invece tu in quei bug non ci sei incappato perchè non è che sai programmare, ma perchè non hai mai lavorato su niente di complesso. E' solo questo il punto. Su programmi di svariate milioni di righe di codice, anche gli sviluppatori top notch commettono centinaia di bug durante il ciclo di sviluppo. Quindi il discorso del non saper programmare non regge, visto che dal contesto stiamo parlando di software che per definizione, da gente che non sa programmare, non può essere proprio scritto. Il nocciolo della questione. Era diverso se parlavamo di programmi da qualche centinaia di righe. Allora ti potevo dare pure ragione.

Azz ho cercato di esporre questo concetto in più di 4 post e non sono stato capito, invidio la tua capacità di sintesi, che evidentemente io non ho

[-fidel-]

@mjordan:

Già. l'università non è che il punto di inizio, l'ho capito subito quando ho cominciato la professione. Nell'informatica, come in tutto del resto, non si finisce mai di imparare (per dirlo con una frase fatta)

[mjordan]

Per quanto riguarda la questione del garbage collector, dei memory leak e per chi pensa che servano per eliminare i memory leaks:

So, no garbage collection doesn't solve the memory leak problem by
itself, in the sense of without thought, but it isn't just a matter of
making leaks less common (and premature deallocations/reallocations
impossible). Instead, it is a matter of making the reasoning much
easier that it takes to make the leaks go away entirely, as opposed to
just becoming less common.

-Max Hailperin
Associate Professor of Computer Science
Gustavus Adolphus College
800 W. College Ave.
St. Peter, MN 56082
USA

Tratto da un interessante post da una mailing list, che consiglio vivamente di leggere, per sfatare ancora una volta i miti che si vanno via via radicando:
http://compilers.iecc.com/comparch/article/97-04-040

Conclusione: I Garbage Collector non sono strumenti che evitano i memory leak. Al di la di quello che dice Microsoft che ti deve convincere a usarlo.

[-fidel-]

Originariamente inviato da mjordan

Conclusione: I Garbage Collector non sono strumenti che evitano i memory leak. Al di la di quello che dice Microsoft che ti deve convincere a usarlo.

Bene stiamo chiarendo il concetto. I GC semplificano per il programmatore la gestione della memoria dinamica, ci sono quelli più efficienti e quelli meno efficienti, ma non sono la panacea dei problemi di memoria.
Per quanto riguarda i memory leaks, anche per rendere un GC più efficiente, normalmente si specifica il cosidetto level of reachability della memoria allocata, così da non rischiare che il GC lasci quella memoria (magari indirizzata indirettamente) allocata inutilmente.

[-fidel-]

Posto un semplicissimo esempio di memory leak in C, è un classico nella letteratura informatica.

int main(void)
{
    char *stringa1, *stringa2;

    stringa1 = (char*)malloc(40*sizeof(char));
    stringa2 = (char*)malloc(40*sizeof(char));
    strncpy(stringa2, "Sto per causare un memory leak!", 31);
    stringa1 = stringa2; /* Ecco il memory leak! La memoria allocata */
                            /* per stringa uno va perduta, dal momento */
                            /* che non è più puntata da nessuno. Per    */
                            /* questo motivo non può essere liberata     */
                            /* esplicitamente.                                    */
    free(stringa2); /* Tutto ok */
    free(stringa1); /* Ecco l'errore...  Si sta cercando di liberare */
                       /* memoria già deallocata.                          */
    return 0;
}

Credo che ad un errore del genere un GC non può porre rimedio (ovviamente omettendo le 'free'). O sì?

[k0nt3]

Originariamente inviato da -fidel-

Credo che ad un errore del genere un GC non può porre rimedio (ovviamente omettendo le 'free'). O sì?

beh il GC in teoria rileva le aree di memoria non più puntate da nessun puntatore e le dealloca.. un possibile problema dei GC è invece quando si crea una lista circolare, perchè in quel caso tutti gli elementi sono puntati dal precedente e quindi la cosa è un pò più fine in fase di deallocazione!
a parte tutto questo discorso.. il GC in se è uno spreco di memoria in quanto è costretto a controllare ogni tanto lo stato della memoria, anche quando ragionevolmente non ce n'è bisogno! per questo è possibile avere un certo controllo sul GC via codice (anche se non completo).
comunque sta di fatto che la gestione della memoria via GC non è affatto ottimale nè mira ad esserlo, ma mira soltanto a semplificare la vita al programmatore.

[MenageZero]

Originariamente inviato da -fidel-

Posto un semplicissimo esempio di memory leak in C, è un classico nella letteratura informatica.

/*esempio memory leak in C*/

Credo che ad un errore del genere un GC non può porre rimedio (ovviamente omettendo le 'free'). O sì?

Ciao a tutti, discussione interessante...
Ad esempio in Java mi pare che proprio una situazione come quella sia il "pane quotidiano" del gc: ovvero se una struttura non è più puntata da nessun riferimento, la relativa memoria verrà liberata dal gc, di default nel momento che la jvm riterrà "più opportuno".
Con .net non so (ne ho solo "un'infarinatura"), ma non penso sia irragionevole suppore un comportamento analogo.
(Se avessi "preso un granchio" e detto starfalcioni perdonatemi... )

[-fidel-]

Originariamente inviato da MenageZero

Ciao a tutti, discussione interessante...

Ciao a te

Originariamente inviato da MenageZero

Ad esempio in Java mi pare che proprio una situazione come quella sia il "pane quotidiano" del gc: ovvero se una struttura non è più puntata da nessun riferimento, la relativa memoria verrà liberata dal gc, di default nel momento che la jvm riterrà "più opportuno".
Con .net non so (ne ho solo "un'infarinatura"), ma non penso sia irragionevole suppore un comportamento analogo.
(Se avessi "preso un granchio" e detto starfalcioni perdonatemi... )

Beh il mio esempio è piuttosto semplificato, del resto un GC credo interpreti quei semplici puntatori come "weak references" e li dealloca sicuramente. Ho dimenticato di aggiungere: e se fossero stati invece delle Handle (smart pointer) invece che dei semplici puntatori a char (*char)? Li avrebbe deallocati lo stesso?

[-fidel-]

E' per questo che sono restio ad usare i GC, mi incasino nel capire se quella memoria verrà liberata e quindi quando mi devo preoccupare e quando no! Mi sa che me li devo studiare in modo più approfondito, al momento non ho tutti gli argomenti per valutare

[k0nt3]

Originariamente inviato da -fidel-

E' per questo che sono restio ad usare i GC, mi incasino nel capire se quella memoria verrà liberata e quindi quando mi devo preoccupare e quando no! Mi sa che me li devo studiare in modo più approfondito, al momento non ho tutti gli argomenti per valutare

senza entrare nei dettagli di un GC... in pratica tiene il conto dei riferimenti per area di memoria, e quando questo conto va a 0 significa che l'area è da deallocare! ovviamente ci sono svariati accorgimenti oltre a questa banale considerazione, ma il succo è quello! qli algoritmi di garbage collecting possono essere anche piuttosto complicati (ma non devono esserlo troppo per non occupare eccessivamente la cpu)

Originariamente inviato da mjordan

Che è sbagliato, perchè un linguaggio di programmazione cos'è ce lo da la teoria dei linguaggi formali, non dobbiamo inventarcela. Bisogna sempre separare un linguaggio di programmazione dalle sue API. La malloc() fa parte delle API del C, non fa parte di quello che i linguaggi formali definiscono un linguaggio. Un linguaggio, non è nient'altro che un insieme di produzioni che definiscono categorie sintattiche. E' quindi un accettatore. Un atuma a stati finiti che accetta o rifiuta stringhe. L'insieme delle stringhe accettate dall'FSA si chiama sintassi del linguaggio. Quello che chiamiamo "linguaggio di programmazione".

Quindi, considerando che una malloc() non fa nient'altro che appoggiarsi a delle system call che vengono fornite in qualità di servizi da un sistema operativo, includerla nella classificazione di un linguaggio è scorretto. Quando si analizzano queste cose sui linguaggi, ci si deve riferire alla sintassi. E basta. Il resto sono opinioni personali.

1) Se mai dellA API, dato che è Application Program Interface

2) Il tuo discorso regge poco per il motivo già detto da k0nt3 (e che tu hai abilmente tentato di scansare), ovvero secondo il tuo ragionamento (e della tua sedicente "teoria dei linguaggi formali") Java sarebbe un linguaggio di "medio livello" cosa notoriamente falsa. La definizione di Java come linguaggio d'alto livello è decisamente più consona al mio criterio di catalogazione

[-fidel-]

Originariamente inviato da k0nt3

senza entrare nei dettagli di un GC... in pratica tiene il conto dei riferimenti per area di memoria, e quando questo conto va a 0 significa che l'area è da deallocare! ovviamente ci sono svariati accorgimenti oltre a questa banale considerazione, ma il succo è quello! qli algoritmi di garbage collecting possono essere anche piuttosto complicati (ma non devono esserlo troppo per non occupare eccessivamente la cpu)

Vabbè dai non è che sono proprio a digiuno Cmq quello che hai descritto tu è un GC reference counting, presente in Java, quello di .NET invece è di tipo tracing , ma il mio problema resta a prescindere dal metodo di garbace collecting. Anche se questo non fa che incasinarmi, dal momento che il GC non si comporta sempre allo stesso modo. Mi devo studiare a fondo il GC per ogni framework o linguaggio che mi trovo ad usare ;(

[mjordan]

Originariamente inviato da ekerazha

1) Se mai dellA API, dato che è Application Program Interface

Casomai è "Application Programming Interface. Ma che facciamo adesso, a fronte di argomentazioni smontate ci diamo agli apostrofi adesso?

2) Il tuo discorso regge poco per il motivo già detto da k0nt3 (e che tu hai abilmente tentato di scansare), ovvero secondo il tuo ragionamento (e della tua sedicente "teoria dei linguaggi formali") Java sarebbe un linguaggio di "medio livello" cosa notoriamente falsa. La definizione di Java come linguaggio d'alto livello è decisamente più consona al mio criterio di catalogazione

Non ho tentato di scansare, ho detto che quando si fa un discorso si segue il contesto. Ma visto che parli di apostrofi anche tu sei uno che è abile nello scansare il discorso che si sta facendo. Java è un linguaggio con una sintassi molto a piu' alto livello di C/C++, si possono trovare decine di esempi. Non ho detto che l'esempio che ho fatto io è unico, ho detto che la questione la si deve vedere a livello sintattico. Inoltre, si, Java continua a essere di medio livello:
http://www.chicercatrova2000.it/java/introd.asp

Sfatiamo inoltre l'equivoco che si e' creato con questo linguaggio di programmazione: Java non e' un linguaggio di programmazione per il web, ma un vero e' proprio linguaggio di programmazione completo di medio livello ed e' strettamente imparentato con il linguaggio C.

Che poi, come ho già detto, parlare di "medio livello" è solo una convenzione, perchè non fa categoria.

Originariamente inviato da -fidel-

Io ho capito così, mi sembra chedal tuo post si evinceva quel concetto. Lo riquoto:



Io ne desumo che in C puoi ed in Delph non puoi, magari ho capito male che ti devo dire...

Hai capito male... e comunque per togliere ogni dubbio l'ho precisato successivamente... sei tu che ti impunti sulle tue convinzioni e poi quando tento di precisare le cose (per fugare eventuali dubbi) dici che "rigiro la frittata"

Lì ti assicuro che che stavo scrivendo mentre tu postavi il link a questo thread, ci sono gli orari dei post a dimostrarlo

Certo... io ho tenuto a precisarlo di nuovo perchè il moderatore incombeva e quindi mi sembrava il caso di "traslocare" in fretta su questa discussione... ma tu te la sei presa.

Per tutto il resto, a me è parso, come ho argomentato nel post #3 di questo thread, che tu abbia corretto il tiro in varie occasioni. Che ti devo dire, a me è sembrato così.

Non mi sembra... come spiegato a volte tentavo ulteriori precisazioni quando vedevo che stavi parzialmente fraintendendo le mie argomentazioni (e tu hai a tua volta frainteso queste precisazioni dicendo che "giro la frittata"... se la mia precisazione ti sembrava tanto diversa dall'originale, è perchè evidentemente avevi mal compreso l'originale e non perchè avessi cambiato la mia versione nella precisazione ).

Per quanto riguarda i toni aspri, onestamente non mi pare di averti offeso. Mi sono limitato a dire che stavi rigirando la frittata. Puoi non essere d'accordo ed è legittimo, ma non mi pare che quella sia un offesa.
Ho visto nel (poco) tempo su cui sono su questo forum cose ben più gravi, dal semplice "utonto" a "cretino", "cog***ne", "tu non sai un ca**o" e simili.
Quelle mi sembrano offese e le evito accuratamente, fino a quando non vengo sfottuto in prima persona. Normalmente evito il trolleggio, ma a volte, anche se raramente, mi faccio coinvolgere. Questo per' non mi sembra il caso (tranne gli ultimi due miei post nell'altro thread, orami la cosa era degenerata senza motivo...).

Non c'è bisogno di insultare per offendere... il "non parlare di cose che non sai..." del tuo post #76 la ritengo una vera e propria mancanza di rispetto.
Se poi per te valgono solo gli insulti, allora io non mi sono mai permesso di darti del cretino" o del "cog***ne".

Per me la questione è chiarita e chiusa

D'accordo

[-fidel-]

Originariamente inviato da ekerazha

1) Se mai dellA API, dato che è Application Program Interface

Occhio quando parli di cose tecniche Almeno in linux, la malloc è implementata facendo ricorso alle system calls "brk" ed "nmap" per prendere dallo heap la memoria necessaria: questo perchè l'heap è definito per ogni processo, e solo il SO può allargarlo (quando il processo ha più bisogno di memoria): il kernel allarga l'heap destinato al processo e rischedula la ichiesta di allocazione.

Originariamente inviato da -fidel-

Occhio quando parli di cose tecniche Almeno in linux, la malloc è implementata facendo ricorso alle system calls "brk" ed "nmap" per prendere dallo heap la memoria necessaria: questo perchè l'heap è definito per ogni processo, e solo il SO può allargarlo (quando il processo ha più bisogno di memoria): il kernel allarga l'heap destinato al processo e rischedula la ichiesta di allocazione.

E quindi?

[MenageZero]

Originariamente inviato da -fidel-

Beh il mio esempio è piuttosto semplificato, del resto un GC credo interpreti quei semplici puntatori come "weak references" e li dealloca sicuramente. Ho dimenticato di aggiungere: e se fossero stati invece delle Handle (smart pointer) invece che dei semplici puntatori a char (*char)? Li avrebbe deallocati lo stesso?

sempre riferendomi al java, e se come handle e smart pointer stiamo parlando di questi concetti:
http://en.wikipedia.org/wiki/Smart_pointer

1) tutti i riferimenti(puntatori) sono in pratica smart pointer
2) handle: la rappresentazione della risorsa come oggetto è sempre deallocata (prima o poi) dal gc quando non ci sono più riferimenti a tale oggetto; per quanto riguarda il "liberare" le risorse fornite e gestite da "un'altro sistema", (ad es. l'os), esempio:
fai I/o su un file, prima di deferenziare il l'oggetto che rapprsenta il flusso di I/O devi chiamare un apposito metodo close() di questo per garantire che l'os liberi quel file mentre è ancora in esecuzione la jvm con la tua app.