Fabbriche, vettori e puntatori intelligenti - Domanda di progettazione

Se usi C ++ come linguaggio OOP in gran parte, dovrai gestire i puntatori in un modo o nell'altro. La risposta a quasi tutti i problemi del puntatore è std::unique_ptr , perché ha una semantica abbastanza simile al valore pur continuando a consentire l'utilizzo del polimorfismo. Il suo unico sovraccarico è l'ingombro sintattico. Questo è molto meglio di

• puntatori non elaborati, perché i puntatori non hanno una semantica della proprietà intrinseca. Ho visto puntatori usati sia per la semantica del prestito di riferimento, sia per il trasferimento di proprietà come copia. Questo potrebbe essere nella documentazione, ma certamente non è codificato nel codice sorgente o nel sistema di tipi.
• il C ++ 11 std::shared_ptr perché questo ha un sovraccarico aggiuntivo per il conteggio dei riferimenti.
• il deprecato std::auto_ptr perché ha semantics confuso: la copia si comporta come lo spostamento, che richiede anche che la sorgente di copia non sia const in modo che il puntatore spostato possa essere cancellato dall'origine. (Si noti inoltre che l'operatore di assegnazione della copia per std::vector si aspetta un riferimento const, quindi vector<auto_ptr<T>> non è copiabile.)
• wrapper Pimpl scritti a mano, dal momento che può essere difficile implementare correttamente un tipo - ho visto abbastanza perdite di memoria e segfaults da implementazioni non corrette (suggerimento: rendere impossibile l'uso di un puntatore nullo come impl ). In effetti, raccomando che Pimpls sia implementato in termini di un campo unique_ptr privato poiché si occupa di tutta la gestione delle risorse necessaria.

Tuttavia, l'utilizzo di un Pimpl come Bridge Pattern può consentire di progettare una gerarchia di classi polimorfiche con un'API basata sul valore ma una semantica del puntatore. In particolare, potresti utilizzare vector<BaseClass> come notazione più comoda per vector<unique_ptr<BaseClassIf>> .

Il "problema" con std::unique_ptr è che richiede C ++ 11. L'idea principale di questo tipo di puntatore è che non può essere copiato, ma può essere spostato. Pertanto, la proprietà è sempre chiaramente definita. Quando restituisci un oggetto in base al valore, sarà soggetto a copiare la semantica (anche se la copia effettiva potrebbe essere ottimizzata), tranne in C ++ 11 dove la semantica del movimento ti consentirà di restituire un unique_ptr in base al valore.

In generale, usare un contenitore di puntatori intelligenti è perfettamente soddisfacente e migliore delle alternative. Nel tuo caso, fallisce a causa della semantica ristretta di C ++ 03 rispetto a auto_ptr . Se non è possibile eseguire l'aggiornamento a C ++ 11 (che è supportato in tutti i compilatori mainstream correnti), si hanno due scelte realistiche: utilizzare i puntatori raw o avvolgere il puntatore in un Pimpl personalizzato. Userei il Pimpl se lo sforzo è giustificabile. Non è un codice tremendamente complicato, ma devi fare attenzione a inoltrare tutte le operazioni necessarie:

class BaseClassIf {
public:
  virtual ~BaseClassIf() {}
  virtual void someOperation() = 0;
  virtual BaseClassIf* copy() = 0; // { return new T(*this); }
}

class BaseClass {
  BaseClassIf* impl;
  void assertInvariant() { if (!impl) throw ...; }
public:
  BaseClass(BaseClassIf* impl) : impl(impl) { assertInvariant(); }

  ~BaseClass() { if (impl) delete impl; impl = 0; }

  BaseClass(const BaseClass& o) : impl(o.impl->copy()) { assertInvariant(); }

  void someOperation() { impl->someOperation(); }

private:
  BaseClass& operator=(const BaseClass&);
  // Cannot be reasonably overloaded as a value-based copy,
  // e.g. "*impl = *rhs.impl" since the exact types are unknown.
  // Cannot be overloaded as a reference copy,
  // e.g. "impl = rhs.impl" since that violates pointer ownership.
};

Si noti che l'interfaccia deve fornire disposizioni per accedere al costruttore della copia, poiché il tipo esatto è sconosciuto dal wrapper BaseClass . Questa è una tecnica utile occasionalmente (ad esempio "cancellazione di tipo" per nascondere i parametri del modello), ma qui è solo un fastidioso fallout derivante dall'uso del polimorfismo. Si noti inoltre che non è possibile definire un operatore di assegnazione copia per l'adattatore, a meno che non si includa un metodo comune virtual BaseClassIf::operator=(const BaseClassIf&) nell'interfaccia, ma la maggior parte delle gerarchie di oggetti non può eseguire una copia utile dalla loro base comune.

Alla tua prima domanda: "è un buon stile lasciare che un metodo di restituzione di fabbrica sia un contenitore?":

IMHO non c'è niente di speciale con un tipo come std::vector<AbstractBaseClass*> - è, almeno in linea di principio, un tipo definito dall'utente come qualsiasi altro tipo. Potresti creare un alias typedef come

 typedef std::vector<AbstractBaseClass*> MyAbstractBaseClassContainer;

se questo ti dà una migliore astrazione, o la avvolgi in una nuova classe. Quest'ultimo ti dà l'opportunità di rendere privato il costruttore, impedendo così la creazione di oggetti di quel tipo con mezzi diversi rispetto a un metodo di produzione di membri di una classe statica. Ma questo non è necessariamente necessario per una fabbrica "buona" - se std::vector<AbstractBaseClass*> si adatta alle tue esigenze, vai avanti!

Se preferisci some_smart_ptr<AbstractBaseClass> a AbstractBaseClass* , specialmente nel contesto di vector è una domanda completamente indipendente dalla prima. Poiché c'erano già buone risposte a questa domanda, ad esempio qui o qui , o la risposta di @ amon, non sto cercando di rispondere a questo, dubito che la mia risposta sarebbe migliorata.