Gtk::manage() risolve il problema specifico della gestione a vita per le gerarchie di widget. E lo risolve bene.
I puntatori intelligenti ( std::shared_ptr in particolare) hanno un intervallo di applicazione più ampio e pertanto saranno meno efficienti se utilizzati per risolvere questo problema specifico. La gestione a vita per le gerarchie di widget può essere risolta con shared_ptr , ma sarà:
- non conciso quanto usando
manage() (come hai indicato tu stesso);
- meno efficiente in termini di utilizzo della memoria, dal momento che l'utilizzo di
shared_ptr s introdurrà un sovraccarico della memoria: shared_ptr ha un'impronta di memoria del suo riferimento al suo conteggio di riferimento, che utilizzerà la dimensione - al contrario di manage() , che usa variabili come Gtk::Object.referenced_ che fanno parte della tua classe base Widget già in ogni momento. Pertanto, se hai un numero significativo di Widgets , quella differenza di dimensione potrebbe diventare un problema da prendere in considerazione;
- non come mainstream come
manage() in gtkmm (che ha alcune conseguenze, inclusa chiarezza e manutenibilità).
Come idea di favorire std::shared_ptr su Gtk::manage() perché shared_ptr fa parte di C ++ Standard, mentre manage() no - Non sono sicuro che cambierà la partita per un'applicazione media, come non usando manage() non tagli comunque la tua dipendenza da Gtk. Quindi la tua applicazione non acquisirà una portabilità migliore se andassi per shared_ptr .
Preferisco sfruttare l'API gtkmm nativa, per motivi di chiarezza ed efficienza.
P.S .: In realtà c'è un puntatore intelligente Glib::RefPtr , che gestisce la gestione a vita per determinati oggetti gtkmm. Anche in questo caso, poiché è una funzione nativa di Glib, sfrutta strutture built-in di Glib::ObjectBase , ed è quindi più efficiente di std::shared_ptr per alcune applicazioni, per i motivi spiegati nel secondo punto sopra.