In C ++, quanto tempo del programmatore viene impiegato per la gestione della memoria

Le persone che sono abituate a spazzare via le lingue raccolte hanno spesso paura della gestione della memoria del C ++. Ci sono strumenti come auto_ptre shared_ptrche gestiranno molte delle attività di gestione della memoria per te. Molte librerie C ++ precedono quegli strumenti e hanno il loro modo di gestire le attività di gestione della memoria.

Quanto tempo dedichi alle attività di gestione della memoria?

Ho il sospetto che dipenda fortemente dall'insieme di librerie che usi, quindi per favore di 'a quali si applica la tua risposta e se la rendono migliore o peggiore.

Il moderno C ++ non ti preoccupa della gestione della memoria fino a quando non è necessario, cioè fino a quando non è necessario organizzare la memoria manualmente, principalmente per scopi di ottimizzazione o se il contesto ti costringe a farlo (pensa all'hardware con grandi vincoli). Ho scritto interi giochi senza manipolare la memoria grezza, preoccupandomi solo di usare contenitori che sono lo strumento giusto per il lavoro, come in qualsiasi lingua.

Quindi dipende dal progetto ma la maggior parte delle volte non è la gestione della memoria che devi gestire, ma solo la durata dell'oggetto. Ciò viene risolto utilizzando i puntatori intelligenti , ovvero uno strumento idiomatico C ++ derivante da RAII .

Una volta capito RAII , la gestione della memoria non sarà un problema.

Quindi, quando avrai bisogno di accedere alla memoria grezza, lo farai in un codice molto specifico, localizzato e identificabile, come nelle implementazioni di oggetti pool, non "ovunque".

Al di fuori di questo tipo di codice, non sarà necessario manipolare la memoria, ma solo la durata degli oggetti.

La parte "difficile" è capire RAII.

La gestione della memoria viene utilizzata per spaventare i bambini, ma è solo un tipo di risorsa che un programmatore deve occuparsi. Pensa agli handle di file, alle connessioni di rete e ad altre risorse che ottieni dal sistema operativo.

Le lingue che supportano la garbage collection di solito non solo ignorano l'esistenza di queste risorse, ma rendono anche più difficile gestirle correttamente non fornendo un distruttore.

Quindi, in breve, suggerirei di non perdere gran parte del tempo di uno sviluppatore C ++ preoccupandosi della gestione della memoria. Come indica la risposta di Klaim , una volta ottenuto il controllo su RAII, il resto è solo riflesso.

Praticamente nessuno. Anche vecchie tecnologie come COM, è possibile scrivere deleter personalizzati per i puntatori standard che li convertiranno in pochissimo tempo. Ad esempio, std::unique_ptrpuò essere convertito per contenere in modo univoco un riferimento COM con cinque righe di un deleter personalizzato. Anche se devi scrivere manualmente il tuo gestore di risorse, la prevalenza di conoscenze come SRP e copy-and-swap rende relativamente semplice scrivere una classe di gestione delle risorse da usare per sempre di più.

La realtà è che la condivisione, l'unicità e la non proprietà sono tutte fornite con il tuo compilatore C ++ 11 e devi solo scrivere piccoli adattatori per farli funzionare anche con il vecchio codice.

Quando ero un programmatore C ++ (molto tempo fa), passavo molto tempo a preoccuparmi dei bug di gestione della memoria quando cercavo di correggere i bug difficili da riprodurre .

Con il modem C ++, la gestione della memoria è molto meno problematica, ma puoi fidarti di tutti i componenti di una grande squadra per farlo bene. Qual è il costo / tempo di:

• Formazione (non molti programmatori nascono con una buona comprensione dei problemi)
• Revisioni del codice per trovare problemi di gestione della memoria
• Debug di problemi di gestione della memoria
• Bisogna sempre tenere presente che un bug in una parte dell'app potrebbe essere dovuto a un problema di gestione della memoria in una parte non correlata dell'app .

Quindi non è solo il tempo a " fare ", questo è più un problema per i grandi progetti.

Uso molto le librerie boost e TR1 e rendono la gestione della memoria in senso stretto (new / delete) un problema. D'altra parte, l'allocazione di memoria in C ++ non è economica e bisogna prestare attenzione a dove vengono creati questi puntatori condivisi fantasiosi. Si finisce per usare molto le aree di lavoro o lavorare con la memoria basata su stack. In generale, direi che è principalmente un problema di progettazione, non un problema di implementazione.

quanto tempo impiega come cliente? molto poco, una volta capito. quando un contenitore gestisce la vita e i riferimenti, è davvero molto semplice. imo, è molto più semplice del conteggio manuale dei riferimenti ed è praticamente trasparente se consideri il contenitore che usi come documentazione che il compilatore ti impedisce convenientemente di eseguire trasferimenti di proprietà non validi in un sistema di typesafe ben progettato.

la maggior parte del tempo che passo (come cliente) viene speso con tipi di altre API, quindi funzionano bene nel contesto dei tuoi programmi. Esempio: questo è il mio contenitore ThirdPartyFont, e supporta queste caratteristiche, e implementa la distruzione in questo modo, e riferimento a contare in questo modo, e la copia di questo modo, e ... . Molti di questi costrutti devono essere in atto, ed è spesso il luogo logico per metterli. se vuoi includerlo nel tempo o meno dipende dalla tua definizione (l'implementazione deve esistere quando si interfaccia con queste API, comunque, giusto?).

successivamente, dovrai prendere in considerazione la memoria e la proprietà. in un sistema di livello inferiore, è buono e necessario, ma possono essere necessari un po 'di tempo e impalcature per implementare il modo in cui spostare le cose. non lo vedo come un dolore poiché questo è un requisito di un sistema di livello inferiore. la proprietà, il controllo e la responsabilità sono evidenti.

quindi possiamo trasformarlo in API basate su c che utilizzano tipi opachi: i nostri contenitori ci consentono di astrarre tutti i piccoli dettagli di implementazione della gestione della vita e della copia di quei tipi opachi, il che alla fine rende la gestione delle risorse molto molto semplice e consente di risparmiare tempo, difetti, e riduce le implementazioni.

è davvero molto semplice utilizzarli: il problema (proveniente da GC) è che ora devi considerare la durata delle tue risorse. se sbagli, la risoluzione può richiedere molto tempo. l'apprendimento e l'integrazione della gestione esplicita della vita sono comprensibilmente complessi in confronto (non per tutte le persone): questo è il vero ostacolo. una volta che hai dimestichezza con il controllo delle vite e l'utilizzo di buone soluzioni, è davvero molto facile gestire le vite delle risorse. non è una parte significativa della mia giornata (a meno che non si sia insinuato un insetto difficile).

se non stai usando contenitori (puntatore automatico / condiviso), stai solo supplicando per il dolore.

ho implementato le mie librerie. mi ci vuole tempo per implementare queste cose, ma la maggior parte delle persone riutilizza (che di solito è una buona idea).

Intendi come dover liberare manualmente memoria, chiudere file, cose di questo tipo? In tal caso, direi il minimo e in genere meno della maggior parte delle altre lingue che ho usato, soprattutto se generalizziamo questo non solo per "gestione della memoria" ma "gestione delle risorse". In tal senso, in realtà penso che C ++ richieda una gestione manuale delle risorse inferiore rispetto a, diciamo Java o C #.

È principalmente dovuto ai distruttori che automatizzano la distruzione della risorsa (memoria o altro). In genere l'unica volta che devo liberare / distruggere una risorsa manualmente in C ++ è se sto implementando una struttura di dati di livello inferiore (cosa che la maggior parte delle persone non ha bisogno di fare) o usando un'API C dove passo solo un po 'di tempo wrapping della risorsa C che deve essere liberata / distrutta / chiusa manualmente in un wrapper C ++ conforme a RAII.

Naturalmente se un utente richiede di chiudere un'immagine in un software di modifica delle immagini, devo rimuovere l'immagine da una raccolta o qualcosa del genere. Ma si spera che ciò non valga come "memoria" o gestione delle "risorse" di un tipo che conta in questo contesto, dal momento che è praticamente richiesto in qualsiasi lingua se si desidera liberare la memoria associata a quell'immagine in quel momento. Ma tutto ciò che devi fare è rimuovere l'immagine dalla raccolta e il distruttore di immagini si occupa di tutto il resto.

Nel frattempo, se paragone, per esempio, a Java o C #, spesso trovi persone che devono chiudere manualmente i file lì, disconnettere manualmente i socket, impostare i riferimenti agli oggetti su null per consentire loro di essere immondizia, ecc. C'è molta più memoria manuale e gestione delle risorse in quelle lingue se me lo chiedi. In C ++ spesso non hai nemmeno bisogno di unlockun mutex manualmente, poiché l'armadietto mutex lo farà automaticamente quando il mutex esce dall'ambito. Ad esempio, non dovresti mai fare cose del genere in C ++:

System.IO.StreamReader file = new System.IO.StreamReader(path);
try
{
    file.ReadBlock(buffer, index, buffer.Length);
}
catch (System.IO.IOException e)
{
    ...
}
finally
{
    if (file != null)
        file.Close();
}

Non è necessario eseguire operazioni come la chiusura manuale dei file in C ++. Finiscono per chiudersi automaticamente nell'istante in cui escono dal campo di applicazione, di conseguenza, o se seguono percorsi di esecuzione normali o eccezionali. Cosa simile per risorse legate alla memoria come std::vector. Tale codice come file.Close()sopra sarebbe spesso disapprovato poiché, specialmente nel contesto di un finallyblocco, suggerisce che la risorsa locale deve essere liberata manualmente quando l'intera mentalità attorno a C ++ è quella di automatizzarla.

In termini di gestione manuale della memoria, direi che C richiede il massimo, Java / C # una quantità media e C ++ il minimo tra questi. Ci sono molte ragioni per essere un po 'timidi nell'uso del C ++ poiché è un linguaggio molto difficile da padroneggiare, ma la gestione della memoria non dovrebbe essere una di queste. Al contrario, in realtà penso che sia una delle lingue più semplici là fuori in questo aspetto.

Naturalmente C ++ ti consente di iniziare a allocare manualmente la memoria e invocare la operator delete/delete[]memoria libera manualmente. Ti permette anche di usare funzioni C come mallocefree. Ma si tratta di pratiche di codifica di tipo antico che credo siano diventate obsolete molto prima che le persone attribuissero credito, dal momento che Stroustrup sosteneva la RAII prima ancora che coniasse il termine fin dall'inizio. Quindi non penso nemmeno che sia giusto dire che il "moderno C ++" automatizza la gestione delle risorse, perché quello doveva essere lo scopo da sempre. Altrimenti non è praticamente possibile ottenere la sicurezza delle eccezioni. È solo che molti sviluppatori mal guidati all'inizio degli anni '90 hanno provato a usare C ++ come C con oggetti, spesso ignorando completamente la gestione delle eccezioni e non avrebbe mai dovuto essere usato in quel modo. Se usi C ++ nel modo in cui era praticamente sempre inteso che fosse usato, allora la gestione della memoria è totalmente automatizzata e in genere non è qualcosa che devi affrontare (o che dovresti trattare) molto manualmente.

Dipende dai lead tecnici senior della squadra. In alcune aziende (compresa la mia), non esiste un concetto chiamato smart poiner. È considerato elegante. Quindi, la gente semplicemente elimina dappertutto e c'è un disco per riparare la perdita di memoria ogni 2 mesi. La nuova ondata di dichiarazioni di eliminazione arriva ovunque. Quindi, dipende dalla compagnia e dal tipo di persone che ci lavorano.