View Full Version : Livello di programmazione con vari linguaggi, allocazione dinamica della memoria
ekerazha
04-02-2006, 12:59
Fork della discussione: http://www.hwupgrade.it/forum/showthread.php?t=1127278&page=5
Eccomi, ho appena visto il tuo post su questo nuovo thread.
Non mi pare di aver alzato il tono della discussione, ti sei a mio avviso appigliato ad un errore di confusione commesso per aver scritto frettolosamente un post (sai non sono sempre "freddo e prciso" come dici tu), ma rimane quello che ho detto sul garbage collection e sul linguaggio di "medio livello". Volevo farti capire, argomentando a dovere, la mia posizione sui linguaggi "di medio livello" come li definisci tu, non a caso ho detto "allora anche delphi è di medio livello per te"?. In troppi pensano che alcune cose si possano fare solo in C/C++ e questo non è vero. Con GetMem ti ho fatto vedere che anche in delphi c'e' una funzione che fa il lavoro della malloc() del C, che hai tirato fuori parlando della gestione "esplicita" dei puntatori. In delphi puoi praticamente usare i puntatori così come fai con il C, poi se questo sia conveniente o meno per come è strutturato il delphi dipende.
ekerazha
04-02-2006, 13:19
Eccomi, ho appena visto il tuo post su questo nuovo thread.
Non mi pare di aver alzato il tono della discussione, ti sei a mio avviso appigliato ad un errore di confusione commesso per aver scritto frettolosamente un post (sai non sono sempre "freddo e prciso" come dici tu), ma rimane quello che ho detto sul garbage collection e sul linguaggio di "medio livello". Volevo farti capire, argomentando a dovere, la mia posizione sui linguaggi "di medio livello" come li definisci tu, non a caso ho detto "allora anche delphi è di medio livello per te"?. In troppi pensano che alcune cose si possano fare solo in C/C++ e questo non è vero. Con GetMem ti ho fatto vedere che anche in delphi c'e' una funzione che fa il lavoro della malloc() del C, che hai tirato fuori parlando della gestione "esplicita" dei puntatori. In delphi puoi praticamente usare i puntatori così come fai con il C, poi se questo sia conveniente o meno per come è strutturato il delphi dipende.
Allora... io cerco sempre di essere amichevole e disponibile al dialogo. Diciamo che ci sono state delle incomprensioni e tentiamo di fare chiarezza per bene:
La mia frase dalla quale è scaturito il tutto è questa:
Per lo più quando il C/C++ è probabilmente il linguaggio di "medio livello" che concede il miglior rapporto rapidità di esecuzione/occupazione della memoria (a parità di algoritmo).
Tu hai risposto:
- Hai detto che il C/C++ sono linguaggi di "medio livello". Cosa intendi per medio livello scusa?? Sono sempre di alto livello fidati...
Io ti ho esposto perchè consideravo il C/C++ di "medio livello" (o "medio-alto" livello") facendo il paragone con alcuni linguaggi (VB, C#, Java) e chiamando in causa come uno dei motivi l'allocazione dinamica della memoria (ma ci sono anche altre cose... a livello anche banale) dicendo che questi linguaggi non consentivano una gestione "esplicita" dell'allocazione dinamica della memoria.
Tu a questo punto hai tirato fuori Delphi e io ti ho detto che non lo avevo -appositamente- citato perchè consideravo anche Delphi un linguaggio di più basso livello rispetto a quelli già citati (VB, C#, Java) dicendo che comunque Delphi possedeva, per l'allocazione dinamica della memoria, alcune facilitazioni (come New() ) che in C non sono presenti.
Poi la cosa è abbastanza degenerata...
Dimmi se ti ritrovi nel racconto ed eventualmente possiamo continuare a discuterne (spero su livelli cordiali).
:)
Veramente non mi ritrovo nei termini che hai esposto :)
Più che da una frase, il tutto mi sembra essere scaturito da questo tuo post:
Il linguaggio di programmazione è solo uno strumento, uno strumento che viene utilizzato dai programmatori. Il "programmatore" degno di questo nome difficilmente commette errori di questo genere. Se determinate cose non vengono "evitate" dai vari linguaggi che utilizzano managed code (Java, C#, etc.) è il programmatore a doverli evitare (come anche i memory leak quando non hai il garbage collector che ti para il cu*o). Per lo più quando il C/C++ è probabilmente il linguaggio di "medio livello" che concede il miglior rapporto rapidità di esecuzione/occupazione della memoria (a parità di algoritmo).
A quel punto mi sono inserito consigliandoti di rivedere il GC di .NET per l'affermazione che un GC ti para il cu*o dai memory leaks, e dicendo che siamo uomini e che non ci sono programmi esenti da bug quando hai detto che un programmatore "degno di questo nome" non dovrebbe commettere questi errori.
Tu allora hai detto di specificare perchè dovevi ripassare il .NET, ed hai detto che tutti commettiamo errori, ma c'è chi ne fa di più e chi di meno.
Già mi è sembrato che stavi corregendo il tiro, giacché nel post che ho quotato affermi che "difficilmente" un buon programmatore commette questi errori, e io volevo semplicemente dire che si commettono comunque. Dopo ho puntualizzato pure che, al crescere della complessità dei programmi, fare errori che "difficilmente" un buon programmatore fa diventa piuttosto facile.
A questo punto ti ho appunto detto che un GC non ti para affatto il cu*o dai memory leaks (ecco perchè dicevo "ripassati il .NET") e ho detto che non consideravo il C/C++ un linguaggio di "medio livello".
Quindi sul GC di .NET hai di nuovo corretto il tiro, dicendo che un GC dovrebbe proteggere dai memory leaks, spiegando pure in due parole prchè i GC sono stati introdotti. Ti ho fatto dopo notare la tua correzione di tiro (post #68).
Sui linguaggi di medio livello mi dici invece che li consideri così solo perchè ci sono a tuo avviso linguaggi che lavorano ad un livello ancora più alto, citando C#, VB e Java. Permettimi di essere insoddisfatto della risposta.
Nello stesso post, correggi ancora il tiro sugli errori che un programmatore commette. Non mi pare di aver capito male, leggendo anche il post #66 di danyroma80 (magari è stato un po' troppo diretto e forse offensivo, però aveva capito bene il discorso). Cercando di capire la tua definizione di "medio livello", ti ho quindi chiesto "perchè lo reputic così? C'è per caso qualcosa che solo il C/C++ sa fare?"
Mi ha risposto:
Intendo principalmente una gestione esplicita di puntatori/allocazione dinamica della memoria.
A questo punto, ho tirato fuori Delphi per dirti che la gestione esplicita dei puntatori e l'allocazione dinamica della memoria le può fare anche delphi (ma non solo), quindi non ritengo il C/C++ un linguaggio di "medio livello", ma un linguaggio di alto livello come gli altri, solo più flessibile e permissivo.
Tu come mi rispondi? "Io non ho tirato fuori il delphi"! Mi dici pure:
Per tua informazione comunque, la gestione dell'allocazione dinamica della memoria nel Pascal-Object Pascal/Delphi è molto più semplificata rispetto a quella del C/C++.
Per farti un esempio in C puoi usare malloc() e devi specificare esattamente la dimensione della memoria da allocare. In Pascal invece utilizzi new() e devi semplicemente specificare il nome della variabile da allocare (si arrangia da solo nelle questioni "di più basso livello"). E quando dico "medio livello" non pregiudico il fatto che si possa lavorare anche a livelli molto alti, ma semplicemente che è possibile lavorare anche a livelli relativamente bassi (al contrario di alcuni già citati linguaggi). L'allocazione dinamica della memoria in C mi sembra un'operazione di livello non altissimo, in quanto si richiede una conoscenza "basilare ma non troppo" del funzionamento della memoria.
A 'sto punto non potevo che tirarti fuori la funzione GetMem()... Se mi dici che in C si usa malloc() e in delphi solo New(), dicendo in maniera neanche troppo implicita "vedi, per tua informazione in delphi non puoi fare questa cosa", dovevo per forza farti presente l'esistenza di GeMem().
La tua risposta?
Certo che conosco GetMem()... ma dato che "tu sai", credo saprai anche che, esistendo nel linguaggio Pascal/Delphi la già citata funzione New(), GetMem() risulta assolutamente inutile ;)
Eh non mi pare che la conosci, e correggi pure il tiro dicendo "sisi si puo' fare ma è inutile farlo".
Ah, tutto questo ragionamento come puoi vedere è a prescindere dalla tua affermazione
/C++ è forse il linguaggio di "medio" livello col miglior rapporto "tempo di esecuzione"/"occupazione di memoria" (a parità di algoritmo)
che fin'ora non c'entra niente.
A questo punto io ho fatto un errore dettato dalla fretta, dicendo che New() di delphi si usa come l'operatore new del C++, ma mi sono prontamente corretto. Prima che correggessi tu avevi già quotato facendomi giustamente denotare l'errore. Su questo errore poi però hai impostato i tuoi post succesivi, a mio avviso "riscaldando" la situazione che fino a quel momento mi è parsa assolutamente civile. Ah, hai pure detto
Non ho mai detto che non si possa fare, anzi ho proprio detto che si può fare ma che grazie a New() la cosa è notevolmente semplificata rispetto al C/C++ (dove in determinate occasione ti cucchi malloc() o affini).
e mi pare che dalla ricostruzione dei fatti questo non sia vero.
Ti sembro una persona che attacca e fa il troll per riscaladare la discussione? Onestamente non mi sembra. Vai tranquillo, Normalmente rimango sempre su termini cordiali, mi sembra ingiusto dire il contrario. Poi se vengo offeso è ovvio che rispondo! :)
Dimenticavo una cosa: come puoi vedere dal mio post precedente, il fatto che in prima battuta avevo sbagliato sulla New() del delphi c'entra poco con tutto il discorso! E credo lo avevi capito pure tu, giacchè hai detto (riquoto)
Non ho mai detto che non si possa fare, anzi ho proprio detto che si può fare ma che grazie a New() la cosa è notevolmente semplificata rispetto al C/C++ (dove in determinate occasione ti cucchi malloc() o affini).
Infatti il discorso era che anche in delphi c'e' una fuznione come la malloc() e che quindi sotto quell'aspetto non ci sono differenze con il C/C++. La frase chiave su questo punto rimane a mio avviso questa:
Intendo principalmente una gestione esplicita di puntatori/allocazione dinamica della memoria.
ekerazha
04-02-2006, 14:58
Veramente non mi ritrovo nei termini che hai esposto :)
Più che da una frase, il tutto mi sembra essere scaturito da questo tuo post:
A quel punto mi sono inserito consigliandoti di rivedere il GC di .NET per l'affermazione che un GC ti para il cu*o dai memory leaks, e dicendo che siamo uomini e che non ci sono programmi esenti da bug quando hai detto che un programmatore "degno di questo nome" non dovrebbe commettere questi errori.
Fino a qui più o meno ci siamo.
Tu allora hai detto di specificare perchè dovevi ripassare il .NET, ed hai detto che tutti commettiamo errori, ma c'è chi ne fa di più e chi di meno.
Già mi è sembrato che stavi corregendo il tiro, giacché nel post che ho quotato affermi che "difficilmente" un buon programmatore commette questi errori, e io volevo semplicemente dire che si commettono comunque. Dopo ho puntualizzato pure che, al crescere della complessità dei programmi, fare errori che "difficilmente" un buon programmatore fa diventa piuttosto facile.
Ti stai facendo paranoie per niente. Io non ho mai affermato nulla come "certo ed imprescindibile", ho appunto detto che "difficilmente" un buon programmatore commette determinati errori, dicendo anche però che nessuno è perfetto e qualche errore è fisiologico (anche per un buon programmatore). Non ho mai affermato che ci sono programmatori "che non commettono errori", ne' prima ne' dopo, anche perchè, come hai ben detto, tutti commettono errori... è umano (ma io ho aggiunto che qualcuno ne commette di più e qualcuno meno :) ).
A questo punto ti ho appunto detto che un GC non ti para affatto il cu*o dai memory leaks (ecco perchè dicevo "ripassati il .NET") e ho detto che non consideravo il C/C++ un linguaggio di "medio livello".
Quindi sul GC di .NET hai di nuovo corretto il tiro, dicendo che un GC dovrebbe proteggere dai memory leaks, spiegando pure in due parole prchè i GC sono stati introdotti. Ti ho fatto dopo notare la tua correzione di tiro (post #68).
Non ho corretto nessun tiro. Il GC serve per evitare memory leak e lo ribadisco (e la documentazione Microsoft dice altrettanto). Alle tue osservazioni sul fatto "che non sia sufficiente" e che sia comunque il caso di ricorrere "manualmente" ti ho dato pienamente ragione e la penso allo stesso modo... ma resta il fatto che il GC è stato introdotto per evitare memory leak (a volte vi riesce meglio, a volte no) e che può spesso "parare il cu*o" alle sviste del programmatore (ma non è comunque una cosa sul quale il programmatore dovrebbe fare affidamento).
Sui linguaggi di medio livello mi dici invece che li consideri così solo perchè ci sono a tuo avviso linguaggi che lavorano ad un livello ancora più alto, citando C#, VB e Java. Permettimi di essere insoddisfatto della risposta.
E' esattamente così, poichè vi sono differenze sostanziali (come quella ampiamente discussa sull'allocazione dinamica della memoria) fra quelli che io chiamo di "medio" livello e quelli di "alto" livello. Se poi tu sei insoddisfatto non so cosa farci :)
Nello stesso post, correggi ancora il tiro sugli errori che un programmatore commette. Non mi pare di aver capito male, leggendo anche il post #66 di danyroma80 (magari è stato un po' troppo diretto e forse offensivo, però aveva capito bene il discorso).
Come già spiegato non ho corretto nessun tiro.
Cercando di capire la tua definizione di "medio livello", ti ho quindi chiesto "perchè lo reputic così? C'è per caso qualcosa che solo il C/C++ sa fare?"
Mi ha risposto:
A questo punto, ho tirato fuori Delphi per dirti che la gestione esplicita dei puntatori e l'allocazione dinamica della memoria le può fare anche delphi (ma non solo), quindi non ritengo il C/C++ un linguaggio di "medio livello", ma un linguaggio di alto livello come gli altri, solo più flessibile e permissivo.
Tu come mi rispondi? "Io non ho tirato fuori il delphi"!
Ecco qui la prima grave incomprensione... provvedo subito a chiarirla perchè forse non l'avevo esplicitato bene: considero anche Delphi un linguaggio di "medio"/"medio-alto" livello. Il fatto che in Delphi vi fossero facilitazioni (come appunto New() ) per l'allocazione dinamica della memoria, era solo una precisazione. Entrambi i linguaggi hanno differenza sostanziali rispetto a quelli che considero di più "alto livello" come i già citati VB, C#, Java, etc.
Mi dici pure:
A 'sto punto non potevo che tirarti fuori la funzione GetMem()... Se mi dici che in C si usa malloc() e in delphi solo New(), dicendo in maniera neanche troppo implicita "vedi, per tua informazione in delphi non puoi fare questa cosa", dovevo per forza farti presente l'esistenza di GeMem().
La tua risposta?
Eh non mi pare che la conosci, e correggi pure il tiro dicendo "sisi si puo' fare ma è inutile farlo".
In effetti (e ti sfido a provare il contrario) non ho mai detto che in Delphi puoi usare *solo* New() e ho poi - giustamente - aggiunto che usare GetMem() in Delphi ha ben poco senso. Tutto questo esula comunque dal fatto che consideri anche Delphi un linguaggio di "medio" livello (certo... poi ci sono anche altre piccole, a volte banali, differenze che in senso assoluto mi fanno dire che il C/C++ sia un filino a più basso livello anche rispetto a Delphi, ma come già detto li considero più o meno sullo stesso piano ed abbastanza staccati da altri suddetti linguaggi).
Ah, tutto questo ragionamento come puoi vedere è a prescindere dalla tua affermazione
che fin'ora non c'entra niente.
Quella affermazione era sempre contenuta nel mio primo post ed era parte integrante del post intero.
A questo punto io ho fatto un errore dettato dalla fretta, dicendo che New() di delphi si usa come l'operatore new del C++, ma mi sono prontamente corretto. Prima che correggessi tu avevi già quotato facendomi giustamente denotare l'errore. Su questo errore poi però hai impostato i tuoi post succesivi, a mio avviso "riscaldando" la situazione che fino a quel momento mi è parsa assolutamente civile.
Si, ti ho appunto fatto notare il *grave* errore (che poi, per fortuna, hai provveduto a correggere). L'hai anche fatto passare come se fosse colpa mia se avevo quotato la tua frase "erronea" dicendomi che:
hai quotato la versione non corretta
... per poi (in un altro momento) passare sulla difensiva col post #98 quando mi hai detto:
Se mi dai il tempo di leggere un post che stavi scrivendo mentre scrivevo il mio....
Insomma... gli altri devono aspettare la revisione A, B e C dei tuoi post... ma poi devono anche lasciare a te a tutto tempo di leggere i post altrui (al che non potevo sapere che non lo avessi letto... ho pensato ti fosse sfuggito) e tentando in questo modo di alimentare un flame inutile.
Ah, hai pure detto
e mi pare che dalla ricostruzione dei fatti questo non sia vero.
Sbagli... come si può ben constatare dal mio post numero #72 ed in particolare dall'affermazione "la gestione dell'allocazione dinamica della memoria nel Pascal-Object Pascal/Delphi *è molto più semplificata* rispetto a quella del C/C++".
Ti sembro una persona che attacca e fa il troll per riscaladare la discussione? Onestamente non mi sembra. Vai tranquillo, Normalmente rimango sempre su termini cordiali, mi sembra ingiusto dire il contrario. Poi se vengo offeso è ovvio che rispondo! :)
Come già detto io cerco sempre di essere cordiale ed amichevole (e non offendo mai nessuno sul piano personale al contrario di altri, del tipo "deduco che non hai mai fatto niente" o "deduco che non sai nulla", se non quando gli altri cominciano a farlo per primi con me) ma tu hai insistito su toni aspri anche quando io cercavo di raffreddare gli animi... il mio carattere mi impone a questo punto di affondare la lama.
ekerazha
04-02-2006, 15:01
Dimenticavo una cosa: come puoi vedere dal mio post precedente, il fatto che in prima battuta avevo sbagliato sulla New() del delphi c'entra poco con tutto il discorso! E credo lo avevi capito pure tu, giacchè hai detto (riquoto)
Infatti il discorso era che anche in delphi c'e' una fuznione come la malloc() e che quindi sotto quell'aspetto non ci sono differenze con il C/C++.
D'accordissimo su questo fatto... come già detto nel post precedente considero C/C++ e Delphi all'interno della stessa fascia (con qualche differenza anche qui certo, come in parte evidenziato).
La frase chiave su questo punto rimane a mio avviso questa:
Sicuro... il fatto è che quella frase non era mai stata riferita a Delphi :), ma a linguaggi che come già detto considero di livello più alto (VB, C# etc).
ekerazha
04-02-2006, 15:13
Rispondo anche a mjordan dall'altro thread :)
Ti rispondo semplicemente. Basta che consideri il numero di righe di codice di quei "programmi fatti con il deretano" per il numero di bug e ti accorgi che il rapporto sta decisamente dentro la media delle statistiche. Se per te serve che bisogna tirare fuori i titoli, mentre tu sei studente io sto preparando la tesi. In informatica. Quindi tirare fuori i titoli non serve, specie quando poi i titoli sono seguiti da inesattezze evidenti sotto gli occhi di tutti. I "migliaia di bug" sono su programmi da "milioni di righe di codice", quindi un programma da 100 righe di codice che ha un bug ha lo stesso rapporto dei "programmi fatti con il deretano" che tu citi. Quindi al mondo ci sta chi sa programmare e chi no. E fra questi ci stanno gli studenti di Ingegneria Informatica, che credono di insegnare con un commento come si programma a sviluppatori professionisti da oltre 30 anni, che hanno piu' di un Ph.d in diverse discipline e che lavorano su progetti multi milionari su repository da svariati milioni di righe di codice. Quindi magari, al posto di vantarti e credere che al mondo ci sei solo tu, fermati a riflettere per un attimo.
Nel caso non te ne fossi accorto la discussione si è spostata di là: http://www.hwupgrade.it/forum/showthread.php?p=11160796 quindi ti rispondo di là :)
P.S.
Continuo ad avvertire quella fastidiosa ostilità-da-invidia nei confronti degli ingegneri :)
Continui anche a parlare di "statistiche" ma sono solo parole non suffragate da dati e da fatti... ovvero valgono meno di zero :) A parità di righe di codice, di linguaggio di programmazione, di algoritmo implementato... ci possono essere notevoli differenze, per un semplice motivo: ognuno di noi è diverso, ogni programmatore è diverso... e ci sono programmatori più o meno preparati e più e meno attenti.
Come vedi è possibile rispondere a tono senza insultare l'interlocutore sul piano personale... ed è davvero singolare che debba spiegartelo uno più giovane (dato che sei già laureando) e teoricamente più immaturo di te.
:)
Comunque tecnicamente C e C++ sono considerati linguaggi di medio livello. I linguaggi, solitamente, si distinguono in alto e basso livello. Il C rientra nella categoria dell'alto livello. Il fatto di dire che sia di medio livello risiede semplicemente nel fatto che la sua sintassi non dispone di quell'"inzuccherimento sintattico" tipico di altri linguaggi di programmazione, come ad esempio VB o Pascal/Delphi.
Per intenderci, dispone di costrutti che sono molto meno "verbali" altri linguaggi. Ad esempio i blocchi in C/C++ sono costituiti da parentesi graffe, mentre in linguaggi come Delphi sono parole riservate del linguaggio (begin, end).
In sostanza, il C/C++ sono linguaggi di "medio livello" semplicemente per il fatto che dispongono di un livello di astrazione inferiore rispetto a linguaggi piu' orientati alla produttività. Ma tecnicamente continuano a essere di "alto livello", visto che la catalogazione la si fa sull'alto e il basso.
Per quanto riguarda la posizione sul saper programmare o no, dal tuo post precedente nel thread delle news si evinceva che volessi dire che simili bug nei software Microsoft sono dovuti a persone che non sanno programmare. Il che, ovviamente, non è affatto vero.
Rispondo anche a mjordan dall'altro thread :)
Continui anche a parlare di "statistiche" ma sono solo parole non suffragate da dati e da fatti... ovvero valgono meno di zero :) A parità di righe di codice, di linguaggio di programmazione, di algoritmo implementato... ci possono essere notevoli differenze, per un semplice motivo: ognuno di noi è diverso, ogni programmatore è diverso... e ci sono programmatori più o meno preparati e più e meno attenti.
Come vedi è possibile rispondere a tono senza insultare l'interlocutore sul piano personale... ed è davvero singolare che debba spiegartelo uno più giovane (dato che sei già laureando) e teoricamente più immaturo di te.
:)
A parte che io non ti ho offeso, ma rileggendo si evince che la polemica l'hai iniziata tu. Le statistiche che ho dato sono citate in tutti gli articoli che parlano di bug relativamente a C/C++ e sono valori "medi" presi su software di una certa importanza. Tempo fa discutevamo in unthread di questa cosa con Fek e si evinceva come la media fondamentalmente sia corretta. Per il resto, il tono polemico nasce dal fatto che per parlare hai bisogno di mettere avanti i titoli, cosa di cui io non ho bisogno quando parlo di argomentazioni. Quello che ti voglio far capire è che dire che sei studente di ingegneria informatica, molte volte testimonia tutto il contrario di quello che vuoi far credere (cioè il saper programmare). Tutto qui. Quello per esempio è un esempio di comportamento saccente.
Per intenderci, dispone di costrutti che sono molto meno "verbali" altri linguaggi. Ad esempio i blocchi in C/C++ sono costituiti da parentesi graffe, mentre in linguaggi come Delphi sono parole riservate del linguaggio (begin, end).
l'esempio non calza.. perchè così java sarebbe di medio livello? :D potevi fare uno migliore!
Per quanto riguarda la posizione sul saper programmare o no, dal tuo post precedente nel thread delle news si evinceva che volessi dire che simili bug nei software Microsoft sono dovuti a persone che non sanno programmare. Il che, ovviamente, non è affatto vero.
verissimo! infatti gli errori che commette MS sono dovuti al non sapere progettare, più che al non saper programmare!
ekerazha
04-02-2006, 15:24
Comunque tecnicamente C e C++ sono considerati linguaggi di medio livello. I linguaggi, solitamente, si distinguono in alto e basso livello. Il C rientra nella categoria dell'alto livello. Il fatto di dire che sia di medio livello risiede semplicemente nel fatto che la sua sintassi non dispone di quell'"inzuccherimento sintattico" tipico di altri linguaggi di programmazione, come ad esempio VB o Pascal/Delphi.
Per intenderci, dispone di costrutti che sono molto meno "verbali" altri linguaggi. Ad esempio i blocchi in C/C++ sono costituiti da parentesi graffe, mentre in linguaggi come Delphi sono parole riservate del linguaggio (begin, end).
In sostanza, il C/C++ sono linguaggi di "medio livello" semplicemente per il fatto che dispongono di un livello di astrazione inferiore rispetto a linguaggi piu' orientati alla produttività. Ma tecnicamente continuano a essere di "alto livello", visto che la catalogazione la si fa sull'alto e il basso.
Tu (e magari molti altri) utilizzi evidentemente un metodo ancora diverso per classificare i linguaggi. Io più che sulla "sintassi" mi baso sulla possibilità o meno di operare scelte che siano "a stretto contatto" con la struttura dell'elaboratore (es. decidere esattamente quanta memoria allocare e come).
Per quanto riguarda la posizione sul saper programmare o no, dal tuo post precedente nel thread delle news si evinceva che volessi dire che simili bug nei software Microsoft sono dovuti a persone che non sanno programmare. Il che, ovviamente, non è affatto vero.
Questo rimane finora un tuo giudizio. Il mio giudizio è che anche a Microsoft vi siano programmatori più o meno competenti :)
ekerazha, te lo scrivo qui, però probabilmente non ti rendi conto del tono che tieni, faresti bene a rileggere da capo tutti e due i topic... quello aggressivo, e quello che sconfina dall'aspetto tecnico per andare su considerazioni personali (dalla competenza in poi) sei tu, tra te, fidel e mjordan
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 =)
Tu (e magari molti altri) utilizzi evidentemente un metodo ancora diverso per classificare i linguaggi. Io più che sulla "sintassi" mi baso sulla possibilità o meno di operare scelte che siano "a stretto contatto" con la struttura dell'elaboratore (es. decidere esattamente quanta memoria allocare e come).
per quale motivo il tuo metodo per classificare i linguaggi sarebbe il migliore? non credo che questa discussione abbia senso, anche perchè tecnicamente sia C che C++ sono linguaggi di alto livello!
ps. se vuoi c# chiamalo di altissimo livello
ekerazha
04-02-2006, 15:38
ekerazha, te lo scrivo qui, però probabilmente non ti rendi conto del tono che tieni, faresti bene a rileggere da capo tutti e due i topic... quello aggressivo, e quello che sconfina dall'aspetto tecnico per andare su considerazioni personali (dalla competenza in poi) sei tu, tra te, fidel e mjordan
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 =)
Io ritengo che tu da "esterno" abbia comunque determinati "pre"giudizi determinati dalla simpatia o meno che hanno suscitato in te alcune mie affermazioni, più che da una visione globale della discussione.
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... e questo non per vantarmi di chissà cosa, ma per affermare che se non proprio un genio in senso assoluto, sicuramente non sono il primo sprovveduto che raccatti per strada. Al che è partito il flame (al quale tu hai dato il tuo contributo finale) sul "caccia agli Ingegneri".
Appurato che la causa scatenante è stata questa, non capisco cosa tu possa aver letto.
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.
Fossi in te rivedrei dunque la mia posizione in merito :)
Spero comunque che questo discorso sia concluso.
ekerazha
04-02-2006, 15:39
per quale motivo il tuo metodo per classificare i linguaggi sarebbe il migliore? non credo che questa discussione abbia senso, anche perchè tecnicamente sia C che C++ sono linguaggi di alto livello!
ps. se vuoi c# chiamalo di altissimo livello
Non ho mai detto che sarebbe il migliore :) E' semplicemente il mio.... stop :)
l'esempio non calza.. perchè così java sarebbe di medio livello? :D potevi fare uno migliore!
Ascolta Kont3, devi impararare a fare una cosa. A prendere il contesto quando si parla, perchè vedo che il contesto ogni volta che posti, viene allargato. Io sto parlando di C/C++/Delphi. Java in questo momento non l'ho considerato. E' chiaro che puoi trovare sempre un contesto che si discosta da quello originale. Ma questo significa rigirare la frittata. Basta che fai una ricerca su Internet e te lo vedi da te.
verissimo! infatti gli errori che commette MS sono dovuti al non sapere progettare, più che al non saper programmare!
Non tocchiamo questo discorso, perchè sai che non ci sono metri per poter giudicare quello che si chiama "progettazione" quando si parla di Microsoft.
Ascolta Kont3, devi impararare a fare una cosa. A prendere il contesto quando si parla, perchè vedo che il contesto ogni volta che posti, viene allargato. Io sto parlando di C/C++/Delphi. Java in questo momento non l'ho considerato. E' chiaro che puoi trovare sempre un contesto che si discosta da quello originale. Ma questo significa rigirare la frittata. Basta che fai una ricerca su Internet e te lo vedi da te.
scusami.. intendevo solo dire che non era l'esempio migliore che potevi fare!
Non tocchiamo questo discorso, perchè sai che non ci sono metri per poter giudicare quello che si chiama "progettazione" quando si parla di Microsoft.
hai già cercato di dimostrare di là che la suite OneCare sarebbe sicura... se quelli non sono errori di progettazione :D
comunque ok! in generale non c'è un metro di paragone!
Non ho mai detto che sarebbe il migliore :) E' semplicemente il mio.... stop :)
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.
In effetti (e ti sfido a provare il contrario) non ho mai detto che in Delphi puoi usare *solo* New() e ho poi - giustamente - aggiunto che usare GetMem() in Delphi ha ben poco senso. Tutto questo esula comunque dal fatto che consideri anche Delphi un linguaggio di "medio" livello (certo... poi ci sono anche altre piccole, a volte banali, differenze che in senso assoluto mi fanno dire che il C/C++ sia un filino a più basso livello anche rispetto a Delphi, ma come già detto li considero più o meno sullo stesso piano ed abbastanza staccati da altri suddetti linguaggi).
Io ho capito così, mi sembra chedal tuo post si evinceva quel concetto. Lo riquoto:
Per farti un esempio in C puoi usare malloc() e devi specificare esattamente la dimensione della memoria da allocare. In Pascal invece utilizzi new() e devi semplicemente specificare il nome della variabile da allocare (si arrangia da solo nelle questioni "di più basso livello")
Io ne desumo che in C puoi ed in Delph non puoi, magari ho capito male che ti devo dire...
Quella affermazione era sempre contenuta nel mio primo post ed era parte integrante del post intero.
Beh ma ormai non c'entrava più nel discorso, almeno per me.
Si, ti ho appunto fatto notare il *grave* errore (che poi, per fortuna, hai provveduto a correggere). L'hai anche fatto passare come se fosse colpa mia se avevo quotato la tua frase "erronea"
Assolutamente non era mia intenzione! Mi spiace tu abbia frainteso pensando in questo modo! Ho pure insistito sul fatto "ops ho sbagliato e mi correggo", ci mancherebbe che do' la colpa a te per un mio errore!
... per poi (in un altro momento) passare sulla difensiva col post #98 quando mi hai detto:
"Se mi dai il tempo di leggere un post che stavi scrivendo mentre scrivevo il mio.... "
Lì ti assicuro che che stavo scrivendo mentre tu postavi il link a questo thread, ci sono gli orari dei post a dimostrarlo ;)
Insomma... gli altri devono aspettare la revisione A, B e C dei tuoi post... ma poi devono anche lasciare a te a tutto tempo di leggere i post altrui (al che non potevo sapere che non lo avessi letto... ho pensato ti fosse sfuggito) e tentando in questo modo di alimentare un flame inutile.
Ok questione chiarita.
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ì.
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...).
Per me la questione è chiarita e chiusa ;)
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.
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.
:eek: 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 :)
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... :asd:
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 ;)
@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) :)
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.
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.
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ì?
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
04-02-2006, 16:58
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... )
Ciao a tutti, discussione interessante... :)
Ciao a te ;)
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?
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 :(
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) :D
ekerazha
04-02-2006, 17:35
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 :)
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) :D
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 ;(
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.
ekerazha
04-02-2006, 17:45
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 :)
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.
ekerazha
04-02-2006, 17:46
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
04-02-2006, 17:49
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.
E quindi? :)
E quindi la questione va portata sul piano sintattico, non implementativo. Visto che le API di un kernel si possono richiamare anche da linguaggi ad "alto livello". Quindi il discorso che fai della malloc() non è utile ai fini della valutazione. Tutto qui' ;)
ekerazha
04-02-2006, 17:53
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.
Allora mi sembra evidente come tu ti sia fatto un'idea sbagliata :)
Inoltre parli di "programmi fatti da milioni di righe di codice" come se quelle milioni di righe le avesse scritte tutte una sola persona.
Se facciamo un programma di 100 righe in 100 persone e ognuno scrive una riga... è abbastanza difficile (per dei programmatori degni di tale nome ;) ) che vi siano molti errori. Quindi quei bei "milioni di righe" suddividili tra i vari programmatori che hanno scritto il codice e come già detto ti assicuro che, a parità di numero di righe, linguaggio di programmazione ed algoritmo da eseguire... vi saranno programmatori che lo scriveranno in maniera più e meno efficiente, più e meno curato, più e meno buggato: i programmatori non sono tutti uguali.
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 mi mettere in mezzo!
il medio livello è una tua invenzione! c++ è di alto livello.
Allora mi sembra evidente come tu ti sia fatto un'idea sbagliata :)
Inoltre parli di "programmi fatti da milioni di righe di codice" come se quelle milioni di righe le avesse scritte tutte una sola persona.
Se facciamo un programma di 100 righe in 100 persone e ognuno scrive una riga... è abbastanza difficile (per dei programmatori degni di tale nome ;) ) che vi siano molti errori. Quindi quei bei "milioni di righe" suddividili tra i vari programmatori che hanno scritto il codice e come già detto ti assicuro che, a parità di numero di righe, linguaggio di programmazione ed algoritmo da eseguire... vi saranno programmatori che lo scriveranno in maniera più e meno efficiente, più e meno curato, più e meno buggato: i programmatori non sono tutti uguali.
Ciò non toglie che le tue 100 righe di codice si interfacciano con le altre milioni di righe di codice. Quindi anche un uso improprio di funzioni che non hai scritto tu può portare a risultati catastrofici.
:doh:
Va bhè non ci sta proprio concezione di causa è inutile.
E quindi? :)
Sorry travisato completamente :D
ekerazha
04-02-2006, 17:57
Casomai è "Application Programming Interface. Ma che facciamo adesso, a fronte di argomentazioni smontate ci diamo agli apostrofi adesso?
Azz... mio refuso :) Comunque si... la precisione è sacra.
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
Diamine... "chicercatrova2000.it" non era ancora tra le mie fonti più autorevoli.
Java ha indubbiamente una sintassi in molti casi diversa da quella del C++, ma secondo il tuo ragionamento essa dovrebbe corrispondere ad un "livello di astrazione" superiore. A me sembrano semplicemente diverse e tra la comprensione di una o dell'altra non vedo particolari differenze in termini di astrazione.
Che poi, come ho già detto, parlare di "medio livello" è solo una convenzione, perchè non fa categoria.
Chiaramente è una convenzione :)
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 ;(
eheh scusami! una volta sapevo molte più cose sul GC.. ma poi le ho rimosse :D
ekerazha
04-02-2006, 18:03
E quindi la questione va portata sul piano sintattico, non implementativo. Visto che le API di un kernel si possono richiamare anche da linguaggi ad "alto livello". Quindi il discorso che fai della malloc() non è utile ai fini della valutazione. Tutto qui' ;)
Ti stai limitando alla valutazione della funzione... se anche potessi "emulare" la malloc() in un linguaggio d'alto livello, poi esso non ti fornirebbe gli strumenti atti a gestirla in maniera consona :)
Mi autoquoto:
Sorry travisato completamente :D
Ah allora non avevo travisato poi del tutto!
ekerazha
04-02-2006, 18:04
non mi mettere in mezzo!
Ok :) Però la tua osservazione è stata utile...
il medio livello è una tua invenzione! c++ è di alto livello.
Ne stiamo discutendo... qui (ma anche altrove) nessuno detiene verità assoluta credo.
Diamine... "chicercatrova2000.it" non era ancora tra le mie fonti più autorevoli.
Java ha indubbiamente una sintassi in molti casi diversa da quella del C++, ma secondo il tuo ragionamento essa dovrebbe corrispondere ad un "livello di astrazione" superiore. A me sembrano semplicemente diverse e tra la comprensione di una o dell'altra non vedo particolari differenze in termini di astrazione.
Il C dispone di 32 parole riservate. Il C99 ne ha aggiunte solo 5. Il C++ ha tutte quelle del C piu' quelle sue. Java nell'ultima versione (J2SE5) conta di un totale di 50 parole riservate. Secondo te VB e Delphi ne hanno di piu' o di meno? A proposito, Herbert Schildt, un membro del comitato di standardizzazione di C e C++, definisce di "medio livello" linguaggi come C, C++, Java e Forth. Fai un po tu.
Ti stai limitando alla valutazione della funzione... se anche potessi "emulare" la malloc() in un linguaggio d'alto livello, poi esso non ti fornirebbe gli strumenti atti a gestirla in maniera consona :)
Non ho capito cosa vuoi dire...
sempre riferendomi al java, e se come handle e smart pointer stiamo parlando di questi concetti:
http://en.wikipedia.org/wiki/Smart_pointer
Letto, parliamo di questo concetti ;)
1) tutti i riferimenti(puntatori) sono in pratica smart pointer
Sì, ma in java grazie allo smart pointer posso pure indicare un puntatore come "weak", "phantom", ecc... In questo modo si va ad influenzare il GC. E' questo che mi interessa ;)
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.
Non ho capito: mi dici che nel caso da te descritto il GC libera la risorsa oppure no?
Come dicevo anche al punto 1), se io indico un puntatore come 'strong reference', il GC quando me la dealloca e quando no?
ekerazha
04-02-2006, 18:18
Il C dispone di 32 parole riservate. Il C99 ne ha aggiunte solo 5. Il C++ ha tutte quelle del C piu' quelle sue. Java nell'ultima versione (J2SE5) conta di un totale di 50 parole riservate. Secondo te VB e Delphi ne hanno di piu' o di meno? A proposito, Herbert Schildt, un membro del comitato di standardizzazione di C e C++, definisce di "medio livello" linguaggi come C, C++, Java e Forth. Fai un po tu.
VB e Delphi direi che ne hanno molte ;)
C++ e Java non penso siano molto diversi (il C è ovvio che ne abbia meno, dato il suo non-supporto alla programmazione ad oggetti).
Per quanto riguarda "Herbert Schildt", bisognerebbe leggere le motivazioni che lo hanno portato a quella affermazione. Possono essere condivisibili o meno credo, anche lui è umano ;)
eheh scusami! una volta sapevo molte più cose sul GC.. ma poi le ho rimosse :D
Capita spesso purtroppo :(
Per quanto riguarda "Herbert Schildt", bisognerebbe leggere le motivazioni che lo hanno portato a quella affermazione. Possono essere condivisibili o meno credo, anche lui è umano ;)
Beh quantomeno è sicuramente una fonte più autorevole di tutti quanti noi...
C'avete presente la pubblicita di Lavazza con Bonolis e Laurenti al pianoforte?
No, io m'arendo... E' inutile... :rotfl:
Lascio un po di libri da consultare a ekerazha, magari potrebbe trovarvi un po piu di luce su argomenti che si denota vi è un po confuso:
Barbuti, Mancarela, Montangero
Semantica Operazionale
SEU di Pisa
Carlo montangero
Elementi di Sintassi dei Linguaggi di Programmazione.
SEU Pisa
Aho, Sethi, Ullman
Compilers: Principles, Techniques and Tools
Addison Wesley
Questo per capire cos'è un linguaggio, cos'è la sua sintassi e semantica. E per capire ed avere un minimo di base di teoria dei linguaggi formali.
e infine:
Martin Fowler
UML Distilled
Addison Wesley
Kendall Scott
UML Explained
Addison Wesley
e
Richard Pressman
Principi di Ingegneria del Software
McGraw-Hill
per avere almeno un briciolo di idea di cosa significa scrivere software non banale.
Con questo chiudo.
ekerazha
04-02-2006, 18:22
Non ho capito cosa vuoi dire...
Allora.
Se uso C ed utilizzo l'allocazione dinamica della memoria, per i puntatori utilizzo la notazione * (ad esempio).
Se in un "linguaggio ad alto livello" "emulo" la malloc() e gli faccio allocare determinata memoria, poi dal linguaggio Java come gestirei questa memoria (magari è anche possibile... non mi sono mai avventurato in questo genere d'esperienza con Java... illuminatemi :) )?
ekerazha
04-02-2006, 18:25
Beh quantomeno è sicuramente una fonte più autorevole di tutti quanti noi...
Anche i politici che lavorano in politica da 40 anni sono più autorevoli di noi, ma questo non ci impedisce (spero) di discutere di determinati argomenti ;)
Comunque come già detto mi piacerebbe leggere queste affermazioni e le relative argomentazioni... altrimenti io potrei ribattere che "dio" ha detto che le cose stanno diversamente :D ed avere la stessa credibilità.
ekerazha
04-02-2006, 18:28
C'avete presente la pubblicita di Lavazza con Bonolis e Laurenti al pianoforte?
No, io m'arendo... E' inutile... :rotfl:
Lascio un po di libri da consultare a ekerazha, magari potrebbe trovarvi un po piu di luce su argomenti che si denota vi è un po confuso:
[...]
[...]
[...]
Questo per capire cos'è un linguaggio, cos'è la sua sintassi e semantica. E per capire ed avere un minimo di base di teoria dei linguaggi formali.
e infine:
[...]
[...]
e
[...]
per avere almeno un briciolo di idea di cosa significa scrivere software non banale.
Con questo chiudo.
Per cortesia risparmiami questi patetici esercizi di retorica.
Tu li hai letti tutti questi libri? Si parla dell'argomento di cui stiamo discutendo? In quali termini? E si parla di questo in tutti i libri o solo in alcuni? Quali? Quali argomentazioni vengono portate a sostegno delle loro tesi (e quali sarebbero le loro tesi?). Se le argomentazioni sono le stesse che hai portato tu, credo sia meglio non buttare i soldi ;)
P.S.
Visto che pur non sapendo a quali progetti partecipo io dici che "scrivo software banale", mi piacerebbe molto conoscere cosa hai sviluppato TU.
Poi metteremo a confronto le due cose e vedremo chi si farà quattro risate ;)
Allora.
Se uso C ed utilizzo l'allocazione dinamica della memoria, per i puntatori utilizzo la notazione * (ad esempio).
Se in un "linguaggio ad alto livello" "emulo" la malloc() e gli faccio allocare determinata memoria, poi dal linguaggio Java come gestirei questa memoria (magari è anche possibile... non mi sono mai avventurato in questo genere d'esperienza con Java... illuminatemi :) )?
in java non credo si possa fare (almeno non l'ho mai fatto)... in C# (che consideri di alto livello) continui a usare la notazione *!
comunque sia non penso che la gestione della memoria sia determinante per stabilire cosa è di alto livello e cosa di un ipotetico medio livello
Ho trovato un bel link per chiarirsi le idee:
Garbage collectors FAQ (http://www.iecc.com/gclist/GC-faq.html)
Domani me lo leggo ;)
ekerazha
04-02-2006, 18:38
Comunque mjordan... quei libri (dai titoli) sembrerebbero abbastanza "basilari" (tranne "Ingegneria del software", materia tra l'altro trattata nel corso di Ingegneria Informatica) e mi sembrerebbero più adatti ad un pubblico come te :)
Tra l'altro alcuni di quelli sono poco inerenti all'argomento di discussione :)
ekerazha
04-02-2006, 18:40
in java non credo si possa fare (almeno non l'ho mai fatto)... in C# (che consideri di alto livello) continui a usare la notazione *!
Buono a sapersi (se è davvero tutto così) :)
ekerazha
04-02-2006, 18:40
comunque sia non penso che la gestione della memoria sia determinante per stabilire cosa è di alto livello e cosa di un ipotetico medio livello
No... ma può essere un fattore di valutazione :)
[breve OT]
Richard Pressman
Principi di Ingegneria del Software
McGraw-Hill
Urgh! Anche grazie a lui dopo aver fatto Ingegneria del software I NON ho continuato con il II! Ho preferito concentrarmi sulle reti :D
Non so voi, io ho trovato quella materia davvero molto (forse troppo?) teorica. Reti di Petri... Incubi :(
Comunque mjordan... quei libri (dai titoli) sembrerebbero abbastanza "basilari" (tranne "Ingegneria del software", materia tra l'altro trattata nel corso di Ingegneria Informatica) e mi sembrerebbero più adatti ad un pubblico come te :)
Tra l'altro alcuni di quelli sono poco inerenti all'argomento di discussione :)
Beh UML Explained non lo troverei così basilare...
quei libri (dai titoli) sembrerebbero abbastanza "basilari" (tranne "Ingegneria del software", materia tra l'altro trattata nel corso di Ingegneria Informatica) e mi sembrerebbero più adatti ad un pubblico come te :))
potesti risparmiare simili commenti che con l'ingegneria hanno poco a che vedere
ekerazha
04-02-2006, 18:44
Buono a sapersi (se è davvero tutto così) :)
Si sembrerebbe così: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/csspec/html/vclrfcsharpspec_A_8.asp
Allora si innalza un altro scalino, Java potrebbe essere considerato di più alto livello rispetto a C# :)
Si sembrerebbe così: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/csspec/html/vclrfcsharpspec_A_8.asp
Allora si innalza un altro scalino, Java potrebbe essere considerato di più alto livello rispetto a C# :)
:doh:
ps. comunque te lo avevo già fatto notare! non so perchè non mi avevi creduto nell'altra discussione
ekerazha
04-02-2006, 18:47
Beh UML Explained non lo troverei così basilare...
UML non mi sembra particolarmente ostico.
potesti risparmiare simili commenti che con l'ingegneria hanno poco a che vedere
Hai ragione. Ma improvvisamente mi sono reso conto che nel post precedente non avevo risposto a tono in maniera adeguata :)
Anche i politici che lavorano in politica da 40 anni sono più autorevoli di noi, ma questo non ci impedisce (spero) di discutere di determinati argomenti ;)
Comunque come già detto mi piacerebbe leggere queste affermazioni e le relative argomentazioni... altrimenti io potrei ribattere che "dio" ha detto che le cose stanno diversamente :D ed avere la stessa credibilità.
I politici sono tutt'altra roba rispetto a chi fa parte del comitato di standardizzazione del C/C++. I politici normalmente mentono per mestiere...
ekerazha
04-02-2006, 18:49
:doh:
ps. comunque te lo avevo già fatto notare! non so perchè non mi avevi creduto nell'altra discussione
Evidentemente mi era sfuggito. Comunque ricordo che ci sono anche altri fattori da valutare rispetto a quello (portato a tittolo esemplificativo) dell'allocazione dinamica.
UML non mi sembra particolarmente ostico.
Non ho detto che è ostico, ho detto che non è basilare. Mica tutte le cose non basilari sono ostiche... Avevi parlato di testi basilari, mica di testi di difficile comprensione. Comunque, per il mio povero cervello, UML non è stato poi così facile ad alti livelli. Magari era una cavolata quando modellavo le classi negli esami di programmazione ad oggetti, ma in ignegneria del software gli schemi sono un po' più complessi.
Evidentemente mi era sfuggito. Comunque ricordo che ci sono anche altri fattori da valutare rispetto a quello (portato a tittolo esemplificativo) dell'allocazione dinamica.
se ad esempio consideri l'orientazione ad oggetti dei due linguaggi ottieni che C# è di più alto livello rispetto a java! perchè in C# l'orientazione è portata all'estremo, non ci sono tipi primitivi e ti permette di usare una sintassi tipo:
12.toString(); // non scherzo
la conclusione è che di sicuro non si può dare un giudizio così frettoloso come hai fatto :D
ekerazha
04-02-2006, 18:55
I politici sono tutt'altra roba rispetto a chi fa parte del comitato di standardizzazione del C/C++. I politici normalmente mentono per mestiere...
Ahaha... qua bisognerebbe forkare nuovamente il thread :)
Io rispetto l'opinione di tutti ma pretendo che gli altri rispettino la mia... d'altronde "opinioni rispettabilissime" rimangono sempre opinioni e credo che gli obiettivi del comitato di standardizzazione del C/C++ siano abbastanza lontani da quello di definire quale linguaggio sia di "alto" o "medio" livello.
Questa è solo inutile retorica e non so perchè ci sto perdendo (ci stiamo perdendo) tempo da oggi pomeriggio... tant'è che nell'altro thread quando ho scritto "medio livello" era solamente in un contesti discorsivo, dato che i concetti che volevo esprimere erano altri... mai avrei pensato che ne potesse scaturire una discussione. E' come se prendessi un articolo da una vostra frase e si iniziasse a discutere di cosa sia l'articolo determinativo.
Detto questo... temo che tra poco vi dovrò lasciare dato che devo uscire e sono già in ritardissimo :muro:
ekerazha
04-02-2006, 18:57
Non ho detto che è ostico, ho detto che non è basilare. Mica tutte le cose non basilari sono ostiche... Avevi parlato di testi basilari, mica di testi di difficile comprensione. Comunque, per il mio povero cervello, UML non è stato poi così facile ad alti livelli. Magari era una cavolata quando modellavo le classi negli esami di programmazione ad oggetti, ma in ignegneria del software gli schemi sono un po' più complessi.
Per basilari intendo che, nel loro campo, esprimono concetti di base... basilari.
MenageZero
04-02-2006, 19:00
Letto, parliamo di questo concetti ;)
Sì, ma in java grazie allo smart pointer posso pure indicare un puntatore come "weak", "phantom", ecc... In questo modo si va ad influenzare il GC. E' questo che mi interessa ;)
Non ho capito: mi dici che nel caso da te descritto il GC libera la risorsa oppure no?
Come dicevo anche al punto 1), se io indico un puntatore come 'strong reference', il GC quando me la dealloca e quando no?
Ora non ho in mente la totalità dei casi possibili, ma ad esempio nel mio punto 2,penso che la rappresentazione in mem. come oggetto, ad es, "FileInputStream", verrà deallocata(essendo parte dell'ambiente di esecuzione java), ma, più importante,se non si chiama il close() l'os manterrà il suo handle aperto per quel file.
cioè di solito se hai un handle, nel senso di quella dfinizione, e quindi in java un riferimento ad un oggetto che ti "aggancia" ad una risorsa esterna all'ambiente di esec. creato dalla jvm, devi operare una qualche chiamata "manuale" per rilasciare quella risorsa; altrimenti la "garbage" la possiamo lasciare all'apposito "collector"... ;)
(il tutto passibile di imprecisioni o eccezzioni, come dicevo non ho la totalità delle possibilità chiara e luminosa in mente al momento, scusami :P)
ekerazha
04-02-2006, 19:02
se ad esempio consideri l'orientazione ad oggetti dei due linguaggi ottieni che C# è di più alto livello rispetto a java! perchè in C# l'orientazione è portata all'estremo, non ci sono tipi primitivi e ti permette di usare una sintassi tipo:
12.toString(); // non scherzo
la conclusione è che di sicuro non si può dare un giudizio così frettoloso come hai fatto :D
Eh... perchè tu inserisci il concetto di "orientazione agli oggetti" fra quelli determinanti per la classificazione del livello d'appartenenza del linguaggio... invece a mio parere esso non è così fondamentale.
Detto questo...
12.ToString() non si può fare perchè avevo provato tempo fa (le prime volte che giocavo con C#) e non si poteva :D
Per basilari intendo che, nel loro campo, esprimono concetti di base... basilari.
Appunto, quel libro non contiene concetti di base, come si evince chiaramente da ciò che mi hai quotato. Non sono troppo ostici ma neanche facili. Forse lo devi leggere. Ah, l'italiano lo capisco eh! :rolleyes:
Ora non ho in mente la totalità dei casi possibili, ma ad esempio nel mio punto 2,penso che la rappresentazione in mem. come oggetto, ad es, "FileInputStream", verrà deallocata(essendo parte dell'ambiente di esecuzione java), ma, più importante,se non si chiama il close() l'os manterrà il suo handle aperto per quel file.
cioè di solito se hai un handle, nel senso di quella dfinizione, e quindi in java un riferimento ad un oggetto che ti "aggancia" ad una risorsa esterna all'ambiente di esec. creato dalla jvm, devi operare una qualche chiamata "manuale" per rilasciare quella risorsa; altrimenti la "garbage" la possiamo lasciare all'apposito "collector"... ;)
(il tutto passibile di imprecisioni o eccezzioni, come dicevo non ho la totalità delle possibilità chiara e luminosa in mente al momento, scusami :P)
:) Mi stai facendo riflettere. Ti ringrazio per le delucidazioni, domani le confronto con quello che c'è scritto sul documento sui GC di cui ho postato prima il link così mi faccio un'idea ancora più precisa. Cmq "a naso" il tuo ragionamento fila ;)
12.ToString() non si può fare perchè avevo provato tempo fa (le prime volte che giocavo con C#) e non si poteva :D
Mi pare pure a me (almeno con il framework 1.1).
ekerazha
04-02-2006, 19:27
Appunto, quel libro non contiene concetti di base, come si evince chiaramente da ciò che mi hai quotato. Non sono troppo ostici ma neanche facili. Forse lo devi leggere. Ah, l'italiano lo capisco eh! :rolleyes:
Ho afferrato :D Sono io che spesso tengo ad assimilare "semplice" e "basilare" :D
ekerazha
04-02-2006, 19:28
Mi pare pure a me (almeno con il framework 1.1).
Nemmeno col 2.0 e Visual Studio .NET 2005 (appena provato).
Ho afferrato :D Sono io che spesso tengo ad assimilare "semplice" e "basilare" :D
Ok ;)
Mi pare pure a me (almeno con il framework 1.1).
http://www.cs.virginia.edu/~lt8f/QUALs/PL/scott/lect39.ppt
Other C# Features
C# provides Java-style garbage collection
C# implements a Java- and Delphi-style value/reference-type system
Variables of primitive types also act like objects (unlike Java primitive objects)
Integer iobj = new Integer(12);
System.out.println(iobj.toString());
Console.WriteLine(12.ToString());
magari si può solo col 12 ;) adesso provo
http://www.cs.virginia.edu/~lt8f/QUALs/PL/scott/lect39.ppt
magari si può solo col 12 ;) adesso provo
Provato, funziona! Ad essere onesto, non mi ero spinto fino a questo livello di astrazione con il C#... che linguaggio folle (nel senso buono) :)
http://www.cs.virginia.edu/~lt8f/QUALs/PL/scott/lect39.ppt
magari si può solo col 12 ;) adesso provo
ahah!
scusate il mio errore!
12.toString() non si può fare... ma 12.ToString() sì :D
ahah!
scusate il mio errore!
12.toString() non si può fare... ma 12.ToString() sì :D
Mi chiedo ekerazha come ha provato... sia a me che a te funziona... boh
Mi chiedo ekerazha come ha provato... sia a me che a te funziona... boh
lui ha scritto toString e non ToString perchè col C# forse ci ha avuto poco a che fare e in java si scrive toString!
comunque il C# è un linguaggio fantastico! peccato che lo ha acquistato MS :rolleyes:
a dire la verità anche io di getto ho scritto toString (colpa di tutto il java che ho masticato di recente), ma poi davanti a monodevelop :D mi è venuto in mente che c'era questa differenza :D
lui ha scritto toString e non ToString perchè col C# forse ci ha avuto poco a che fare e in java si scrive toString!
comunque il C# è un linguaggio fantastico! peccato che lo ha acquistato MS :rolleyes:
Sarà, giacchè ho visto che ha scritto 12.ToString() quando ti ha quotato. Cmq è una sottigliezza, evidentemente avrà sbagliato in fase di prova.
comunque il C# è un linguaggio fantastico! peccato che lo ha acquistato MS :rolleyes:
Come acquistato? Non l'hanno sviluppato loro?
Come acquistato? Non l'hanno sviluppato loro?
si.. effettivamente l'ha sviluppato un team guidato da Anders Hejlsberg (ex-borland) per Microsoft! MS lo ha assunto nel '96
ps. C# mi sembra un linguaggio troppo pulito per essere frutto della mente dello zio bill ;)
pps. mi ero sbagliato a dire "acquistato"
Eh... perchè tu inserisci il concetto di "orientazione agli oggetti" fra quelli determinanti per la classificazione del livello d'appartenenza del linguaggio... invece a mio parere esso non è così fondamentale.
io non considero niente "determinante"! leggi bene quello che ho scritto :read:
ps. C# mi sembra un linguaggio troppo pulito per essere frutto della mente dello zio bill ;)
Beh è noto che lo zio Bill non sia propriamente un grande programmatore... Direi che è stato molto più bravo come imprenditore!!
ekerazha
05-02-2006, 10:50
io non considero niente "determinante"! leggi bene quello che ho scritto :read:
Allroa la tua osservazione non aveva senso di essere fatta..
Allroa la tua osservazione non aveva senso di essere fatta..
determinante significa "che determina"! io ho solo detto che è un elemento da tenere in considerazione! e poi ho detto che non puoi "determinare" il livello di un linguaggio analizzando solo la sua gestione della memoria (cosa che hai fatto frettolosamente)
ekerazha
05-02-2006, 10:58
lui ha scritto toString e non ToString perchè col C# forse ci ha avuto poco a che fare e in java si scrive toString!
No... in effetti ho scritto ToString() solo che non avevo provato a compilare... mi ero "fidato" del fatto che dopo aver scritto il punto (12.) non comparisse l'IntelliSense :D Effettivamente poi provando a compilare funziona ;)
ekerazha
05-02-2006, 11:00
determinante significa "che determina"! io ho solo detto che è un elemento da tenere in considerazione! e poi ho detto che non puoi "determinare" il livello di un linguaggio analizzando solo la sua gestione della memoria (cosa che hai fatto frettolosamente)
Determinante nel senso che contribuisce a determinare... chiaramente non è l'unico fattore... solo che a mio parere fra i fattori da considerare non è il più rilevante...
Seconda cosa... io non ho mai detto di analizzare solo la gestione della memoria, ho sempre detto (e se vuoi ti cito i post) che è solo un esempio, una cosa tra le altre...
Determinante nel senso che contribuisce a determinare... chiaramente non è l'unico fattore... solo che a mio parere fra i fattori da considerare non è il più rilevante...
Seconda cosa... io non ho mai detto di analizzare solo la gestione della memoria, ho sempre detto (e se vuoi ti cito i post) che è solo un esempio, una cosa tra le altre...
ok.. dobbiamo parlare la stessa lingua però, perchè se dici che una cosa determina un'altra vuol dire che da sola basta! piuttosto potevi dire contribuisce..
Determinante nel senso che contribuisce a determinare...
Sarò onesto. Penso che qui un minimo di italiano lo conoscano tutti. Le parole hanno un significato preciso, non è che puoi interpretarle a tuo piacimento a seconda delle necessità del caso. Ho visto che è una tua abitudine. In questo caso scrivo sotto il significato della parola "determinante":
determinante: agg. CO - che è fondamentale, decisivo, risolutivo: una decisione d., la sua partecipazione è stata d. per la riuscita del progetto
Dal dizionario De Mauro della lingua italiana.
ekerazha
05-02-2006, 11:34
Sarò onesto. Penso che qui un minimo di italiano lo conoscano tutti. Le parole hanno un significato preciso, non è che puoi interpretarle a tuo piacimento a seconda delle necessità del caso. Ho visto che è una tua abitudine. In questo caso scrivo sotto il significato della parola "determinante":
determinante: agg. CO - che è fondamentale, decisivo, risolutivo: una decisione d., la sua partecipazione è stata d. per la riuscita del progetto
Dal dizionario De Mauro della lingua italiana.
Certo... ma non dice "l'unico fondamentale" "l'unico decisivo" "l'unico risolutivo".
Le cose fondamentali, decisive, risolutive possono sempre essere più di una... non mi sembra così difficile.
Certo... ma non dice "l'unico fondamentale" "l'unico decisivo" "l'unico risolutivo".
Le cose fondamentali, decisive, risolutive possono sempre essere più di una... non mi sembra così difficile.
:confused: :mc:
Certo... ma non dice "l'unico fondamentale" "l'unico decisivo" "l'unico risolutivo".
A me le parole "fondamentale", "decisivo" e "risolutivo" sembrano già abbastanza esplicite.
Le cose fondamentali, decisive, risolutive possono sempre essere più di una... non mi sembra così difficile.
Nel qual caso si dice "contribuisce a determinare".
Ti do' un consiglio, senza offesa. La presunzione non ti aiuterà un domani, soprattutto quando inizierai a lavorare. E' sempre meglio imparare dai propri errori invece che arrampicarsi sugli specchi per cercare di dimostrare "ho detto una cosa giusta" quando magari giusta non è. Tra l'altro anche k0nt3 mi pare abbia capito in un altro modo.
ekerazha
05-02-2006, 11:55
A me le parole "fondamentale", "decisivo" e "risolutivo" sembrano già abbastanza esplicite.
Nel qual caso si dice "contribuisce a determinare".
Ti do' un consiglio, senza offesa. La presunzione non ti aiuterà un domani, soprattutto quando inizierai a lavorare. E' sempre meglio imparare dai propri errori invece che arrampicarsi sugli specchi per cercare di dimostrare "ho detto una cosa giusta" quando magari giusta non è. Tra l'altro anche k0nt3 mi pare abbia capito in un altro modo.
Ma in che mondo sono finito?
Ti faccio un esempio semplice... per fare una macchina sono fondamentali 4 ruote... non mi sembra di difficile comprensione... :rolleyes:
Io spero davvero stiate scherzando, altrimenti siete messi male... ma davvero malissimo...
Voi confondete con "necessario e sufficiente"...
Ma in che mondo sono finito?
Ti faccio un esempio semplice... per fare una macchina sono fondamentali 4 ruote... non mi sembra di difficile comprensione... :rolleyes:
Io spero davvero stiate scherzando, altrimenti siete messi male... ma davvero malissimo...
determinare vuol dire che da solo basta per decidere! mi sembra di essere stato chiaro, e la gestione della memoria non è determinante per il livello di un linguaggio punto.
ps. se ci sono più cose determinanti vuol dire che ci sono più cose che da sole bastano per decidere (si tratta di italiano)
Ma in che mondo sono finito?
Ti faccio un esempio semplice... per fare una macchina sono fondamentali 4 ruote... non mi sembra di difficile comprensione... :rolleyes:
Io spero davvero stiate scherzando, altrimenti siete messi male... ma davvero malissimo...
Mi sa che aveva ragione mjordan:
No, io m'arendo... E' inutile...
ekerazha
05-02-2006, 12:05
determinare vuol dire che da solo basta per decidere!
Errato. Vatti a rileggere la definizione sul dizionario... questa cosa non è scritta da nessuna parte...
... mi sembra davvero di essere capitato fra un manipolo di pazzi...
... mi sembra davvero di essere capitato fra un manipolo di pazzi...
Ecco una barzelletta:
"Un signore esce di casa, entra in macchina e si mette in viaggio in autostrada per andare a trovare un amico. Accende la radio, e mentre sente musica le trasmissioni sono interrotte per lanciare un preoccupante messaggio: 'Attenzione!! Un pazzo sta viaggiando contromano, siate prudenti stiamo facendo il possibile per fermarlo!". Poco dopo il signore vede sfrecciare una macchina contromano. 'Uff lo evitato!' pensa. subito dopo ne sfreccia un altro, e un altro ancora. Al che il signore pensa: 'Un matto?? Ma qui sono TUTTI matti!!'"
ekerazha
05-02-2006, 12:17
Ecco una barzelletta:
"Un signore esce di casa, entra in macchina e si mette in viaggio in autostrada per andare a trovare un amico. Accende la radio, e mentre sente musica le trasmissioni sono interrotte per lanciare un preoccupante messaggio: 'Attenzione!! Un pazzo sta viaggiando contromano, siate prudenti stiamo facendo il possibile per fermarlo!". Poco dopo il signore vede sfrecciare una macchina contromano. 'Uff lo evitato!' pensa. subito dopo ne sfreccia un altro, e un altro ancora. Al che il signore pensa: 'Un matto?? Ma qui sono TUTTI matti!!'"
E' vecchia... consiglio: invece delle barzellette prova con i fatti
E' vecchia... consiglio: invece delle barzellette prova con i fatti
Eh ci ho provato, ma non è servito a molto...
ekerazha
05-02-2006, 12:24
Eh ci ho provato, ma non è servito a molto...
Ho detto fatti non invenzioni...
Ho detto fatti non invenzioni...
:mc: :muro:
ekerazha
05-02-2006, 12:44
:mc: :muro:
Non c'è nulla da arrampicarsi... si chiama lingua italiana
Non c'è nulla da arrampicarsi... si chiama lingua italiana
:rotfl:
Ok rispondo così poiché ormai mi sono arreso :rolleyes:
ekerazha
05-02-2006, 13:00
Questa discussione è scaduta... penso sia ormai giunta la sua sera...
Voi confondete con "necessario e sufficiente"...
tu confondi determinante con necessario invece
comunque sia mi pare che il discorso sui linguaggi non abbia tutto questo senso, a meno che non si considera il C# di "medio livello"... cosa che IMHO trovo assurda..
ekerazha
05-02-2006, 13:20
tu confondi determinante con necessario invece
Non mi risulta... entrambe hanno un significato ben preciso... e nel caso delle prima non è quello che intendi tu (o voi), dizionario alla mano (se poi ci mettiamo a fare "stravaganti interpretazioni" su definizioni che sono invece ben precise... allora siamo punto e a capo).
comunque sia mi pare che il discorso sui linguaggi non abbia tutto questo senso, a meno che non si considera il C# di "medio livello"... cosa che IMHO trovo assurda..
Infatti io non lo considero di medio livello...
... comunque ormai le varie posizioni mi sembrano chiare, è inutile continuare a discutere sul sesso degli angeli, ribadisco:
Questa discussione è scaduta... penso sia ormai giunta la sua sera...
:)
Questa discussione è scaduta... penso sia ormai giunta la sua sera...
Indovina grazie a chi... sei proprio senza speranza.
Io intanto aspetto delle risposte sul GC, che in parte sono arrivate, quindi per me quegli argomenti sono ancora validi.
ekerazha
05-02-2006, 13:40
Indovina grazie a chi... sei proprio senza speranza.
Io intanto aspetto delle risposte sul GC, che in parte sono arrivate, quindi per me quegli argomenti sono ancora validi.
Guarda... volevo dire la stessa cosa su di te ma non l'ho detto perchè a differenza tua ho un briciolo di educazione e maturità e cerco di non alimentare flame inutilmente.
Per quanto mi riguarda, sul GC quello che bisognava dire è stato detto.
Cresci.
Cresci.
No comment :rotfl:
ekerazha
05-02-2006, 15:43
No comment :rotfl:
Bravo. Dopo aver dimostrato scarsa competenza con i tuoi errori grossolani mentre tentavi di addentrarti in argomenti che esulano dalla tua conoscenza ed il tentativo di "invenzione" della lingua italiana, l'unico modo che hai per dare una parvenza di intelligenza è proprio quella di non parlare :)
P.S.
Come già detto... il riso abbonda sulla bocca degli stolti :)
Bravo.
Grazie!
Dopo aver dimostrato scarsa competenza con i tuoi errori grossolani mentre tentavi di addentrarti in argomenti che esulano dalla tua conoscenza ed il tentativo di "invenzione" della lingua italiana, l'unico modo che hai per dare una parvenza di intelligenza è proprio quella di non parlare :)
P.S.
Come già detto... il riso abbonda sulla bocca degli stolti :)
Sisi ho dimostrato scarsa competenza, continua così :ahahah:
ekerazha
05-02-2006, 15:58
Sisi ho dimostrato scarsa competenza, continua così :ahahah:
Tu nel frattempo continua ad istanziare oggetti con New() in Delphi ;)
Sei solo un poveraccio :)
... ora ti lascerei anche l'ultima parola se vuoi replicare ;)
rdefalco
05-02-2006, 16:09
:mbe: la finite?
Stavo seguendo la discussione relativa alla parte del Garbage Collection poi non ho capito più niente, men che meno il voler giudicare il "livello" di un linguaggio di programmazione.
Tu nel frattempo continua ad istanziare oggetti con New() in Delphi ;)
Sei solo un poveraccio :)
... ora ti lascerei anche l'ultima parola se vuoi replicare ;)
Dopo tutte le castronerie che hai detto e che hai pure difeso arrampicandoti sugli specchi, ci mancherebbe che devo replicare su una cosa che ho corretto da solo prima che me lo facessi notare, e su cui abbiamo largamente parlato prima. Ormai ti ho capito, quando non hai più argomenti arrivi a questi livelli, se io sono un poveraccio... :ahahah:
Per fortuna questo thread e l'altro staranno ad evidenziare la tua presunzione e la tua superficialtà negli argomenti per un bel pezzo.
Con questo ho chiuso. Puoi trolleggiare quanto vuoi da ora in poi, non ti seguo.
:mbe: la finite?
Io ho finito, torniamo in topic.
Stavo seguendo la discussione relativa alla parte del Garbage Collection poi non ho capito più niente, men che meno il voler giudicare il "livello" di un linguaggio di programmazione.
Sì, io avevo posto dei quesiti, poi ho postato un link sui GC che però non ho ancora avuto modo di leggere. MenageZero ha già detto qualcosa. Hai qualche informazione in merito?
rdefalco
05-02-2006, 16:34
Sì, io avevo posto dei quesiti, poi ho postato un link sui GC che però non ho ancora avuto modo di leggere. MenageZero ha già detto qualcosa. Hai qualche informazione in merito?
:nonsifa: No, leggevo per apprendere...
ekerazha
05-02-2006, 16:39
Dopo tutte le castronerie che hai detto e che hai pure difeso arrampicandoti sugli specchi, ci mancherebbe che devo replicare su una cosa che ho corretto da solo prima che me lo facessi notare, e su cui abbiamo largamente parlato prima. Ormai ti ho capito, quando non hai più argomenti arrivi a questi livelli, se io sono un poveraccio...
Per fortuna questo thread e l'altro staranno ad evidenziare la tua presunzione e la tua superficialtà negli argomenti per un bel pezzo.
Con questo ho chiuso. Puoi trolleggiare quanto vuoi da ora in poi, non ti seguo.
Tutte castronerie a cui non hai saputo contrapporre la minima argomentazione convincente se non fraintendendo le cose che venivano dette e commettendo errori come già detto grossolani, al culmine dei quali vi è stata l'uscita su Delphi, sulla quale nessuno mette in dubbio che tu ti sia corretto (e ci mancherebbe altro) ma sulla quale è scandaloso che tu abbia potuto sbagliare in quanto è una cosa davvero "basilare" ;) e sulla quale non dovrebbe essere necessaria la minima riflessione. Occasione che non è stata altro che la punta di un enorme iceberg: il tuo scarso ed imbarazzante livello di competenza. Come hai detto tu, per fortuna i due thread rimarranno :)
Con questo ho chiuso. Puoi trolleggiare quanto vuoi da ora in poi, non ti seguo.
Speriamo. Discutere con te non è stato un piacere. Per il resto c'è ben poco da trolleggiare. Ti consiglio piuttosto una attenta analisi di coscienza.
la finite?
Ho finito. Spero.
:nonsifa: No, leggevo per apprendere...
Intanto riposto il link sui GC:
Garbage collectors FAQ (http://www.iecc.com/gclist/GC-faq.html)
Magari dopo aver letto questo documento escono fuori precisazioni interessanti.
@ekerazha
Stavo pensando: ora ho capito da dove prendi argomenti. Semplicemente inventi. Mi piacerebbe vedere tutti gli errori grossolani che ho commesso rispondendoti, al culmine dei quali dici ci sia quella della New(), sulla quale puoi pensare che per la tua mente superiore sia una cosa ovvia, ma appunto capita di sbagliare anche su cose ovvie, ma evidentemente tu non contempli neanche una svista (tra l'altro corretta 5 minuti dopo autonomamente). Questo non per fare polemica, ma per farti rendere conto che prendere in giro le persone su cose inventate non ti fa bene su un forum pubblico.
Scrivo questo solo perchè mi da fastidio che mi si attacchi dicendo falsità.
Forse questo post è inutile, perchè tutti gli altri parlano da soli, ma a volte non riesco a trattenermi e certe cose devo dirle. Questo è uno di quei momenti.
Ah, non voglio assolutamente rientrare in polemica, mi piacerebbe parlare di tutt'altro, solo che se vuoi, puoi postare, quotando, questi errori grossolani che avrei a tuo parere commesso. Ti consiglio di evitare la storia della New() ripetendo "sì l'hai corretta, ma non dovevi sbagliare!" perchè davvero non sta in piedi, se siamo ancora uomini e non macchine. Se questi errori ci sono, la brutta figura la faccio io, altrimenti la fai tu, ed il perché sarà evidente.
ekerazha
05-02-2006, 18:49
@ekerazha
Stavo pensando: ora ho capito da dove prendi argomenti. Semplicemente inventi. Mi piacerebbe vedere tutti gli errori grossolani che ho commesso rispondendoti, al culmine dei quali dici ci sia quella della New(), sulla quale puoi pensare che per la tua mente superiore sia una cosa ovvia, ma appunto capita di sbagliare anche su cose ovvie, ma evidentemente tu non contempli neanche una svista (tra l'altro corretta 5 minuti dopo autonomamente). Questo non per fare polemica, ma per farti rendere conto che prendere in giro le persone su cose inventate non ti fa bene su un forum pubblico.
Scrivo questo solo perchè mi da fastidio che mi si attacchi dicendo falsità.
Forse questo post è inutile, perchè tutti gli altri parlano da soli, ma a volte non riesco a trattenermi e certe cose devo dirle. Questo è uno di quei momenti.
Ah, non voglio assolutamente rientrare in polemica, mi piacerebbe parlare di tutt'altro, solo che se vuoi, puoi postare, quotando, questi errori grossolani che avrei a tuo parere commesso. Ti consiglio di evitare la storia della New() ripetendo "sì l'hai corretta, ma non dovevi sbagliare!" perchè davvero non sta in piedi, se siamo ancora uomini e non macchine. Se questi errori ci sono, la brutta figura la faccio io, altrimenti la fai tu, ed il perché sarà evidente.
Ehm...
Puoi trolleggiare quanto vuoi da ora in poi, non ti seguo.
Io ho finito, torniamo in topic.
Le ultime parole famose di un uomo coerente ;)
Purtroppo domani ho un esame e con te ho già perso/sprecato fin troppo tempo, quindi per stasera nisba. Martedì se vuoi ti accontento. Io speravo veramente che la cosa fosse conclusa... ma se continui a rimuginare è segno che evidentemente hai la "coscienza sporca" (ed in effetti è probabile che sia così) :)
A martedì :)
rdefalco
05-02-2006, 18:56
Intanto riposto il link sui GC:
Garbage collectors FAQ (http://www.iecc.com/gclist/GC-faq.html)
Magari dopo aver letto questo documento escono fuori precisazioni interessanti.
Quando sento parlare di argomenti interessanti come il GC applicato ai linguaggi che uso (ad esempio il Java) approfondisco solo cose che userò nel pratico a breve. In questo caso ho letto e capito le FAQ ma non andrò oltre perché arriverò a sviluppare programmi più seri fra un po' di tempo, e magari le cose saranno cambiate (magari no)...
Se non avessi da lavorare e studiare potrei provare altri 5-6 linguaggi di programmazione che reputo interessanti (.NET e Python in primis) sia a livello personale sia per l'impatto lavorativo che potrebbero avere.
rdefalco
05-02-2006, 18:57
Purtroppo domani ho un esame
Ce l'avevo anche io (Algoritmi e Strutture Dati) ma seguire il forum mi ha impegnato più dello studio e rimanderò al secondo appello (un 23 non mi pare tanto valido da tenerlo :stordita: )
... ora ti lascerei anche l'ultima parola se vuoi replicare ;)
-- cut-- mia replica --cut--
Tutte castronerie a cui non hai saputo contrapporre la minima argomentazione convincente se non fraintendendo le cose che venivano dette --cut --
Le ultime parole famose di un uomo coerente ;)
Ti dico che non voglio fare polemica, non ci guadagna nessuno. Ho solo chiesto, senza offendere o "trolleggiando", di non essere offeso con argomenti inventati, altro che coscienza sporca. Poi si può non essere d'accordo su qualcosa ma è pacifico. A Martedì per questo.
Quando sento parlare di argomenti interessanti come il GC applicato ai linguaggi che uso (ad esempio il Java) approfondisco solo cose che userò nel pratico a breve. In questo caso ho letto e capito le FAQ ma non andrò oltre perché arriverò a sviluppare programmi più seri fra un po' di tempo, e magari le cose saranno cambiate (magari no)...
Beh è una scelta legittima, soprattutto se stai studiando all'università, dove il tempo scarseggia. Personalmente ho approfondito molti aspetti dopo l'università proprio per il tuo stesso motivo. Anche se alcuni argomenti li ho approfonditi subito, dal momento che mi affascinavano di più, e che poi sono diventati il mio lavoro. I GC non erano tra quelli ;) Mi sono limitato a sapere cosa sono, come funzionano e come "usarli", ma ancora non mi sono addentrato nello specifico. Vorrei approfondire a tal proposito l'uso della classe GC di .NET, non ne conosco tutti gli aspetti e le peculiarità.
Ce l'avevo anche io (Algoritmi e Strutture Dati) ma seguire il forum mi ha impegnato più dello studio e rimanderò al secondo appello (un 23 non mi pare tanto valido da tenerlo :stordita: )
IMHO dipende dall'esame ;)
@ekerazha
devi ancora spiegare (secondo la tua definizione) qual'è la differenza tra necessario e determinante visto che prima hai giustamente detto che vogliono dire cose diverse...
poi è stato ampiamente dimostrato che il tuo modo di classificare i linguaggi non sta in piedi, come pure il ragionamento che la colpa del SW buggato è dei programmatori (immagino che essendo stati assunti sanno il fatto loro)! hai mai scritto un programma in C++/C lungo qualche migliaio di righe (non ti chiedo milioni di righe ovviamente)? e se si... pensi che non conteneva dei bugs?
rdefalco
05-02-2006, 19:47
IMHO dipende dall'esame ;)
Sicuramente ma la mia situazione era: 1 solo giorno completo di studio (il giorno prima), al corso avevo capito bene tutti gli argomenti, ma senza studiare ovviamente non li ricordo (sono pur sempre formule), in pratica mi invento mezzo compito "live" e altri due quesiti li avrei studiati se avessi avuto un giorno in più di tempo :D penso che con un po' di impegno in più non posso andare a peggiorare... fra l'altro sono solo due settimane e non rischio di dimenticare qualcosa :D
rdefalco
05-02-2006, 19:54
Le mie opinioni su tutto:
Concordo sul non poter criticare bug su programmi complessi. Ci sono e ci saranno sempre. Se pure inventassero macchine che scrivono programmi completi potrebbero esserci dei bug sulle macchine che introdurrebbero bug nel codice. Ovvio pure che programmatori più esperti potranno schivare più possibili bug.
Ritengo che la classificazione dei linguaggi sia ASSOLUTAMENTE personale e che sia stupido discuterne. Cito Wikipedia che 15 o 20 anni fa l'ASSEMBLY era basso livello e il C/COBOL erano alto livello. Ovvio che se un programmatore con il Java usa la JNI e ci scrive dentro metodi in assembler per la specifica macchina rende anche il Java a livello "basso".
Sicuramente ma la mia situazione era: 1 solo giorno completo di studio (il giorno prima), al corso avevo capito bene tutti gli argomenti, ma senza studiare ovviamente non li ricordo (sono pur sempre formule), in pratica mi invento mezzo compito "live" e altri due quesiti li avrei studiati se avessi avuto un giorno in più di tempo :D penso che con un po' di impegno in più non posso andare a peggiorare... fra l'altro sono solo due settimane e non rischio di dimenticare qualcosa :D
Sì allora puoi fare meglio ;) Domanda: ma pure in campania è arrivata la raffo?
rdefalco
05-02-2006, 20:33
Sì allora puoi fare meglio ;) Domanda: ma pure in campania è arrivata la raffo?
:nonsifa: no, no, Raffo è il mio nome da battaglia, la birra però me l'avevano segnalata (ma tutto ciò che ho è una jpeg col tappo della suddetta)...
@k0nt3
Ormai siamo un po' OT, quindi volevo dirti, Gstreamer nisba :( non va, ma ho scoperto banalmente il perchè. Vuole Alsa 1.0.8 come prerequisito, io ho 1.0.6. Mi pare di aver provato ad aggiornare, però poi non mi vedeva più la scheda audio (!!). Alla fine ti dirò, mi trovo da dio con xine. Lo hai provato?
:nonsifa: no, no, Raffo è il mio nome da battaglia, la birra però me l'avevano segnalata (ma tutto ciò che ho è una jpeg col tappo della suddetta)...
:D In effetti è una birra di Taranto, mi pareva strano si fossero allargati così tanto ;)
rdefalco
05-02-2006, 20:37
:D In effetti è una birra di Taranto, mi pareva strano si fossero allargati così tanto ;)
azz non mi ero mai informato, pensavo fosse straniera! :eek:
ekerazha
05-02-2006, 20:51
Ti dico che non voglio fare polemica, non ci guadagna nessuno. Ho solo chiesto, senza offendere o "trolleggiando", di non essere offeso con argomenti inventati, altro che coscienza sporca. Poi si può non essere d'accordo su qualcosa ma è pacifico. A Martedì per questo.
Eh no... tu avevi proprio detto:
Puoi trolleggiare quanto vuoi da ora in poi, non ti seguo.
Io ho finito, torniamo in topic.
Quindi per essere coerente, in primis con te stesso, non dovevi chiedere proprio nulla ;) Che gli argomenti siano inventati o meno sarà da accertare... poi è chiaro che "si può non essere d'accordo su qualcosa", ma non solo è chiaro, è addirittura ovvio... come già detto qui nessuno detiene verità divina e qualsiasi cosa venga espressa è una, più o meno rispettabile, opinione.
devi ancora spiegare (secondo la tua definizione) qual'è la differenza tra necessario e determinante visto che prima hai giustamente detto che vogliono dire cose diverse...
Guarda, non è una definizione mia... è lingua italiana, pura lingua italiana ;)
poi è stato ampiamente dimostrato che il tuo modo di classificare i linguaggi non sta in piedi, come pure il ragionamento che la colpa del SW buggato è dei programmatori (immagino che essendo stati assunti sanno il fatto loro)! hai mai scritto un programma in C++/C lungo qualche migliaio di righe (non ti chiedo milioni di righe ovviamente)? e se si... pensi che non conteneva dei bugs?
Mi pare evidente come il tuo concetto di "dimostrare" sia assolutamente ridicolo e risibile, non avendo argomentato davvero nulla che sia anche lontanamente riconducibile alla pallida controfigura di una dimostrazione.
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.
@k0nt3
Ormai siamo un po' OT, quindi volevo dirti, Gstreamer nisba :( non va, ma ho scoperto banalmente il perchè. Vuole Alsa 1.0.8 come prerequisito, io ho 1.0.6. Mi pare di aver provato ad aggiornare, però poi non mi vedeva più la scheda audio (!!). Alla fine ti dirò, mi trovo da dio con xine. Lo hai provato?
ecco mi sembrava strano che avevi tutti sti problemi con gstreamer! alsa deve essere delicato da maneggiare.. xine è un pezzo che non lo uso (una volta non era completo con i vari formati), ma gstreamer sembra essere molto pulito, elastico e solido.. mi è sembrata un'ottima conquista sul mio kde3.5! mi ricordo quando l'audio in linux era grezzissimo.. adesso è tutta un'altra storia! potresti anche tenerti xine fino a KDE4 :D tanto prima non c'è modo di evitare artsd!
ps. anchio ho bevuto raffo :D ma quando sono stato in puglia!
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 :p) 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)
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:
Assembly -> linguaggio di basso livello
C/C++, eventualmente con estensioni specifiche per un compilatore -> linguaggio di medio livello
Bash -> linguaggio di alto livello
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).
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. :)
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!).
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").
Non metto in dubbio che poni la massima attenzione mentre programmi. Del resto è (o dovrebbe essere) la prassi per un buon programmatore. Non so i "programmatori" che hai conosciuto finora all'università, però posso dirti una cosa. Almeno sul lavoro, i programmatori sanno il fatto loro, sennò non gli assumono. Figurati, con la concorrenza globale che c'è, l'ultimo pensiero di una software-house è quella di assumere un programmatore poco attento. Almeno quelli che ho conosciuto io ci mettono sempre il massimo quando sviluppano codice, ed ovviamente i programmi non sono strapieni di bug. Il problema arriva quando il programma va "in pasto" al mercato, e quindi a decine di migliaia di utenti: ti assicuro che i bug escono fuori SEMPRE, più o meno gravi. Ho capito che questo lo sai, ma voglio sottolineare due aspetti:
non solo per fare un programma complesso ci vuole la massima attenzione sempre (i programmatori poco attenti neanche gli assumono), ma anche che la maggior parte dei bug escono fuori quando si mettono insieme i tanti pezzi sviluppati da tante persone in un unico prodotto. Magari tu testo al massimo (da solo, e quindi neanche fa testo) il tuo pezzo e non da errori, poi lo metti insieme ad un altro e scopri che l'errore c'è.
Ah, IMHO mai essere sicuri (neanche abbastanza) sulle falle di sicurezza: prima bisogna far testare il software a più persone possibile prima di poter dire "ok per il momento va bene , ma poi qualcosa spunta fuori sempre purtoppo... E' fisiologico.
ekerazha
05-02-2006, 21:23
Concordo più o meno con 71104 tranne sul punto 1. Sarà per una mia visione "strict" della programmazione, ma io ritengo che il programmatore debba sempre agire in maniera corretta e rigorosa. Come ho già detto, considero il GC qualcosa che può tornare utile in caso di "sviste" del programmatore, ma non qualcosa che esuli il programmatore dai suoi ""doveri"" (metto le doppie-virgolette :D ). La memoria non più utilizzata dovrebbe essere sempre deallocata... se poi "per sbaglio" dovessi dimenticarmene, allora il GC potrebbe appunto venire in mio soccorso.
Certo... a questo potrebbero esservi determinate eccezioni (vedi PHP4 che non possiede un distruttore nelle classi, quindi implementare "manualmente" un suo "rimpiazzo" sarebbe una complicazione inutile che complicherebbe solamente il codice... quindi in casi come questi -dovuti a limitazioni intrinseche del linguaggio- direi che si può in un certo senso "fare affidamento" sul GC).
:)
1) secondo me un linguaggio in cui l'allocazione dinamica della memoria disponga di un sistema di garbage collection (Java e simili insomma :p) 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)
Quindi stai dicendo che un GC evita sempre i memory leaks?
Bash -> linguaggio di alto livello
:eek: :eek: Ma bash è un LINGUAGGIO SCRIPT!! Prima parli di traduttori, poi di interpreti... Questo va ad inficiare tutto il tuo discorso successivo....
se mi obiettate che il bash non va bene come esempio di linguaggio di alto livello
Non obietto, è proprio sbagliato!
(ed è proprio questa una delle caratteristiche migliori di Java: in Java praticamente i buffer overflow e i buffer overrun non esistono!).
Spero tu stia scherzando!! :eek:
ekerazha
05-02-2006, 21:33
Non metto in dubbio che poni la massima attenzione mentre programmi. Del resto è (o dovrebbe essere) la prassi per un buon programmatore. Non so i "programmatori" che hai conosciuto finora all'università, però posso dirti una cosa. Almeno sul lavoro, i programmatori sanno il fatto loro, sennò non gli assumono. Figurati, con la concorrenza globale che c'è, l'ultimo pensiero di una software-house è quella di assumere un programmatore poco attento. Almeno quelli che ho conosciuto io ci mettono sempre il massimo quando sviluppano codice, ed ovviamente i programmi non sono strapieni di bug.
Il problema arriva quando il programma va "in pasto" al mercato, e quindi a decine di migliaia di utenti: ti assicuro che i bug escono fuori SEMPRE, più o meno gravi. Ho capito che questo lo sai, ma voglio sottolineare due aspetti:
non solo per fare un programma complesso ci vuole la massima attenzione sempre (i programmatori poco attenti neanche gli assumono), ma anche che la maggior parte dei bug escono fuori quando si mettono insieme i tanti pezzi sviluppati da tante persone in un unico prodotto.
Non solo all'università :)
Comunque ti dico... conosco anche gente davvero in gamba che lavora in grandi multinazionali e che mi racconta spesso dell'"incapacità" di alcuni loro colleghi... oppure ho conosciuto gente che lavora appunto in queste grande aziende e che per conoscenza diretta posso assicurarti che erano davvero poco competenti. Comunque nel primo caso avrai sicuramente meno da obiettare dato che non è un mio giudizio "da esterno" ma è appunto un giudizio tra colleghi entrambi assunti dalla stessa azienda.
Magari tu testo al massimo (da solo, e quindi neanche fa testo) il tuo pezzo e non da errori, poi lo metti insieme ad un altro e scopri che l'errore c'è.
Ah, IMHO mai essere sicuri (neanche abbastanza) sulle falle di sicurezza: prima bisogna far testare il software a più persone possibile prima di poter dire "ok per il momento va bene , ma poi qualcosa spunta fuori sempre purtoppo... E' fisiologico.
Certo che è fisiologico... nessuno lo sta mettendo in dubbio. La mia posizione è che esistono appunto programmatori più o meno attenti e non è necessariamente vero che chi viene assunto da grandi aziende deve essere per forza "bravo" (come esposto poche righe sopra). Certamente qualche errore può sfuggire anche a me... anche se come già detto sono sempre molto attento e per quanto riguarda PHP/ASP etc. conosco esattamente data una certa esperienza dove possono insidiarsi gli errori (ed è proprio qui che mi concentro particolarmente), dato che mi diletto spesso nella ricerca di falle negli script altrui (troverai anche una mia segnalazione su Secunia e SecurityFocus che ho fatto qualche anno fa). :)
Concordo più o meno con 71104 tranne sul punto 1. Sarà per una mia visione "strict" della programmazione, ma io ritengo che il programmatore debba sempre agire in maniera corretta e rigorosa. Come ho già detto, considero il GC qualcosa che può tornare utile in caso di "sviste" del programmatore, ma non qualcosa che esuli il programmatore dai suoi ""doveri"" (metto le doppie-virgolette :D ). La memoria non più utilizzata dovrebbe essere sempre deallocata... se poi "per sbaglio" dovessi dimenticarmene, allora il GC potrebbe appunto venire in mio soccorso.
Certo... a questo potrebbero esservi determinate eccezioni (vedi PHP4 che non possiede un distruttore nelle classi, quindi implementare "manualmente" un suo "rimpiazzo" sarebbe una complicazione inutile che complicherebbe solamente il codice... quindi in casi come questi -dovuti a limitazioni intrinseche del linguaggio- direi che si può in un certo senso "fare affidamento" sul GC).
:)
...e finalmente ci siamo!! Il tutto era partito da un'affermazione simile a quella fatta da 71104, mentre adesso va bene. Se uno mi dice "il GC evita i memory leaks" e questo non è vero, io lo faccio notare. A questo mi aspetterei una risposta del tipo "ops ho scritto una cazzata" oppure chiederei informazioni in merito... Meglio che correggere il tiro dicendo "Ah no ma io volevo dire che dovrebbe evitare". Tutto questo a prescindere dalla discussione che abbiamo avuto prima.
ekerazha
05-02-2006, 21:35
Quindi stai dicendo che un GC evita sempre i memory leaks?
Ti prego 71104 non rispondergli!! :D :D
Ti prego 71104 non rispondergli!! :D :D
A parte l'ironia, però c'è troppa gente che pensa che grazie ad un GC i memory leaks scompaiono! Questo a mio parere è un concetto molto pericoloso per un programmatore che vuole riuscire bene nel suo lavoro.
ekerazha
05-02-2006, 21:45
...e finalmente ci siamo!! Il tutto era partito da un'affermazione simile a quella fatta da 71104, mentre adesso va bene. Se uno mi dice "il GC evita i memory leaks" e questo non è vero, io lo faccio notare. A questo mi aspetterei una risposta del tipo "ops ho scritto una cazzata" oppure chiederei informazioni in merito... Meglio che correggere il tiro dicendo "Ah no ma io volevo dire che dovrebbe evitare". Tutto questo a prescindere dalla discussione che abbiamo avuto prima.
Guarda... questo era proprio uno degli argomenti sui quali volevo "attaccarti" (si fa per dire) martedì, dato che dal tuo post #32 in questo thread si può dedurre come tu "faccia affidamento" sul GC e non compia i tuoi "doveri di programmatore" (reputandoti in tal caso un cattivo programmatore).
Poi come già detto all'inizio del thread io non ho mai corretto nessun tiro, ho semplicemente precisato alcune cose quando notavo che tu le fraintendevi (nonostante io le reputassi chiare ed evidenti) in maniera sempre coerente al mio pensiero precedente.
ekerazha
05-02-2006, 21:49
(nonostante io le reputassi chiare ed evidenti)
Certo... magari potevo essermi spiegato male io (nel caso non avesse capito *nessuno* è più che probabile), ma le sucecssive "precisazioni" erano sempre e comunque in buona fede.
P.S.
Ora vado a nanna che domani ho l'esamino... ci si sente prossimamente :D ciao! ;)
^TiGeRShArK^
05-02-2006, 22:01
Inoltre parli di "programmi fatti da milioni di righe di codice" come se quelle milioni di righe le avesse scritte tutte una sola persona.
Se facciamo un programma di 100 righe in 100 persone e ognuno scrive una riga... è abbastanza difficile (per dei programmatori degni di tale nome ;) ) che vi siano molti errori. Quindi quei bei "milioni di righe" suddividili tra i vari programmatori che hanno scritto il codice e come già detto ti assicuro che, a parità di numero di righe, linguaggio di programmazione ed algoritmo da eseguire... vi saranno programmatori che lo scriveranno in maniera più e meno efficiente, più e meno curato, più e meno buggato: i programmatori non sono tutti uguali.
ehm.. non funziona assolutamente così nella realtà...
anzi... molto spesso è vero il contrario...
è piu' semplice ke un programma complesso scritto da UN SOLO programmatore presenti meno bug di un programma complesso scritto da MOLTI programmatori.
Questo perchè l'unico programmatore conosce TUTTO il codice in maniera piu' approfondita di quanto ogni componente del team di programmatori conosca tutto il codice poichè ognuno si è concentrato solo sulla scrittura di una ben determinata parte di codice e non del codice nella sua totalità.
Quando si ha a ke fare con progetti complessi i bug saltano fuori, te lo posso assicurare...
soprattuto se x scrivere il tuo codice ti appoggi a software scritto da altri (e poi ti devi mettere a correggere pure il loro codice :muro: ogni riferimento ad avvenimenti capitati all'autore del post è puramente casuale... :fiufiu: )
ekerazha
05-02-2006, 22:04
ehm.. non funziona assolutamente così nella realtà...
anzi... molto spesso è vero il contrario...
è piu' semplice ke un programma complesso scritto da UN SOLO programmatore presenti meno bug di un programma complesso scritto da MOLTI programmatori.
Questo perchè l'unico programmatore conosce TUTTO il codice in maniera piu' approfondita di quanto ogni componente del team di programmatori conosca tutto il codice poichè ognuno si è concentrato solo sulla scrittura di una ben determinata parte di codice e non del codice nella sua totalità.
Quando si ha a ke fare con progetti complessi i bug saltano fuori, te lo posso assicurare...
soprattuto se x scrivere il tuo codice ti appoggi a software scritto da altri (e poi ti devi mettere a correggere pure il loro codice :muro: ogni riferimento ad avvenimenti capitati all'autore del post è puramente casuale... :fiufiu: )
Vero... era solo un esempio banale. Ovviamente "per far funzionare l'esempio" il codice di ognuno deve essere davvero curato e ben strutturato per permettere agli altri di concentrarsi solo sul loro codice.
Ora scappo davvero a nanna, ciao! :)
^TiGeRShArK^
05-02-2006, 22:05
Il C dispone di 32 parole riservate. Il C99 ne ha aggiunte solo 5. Il C++ ha tutte quelle del C piu' quelle sue. Java nell'ultima versione (J2SE5) conta di un totale di 50 parole riservate. Secondo te VB e Delphi ne hanno di piu' o di meno? A proposito, Herbert Schildt, un membro del comitato di standardizzazione di C e C++, definisce di "medio livello" linguaggi come C, C++, Java e Forth. Fai un po tu.
ancora mi sfugge cosa si intende per medio livello... :mbe:
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... :confused:
Guarda... questo era proprio uno degli argomenti sui quali volevo "attaccarti" (si fa per dire) martedì, dato che dal tuo post #32 in questo thread si può dedurre come tu "faccia affidamento" sul GC e non compia i tuoi "doveri di programmatore" (reputandoti in tal caso un cattivo programmatore).
:eek: Mi prendi in giro sì? Per essere chiari riquoto
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
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!
^TiGeRShArK^
05-02-2006, 22:12
se ad esempio consideri l'orientazione ad oggetti dei due linguaggi ottieni che C# è di più alto livello rispetto a java! perchè in C# l'orientazione è portata all'estremo, non ci sono tipi primitivi e ti permette di usare una sintassi tipo:
12.toString(); // non scherzo
la conclusione è che di sicuro non si può dare un giudizio così frettoloso come hai fatto :D
in C# non avevo mai provato..
cmq in ruby e se nn sbaglio anke in python quella è una cosa normalissima ;)
^TiGeRShArK^
05-02-2006, 22:13
Non ho capito: mi dici che nel caso da te descritto il GC libera la risorsa oppure no?
Come dicevo anche al punto 1), se io indico un puntatore come 'strong reference', il GC quando me la dealloca e quando no?
:mbe:
ma perchè in java puoi avere un controllo ESPLICITO dei puntatori????
ke io sappia TUTTO in java viene passato per valore, ed i puntatori vengono passati implicitamente....
oddio.. non so nemmeno se vengono kiamati puntatori... quello ke accade è indicato di seguito:
1) Tipi di dati primitivi (int, char, byte... ecc....) Vengono passati ad una funzione per valore
2) Tipi di dati complessi (gli oggetti) viene passato per valore la copia del riferimento a cui essi puntano (ke è diverso dal passaggio per riferimento)
Per questo motivo mi kiedo come si possibile in java avere un accesso esplicito ai puntatori... :mbe:
^TiGeRShArK^
05-02-2006, 22:15
12.ToString() non si può fare perchè avevo provato tempo fa (le prime volte che giocavo con C#) e non si poteva :D
ah ecco...
mi pareva strano ke ron jeffries non avesse fatto qualke virtuosismo di quel tipo nelle sue avventure di programmazione estrema in C# :D
^TiGeRShArK^
05-02-2006, 22:17
DOPPIO :muro:
^TiGeRShArK^
05-02-2006, 22:18
lui ha scritto toString e non ToString perchè col C# forse ci ha avuto poco a che fare e in java si scrive toString!
comunque il C# è un linguaggio fantastico! peccato che lo ha acquistato MS :rolleyes:
ok...allora cazzio a ron e a chet ke nn mi hanno fatto vedere 'ste kose :O
(almeno fino a dove sono arrivato a leggere) :D
P.S. cmq pure io odio il fatto ke in java i metodi iniziano con la minuscola e in C# con la maiuscola....
imho è + leggibile con la minuscola... ma mi sa ke è questione di gusti :p
P.P.S. scusate se scrivo cose probabilmente già dette nei miei interventi ma io rsp a mano a mano ke leggo.... :fagiano:
ancora mi sfugge cosa si intende per medio livello... :mbe:
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... :confused:
Quoto. Ma alla fine è solo una classificazione. Personalmente faccio notare, quando alcuni dicono che in C puoi fare cose che in altri linguaggi non puoi fare, che l'idea non è corretta.
Cmq, ma tu programmi in linguaggio macchina ?!?!? :O
^TiGeRShArK^
05-02-2006, 22:28
La memoria non più utilizzata dovrebbe essere sempre deallocata... se poi "per sbaglio" dovessi dimenticarmene, allora il GC potrebbe appunto venire in mio soccorso.
ehm....scusa se torno a ropetermi...
ma come fai a deallocare la memoria in java??? :mbe:
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....
:mbe:
ma perchè in java puoi avere un controllo ESPLICITO dei puntatori????
No, per quello che mi risulta.
ke io sappia TUTTO in java viene passato per valore, ed i puntatori vengono passati implicitamente....
oddio.. non so nemmeno se vengono kiamati puntatori... quello ke accade è indicato di seguito:
1) Tipi di dati primitivi (int, char, byte... ecc....) Vengono passati ad una funzione per valore
2) Tipi di dati complessi (gli oggetti) viene passato per valore la copia del riferimento a cui essi puntano (ke è diverso dal passaggio per riferimento)
Per questo motivo mi kiedo come si possibile in java avere un accesso esplicito ai puntatori... :mbe:
Implicitamente perchè (se ho capito cosa intendi per "implicitamente") sono "smart pointer", strutture opache che rappresentano i puntatori ma sono molto di più. Esistono anche in C++ (il template auto_ptr nella libreria <memory>). Essendo smart pointer, almeno in Java puoi "etichettarli" in modo differente, andando ad influenzare il GC. In quel post chiedevo informazioni più precise su come influenzare il GC con questo approccio.
^TiGeRShArK^
05-02-2006, 22:31
Certo che è fisiologico... nessuno lo sta mettendo in dubbio. La mia posizione è che esistono appunto programmatori più o meno attenti e non è necessariamente vero che chi viene assunto da grandi aziende deve essere per forza "bravo" (come esposto poche righe sopra). Certamente qualche errore può sfuggire anche a me... anche se come già detto sono sempre molto attento e per quanto riguarda PHP/ASP etc. conosco esattamente data una certa esperienza dove possono insidiarsi gli errori (ed è proprio qui che mi concentro particolarmente), dato che mi diletto spesso nella ricerca di falle negli script altrui (troverai anche una mia segnalazione su Secunia e SecurityFocus che ho fatto qualche anno fa). :)
l'unico modo x LIMITARE l'occorrenza di bug è scrivere in maniera Test Driven tutto il codice, cercando di strutturare BENE i test...
ma ti posso assicurare ke anke cos' facendo qualke buggettino scappa sempre fuori, anke se sei MOLTO facilitato in quanto, testando tutto il codice sai benissimo ke cosa è andato male e quindi potrai scrivere un test ke evidenzi il bug e solo dopo il codice necessario per corregerlo.
^TiGeRShArK^
05-02-2006, 22:35
A parte l'ironia, però c'è troppa gente che pensa che grazie ad un GC i memory leaks scompaiono! Questo a mio parere è un concetto molto pericoloso per un programmatore che vuole riuscire bene nel suo lavoro.
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...
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....)
^TiGeRShArK^
05-02-2006, 22:38
Quoto. Ma alla fine è solo una classificazione. Personalmente faccio notare, quando alcuni dicono che in C puoi fare cose che in altri linguaggi non puoi fare, che l'idea non è corretta.
Cmq, ma tu programmi in linguaggio macchina ?!?!? :O
solo sui PLC :asd:
no a parte gli skerzi... la programmazione in linguaggio makkina è stata abbandonata da DECENNI ormai... si usava prima dell'assembly se non erro.....
nei PLC però mi divertivo a programmare direttamente in ladder ke è un pò l'equivalente dell'assembly anzike nell'altro linguaggio "un pò" + ad alto livello (SFC mi pare ke si kiama.. o qualcosa del genere :fagiano: )
ehm....scusa se torno a ropetermi...
ma come fai a deallocare la memoria in java??? :mbe:
ogni oggetto, come ho già detto prima, non è altro ke un "puntatore" all'heap.... --cut--
Appunto mi interessa sapere come in Java posso ottimizzare il funzionamento del GC! ;)
Ah, comunque con la JNI puoi sempre chiamare una malloc() mi pare ;) Ok poi il codice diventa platform-dependent però in casi estremi...
^TiGeRShArK^
05-02-2006, 22:40
Implicitamente perchè (se ho capito cosa intendi per "implicitamente") sono "smart pointer", strutture opache che rappresentano i puntatori ma sono molto di più. Esistono anche in C++ (il template auto_ptr nella libreria <memory>). Essendo smart pointer, almeno in Java puoi "etichettarli" in modo differente, andando ad influenzare il GC. In quel post chiedevo informazioni più precise su come influenzare il GC con questo approccio.
ecco perfetto.. mi sfuggiva il termine :D
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... :fagiano:
solo sui PLC :asd:
no a parte gli skerzi... la programmazione in linguaggio makkina è stata abbandonata da DECENNI ormai... si usava prima dell'assembly se non erro.....
nei PLC però mi divertivo a programmare direttamente in ladder ke è un pò l'equivalente dell'assembly anzike nell'altro linguaggio "un pò" + ad alto livello (SFC mi pare ke si kiama.. o qualcosa del genere :fagiano: )
Sempre un linguaggio è ;) (mii l'ho detto alla siciliana :D)
ecco perfetto.. mi sfuggiva il termine :D
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... :fagiano:
Con piacere, domattina però, adesso sto uscendo ;) Ciao!
^TiGeRShArK^
05-02-2006, 22:44
Appunto mi interessa sapere come in Java posso ottimizzare il funzionamento del GC! ;)
Ah, comunque con la JNI puoi sempre chiamare una malloc() mi pare ;) Ok poi il codice diventa platform-dependent però in casi estremi...
vabbè.. con il JNI stai appunto abbandonando java per interfacciarti a dei linguaggi esterni :D
e qdo alloki della memoria con questi linguaggi devi sempre deallocarla ... perchè non ho la minima idea di cosa accade se non la dealloki.. onestamente non mi sono mai posto il problema :D
^TiGeRShArK^
05-02-2006, 22:45
Con piacere, domattina però, adesso sto uscendo ;) Ciao!
ok a domani allora ;)
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.
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" ;)
premesso che purtroppo conosco molto poco C# e .NET:
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)
:eek: :eek: 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!! :eek: 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 :D
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 :D
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... :asd:
Ti prego 71104 non rispondergli!! :D :D ops :Prrr: :D
Ragazzi...ho visto il mio primo flame in Programmazione... Cerchiamo di darci una calmata...
è 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...
ekerazha
06-02-2006, 08:48
:eek: Mi prendi in giro sì? Per essere chiari riquoto No :D
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" ;)
ekerazha
06-02-2006, 08:53
ehm....scusa se torno a ropetermi...
ma come fai a deallocare la memoria in java??? :mbe:
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 :D), anche se forse è un po' una forzatura.
P.S.
Torno a ripassare che alle 16.30 ho l'esame :D
rdefalco
06-02-2006, 09:07
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 :D 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
06-02-2006, 09:08
P.S. e pure in bocca al lupo per l'esame, và :D
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 (http://www-128.ibm.com/developerworks/library/j-leaks/) articolo. Ovvio che i GC riducono i memory leaks, è uno dei motivi per cui sono stati pensati, ma non li eliminano del tutto (magari!).
è 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 (http://www.gnu.org/software/bash/manual/bash.html) 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.
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 ;)
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 :D
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 ;)
Non capisco perché ostinarsi su questa questione, sia da una parte che dall'altra :D 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:
conoscerne le funzionalità e i limiti
Le funzionalità già le conosco (a volte uso il GC di .NET), volevo approfondirne i limiti.
ekerazha
06-02-2006, 10:55
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 :)
ancora mi sfugge cosa si intende per medio livello... :mbe:
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... :confused:
quoto! se uno definisce il "medio livello" dovrebbe scrivere un libro :D
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 :D! comunque sarebbe quantomeno stupido usare il C# in quel modo se c'è una strada alternativa..
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ò!
ecco perfetto.. mi sfuggiva il termine :D
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... :fagiano:
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 (http://java.sun.com/j2se/1.4.2/docs/api/java/lang/ref/package-summary.html)
Il lavoro che sto facendo, e sul quale cercavo maggiori informazioni per sbrigarmi (:D) è 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.
Non capisco perché ostinarsi su questa questione, sia da una parte che dall'altra :D 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 :D! 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)...
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...
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 :D! comunque sarebbe quantomeno stupido usare il C# in quel modo se c'è una strada alternativa..
Beh questo è sicuro :D
ekerazha
06-02-2006, 11:21
il tuo "sarebbe appunto *SEMPRE*" vuol dire "dovrebbe essere sempre"? sai.. non voglio fraintendere di nuovo!
Vuol dire quello che c'è scritto.
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ò!
E allora?
@fidel
non mi sono mai addentrato nel package cui ti riferisci... però per capire meglio il codice.. con "// Aspetto fino a quando il weak reference è in coda e lo rimuovo" intendi dire che le funzioni di questo package sono bloccanti? mi è venuto il dubbio perchè so che il GC anche se lo invochi non sai quando si esegue di preciso e non ho visto cicli while.. non so se ho capito bene comunque!
E allora?
allora *SEMPRE* non è corretto!
rdefalco
06-02-2006, 11:28
la gestione manuale "permette" di raggiungere l'ottimo! dico tra " perchè è ovvio che lo si può raggiungere solo in programma di 10righe :D! 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)...
Ecco anche io sono d'accordo che con una gestione manuale SI POSSA arrivare all'ottimo, ma che la cosa diventi enormemente più complessa qualora ci si trovi a lavorare su un progetto che non sia composto da sole 10 funzioni. Allo stesso modo con una gestione manuale "scellerata" si può distruggere tutto ciò che abbiamo appena detto, quindi è un'arma a doppio taglio.
Ecco anche io sono d'accordo che con una gestione manuale SI POSSA arrivare all'ottimo, ma che la cosa diventi enormemente più complessa qualora ci si trovi a lavorare su un progetto che non sia composto da sole 10 funzioni. Allo stesso modo con una gestione manuale "scellerata" si può distruggere tutto ciò che abbiamo appena detto, quindi è un'arma a doppio taglio.
ok, ma a volte BISOGNA ricorrere alla gestione manuale, perchè quella del GC non è soddisfacente! in quel caso appunto bisogna stare parecchio attenti perchè come hai detto è un'arma a doppio taglio e bisogna fare in modo di non tagliarsi :D!
ekerazha
06-02-2006, 11:34
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.
Forse è meglio che ti fermi...
Forse denota la mia scarsa competenza... ma secondo me, e parlo sul serio, denota le tue *pessime* qualità di programmatore.
Almeno potrei prenderti in giro sui fatti, a differenza tua che hai inventato, e questo post lo dimostra.
La cosa davvero preoccupante è che dici che invento cose che hai scritto tu stesso e che ti ho più volte quotato ed illustrato nei dettagli. Capisco fraintendere le cose dette da altri... ma fraintendere quelle dette da sè stessi è veramente ridicolo.
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.
Io non ti ho mai offeso (tra l'altro tu stesso hai detto che le offese sono gli insulti, come da tuo post #20). Io dico semplicemente quello che penso e cioè che tu sia un programmatore pessimo e di scarsissima competenza... e come già detto non lo dico per offenderti ma è quello che penso in realtà e i motivi che mi hanno condotto a questo pensiero te li ho fatti notare più e più volte :) Ma tu continui a non capire fraintendendo di proposito le mie parole (e denotando anche una scarsa conoscenza dell'italiano) poichè le tue sciocche argomentazioni non potrebbero scalfire minimamente ciò che affermo effettivamente e sei quindi costretto a ricorrere a questi "giochetti" di tenore davvero basso.
:)
@fidel
non mi sono mai addentrato nel package cui ti riferisci... però per capire meglio il codice.. con "// Aspetto fino a quando il weak reference è in coda e lo rimuovo" intendi dire che le funzioni di questo package sono bloccanti? mi è venuto il dubbio perchè so che il GC anche se lo invochi non sai quando si esegue di preciso e non ho visto cicli while.. non so se ho capito bene comunque!
Il GC è asincrono, ecco perchè aspetto. Nel blocco "try", il metodo remove() della classe ReferenceQueue è bloccante.
Quando chiamo il GC esplicitamente, devo quindi aspettare, nella sperazna che si sbrighi per non penalizzare troppo le prestazioni ;) Non mi addentro sull'efficienza in termini prestazionali del GC altrimenti apriamo un altro thread ;)
Il GC è asincrono, ecco perchè aspetto. Nel blocco "try", il metodo remove() della classe ReferenceQueue è bloccante.
Quando chiamo il GC esplicitamente, devo quindi aspettare, nella sperazna che si sbrighi per non penalizzare troppo le prestazioni ;) Non mi addentro sull'efficienza in termini prestazionali del GC altrimenti apriamo un altro thread ;)
grazie! esattamente come pensavo :D
Visto che non ti fermi...
Forse denota la mia scarsa competenza... ma secondo me, e parlo sul serio, denota le tue *pessime* qualità di programmatore.
--cut--
Io dico semplicemente quello che penso e cioè che tu sia un programmatore pessimo e di scarsissima competenza... e come già detto non lo dico per offenderti ma è quello che penso in realtà e i motivi che mi hanno condotto a questo pensiero te li ho fatti notare più e più volte :)
Io questi motivi ancora non li ho visti.
ekerazha
06-02-2006, 11:38
allora *SEMPRE* non è corretto!
Certo... *SEMPRE* con la ribadita eccezione.
Nel caso la pensassi diversamente *sembreresti* proprio nella stessa barca del caro -fidel- (lungi da me gudicarti solo per questo aspetto). E' incredibile come nella mia "giovane vita", fra tutti i programmatori che ho conosciuto (alcuni dei quali lavorano come già detto in grandi multinazionali), i peggiori li possa incontrare insieme e nello stesso forum. E' una coincidenza stranissima.
ekerazha
06-02-2006, 11:39
Visto che non ti fermi...
Io questi motivi ancora non li ho visti.
Te li sto citando man mano... comunque se preferisci posso farti un sunto (appena ho tempo per l'appunto).
@ekerazha
beh visto che tu sei un programmatore migliore di fidel... allora spiegagli te come funziona il package java.lang.ref invece di parlare di cose astratte!
Ragazzi basta o vi sospendo entrambi...
comunque se preferisci posso farti un sunto (appena ho tempo per l'appunto).
Fai fai, è quello che ti ho chiesto dal'inizio. Quando hai tempo, senza fretta. Per il momento rientra in topic, se hai qualcosa da aggiungere.
NB: ti sconsiglio gaffe come quella del post #193
Certo... *SEMPRE* con la ribadita eccezione.
Nel caso la pensassi diversamente *sembreresti* proprio nella stessa barca del caro -fidel- (lungi da me gudicarti solo per questo aspetto). E' incredibile come nella mia "giovane vita", fra tutti i programmatori che ho conosciuto (alcuni dei quali lavorano come già detto in grandi multinazionali), i peggiori li possa incontrare insieme e nello stesso forum. E' una coincidenza stranissima.
allora metti una nota con scritto cosa significano gli *! non è mica una convenzione internazionale!
poi per il fatto che credi che io sia un pessimo programmatore... mah! devo risponderti? uno che non ha mai avuto a che fare con programmi in C/C++ veramente complessi... :doh:
ps. il PHP è un pò diverso.. credimi!
ekerazha
06-02-2006, 11:46
Fai fai, è quello che ti ho chiesto dal'inizio. Quando hai tempo, senza fretta. Per il momento rientra in topic, se hai qualcosa da aggiungere.
NB: ti sconsiglio gaffe come quella del post #193
"Gaffe" se mai ne puoi aver fatte solo tu dato che in quel post ho citato passo passo quello che TU hai detto ;)
Ragazzi basta o vi sospendo entrambi...
Scusa, per quanto mi riguarda non avevo ancora letto ;)
ekerazha
06-02-2006, 11:47
allora metti una nota con scritto cosa significano gli *! non è mica una convenzione internazionale!
poi per il fatto che credi che io sia un pessimo programmatore... mah! devo risponderti? uno che non ha mai avuto a che fare con programmi in C/C++ veramente complessi... :doh:
ps. il PHP è un pò diverso.. credimi!
Non mi sembra di averlo mai detto in maniera esplicita e "definitiva".
scusa cionci... ma questo ha dato a me e a fidel del "pessimo programmatore" senza nessun motivo tecnico a riguardo..
ekerazha
06-02-2006, 11:49
Ragazzi basta o vi sospendo entrambi...
Va bene.
Nel frattempo ho solo replicato brevemente a cose già dette (senza tirare in ballo "nuovi argomenti") per evitare che passassero falsità.
ekerazha
06-02-2006, 11:54
In ogni caso mi scuso con tutti se posso aver urtato la sensibilità di qualcuno (cosa che comunque hanno fatto in molti anche con me), non era mia intenzione. Sto solo esprimendo delle mie opinioni. Per il resto se volete vi posso offrire una "tregua" altrimenti sarà quel che sarà.
:)
In ogni caso mi scuso con tutti se posso aver urtato la sensibilità di qualcuno (cosa che comunque hanno fatto in molti anche con me), non era mia intenzione. Sto solo esprimendo delle mie opinioni. Per il resto se volete vi posso offrire una "tregua" altrimenti sarà quel che sarà.
:)
Per me va bene, con una promessa. Quando sono opinioni ok, basta metterci un bell'IMHO, oppure si capisce dall'argomento trattato. Quando si parla di cose tecniche, si argomenta con i fatti, sennò non si finisce più. Ok?
Sto solo esprimendo delle mie opinioni.
un conto sono le opinioni sugli argomenti, un conto sono le opinioni sulle persone
"per me quel che dici non si regge in piedi" è diverso da "per me non capisci un cazzo", concetto che hai espresso in altri termini (non così diversi) parecchie volte nei confronti dei tuoi interlocutori: se con un po' di calma e oggettività ti andrai a rileggere il topic coglierai dei toni aggressivi nei tuoi post
te lo dico in modo sterile, per evitare polemiche
^TiGeRShArK^
06-02-2006, 13:50
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 (http://www-128.ibm.com/developerworks/library/j-leaks/) articolo. Ovvio che i GC riducono i memory leaks, è uno dei motivi per cui sono stati pensati, ma non li eliminano del tutto (magari!).
:eek:
ma vedi ke quell'articolo è del feb 2001 e parla di java 1.1.. :mbe:
da allora ne è passata d ia cqua sotto i ponti...
siamo a java 5 e, se tutto va bene, dopo giugno dovrebbe uscire mustang...
immagino ke un paio di migliorie le abbiano fatte in questi anni :D
^TiGeRShArK^
06-02-2006, 13:53
la gestione manuale "permette" di raggiungere l'ottimo! dico tra " perchè è ovvio che lo si può raggiungere solo in programma di 10righe :D! 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)...
:mbe:
ma eclipse vedi ke è MOOOLTO piu' leggero di netbeans...
onestamente con la versione 3.1 mi trovo abbastanza bene.. non mi posso lamentare.... quelle precedenti forse erano un pò piu' pesantucce in effetti...
^TiGeRShArK^
06-02-2006, 13:55
Ecco anche io sono d'accordo che con una gestione manuale SI POSSA arrivare all'ottimo, ma che la cosa diventi enormemente più complessa qualora ci si trovi a lavorare su un progetto che non sia composto da sole 10 funzioni. Allo stesso modo con una gestione manuale "scellerata" si può distruggere tutto ciò che abbiamo appena detto, quindi è un'arma a doppio taglio.
secondo me invece si "potrebbe" arrivare all'ottimo teoricamente...
ma questo diventa tanto piu' falso quanto il progetto a cui si lavora è grande..
invece con il GC hai un minimo di costanza in quest'andamento, senza decrescere molto velocemente al crescere del progetto...
tutto questo ovviamente imho...
^TiGeRShArK^
06-02-2006, 13:56
ok, ma a volte BISOGNA ricorrere alla gestione manuale, perchè quella del GC non è soddisfacente! in quel caso appunto bisogna stare parecchio attenti perchè come hai detto è un'arma a doppio taglio e bisogna fare in modo di non tagliarsi :D!
quoto...
e nel 99% dei casi la gestione del GC dovrebbe esser sufficente....
rdefalco
06-02-2006, 13:59
secondo me invece si "potrebbe" arrivare all'ottimo teoricamente...
ma questo diventa tanto piu' falso quanto il progetto a cui si lavora è grande..
invece con il GC hai un minimo di costanza in quest'andamento, senza decrescere molto velocemente al crescere del progetto...
tutto questo ovviamente imho...
:mano: Non so se ero stato chiaro, ma è esattamente quello su cui mi trovo d'accordo io. C'è il GC di default? Perché non usarlo? Oltretutto è un po' come i sofisticati compilatori di adesso, solo nell'1% dei casi è possibile scrivere a mano codice migliore di quello generato da un compilatore ottimizzato.
P.S.: Se avessi più tempo e non fossi oppresso da esami e lavoro aderirei di corsa al progetto Diamonds, la trovo un'ottima idea...
MenageZero
06-02-2006, 14:23
Vorrei dire la mia su gestione manuale della mem vs gc:
second me, in progetti non banali e come prassi più comune(ci possono ovviamente essere eccezzioni dovute a ragioni specifiche, es i gc asincroni non vanno molto d'accordo con vincoli tipo garantire un task eseguito entro un dato tempo), è meglio occuparsi manualmente della allocazione memoria non sempre tranne che per limiti intrinseci del linguaggio, ma quando necessario, ovvero quando usi un linguaggio che non prevede gestione automatica o quando è di default previsto l'intervento del programmatore anche se presente un gc (ovvio :p ) o nei casi particolari in cui è noto che questa fallisce (vedi es liste circolari in java)
Sempre rigurado al caso del java, ciò che rende naturale appoggiarsi al gc non è il "limite" del linguaggio di permettre pochi "giochetti" con i riferimenti("puntatori"), ma il fatto che se usi System.gc() non è comunque garantito che la "garbage collection" verrà effetivamente eseguita a quel punto di esecuzione del programma:
la gestione rimane prioritariamente automatica, la differenza è che con quella chiamata, come racita la documentazione della api,
"the gc method suggests that the Java Virtual Machine expend effort toward recycling unused objects in order to make the memory they currently occupy available for quick reuse. When control returns from the method call, the Java Virtual Machine has made a best effort to reclaim space from all discarded objects. "
ovvero non c'è garanzia, come dicevo.
E anche ci fosse, come mi pare diceva tigershark pagine fa, cercare di gestire manualmente e puntualmente la deallocazione potrebbe facilmente avere un impatto negativo sulle prestazioni complessive oltre a richiedere una "stile" di programmazione meno produttivo per la persona...
Inoltre il gc garantisce, a meno di casi(caso?) particolari e noti l'assenza di mem leaks intesi "in senso stretto" relativamente all'astrazione offerta dal linguaggio, ovvero per le risorse "esterne" serve in genere "chiusura" manuale (es banale di uno stream di I/O e relativo metodo close() o chiamate per il rilascio esplicito di risorse su librerie esterne usate tramite jn,i esempio precedente sempre di tigershark mi pare), ma è semplicemente prassi quotidiana ben nota a priori e che comporta "inteventi manuali" del programmatore con una frequenza enormemente inferiore che una gestione manuale della memoria
:eek:
ma vedi ke quell'articolo è del feb 2001 e parla di java 1.1.. :mbe:
da allora ne è passata d ia cqua sotto i ponti...
siamo a java 5 e, se tutto va bene, dopo giugno dovrebbe uscire mustang...
immagino ke un paio di migliorie le abbiano fatte in questi anni :D
Vediamo se ora sei più contento :D Prova questo:
public class LeakyChecksum {
private byte[] byteArray;
public synchronized int getFileChecksum(String fileName) {
int len = getFileSize(fileName);
if (byteArray == null || byteArray.length < len)
byteArray = new byte[len];
readFileContents(fileName, byteArray);
// Calcola il checksum e ritorna (omesso...)
}
}
Prova pure con Java 1.5 ad usare questa classe, guardando lo stato della memoria con un profiler. Vedrai che, fino a quando non la distruggi, il memory leak c'è eccome, ed il GC non ci fa nulla se non prendi i dovuti accorgimenti. C'è un modo per correggerla ovviamente ;)
quoto...
e nel 99% dei casi la gestione del GC dovrebbe esser sufficente....
Quella percentuale non mi risulta ;) Magari hai dati più attendibili?
:mano: Non so se ero stato chiaro, ma è esattamente quello su cui mi trovo d'accordo io. C'è il GC di default? Perché non usarlo?
Beh perchè a volte conviene, a volte no. Spesso non conviene in termini prestazionali ad esempio. In altri casi (ma questa è una mio parere per come sono abituato a programmare) risulta più facile gestire la memoria manualmente invece che usare il GC per evitare problemi di memoria. In particolare dipende molto da quanto spesso allochi memoria, a prescindere dalla lunghezza o complessità del codice/algoritmi usati.
Nel caso medio (apps non mission critical, senza problemi particolari di prestazioni) il GC risulta ovviamente conveniente dal punto di vista dello sviluppatore.
Vi faccio una domanda: i videogiochi usano i GC?
EDIT: Discorso a parte è Java, lì devi usare per forza il GC, quindi penso sia buona cosa imparare ad ottimizzarlo. Non a caso ho tirato fuori prima i weak, phantom e soft references. Aggiungo anche che il GC di Java, per quanto raffinato, contribuisce a rendere una app Java piuttosto lenta se paragonata ad una analogo programma fatto in un altro linguaggio tipo il C/C++. Se non erro, Java fu introdotto, più che per le prestazioni, per la "semplicità" di programmazione e soprattutto per la portabilità delle applicazioni.
rdefalco
06-02-2006, 14:49
Vediamo se ora sei più contento :D Prova questo:
public class LeakyChecksum {
private byte[] byteArray;
public synchronized int getFileChecksum(String fileName) {
int len = getFileSize(fileName);
if (byteArray == null || byteArray.length < len)
byteArray = new byte[len];
readFileContents(fileName, byteArray);
// Calcola il checksum e ritorna (omesso...)
}
}
Prova pure con Java 1.5 ad usare questa classe, guardando lo stato della memoria con un profiler. Vedrai che, fino a quando non la distruggi, il memory leak c'è eccome, ed il GC non ci fa nulla se non prendi i dovuti accorgimenti. C'è un modo per correggerla ovviamente ;)
Ok ora io sono un novellino di Java ma non capisco una cosa. Qual'è l'istruzione precisa che genera il memory leak? Cioè sono consapevole che alcuni metodi lasceranno qualcosa "aperto" ma sono davvero così tanti? Perché ovviamente si era parlato dei close() su operazioni con file eccetera eccetera...
Ok ora io sono un novellino di Java ma non capisco una cosa. Qual'è l'istruzione precisa che genera il memory leak? Cioè sono consapevole che alcuni metodi lasceranno qualcosa "aperto" ma sono davvero così tanti? Perché ovviamente si era parlato dei close() su operazioni con file eccetera eccetera...
il problema sta nel buffer ' private byte[] byteArray;' dichiarato nella classe invece che nel metodo. Non verrà rilasciato fino a quando non distruggo la classe. Ancora peggio, non solo non può rimpicciolirsi, ma può addirittura crescere ad ogni chiamata del metodo. Immagina (caso molto frequente per un checksum) di dover fare un checksum di più data streams molto ampi... Immagina pure d istanziare più oggetti LeakyChecksum...
MenageZero
06-02-2006, 15:11
public class LeakyChecksum {
private byte[] byteArray;
public synchronized int getFileChecksum(String fileName) {
int len = getFileSize(fileName);
if (byteArray == null || byteArray.length < len)
byteArray = new byte[len];
readFileContents(fileName, byteArray);
// Calcola il checksum e ritorna (omesso...)
}
}
Prova pure con Java 1.5 ad usare questa classe, guardando lo stato della memoria con un profiler. Vedrai che, fino a quando non la distruggi, il memory leak c'è eccome, ed il GC non ci fa nulla se non prendi i dovuti accorgimenti. C'è un modo per correggerla ovviamente ;)
cioè getFileChecksum viene chiamato più volte e le istanze di byteArray allocate dalle precedenti chiamate (e non più "puntate") non vengono deallocate ? (no perché in quel codice byteArray è semplicemente istanziato una volta...per capire eh, non è che volglio criticarti l'esempio senza nanche aver capito con sicurezza dove e come spunta il leak... :) )
cmq sicuro di aver guradato "abbastanza a lungo" con il profiler (non ci sono garanzie a priori su quando il gc interviene...) ?
Ma il GC non interviene (quando gli pare a lui ovviamente) a liberare la memoria se perdo il riferimento al buffer allocato precedentemente ?
Faccio un po' di chiarezza sull'esempio ;)
Il buffer 'byteArray', non essendo dichiarato nel metodo, non viene eliminato dal GC se non quando distruggo l'intera classe. Ancora peggio, ogni volta che il metodo viene chiamato, se il buffer non è largo a sufficienza si provvede ad allargarlo ancora di più. Quindi non solo il buffer non fa che allargarsi sempre di più, ma non può rimpicciolire, e soprattutto rimane lì anche quando ho concluso il metodo che calcola il checksum.
EDIT: se poi istanzio più di una classe LeakyChecksum come detto prima, addio... :)
Sinceramente non mi torna... Tu mi parli di "ingrandire", ma il buffer non si ingrandisce, viene allocato un nuovo array di grandezza maggiore e, quando avviene, si perde il riferimento a quello vecchio... In questo modo il GC può intervenire a liberare la memoria occupata dal buffer precedente...
E' chiaro che la memoria occupata dal buffer corrente verrà liberata solo quando la classe verrà distrutta, ma non mi sembra un problema di memory leak, piuttosto di errata programmazione...se poi il buffer i dati nel buffer servono anche ad altri metodi non mi sembra un errore...
MenageZero
06-02-2006, 15:32
il problema sta nel buffer ' private byte[] byteArray;' dichiarato nella classe invece che nel metodo. Non verrà rilasciato fino a quando non distruggo la classe. Ancora peggio, non solo non può rimpicciolirsi, ma può addirittura crescere ad ogni chiamata del metodo.
l'array associato al riferimento "byteArray" è un nuovo oggetto ogni volta che lo istanzi con "byteArray = new byte[len];" di lungezza "len" non è che si accorcia o allunga a seconda della nuova "len" passata, mentre le precedenti istanze rimangono strutture senza più nessun riferimento e sono passibili di "subire le attenzioni" del gc...
(il "byteArray" corrente, ovvero l'ultimo istanziato, è normale che "muore" insieme alla classe, essendo variabile di istanza)
quindi mi dici che le istanze precedenti di "byteArray", non più referenziate, non verranno mai deallocate dal gc ? :confused: (magari se utilizzi quella classe in un app che spesso allocando l'array lo fa per una grande mole di dati, magari quando diventa effettivamente necessario recuperare memoria il gc() interviene sulle istanze precedenti non più referenziate... può essere ? o hai proprio trovato la dim. che con quella classe e successive chiamate il gc rimarrà latitante "all'infinito" ?)
Dato che concettualmente l'esempio che hai proposto corrisponderebbe, come l'esempio che hai fatto l'altro giorno con le stringhe, alla più elementare situazione di intervento del gc... boh... se è come dici sembra più un bug di implememtazione a livello di jvm...
:confused:
^TiGeRShArK^
06-02-2006, 15:33
Vediamo se ora sei più contento :D Prova questo:
public class LeakyChecksum {
private byte[] byteArray;
public synchronized int getFileChecksum(String fileName) {
int len = getFileSize(fileName);
if (byteArray == null || byteArray.length < len)
byteArray = new byte[len];
readFileContents(fileName, byteArray);
// Calcola il checksum e ritorna (omesso...)
}
}
Prova pure con Java 1.5 ad usare questa classe, guardando lo stato della memoria con un profiler. Vedrai che, fino a quando non la distruggi, il memory leak c'è eccome, ed il GC non ci fa nulla se non prendi i dovuti accorgimenti. C'è un modo per correggerla ovviamente ;)
non ho capito bene ke fai con quella classe...
praticamente ad ogni esecuzione carichi in memoria il file mettendolo in un'array di byte???
se è così immagino ke il problema sia nel fatto ke, come dicevo prima, java per le kiamate a funzione NON effettua un passaggio per riferimento, ma effettua un passaggio PER VALORE del riferimento...
così facendo la funzione chiamata punta al riferimento che gli viene passato in quel momento, ma se tu subito dopo assegni allo stesso oggetto un altro riferimento mi sa che ti resta quello appeso in memoria...
per spiegarmi meglio....
io farei invece in questo modo:
byteArray = readFileContents(fileName, byteArray);
facendo ritodanre alla funzione readFileContents al posto di void un array di byte....
non per niente effettuare passaggi per riferimento è spesso etichettata come tecnica di programmazione errata in quanto diminuisce la leggibilità del codice e induce spesso e volentieri a questo errore.....
Tutto questo ovviamente se il memory leak è lì... ma non mi pare ci siano altri punti dove ci possa essere un memory leak a quanto ne so io.. :mbe:
^TiGeRShArK^
06-02-2006, 15:36
Quella percentuale non mi risulta ;) Magari hai dati più attendibili?
vabbè.. era un esagerazione tanto per dire ke nei casi piu' comuni NON è necessario..
e poi secondo la filosofia YAGNI bisogna ricorrere ad una qualsiasi ottimizzazione SOLO SE veramente necessario..
è inutile sbattersi ad ottimizzare ad esempio una sezione di codice che coporterà miglioramenti di prestazioni dell'1% ma è necessario concentrarsi su sezioni di codice critiche.
Ma questo si potrà sapere solo in fasi avanzate di sviluppo... per questo è inutile concentrarsi su questi aspetti, ma è meglio concentrarsi sull'effettiva funzionalità del codice, e solo dopo, mediante un profiler, è possibile scoprire cosa c'è ke non va... sempre se le prestazioni totali non raggiungano i requisiti minimi....
MenageZero
06-02-2006, 15:36
Sinceramente non mi torna... Tu mi parli di "ingrandire", ma il buffer non si ingrandisce, viene allocato un nuovo array di grandezza maggiore e, quando avviene, si perde il riferimento a quello vecchio... In questo modo il GC può intervenire a liberare la memoria occupata dal buffer precedente...
E' chiaro che la memoria occupata dal buffer corrente verrà liberata solo quando la classe verrà distrutta, ma non mi sembra un problema di memory leak, piuttosto di errata programmazione...se poi il buffer i dati nel buffer servono anche ad altri metodi non mi sembra un errore...
ora sono un po' meno :confused: , almeno siamo in due a cui "non torna" allo stesso modo... :)
^TiGeRShArK^
06-02-2006, 15:37
il problema sta nel buffer ' private byte[] byteArray;' dichiarato nella classe invece che nel metodo. Non verrà rilasciato fino a quando non distruggo la classe. Ancora peggio, non solo non può rimpicciolirsi, ma può addirittura crescere ad ogni chiamata del metodo. Immagina (caso molto frequente per un checksum) di dover fare un checksum di più data streams molto ampi... Immagina pure d istanziare più oggetti LeakyChecksum...
appunto... quindi era come dicevo io per il problema della copia per valore del riferimento......
ad okkio con la mia soluzione non dovrebbero esserci problemi di memory leak poichè il riferimento della variabile di classe viene sempre aggiornato con quello restituito dalla funzione...
Sinceramente non mi torna... Tu mi parli di "ingrandire", ma il buffer non si ingrandisce, viene allocato un nuovo array di grandezza maggiore e, quando avviene, si perde il riferimento a quello vecchio... In questo modo il GC può intervenire a liberare la memoria occupata dal buffer precedente...
E' chiaro che la memoria occupata dal buffer corrente verrà liberata solo quando la classe verrà distrutta, ma non mi sembra un problema di memory leak, piuttosto di errata programmazione...se poi il buffer i dati nel buffer servono anche ad altri metodi non mi sembra un errore...
Nono attenzione! Il buffer 'byteArray' dichiarato nella classe viene ridimensionato dal metodo se ce n'è bisogno. Supponi di dover fare il checksum di un file di 10 Mb: istanzio la classe e chiamo il metodo per il calcolo. Poco dopo devo fare il checksum di un file da 100 Mb. Il buffer 'byteArray' viene ridimensionato a 100 Mb (non viene riallocato, occhio al codice ;) ). Poi devo processare un file di 50 Mb: il buffer rimane di 100 Mb. Quei 100 Mb rimarranno lì fino a quando non distruggo l'intera classe, anche se nel frattempo non mi servono. Ecco il memory leak. Posso risolvere ovviamente spostando la definizione di byteArray nel metodo (così il GC libera la memoria al termine del metodo) ma spesso torna utile utilizzare un buffer definito nella classe.
In questo caso per risolvere il problema si può usare, ad esempio, un soft reference.
EDIT: ripeto, quel buffer non viene deallocato fino a quando non distruggo la classe. Il GC fino a quel momento semplicemente non può intervenire su quel buffer.
^TiGeRShArK^
06-02-2006, 15:44
Nono attenzione! Il buffer 'byteArray' dichiarato nella classe viene ridimensionato dal metodo se ce n'è bisogno. Supponi di dover fare il checksum di un file di 10 Mb: istanzio la classe e chiamo il metodo per il calcolo. Poco dopo devo fare il checksum di un file da 100 Mb. Il buffer 'byteArray' viene ridimensionato a 100 Mb (non viene riallocato, occhio al codice ;) ). Poi devo processare un file di 50 Mb: il buffer rimane di 100 Mb. Quei 100 Mb rimarranno lì fino a quando non distruggo l'intera classe, anche se nel frattempo non mi servono. Ecco il memory leak. Posso risolvere ovviamente spostando la definizione di byteArray nel metodo (così il GC libera la memoria al termine del metodo) ma spesso torna utile utilizzare un buffer definito nella classe.
In questo caso per risolvere il problema si può usare, ad esempio, un soft reference.
no, vedi ke ha ragione cionci...
un array NON può essere ridimensionato..
quello ke fai tu è assegnare un nuovo array ad ogni kiamata della new...
e in abbinamento al passaggio alla funzione ti causa questo "memory leak" che però imho dovrebbe essere eliminato automaticamente dal GC...
MenageZero
06-02-2006, 15:47
... Il buffer 'byteArray' viene ridimensionato a 100 Mb (non viene riallocato, occhio al codice ;) )...
no no, il codice dice che "byteArray" viene ogni volta re-istanziato(allocato):
"byteArray = new byte[len];"
e quindi vedi post precedenti (anche cionci)
penso che abbiamo capito dove tu indichi il leak, il problema è che a noi al momento risulta che le cose funzionino diversamente ;)
Non ne sono affatto convinto:
if (byteArray == null || byteArray.length < len)
byteArray = new byte[len];
Magari non sono molto esperto di Java (e questo è vero), ma mi sembra che questo codice, nel caso in cui la lunghezza del buffer non sia sufficiente, allochi un nuovo buffer della lunghezza necessaria e si perda il riferimento a quello vecchio...
Mi sembra un comportamento classico per l'intervento del GC... Se poi mi dici che il problema è byteArray che viene dichiarato come membro della classe...allora mi sembra più un problema di design...ma non è sicuramente un memory leak, in quanto la memoria che rimane allocata ha pur sempre un riferimento... Un memory leak per definizione è irrecuperabile da codice...quindi è un "pezzo" di memora non più raggiungibile dal programma, ma lasciata allocata... Ed in questo caso non lo è...
^TiGeRShArK^
06-02-2006, 15:48
no no, il codice dice che "byteArray" viene ogni volta re-istanziato(allocato):
"byteArray = new byte[len];"
e quindi vedi post precedenti (anche cionci)
penso che abbiamo capito dove tu indichi il leak, il problema è che a noi al momento risulta che le cose funzionino diversamente ;)
appunto con la funzione ke ho rsicritto prima si dovrebbe evitare questo problema...
byteArray = readFileContents(fileName, byteArray);
no, vedi ke ha ragione cionci...
un array NON può essere ridimensionato..
quello ke fai tu è assegnare un nuovo array ad ogni kiamata della new...
e in abbinamento al passaggio alla funzione ti causa questo "memory leak" che però imho dovrebbe essere eliminato automaticamente dal GC...
Emh, ma che stai dicendo?!?!? :rolleyes:
^TiGeRShArK^
06-02-2006, 15:50
Non ne sono affatto convinto:
if (byteArray == null || byteArray.length < len)
byteArray = new byte[len];
Magari non sono molto esperto di Java (e questo è vero), ma mi sembra che questo codice, nel caso in cui la lunghezza del buffer non sia sufficiente, allochi un nuovo buffer della lunghezza necessaria e si perda il riferimento a quello vecchio...
Mi sembra un comportamento classico per l'intervento del GC... Se poi mi dici che il problema è byteArray che viene dichiarato come membro della classe...allora mi sembra più un problema di design...ma non è sicuramente un memory leak, in quanto la memoria che rimane allocata ha pur sempre un riferimento... Un memory leak per definizione è irrecuperabile da codice...quindi è un "pezzo" di memora non più raggiungibile dal programma, ma lasciata allocata... Ed in questo caso non lo è...
infatti il problema maggiore in questo caso è proprio l'utilizzare la tanto sconsigliata forma di passaggio "per riferimento" (ho già spiegato prima il xkè delle virgolette :Prrr: )
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.