C++ gestione memoria

[tuvok01]

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:

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.

[-MiStO-]

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

[jepessen]

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.

[DanieleC88]

Scusa l'ignoranza, ma se send() non prende possesso di quella memoria, a che serve allocarla sullo heap?

Non ti basta fare questo?

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

[Lampo89]

Originariamente inviato da DanieleC88

Scusa l'ignoranza, ma se send() non prende possesso di quella memoria, a che serve allocarla sullo heap?

Non ti basta fare questo?

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 ...

[Lampo89]

Originariamente inviato da jepessen

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

[jepessen]

Originariamente inviato da Lampo89

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.