Assegnazione PIMPL e Stack

Question

Così ho pensato a Assegnazione di PIMPL e Stack.Ho scritto una biblioteca e ho deciso di utilizzare PIMPL per nascondere il membro privato della classe.Ciò significa che avrei dichiarato una classe come questa

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

.

È piuttosto semplice.Ma poi nel costruttore fai questo

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

.

Quindi quando qualcuno che utilizza la mia biblioteca crea un foo sulla pila, stanno essenzialmente facendo un'allocazione dell'heap comunque.È questo il trade-off con cui devi vivere quando usi PIMPL?Ho pensato di rilasciare la documentazione con un avvertimento accanto ai costruttori: "Avvertenza: questo risulta in un'allocazione heap" o somisuch.

Il mio altro pensiero era di avere tutte le classi che sono esposte all'attuazione come pura interfacce virtuali e un sacco di metodi di fabbrica statica che restituiscono i puntatori intelligenti.Questo significa anche l'allocazione dell'heap ma non c'è trucco ad esso.

Qualsiasi pensiero o suggerimento?Sono eccessivamente considerato dei programmatori che utilizzano la mia biblioteca?

Answer 1

.

È questo il trade-off con cui devi vivere quando si utilizza PIMPL?

Effettivamente, sì, anche se ci sono tecniche, come quelle discusse da Herb Sutter in "il Fast Pimpl Idiom, " che può essere utilizzato per eliminare o velocizzare l'allocazione dell'heap, al costo di maggiore complessità.

.

Ho pensato di rilasciare la documentazione con un avvertimento accanto ai costruttori: "Avvertenza: questo risulta in un'allocazione heap" o somisuch.

solo se è necessario farlo (cioè solo se i tuoi utenti sarebbero sorpresi dal fatto che la tua classe ha eseguito l'allocazione dell'heap). Molte classi eseguono l'allocazione del mucchio, compresi molti di quelli nella libreria standard C ++ (tutti i contenitori, ad esempio).

.

Sono eccessivamente considerato dei programmatori che utilizzano la mia biblioteca?

possibilmente :-). A meno che tu non abbia requisiti ad alte prestazioni per la tua classe o ti aspetti che le istanze della tua classe siano create e distrutte estremamente frequentemente, non mi preoccuperei troppo. Naturalmente, se hai requisiti significativi performance, PIMPL potrebbe non essere una buona scelta.

Answer 2

.

Quindi quando qualcuno che utilizza la mia biblioteca crea un foo sulla pila, stanno essenzialmente facendo un'allocazione dell'heap comunque. È questo il trade-off con cui devi vivere quando usi PIMPL?

yep.

.

Ho pensato di rilasciare la documentazione con un avvertimento accanto ai costruttori: "Avvertenza: questo risulta in un'allocazione heap" o somisuch.

Considererei che su un commento aggressivo :) Se la tua classe è così critica performance, forse dovresti evitare l'idioma PIMPL. Se stai rappresentando un numero, questo potrebbe essere riguardo e vale la pena notare. Se stai nascondendo l'implementazione di una connessione al database, non vale il commento :)

.

Il mio altro pensiero era di avere tutte le classi che sono esposte all'attuazione come pura interfacce virtuali e un sacco di metodi di fabbrica statica che restituiscono i puntatori intelligenti. Questo significa anche l'allocazione dell'heap ma non c'è trucco ad esso.

Sì, è un po 'più ovvio per l'utente, ma probabilmente probabilmente non vale la pena riguardo a te stesso.

.

Qualsiasi pensiero o suggerimento? Sono eccessivamente considerato dei programmatori che utilizzano la mia biblioteca?

C'è un compromesso, ma se la tua classe è abbastanza complessa da guadagnare davvero dal PIMPL Idiom, probabilmente puoi assumere un'allocazione dell'heap è ok. Se stavo usando la tua biblioteca, probabilmente non mi riguardava.