Was sind die Vorteile von boost :: noncopyable?

Um das Kopieren einer Klasse zu verhindern, können Sie ganz einfach einen Konstruktor / Zuweisungsoperator für private Kopien deklarieren. Sie können aber auch erben boost::noncopyable.

Was sind in diesem Fall die Vor- und Nachteile der Verwendung von Boost?

Ich sehe keinen Dokumentationsvorteil:

#include <boost/noncopyable.hpp>

struct A
    : private boost::noncopyable
{
};

vs:

struct A
{
     A(const A&) = delete;
     A& operator=(const A&) = delete;
};

Wenn Sie Nur-Verschieben-Typen hinzufügen, sehe ich die Dokumentation sogar als irreführend an. Die folgenden zwei Beispiele sind nicht kopierbar, obwohl sie beweglich sind:

#include <boost/noncopyable.hpp>

struct A
    : private boost::noncopyable
{
    A(A&&) = default;
    A& operator=(A&&) = default;
};

vs:

struct A
{
    A(A&&) = default;
    A& operator=(A&&) = default;
};

Bei Mehrfachvererbung kann es sogar zu einer Platzstrafe kommen:

#include <boost/noncopyable.hpp>

struct A
    : private boost::noncopyable
{
};

struct B
    : public A
{
    B();
    B(const B&);
    B& operator=(const B&);
};

struct C
    : public A
{
};

struct D
    : public B,
      public C,
      private boost::noncopyable
{
};

#include <iostream>

int main()
{
    std::cout << sizeof(D) << '\n';
}

Für mich druckt dies aus:

3

Aber das, von dem ich glaube, dass es eine überlegene Dokumentation hat:

struct A
{
    A(const A&) = delete;
    A& operator=(const A&) = delete;
};

struct B
    : public A
{
    B();
    B(const B&);
    B& operator=(const B&);
};

struct C
    : public A
{
    C(const C&) = delete;
    C& operator=(const C&) = delete;
};

struct D
    : public B,
      public C
{
    D(const D&) = delete;
    D& operator=(const D&) = delete;
};

#include <iostream>

int main()
{
    std::cout << sizeof(D) << '\n';
}

Ausgänge:

2

Ich finde es viel einfacher, meine Kopiervorgänge zu deklarieren, als zu überlegen, ob ich boost::non_copyablemehrmals davon abgeleitet bin oder nicht und ob mich das kosten wird. Vor allem, wenn ich nicht der Autor der vollständigen Vererbungshierarchie bin.

Es macht die Absicht explizit und klar , andernfalls muss man die Definition der Klasse sehen und nach der Deklaration suchen, die sich auf die Kopiersemantik bezieht, und dann nach dem Zugriffsspezifizierer suchen, in dem sie deklariert ist , um festzustellen, ob die Klasse ist nicht kopierbar oder nicht. Eine andere Möglichkeit, dies zu erkennen, indem Sie Code schreiben, für den eine kopiersemantische Aktivierung erforderlich ist, und den Kompilierungsfehler anzeigen.

Zusammenfassend, was andere gesagt haben:

Vorteile boost::noncopyablegegenüber privaten Kopiermethoden :

1. Es ist expliziter und beschreibender in der Absicht. Die Verwendung von Funktionen für private Kopien ist eine Redewendung, deren Erkennung länger dauert als noncopyable.
2. Es ist weniger Code / weniger Eingabe / weniger Unordnung / weniger Raum für Fehler (am einfachsten wäre es, versehentlich eine Implementierung bereitzustellen).
3. Es bettet die Bedeutung direkt in die Metadaten des Typs ein, ähnlich einem C # -Attribut. Sie können jetzt eine Funktion schreiben, die nur Objekte akzeptiert, die nicht kopierbar sind.
4. Möglicherweise werden Fehler früher im Erstellungsprozess abgefangen. Der Fehler wird eher zur Kompilierungszeit als zur Verbindungszeit angezeigt, falls die Klasse selbst oder Freunde der Klasse das fehlerhafte Kopieren durchführen.
5. (fast das gleiche wie # 4) Verhindert, dass die Klasse selbst oder Freunde der Klasse die Methoden für private Kopien aufrufen.

Vorteile privater Kopiermethoden gegenüberboost::noncopyable :

1. Keine Boost-Abhängigkeit

1. Die Absicht von boost :: noncopyable ist klarer.
2. Boost :: noncopyable verhindert, dass die Klassenmethoden versehentlich den Konstruktor für private Kopien verwenden.
3. Weniger Code mit boost :: noncopyable.

Ich kann nicht verstehen, warum es sonst niemand zu erwähnen scheint, aber:

Mit noncopyable Ihnen schreiben Sie den Namen Ihrer Klasse nur einmal.

Ohne fünffache Vervielfältigung : Ein A für 'Klasse A', zwei zum Deaktivieren der Zuweisung und zwei zum Deaktivieren des Kopierkonstruktors.

Zitieren der Dokumentation:

"Der traditionelle Weg, um damit umzugehen, besteht darin, einen Konstruktor für private Kopien und eine Kopierzuweisung zu deklarieren und dann zu dokumentieren, warum dies getan wird. Die Ableitung von nicht kopierbar ist jedoch einfacher und klarer und erfordert keine zusätzliche Dokumentation."

http://www.boost.org/libs/utility/utility.htm#Class_noncopyable

Ein konkreter Vorteil (abgesehen davon, dass Sie Ihre Absicht etwas klarer ausdrücken) ist, dass der Fehler früher erkannt wird, in der Kompilierungsphase und nicht in der Verknüpfungsphase, wenn eine Mitglied- oder Freundfunktion versucht, ein Objekt zu kopieren. Auf den Konstruktor / die Zuweisung der Basisklasse kann nirgendwo zugegriffen werden, was zu einem Kompilierungsfehler führt.

Es verhindert auch die Funktionen versehentlich definieren (dh Typisierung {}statt ;), einen kleinen Fehler , die auch unbemerkt bleiben können, aber die würden dann Mitglieder und Freunde , damit ungültige Kopien des Objekts machen.

Der Vorteil ist, dass Sie keinen privaten Kopierkonstruktor und keinen privaten Kopieroperator selbst schreiben müssen und dies Ihre Absicht klar zum Ausdruck bringt, ohne zusätzliche Dokumentation zu schreiben.

Ein kleiner Nachteil (GCC-spezifisch) ist, dass, wenn Sie Ihr Programm mit kompilieren g++ -Weffc++und Klassen haben, die Zeiger enthalten, z

class C : boost::noncopyable
{
public:
  C() : p(nullptr) {}

private:
  int *p;
};

GCC versteht nicht, was passiert:

Warnung: 'Klasse C' hat Zeigerdatenelemente [-Weffc ++]
Warnung: überschreibt jedoch nicht 'C (const S &)' [-Weffc ++]
Warnung: oder 'operator = (const C &)' [-Weffc ++]

Während es sich nicht beschweren wird mit:

#define DISALLOW_COPY_AND_ASSIGN(Class) \
  Class(const Class &) = delete;     \
  Class &operator=(const Class &) = delete

class C
{
public:
  C() : p(nullptr) {}
  DISALLOW_COPY_AND_ASSIGN(C);

private:
  int *p;
};

PS Ich weiß, dass GCCs -Weffc ++ mehrere Probleme hat. Der Code, der nach "Problemen" sucht, ist sowieso ziemlich simpel ... manchmal hilft es.

Ich würde lieber boost :: noncopyable verwenden, als den Kopierkonstruktor und den Zuweisungsoperator manuell zu löschen oder zu privatisieren.

Ich benutze es jedoch fast nie entweder Methoden, weil:

Wenn ich ein nicht kopierbares Objekt erstelle, muss es einen Grund geben, warum es nicht kopierbar ist. Dieser Grund liegt in 99% der Fälle darin, dass ich Mitglieder habe, die nicht sinnvoll kopiert werden können. Möglicherweise eignen sich solche Mitglieder auch besser als Details zur privaten Implementierung. Also mache ich die meisten solcher Klassen so:

struct Whatever {
  Whatever();
  ~Whatever();
  private:
  struct Detail;
  std::unique_ptr<Detail> detail;
};

Jetzt habe ich eine private Implementierungsstruktur und da ich std :: unique_ptr verwendet habe, kann meine Klasse der obersten Ebene nicht kostenlos kopiert werden. Die daraus resultierenden Linkfehler sind verständlich, da sie darüber sprechen, wie Sie ein std :: unique_ptr nicht kopieren können. Für mich sind dies alle Vorteile von boost :: noncopyable und einer privaten Implementierung in einem.

Der Vorteil dieses Musters besteht später darin, dass ich, wenn ich beschließe, meine Objekte dieser Klasse tatsächlich kopierbar zu machen, einfach einen Kopierkonstruktor und / oder einen Zuweisungsoperator hinzufügen und implementieren kann, ohne die Klassenhierarchie zu ändern.

Der Nachteil, laut Scott Meyers, ist der Name "nicht natürlich", wenn Sie einen Nachteil davon finden müssen.