Nel mio parere, peraltro dogmatico, su questo argomento, non ci sono scuse per le fughe fisiche, almeno in una biblioteca che si propone di essere ampiamente applicabile. Quindi cercherò di intercettare gli sviluppatori GTK + finché non lo risolvono da soli.
È abbastanza banale per una libreria registrare atexit callback per liberare tutta la memoria allocata almeno dopo essere stata scaricata. Se vuole evitare le spese di un carico di adolescenti di allocazioni teeny, non dovrebbe farlo in primo luogo.
Anche il programma più pigro che voglia solo allocare una barca di piccoli pezzi di memoria in una volta sola potrebbe usare un semplice allocatore sequenziale che cancella tutta la memoria all'arresto. Se l'allocatore non vuole nemmeno occuparsi dell'allineamento, può semplicemente riempire ogni singolo blocco che esso raggruppa ai limiti di allineamento massimo. Se fosse in grado di beneficiare di tempi di spegnimento più rapidi non liberando tutti quei piccoli pezzi di memoria individualmente, allo stesso modo beneficerebbe in modo simmetrico in cambio di uno sforzo banale usando un tale allocatore sequenziale che raggruppa la memoria in modo diretto e sequenziale con allocazioni molto più veloci di malloc e più modelli di memoria cache-friendly, solo per avere tutti i grandi blocchi di memoria contigua accumulati dall'allocatore liberati quando la libreria è terminata. Tutto ciò che la libreria deve fare è sostituire le loro chiamate malloc per le quali non si preoccupano di free con qualcosa come seq_malloc , e chiama seq_purge in un callback atexit per liberare tutta la memoria allocata dopo essere stata scaricato.
Altrimenti hai questa cattiva libreria che ingombra i messaggi negli strumenti di rilevamento delle perdite di memoria che ora devi filtrare. Peggio ancora, se non li filtrate sistematicamente, potrebbero oscurare le perdite nella vostra applicazione e i vostri colleghi potrebbero sviluppare l'abitudine di trascurarli, riducendo l'utilità degli strumenti di rilevamento delle perdite, in primo luogo, impedendo alla vostra squadra di spingendo codice leaky. È grossolano e brutto e soprattutto non trovo gli argomenti a favore di fare questo deliberatamente per essere irresistibili dato quanto è banale usare la soluzione sopra.
Le perdite logiche (il tipo più complesso che nemmeno la garbage collection è in grado di proteggere) sono un problema più complesso e potrei trovare qualche giustificazione per i programmi di breve durata che hanno perdite logiche fintanto che eliminano tutta quella memoria sono stati assegnati allo spegnimento poiché richiede una grande quantità di pensiero sulla gestione delle risorse per evitare perdite logiche (probabilmente più nelle lingue con GC). Ma non trovo nessuna scusa ragionevole per evitare perdite fisiche, visto quanto sono banali da evitare anche nei contesti più pigri.
In ogni caso, perlomeno filtrerei le perdite in Valgrind in modo che almeno non compromettessero l'abilità della tua squadra di individuare le tue.