Allocazione PIMPL e stack

Question

Quindi ho pensato a PIMPL e allo stack allocation. Ho scritto una libreria e ho deciso di usare PIMPL per nascondere il membro privato della classe. Ciò significa che avrei una classe dichiarata in questo modo

class Foo { 
private: 
    class Handle; 
    std::tr1::shared_ptr<Handle> handle; 
public: 
    Foo(); 
}; 

È piuttosto semplice. Ma poi nel costruttore si esegue questa operazione

Foo::Foo() : handle(new Handle()) {} 

Così, quando qualcuno che utilizza la mia libreria crea un Foo in pila, sono essenzialmente facendo un mucchio di allocazione comunque. È questo il compromesso con cui devi convivere quando usi PIMPL? Ho pensato di rilasciare la documentazione con un avvertimento accanto ai costruttori: "ATTENZIONE: questo si traduce in un'allocazione dell'heap" o qualcosa di simile.

Il mio altro pensiero era di avere tutte le classi che sono esposte all'implementazione come pure interfacce virtuali e un sacco di metodi statici di fabbrica che restituiscono puntatori intelligenti. Questo significa anche allocazione dell'heap ma non c'è alcun trucco.

Qualche idea o suggerimento? Sono eccessivamente premuroso nei confronti dei programmatori che usano la mia biblioteca?

Answer 1

È questo il trade-off con cui devi convivere quando usi PIMPL?

Effettivamente, sì, anche se esistono tecniche, come quelli discussi da Herb Sutter in "The Fast Pimpl Idiom," che possono essere usati per eliminare o accelerare l'assegnazione mucchio, a costo di una maggiore complessità.

Ho pensato di rilasciare la documentazione con un avviso accanto ai costruttori: "ATTENZIONE: Ciò comporta un'allocazione dell'heap" o qualcosa di simile.

Solo se è necessario farlo (vale a dire, solo se gli utenti saranno sorpresi dal fatto che la classe eseguita allocazione heap). Molte classi eseguono l'allocazione dell'heap, compresi molti di quelli nella libreria standard C++ (tutti i contenitori, per esempio).

Sono eccessivamente attento ai programmatori che utilizzano la mia libreria?

Possibilmente :-). A meno che tu non abbia requisiti di rendimento elevato per la tua classe o ti aspetti che le istanze della tua classe vengano create e distrutte con estrema frequenza, non mi preoccuperei troppo di ciò. Naturalmente, se si hanno requisiti di prestazioni significativi, il Pimpl potrebbe non essere una buona scelta.

Answer 2

Quindi, quando qualcuno che usa la mia libreria crea un Foo nello stack, in pratica fanno comunque un'allocazione dell'heap. È questo il compromesso con cui devi convivere quando usi PIMPL?

Sì.

Ho pensato di rilasciare la documentazione con un avviso accanto ai costruttori: "ATTENZIONE: Ciò comporta un'allocazione dell'heap" o qualcosa di simile.

Considererei un commento troppo aggressivo :) Se la vostra classe è così importante per le prestazioni, forse dovreste evitare l'idioma PIMPL.Se stai rappresentando un numero, questo potrebbe essere interessante e degno di nota. Se ti stai nascondendo implementazione di una connessione al database, non vale il commento :)

altro mio pensiero era quello di avere tutte le classi che sono esposti alla realizzazione di interfacce virtuali puri e tutta una serie di metodi di fabbrica statici ritorno puntatori intelligenti. Questo significa anche allocazione dell'heap ma non c'è alcun trucco.

Sì, è un po 'più ovvio per l'utente, ma probabilmente probabilmente non vale la pena di preoccuparsi.

Qualche idea o suggerimento? Sono eccessivamente premuroso nei confronti dei programmatori che usano la mia biblioteca?

C'è un compromesso, ma se la tua classe è abbastanza complessa da trarre veramente dall'idioma Pimpl, probabilmente puoi presupporre che l'allocazione dell'heap sia OK. Se stavo usando la tua libreria, probabilmente non mi riguarderebbe.