allocazione dinamica matrici

Stato
Discussione chiusa ad ulteriori risposte.

DareDevil_

Bob Aggiustatutto👨‍🔧
Staff Forum
Utente Èlite
22,523
10,615
CPU
Ryzen 7 3800X @4.4Ghz
Dissipatore
Gelid Solution Phantom
Scheda Madre
MSI B550 Tomahawk
HDD
Sabrent Rocket NVME 256GB+A400 120GB+P300 2 TB
RAM
32 GB DDR4 3200 MHz
GPU
Asus RTX 3070 ROG Strix OC
Monitor
AOC 24G2U
PSU
Corsair TX650M
Case
TG5 PRO RGB
Periferiche
Mouse : Logitech G502; Tastiera : Logitech G213; Volante : Logitech G920.
Net
🤡😭
OS
Windows 11
Raga stiamo calmi eh, mi raccomando.:patpat:
 
  • Mi piace
Reazioni: Andreagamer1999

Andretti60

Utente Èlite
6,440
5,091
Vabbè bambini smettetela di fare a gara a chi lo ha più lungo e andate a letto.

Vero che il sistema operativo libera le risorse usate da un programma quando tale programma termina, almeno prova, ma se un programma non termina normalmente mentre sta bloccando un file, quel file rimane bloccato e il sistema operativo pensa sia ancora in uso. E perfino il garbage collector usato da alcuni linguaggi non riesce a liberare tutto, per esempio in .net libera solo le “managed” risorse, se dimenticare di distruggere un device context per esempio ecco che create un bel memory leak. In parole povere, è buona norma liberare sempre le risorse allocate. Mettete per esempio che in futuro modificate il programma e quello che prima era nel main() adesso è in una funzione o un metodo di una classe che viene chiamato più volte. Se non ricordate più come era progettato il codice, c’è una buona probabilità che vi dimenticate di liberare le risorse allocate. Mentre se il codice di de-allocazione è già presente, tutto è a posto.

Ad ogni modo, questa non è una competizione. Non serve a nulla farsi belli se non irritare gli altri utenti. Se si ha qualcosa di costruttivo lo si dice altrimenti si sta zitti. Inutile andare a cercare il pelo nell’uovo, questo è un forum per NON esperti, gente alle prime armi, per cui non ha senso a volte essere precisi al dettaglio.

PS non c’è nulla di sbagliato nel dire “uccidere un processo” in quanto è la traduzione letterale dall’inglese. Ma anche se non fosse formalmente corretto, ripeto, questo è un forum per dilettanti, non un esame universitario, quella espressione si capisce benissimo e non ha senso alcuno criticarla.
 

nullptr

Nuovo Utente
34
9
Vabbè bambini smettetela di fare a gara a chi lo ha più lungo e andate a letto.
Qualsiasi cosa tu stia provando a dire, che sia di acquietarsi o qualcosa di simile è giusto, ma dovresti iniziare a dirlo in modo referente. Se sono bambino inizia tu stesso a dimostrare quanto tu sia adulto e cresciuto in confronto a me, non serve porre altra legna sul fuoco di questo andare... magari medita per 1 minuto prima di dire certe cose, davvero, non è inevitabile offendere di proposito.

Vero che il sistema operativo libera le risorse usate da un programma quando tale programma termina, almeno prova, ma se un programma non termina normalmente mentre sta bloccando un file, quel file rimane bloccato e il sistema operativo pensa sia ancora in uso
Mi stai dicendo che il sistema operativo desiste dal gestire la memoria "quando il file si blocca"? Di cosa abbiamo parlato fino a prima? Affermazione temeraria e da citation needed. Documentatevi e linkate qualcosa quando affermate roba del genere.

Se si ha qualcosa di costruttivo lo si dice altrimenti si sta zitti
Potresti dirmi quale dei commenti miei non è costruttivo? Se la vogliamo dire più lunga di quanto fosse davvero, al massimo vedrei solo di aver provato a disciplinare delle prese per il culo nei miei confronti, molto passivamente. Del resto cercavo di argomentare e correggere cosa non andava.

PS non c’è nulla di sbagliato nel dire “uccidere un processo” in quanto è la traduzione letterale dall’inglese. Ma anche se non fosse formalmente corretto, ripeto, questo è un forum per dilettanti, non un esame universitario, quella espressione si capisce benissimo e non ha senso alcuno criticarla.
E perfino il garbage collector usato da alcuni linguaggi non riesce a liberare tutto, per esempio in .net libera solo le “managed” risorse, se dimenticare di distruggere un device context per esempio ecco che create un bel memory leak
Perlomeno quando trovate roba su Internet, interpretatela e traducetela in modo pertinente (e magari cercate di capire se contorna bene con l'argomento) tu, @BAT00cent e tutti gli altri... io non credo che in italiano si metta l'aggettivo (che tra l'altro manco in italiano hai scritto) prima del nome. Se poi traducessimo tutte le lingue del mondo con traduzioni letterali, chi si capirebbe mai... non vedo nulla di male nell'utilizzare il linguaggio più affine, mica cerchi di farti capire dagli animali della foresta tropicale. "è un forum per dilettanti" "questo è un forum per non esperti" non c'entra nulla, nessuno ha mai posto specifiche condizioni per non rispondere ad un certo livello ad uno o più apprendisti.
Per di più il garbage collector in .NET non c'entra nulla con il sistema operativo che gestisce la memoria, quindi mi sottraggo pure dal rifinire certo pressapochismo (anche contestualmente ciò che dici nonchè il tuo esempio è traviato e incorretto):
Mettete per esempio che in futuro modificate il programma e quello che prima era nel main() adesso è in una funzione o un metodo di una classe che viene chiamato più volte.
In .NET è impossibile avere memory leak almeno per roba safe.

Volevo semplicemente correggere delle definizioni, credo che sia solo da buone maniere progredire le risorse di questo forum e farlo tornare più utile per chi legge e vuole imparare.
 

pabloski

Utente Èlite
2,868
916
Vero che il sistema operativo libera le risorse usate da un programma quando tale programma termina, almeno prova, ma se un programma non termina normalmente mentre sta bloccando un file, quel file rimane bloccato e il sistema operativo pensa sia ancora in uso.

Ma stanno dimenticando l'elefante nella stanza, ovvero che stiamo parlando del C. Non è detto che il tal programma scritto in C girerà su un sistema operativo. E se fosse un programma bare-metal che gira su un sistema embedded? Chi dovrebbe liberare le risorse in quel caso?

Senza contare che stiamo sempre parlando di comportamenti non definiti nello standard. Ci sono runtime che tracciano l'allocazione di certe risorse e le liberano anche se il programma crasha. Ma non è un comportamento standardizzato e dunque non ci si può contare.
 

Mursey

Super Moderatore
Staff Forum
Utente Èlite
8,243
5,674
Volevo semplicemente correggere delle definizioni, credo che sia solo da buone maniere progredire le risorse di questo forum e farlo tornare più utile per chi legge e vuole imparare.
L'intento è lodevole ma il modo sta dando problemi in ogni intervento.
Quindi restiamo umili anche se sappiamo più della media e troviamo modi gentili ed educati per dimostrarlo. :)
 
  • Mi piace
Reazioni: Andretti60

AntonioRagagnin

Nuovo Utente
13
11
Nullptr, mettiamola cosi, proprio dal lato pratico:

1) un utente potrebbe voler compilare il codice come libreria e chiamarne la funzione main() da un altro programma: poco usato? Sì, ma è legittimo volerlo fare? assolutamente sì, e la cosa produrrebbe un mancato rilascio della memoria allocata durante l'esecuzione del programma chiamante.
2) un utente potrebbe star scrivendo un codice in cui è molto importante la sicurezza e quindi compilare il codice con l'opzione -fsanitize=leak di gcc9: un mancato free fa terminare l'esecuzione con uno stato 1, quindi a tutti gli effetti il codice crasha.

EDIT: Tra l'altro il fatto che il sanitiser di gcc segnali un mancato free alla fine del main, ti fa capire che la comunità informatica rietiene importante fare free prima di chiudere il main.
 
Ultima modifica:
  • Mi piace
Reazioni: Andretti60

nullptr

Nuovo Utente
34
9
1) un utente potrebbe voler compilare il codice come libreria e chiamarne la funzione main() da un altro programma: poco usato? Sì, ma è legittimo volerlo fare? assolutamente sì, e la cosa produrrebbe un mancato rilascio della memoria allocata durante l'esecuzione del programma chiamante.
2) un utente potrebbe star scrivendo un codice in cui è molto importante la sicurezza e quindi compilare il codice con l'opzione -fsanitizer di gcc9: un mancato free fa terminare l'esecuzione con uno stato -1, quindi a tutti gli effetti il codice crasha.
L'utente stava parlando di .NET ma come già spiegato, non c'entra nemmeno questo.

Quindi restiamo umili anche se sappiamo più della media e troviamo modi gentili ed educati per dimostrarlo. :)
Assolutamente concordo con te, altrimenti avrei risposto a certe provocazioni... Io non ho niente di personale verso nessuno, volevo solo ragionare un po' sull'argomento mezzo messo in ballo da @Frank2000 sul free() e ho cercato di rendere limpide alcune idee perchè alcune definizioni che gli hanno dato erano stravolgibili. E come ho già detto precedentemente, sbagliare è umano e mica l'ho fatto per umiliare qualcuno.
 

AntonioRagagnin

Nuovo Utente
13
11
L'utente stava parlando di .NET ma come già spiegato, non c'entra nemmeno questo.

Non hai capito: Mi sto riferendo al C, che e' il linguaggio usato dall' autore dle thread. Non sviare la conversazione.

E rimango della mia posizione:

1) in C, se la funzione viene compilata come libreria (opzione -o -fPIC) e` possibile chiamare il main da un altro programma: questo implica un leak.
2) sempre in C, se compili con -fsanitize=leak su gcc9 e non fai free prima di chiudere il main allora il codice crasha.

Quindi e` buona pratica fare free prima di chiudere il main.
 
  • Mi piace
Reazioni: Andretti60

nullptr

Nuovo Utente
34
9
EDIT: Tra l'altro il fatto che il sanitiser di gcc segnali un mancato free alla fine del main, ti fa capire che la comunità informatica rietiene importante fare free prima di chiudere il main.
Non hai capito: io non mi sto riferendo a .NET. Mi sto riferendo al C.

E rimango della mia posizione:

1) in C, se la funzione viene compilata come libreria (opzione -o) e` possibile chiamare il main da un altro programma: questo implica un leak.
2) sempre in C, se compili con -fsanitize=leak su gcc9 e non fai free prima di chiudere il main allora il codice crasha.
Infatti sono stato abbastanza specifico:
Ciò che invece vorresti dire è che nel caso un qualsivoglia memory debugger lo rilevi come memory leak, potrebbe aggrovigliare leggermente le tue idee se il tuo programma ne presenta ulteriori.
quello che ti segnala non è un vero memory leak. È buono metterlo solo per eludere confusioni con quello che iniquamente si dichiara che sia, ma il mio intervento l'ho dato più che altro perchè si era detto che "se non fai free() indubbiamente c'è un memory leak" o roba simile.
Inoltre ho ben chiarificato cosa io voglia dire con "al termine del programma".
 

pabloski

Utente Èlite
2,868
916
Quindi e` buona pratica fare free prima di chiudere il main.

E' buona norma esplicitare tutto ciò che va sotto l'etichetta "undefined behavior". Altrimenti i risultati possono essere catastrofici.

C è un linguaggio che lascia la gestione delle risorse al programmatore. Ergo è lapalissiano che il programmatore debba gestirle. Contare sull'intervento di entità esterne è un no no.

Per cui hai ragione da un punto di vista generale. I casi particolari ovviamente ci sono e si può accettare il rischio, ma in tal caso si va contro le best practises. Onestamente, se io fossi il CTO di un'azienda, licenzierei un programmatore che ostina a non voler usare il free per liberare la memoria allocata.
 

nullptr

Nuovo Utente
34
9
E' buona norma esplicitare tutto ciò che va sotto l'etichetta "undefined behavior". Altrimenti i risultati possono essere catastrofici.

C è un linguaggio che lascia la gestione delle risorse al programmatore. Ergo è lapalissiano che il programmatore debba gestirle. Contare sull'intervento di entità esterne è un no no.

Per cui hai ragione da un punto di vista generale. I casi particolari ovviamente ci sono e si può accettare il rischio, ma in tal caso si va contro le best practises. Onestamente, se io fossi il CTO di un'azienda, licenzierei un programmatore che ostina a non voler usare il free per liberare la memoria allocata.
In questo link trovi una delle domande più richieste, che ti spiega perchè di default o per lo più i casi per cui potrebbe non essere utile liberare la memoria prima che il programma termini. Insomma, non è ineluttabile farlo.
C - Frequently Asked Questions ha detto:
Q: Must I free allocated memory before the program exits?


A: You shouldn't have to. A real operating system definitively reclaims all memory and other resources when a program exits; the system cannot afford to have memory integrity depend on the whims of random programs. (Strictly speaking, it is not even free's job to return memory to the operating system; see question 7.25.) Nevertheless, some personal computers are said not to reliably recover memory unless it was freed before exiting, and all that can be inferred from the ANSI/ISO C Standard is that this is a ``quality of implementation issue.''

On the other hand, the C library free function rarely returns memory back to the operating system (see question 7.25), so calling free probably isn't the way to guarantee that an exiting program's memory is recovered by the system, anyway.

In any case, it can be considered good practice to explicitly free all memory--for example, in case the program is ever rewritten to perform its main task more than once (perhaps under a Graphical User Interface). [footnote] On the other hand, there are programs (such as interpreters) that don't know what memory they're done with (i.e. what memory could be freed) until it's time to exit, and since all memory should be released at exit, it would be a needless, potentially expensive, and error-prone exercise for the program to explicitly free all of it.

Ma ribadisco un'ultima volta, la mia prima risposta in questa discussione mette già tutto in chiaro: fabio63 dice "bisogna sempre liberare la memoria quando non serve più altrimenti hai un memory leak", e io ho precisato semplicemente con "giusto liberare la memoria quando non serve, ma non necessariamente si ha un memory leak se non si libera la memoria manualmente, come nel caso ... (esempio caso di programma che non libera la memoria prima di uscire)", BAT00cent risponde in modo fuorviante: "bisogna liberarla manualmente sempre, mentre è sbagliato lasciarlo fare all'OS" (anche se non proprio, dipende) senza comprendere sin dal punto di partenza che il fine era spiegare solo che il sistema operativo lì si potrebbe frapporre per riscattarla automaticamente senza esplicitare un free(), quindi all'incirca metodicamente nessun memory leak...
Nessuno stava parlando del metodo migliore malgrado potesse essere molto assoggettato dall'utente, quindi non è colpa mia se la discussione è stata dilapidata nell'immondizia.

Un po' di stima comunque le tue risposte rispetto ad alcune altre in quanto molto più confidenziali e dispensate da qualunque offesa. Con questo concludo qui.
 

BAT

Moderatore
Staff Forum
Utente Èlite
22,944
11,580
CPU
1-Neurone
Dissipatore
Ventaglio
RAM
Scarsa
Net
Segnali di fumo
OS
Windows 10000 BUG
BAT00cent risponde in modo fuorviante: "bisogna liberarla manualmente sempre, mentre è sbagliato lasciarlo fare all'OS"
Bugiardo: o non sai leggere o non capisci l'Italiano. La mia neutra affermazione è stata
Vero, tuttavia trascurare tale pratica perché "lo fa il sistema operativo" non è corretto:
innanzitutto non si ha mai la certezza che il sistema rilasci correttamente le risorse, in secondo luogo è parte integrante delle pratiche di buona programmazione quando lavori in C/C++ che ti lasciano "libero accesso" alla gestione della memoria.
Il messaggio è: intanto cominciamo a scrivere NOI codice che sia "ben fatto" (per quanto possibile ed alla portata delle nostre conoscenza).
una cosa completamente differente da quanto vai affermando, rigirando la frittata a tuo uso e consumo. Tra l'altro il link chiarificatore che tu stesso hai postato si conclude con
In any case, it can be considered good practice to explicitly free all memory
(traduzione: in ogni caso, si considera buona pratica liberare esplicitamente tutta la memoria)
che era esattamente il senso del mio innocuo intervento, e che tutti hanno capito tranne te.
Anche se è vero che poi cita il caso particolare degli interpreti.

Tu offendi sistematicamente gli altri utenti perché, contrariamente allo spirito di un forum di supporto e aiuto, il tono dei tuoi interventi è mirato esclusivamente a sottolinearne errori o imprecisioni, all'unico scopo di farli apparire incompetenti. Quindi, non ti lamentare se ricevi risposte piccate alle tue irritanti citazioni su qualunque cosa si scriva in un thread dove sei intervenuto.
Il rispetto degli altri si guadagna col comportamento.
Tu invece sei un provocatore nascosto dietro una patina di presunta perizia tecnica.
Vivi una vita ben triste se l'unico modo che hai di divertirti è questo.
 
Ultima modifica:
  • Mi piace
Reazioni: AntonioRagagnin

pabloski

Utente Èlite
2,868
916
In questo link trovi una delle domande più richieste, che ti spiega perchè di default o per lo più i casi per cui potrebbe non essere utile liberare la memoria prima che il programma termini. Insomma, non è ineluttabile farlo.

C'è un problema: "A real operating system definitively reclaims all memory and other resources when a program exits". E se sto programmando Arduino? E se il sistema operativo ha un bug? E se il sistema operativo è un library OS tipo FreeRTOS?

Troppi se portano a bug tremendi. Contare su qualcun altro affinchè tolga le castagne dal fuoco, non è il modo giusto di programmare.

fabio63 dice "bisogna sempre liberare la memoria quando non serve più altrimenti hai un memory leak", e io ho precisato semplicemente con "giusto liberare la memoria quando non serve, ma non necessariamente si ha un memory leak

Questo è giusto. Nella pratica, nella stragrande maggioranza dei casi tipici e comuni, è così. Il problema è che le cattive abitudini, una volta prese, sono dure a morire.
 

nullptr

Nuovo Utente
34
9
Caro @BAT00cent,
Bugiardo: o non sai leggere o non capisci l'Italiano.
Sono le parole che hai scritto, alla lettera.
Vero, tuttavia trascurare tale pratica perché "lo fa il sistema operativo" non è corretto:
sei privo di puntualità, hai utilizzato un linguaggio poco tecnico e sei stato poco preciso, almeno dimostra una infima coesione tra le tue argomentazioni a dispetto del fatto che tu stia solo scialacquando una discussione con roba fuori-tema.

In any case, it can be considered good practice to explicitly free all memory
(traduzione: in ogni caso, si considera buona pratica liberare esplicitamente tutta la memoria)
che era esattamente il senso del mio innocuo intervento, e che tutti hanno capito tranne te.
Vuoi concentrarti sul metodo migliore per liberare la memoria prima che il programma termini in questa discussione? Sollazzati creando una nuova discussione, ma prima inizia a dimostrare abbastanza maturità da sottrarla da ogni insulto nel personale altrimenti nessuno si abbandonerà alla tua poca serietà.

Poi qui viene spiegato universalmente o genericamente cosa bisogna fare e cosa non. Sono stato più che sufficientemente limpido al riguardo:
ti spiega perchè di default o per lo più i casi per cui potrebbe non essere utile liberare la memoria prima che il programma termini
malgrado potesse essere molto assoggettato dall'utente
(e rispondendo pure a @pabloski) dipende dalle necessità e delle responsabilità a cui l'utente si appresta... "non è il modo giusto per programmare" nello schema del disimpegnamento della memoria prima che il programma termini, sono parole troppo enfatiche e ampollose. Deallocare manualmente tanti brani di memoria prima che il programma termini potrebbe richiedere tanto lavoro, mentre il sistema operativo aspirerebbe a liberarla molto più velocemente di quanto tu possa farlo da uno spazio utente.
Ho utilizzato una terminologia inequivocabile e l'ho mandata al confino con l'accuratezza, oppostamente a te che dicevi che fosse scorretto lasciarla liberare dal sistema operativo (oh giusto, in realtà hai detto "trascurare tale pratica perchè lo fa il sistema operativo non è corretto", asserzioni davvero tanto diverse per te). Non capisco perchè tu stia facendo tanto l'intrallazzatore, non serve mistificare ciò che dapprima hai detto, manifesti solo di voler negare l'evidenza.

Tu offendi sistematicamente gli altri utenti perché
Vivi una vita ben triste se l'unico modo che hai di divertirti è questo.
non sia opportuno fare ramanzine e imputarsi di ciò che unicamente tu hai fatto nella discussione. Quando sei una persona poco seria, vuoi sgominare in una argomentazione e non riesci, andare sul personale è sempre la via corretta.
 

DareDevil_

Bob Aggiustatutto👨‍🔧
Staff Forum
Utente Èlite
22,523
10,615
CPU
Ryzen 7 3800X @4.4Ghz
Dissipatore
Gelid Solution Phantom
Scheda Madre
MSI B550 Tomahawk
HDD
Sabrent Rocket NVME 256GB+A400 120GB+P300 2 TB
RAM
32 GB DDR4 3200 MHz
GPU
Asus RTX 3070 ROG Strix OC
Monitor
AOC 24G2U
PSU
Corsair TX650M
Case
TG5 PRO RGB
Periferiche
Mouse : Logitech G502; Tastiera : Logitech G213; Volante : Logitech G920.
Net
🤡😭
OS
Windows 11
Ok, vi avevo avvisato.
Chiudo la discussione almeno la smettete con sti continui flame.
 
  • Mi piace
Reazioni: BAT e Andretti60
Stato
Discussione chiusa ad ulteriori risposte.

Ci sono discussioni simili a riguardo, dai un'occhiata!

Entra

oppure Accedi utilizzando
Discord Ufficiale Entra ora!

Discussioni Simili