Torna indietro   Hardware Upgrade Forum > Software > Programmazione

Apple MacBook Air M3: chi deve davvero comprarlo? La recensione
Apple MacBook Air M3: chi deve davvero comprarlo? La recensione
A distanza di circa 8 mesi arriva l’importante aggiornamento dei MacBook Air: nessun cambiamento estetico, ma una revisione hardware interna con l’upgrade al processore M3. Le prestazioni migliorano rispetto alle generazioni precedenti, e questo fa sorgere una domanda spontanea: a chi è rivolto oggi questo laptop? Cerchiamo di capirlo nella nostra recensione 
ASUS ROG Swift OLED PG49WCD: quando QD-OLED e ultrawide si fondono
ASUS ROG Swift OLED PG49WCD: quando QD-OLED e ultrawide si fondono
Da ASUS un monitor particolare ma molto completo: principalmente indirizzato al videogiocatore, può essere sfruttato con efficacia anche per attività creative e di produzione multimediale
Dreame L10s Pro Ultra Heat: la pulizia di casa tutta sostanza
Dreame L10s Pro Ultra Heat: la pulizia di casa tutta sostanza
Il nuovo robot aspirapolvere domestico di Dreame abbina funzionalità complete a un moccio flottante che raggiunge al meglio gli angoli delle pareti. Un prodotto tutto in uno semplice da utilizzare ma molto efficace, in grado di rispondere al meglio alle necessità di pulizia della casa
Tutti gli articoli Tutte le news

Vai al Forum
Rispondi
 
Strumenti
Old 10-05-2021, 11:19   #1
tuvok01
Junior Member
 
Iscritto dal: May 2021
Messaggi: 1
C++ gestione memoria

Ciao a tutti.

Ho un dubbio che probabilmente è banale.
Allora io ho un processo che, in base ad un evento chiama un metodo di una classe. Il metodo è simile a questo, crea un messagio e lo invia sulla rete:

Codice:
void Manager::doOp() {
    for(int i=0; i <=10; i++) {
        Message* msg = new Message();
        send(msg);
    }
}
Questa parte di codice ogni volta che è chiamata porta ad un memory leak giusto? Per risolverlo dovrebbe bastare mettere una "delete msg" subito dopo la send credo.
Ma nel momento in cui il processo che possedeva l'istanza della classe manager viene terminato, e ne viene poi creato uno nuovo senza terminare il programma. La parte di memoria occupata dai messaggi creati viene liberata?

Grazie.
tuvok01 è offline   Rispondi citando il messaggio o parte di esso
Old 10-05-2021, 12:50   #2
-MiStO-
Senior Member
 
Iscritto dal: May 2005
Città: Trieste
Messaggi: 2275
ciao

senza sapere cosa fa esattamente il metodo send si può solo ipotizzare(magari questo metodo è delegato al cleanup dopo l'effettiva spedizione...), comunque sì, in linea di massima c'è un memleak e va risolto o con una delete oppure, scelta migliore usando smart pointer che semplificano enormemente la vita in operazioni di questo tipo

solitamente la memoria heap è "per-process", quindi viene rilasciata alla chiusura del processo
__________________
neo mini v2 / asus strix z490i / 10600k@? / uh12s / rx6700xt / 32gb ddr4@3200 / sandisk 250 + asenno 1tb / lenovo g34w
trattative concluse : tante...

-MiStO- è offline   Rispondi citando il messaggio o parte di esso
Old 18-05-2021, 08:47   #3
jepessen
Senior Member
 
L'Avatar di jepessen
 
Iscritto dal: Jul 2007
Città: Sicilia
Messaggi: 5428
Il principio di buona programmazione prevede che la classe che crea un puntatore ne diventa l'owner, quindi dovrebbe essere responsabile anche della sua cancellazione. Quindi una classe/funzione che accetta un puntatore come argomento non dovrebbe cancellarla. Questo principio evita problemi come utilizzo di dangling pointer o memory leak, perche' ogni utilizzatore del puntatore ha la sua responsabilita'.

Se per motivi di design si DEVE spostare l'ownership di un puntatore (ad esempio perche' viene creato da una factory), sarebbe opportuno dirlo esplicitamente, ad esempio con l'utilizzo di un unique_ptr che non puo' essere copiato ma soltanto spostato, quindi passarlo ad una funzione o ad una classe significa esplicitamente che lei ne acquisisce la proprieta' e ne diventa responsabile.

Quindi nel tuo caso "send()" non dovrebbe cancellare il puntatore, ma dovrebbe farlo il tuo manager nel ciclo. Se dovesse per qualche motivo cancellarlo il "send()" allora invece di "Message*" dovresti fare un "std::unique_ptr<Message>" e passarlo per move al send. In questo modo si invalida il puntatore del ciclo for dato che viene "mosso" e non "copiato" all'interno del send, la cui signature diventa "void send(std::unique_ptr<Message>&& message", e quando finira' il suo scope verra' automaticamente cancellato.
__________________
Non abbiamo ereditato il mondo dai nostri padri
L'abbiamo preso in prestito dai nostri figli

Ultima modifica di jepessen : 18-05-2021 alle 08:49.
jepessen è offline   Rispondi citando il messaggio o parte di esso
Old 27-06-2021, 12:42   #4
DanieleC88
Senior Member
 
L'Avatar di DanieleC88
 
Iscritto dal: Jun 2002
Città: Dublin
Messaggi: 5964
Scusa l'ignoranza, ma se send() non prende possesso di quella memoria, a che serve allocarla sullo heap?

Non ti basta fare questo?

Codice:
void Manager::doOp() {
    for(int i=0; i <=10; i++) {
        Message msg;
        send(&msg);
    }
}
__________________

C'ho certi cazzi Mafa' che manco tu che sei pratica li hai visti mai!
DanieleC88 è offline   Rispondi citando il messaggio o parte di esso
Old 28-06-2021, 21:52   #5
Lampo89
Member
 
L'Avatar di Lampo89
 
Iscritto dal: Dec 2006
Messaggi: 33
Quote:
Originariamente inviato da DanieleC88 Guarda i messaggi
Scusa l'ignoranza, ma se send() non prende possesso di quella memoria, a che serve allocarla sullo heap?

Non ti basta fare questo?

Codice:
void Manager::doOp() {
    for(int i=0; i <=10; i++) {
        Message msg;
        send(&msg);
    }
}
concordo anche io con questo suggerimento, anche se con le poche informazioni a disposizioni non è detto che sia il modo più safe per risolvere il problema ( per gli stessi dubbi che hai anche tu).
Ad esempio, se la send() avvenisse in maniera asincrona il rischio è che al momento dell'invio venga letta memoria non valida (msg verrebbe cancellata alla chiusura del blocco in cui è dichiarata). In un caso del genere, deve avvenire un trasferimento di ownership della memoria.

Come detto, meglio usare unique_ptr e trasferire l'ownership alla funzione send() ma, secondo me, con le informazioni a disposizione è difficile dare una risposta più precisa ...

Ultima modifica di Lampo89 : 28-06-2021 alle 22:33.
Lampo89 è offline   Rispondi citando il messaggio o parte di esso
Old 28-06-2021, 22:17   #6
Lampo89
Member
 
L'Avatar di Lampo89
 
Iscritto dal: Dec 2006
Messaggi: 33
Quote:
Originariamente inviato da jepessen Guarda i messaggi
Quindi nel tuo caso "send()" non dovrebbe cancellare il puntatore, ma dovrebbe farlo il tuo manager nel ciclo. Se dovesse per qualche motivo cancellarlo il "send()" allora invece di "Message*" dovresti fare un "std::unique_ptr<Message>" e passarlo per move al send. In questo modo si invalida il puntatore del ciclo for dato che viene "mosso" e non "copiato" all'interno del send, la cui signature diventa "void send(std::unique_ptr<Message>&& message", e quando finira' il suo scope verra' automaticamente cancellato.
a meno dell'osservazione sopra, mi trovi d'accordo con il tuo suggerimento nel senso che è la pratica più safe per è possibile allo stato attuale della conoscenza.

Solamente, modificherei invece la signature del metodo send() in:
send(std::unique_ptr<Message> message)

in modo da eseguire esplicitamente il passaggio di ownership del puntatore alla funzione send(). Nel modo in cui proponi, passeresti comunque una referenza (una ref ad un temporaneo) ma, in assenza di ulteriori move del puntatore nel corpo della funzione, il trasferimento di ownership non avverrebbe.

questo esempio dovrebbe chiarificare, nota come dopo prima chiamata (argomento unique_ptr&&) lo smart pointer è ancora valido, mentre dopo la seconda è nullptr in seguito alla costruzione dell'argomento via move constructor

https://gist.github.com/Lampo89/8194...ec47777ba3454c

Non c'entra nulla, ma giro un link su best practices riguardo la gestione della memoria (il link punta al caso che facevo notare). ci sono molti altri suggerimenti interessanti che vale davvero la pena leggere, opinione mia
http://isocpp.github.io/CppCoreGuide...ip-of-a-widget

Ultima modifica di Lampo89 : 28-06-2021 alle 23:02.
Lampo89 è offline   Rispondi citando il messaggio o parte di esso
Old 29-06-2021, 10:09   #7
jepessen
Senior Member
 
L'Avatar di jepessen
 
Iscritto dal: Jul 2007
Città: Sicilia
Messaggi: 5428
Quote:
Originariamente inviato da Lampo89 Guarda i messaggi
a meno dell'osservazione sopra, mi trovi d'accordo con il tuo suggerimento nel senso che è la pratica più safe per è possibile allo stato attuale della conoscenza.

Solamente, modificherei invece la signature del metodo send() in:
send(std::unique_ptr<Message> message)

in modo da eseguire esplicitamente il passaggio di ownership del puntatore alla funzione send(). Nel modo in cui proponi, passeresti comunque una referenza (una ref ad un temporaneo) ma, in assenza di ulteriori move del puntatore nel corpo della funzione, il trasferimento di ownership non avverrebbe.

questo esempio dovrebbe chiarificare, nota come dopo prima chiamata (argomento unique_ptr&&) lo smart pointer è ancora valido, mentre dopo la seconda è nullptr in seguito alla costruzione dell'argomento via move constructor

https://gist.github.com/Lampo89/8194...ec47777ba3454c

Non c'entra nulla, ma giro un link su best practices riguardo la gestione della memoria (il link punta al caso che facevo notare). ci sono molti altri suggerimenti interessanti che vale davvero la pena leggere, opinione mia
http://isocpp.github.io/CppCoreGuide...ip-of-a-widget
La realta' e' che l'utilizzo dei puntatori a sproposito e' il tipico sintomo di uno sviluppatore che ha raggiunto il primo picco del grafico di Dunning-Kruger. Quando studi i puntatori e vedi la loro potenza allora sei convinto che debbano essere utilizzati ovunque, quando in realta' si tende a minimizzare il loro utilizzo, e quando vengono utilizzati si dovrebbe quanto piu' possibile limitarne lo scope (ad esempio sfruttando il RAII). Ci sono un sacco di problemi che sembrano risolvibili con i puntatori ma che in realta' non lo richiedono, senza arrivare a rompere i cabbasisi con l'utilizzo di std::variant con std::visit per mimare il polimorfismo... In genere quando fai un'applicazione dovresti avere ben chiaro dove i puntatori vengono creati e vengono distrutti, e capire quindi quando effettivamente servono e quando no. Quando servono poi, a meno di compatibilita' con librerie terze, e' sempre meglio utilizzare gli smart pointer, stanno li' per questo, e ormai risalgono al C++11, quindi non e' giustificabile ad esempio non insegnarli in un corso universitario di C++ al giorno d'oggi. E' sacrosanto insegnare i puntatori raw, come si e' sempre fatto, ma dopo occorre spiegare cosa sono gli smart pointer e come utilizzarli in maniera proficua.

Anche le CppCoreGuidelines sono veramente un'ottima lettura, ma a mio avviso il fatto di avere un unico .md rende la lettura pesante, ed anche il file. Preferisco convertirlo in PDF per poterlo leggere con piu' naturalezza, riaprire il file per ricominciare a leggere da dove avevo interrotto etc... Anche abilitare il check delle regole cpp sugli IDE come visual studio e' molto interessante, e permette di analizzare i "code smell" il prima possibile.
__________________
Non abbiamo ereditato il mondo dai nostri padri
L'abbiamo preso in prestito dai nostri figli
jepessen è offline   Rispondi citando il messaggio o parte di esso
 Rispondi


Apple MacBook Air M3: chi deve davvero comprarlo? La recensione Apple MacBook Air M3: chi deve davvero comprarlo...
ASUS ROG Swift OLED PG49WCD: quando QD-OLED e ultrawide si fondono ASUS ROG Swift OLED PG49WCD: quando QD-OLED e ul...
Dreame L10s Pro Ultra Heat: la pulizia di casa tutta sostanza Dreame L10s Pro Ultra Heat: la pulizia di casa t...
HONOR Magic6 Pro: come funziona Magic Portal, il modo ''intelligente'' di condividere HONOR Magic6 Pro: come funziona Magic Portal, il...
L'innovazione richiede fiducia: Workday si propone come guida nell'era dell'IA L'innovazione richiede fiducia: Workday si propo...
Tesla spinge la produzione del Cybertruc...
Google Pixel 8 Pro a prezzi imperdibili:...
Xiaomi spacca il mercato: l'elettrica SU...
CPU Intel, un futuro tra The Big Bang Th...
Game Pass ed Epic Games Store: il suppor...
NIO inizia la produzione del sistema a 9...
Microsoft Edge consentirà di limi...
I driver NVIDIA crashano al torneo milio...
Rinviato l'ultimo lancio del razzo spazi...
CMF Buds by Nothing: gli auricolari econ...
Accordo di intesa firmato, saranno di SK...
iPhone, il supporto alla messaggistica R...
Una GeForce RTX 3080 a meno di 800 euro ...
Ecco le migliori offerte sui processori ...
Polestar presenta Polestar Charge, il se...
Chromium
GPU-Z
OCCT
LibreOffice Portable
Opera One Portable
Opera One 106
CCleaner Portable
CCleaner Standard
Cpu-Z
Driver NVIDIA GeForce 546.65 WHQL
SmartFTP
Trillian
Google Chrome Portable
Google Chrome 120
VirtualBox
Tutti gli articoli Tutte le news Tutti i download

Strumenti

Regole
Non Puoi aprire nuove discussioni
Non Puoi rispondere ai messaggi
Non Puoi allegare file
Non Puoi modificare i tuoi messaggi

Il codice vB è On
Le Faccine sono On
Il codice [IMG] è On
Il codice HTML è Off
Vai al Forum


Tutti gli orari sono GMT +1. Ora sono le: 16:01.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Served by www2v