mich würde interessieren, ob es zulässig und vor allem sinnvoll ist, in einem eigenen Container einen Move-Konstruktor anzubieten, der als Parameter einen Container anderen Typs bekommt. (Vielleicht ist dann der Begriff Move-Konstruktor nicht mehr ganz korrekt.) Die Bedingung, dass beide Containertypen ihre Daten in einem zusammenhängenden Speicherbereich verwalten, sei gegeben.

Im Prinzip möchte ich etwas in dieser Art machen:

template<class T>
class MyContainer
{
protected:
    T* m_data;
    size_t m_size;

public:

    MyContainer(std::vector&& rhs)
    : m_data(rhs.data),
      size(rhs.size)
    {
        rhs.data = nullptr;
    }
};

Konkret hätte ich folgende Fragen:
1. Funktioniert diese Vorgehensweise im konkreten Fall überhaupt?
2. Ist sie auch empfehlenswert oder sollte man sowas tunlichst unterlassen?
3. Gibt es überhaupt Fälle, in denen ein Konstruktor dieses Typs (nimmt rValue-reference eines anderen Typs) in Ordnung wäre?
4. Falls das in dieser Form akzeptabel ist, ist es dann auch akzeptabel einen entsprechenden Zuweisungsoperator (mit rValue) analog zu implementieren?

Vielen Dank schonmal vorab.

Bei der ganzen Aktion fragt man sich allerdings wozu das gut sein soll, und warum du nicht intern einfach wieder einen std::vector speicherst.

cooky451 schrieb:

1. Nein, du kannst vector nicht beibringen dass er seinen Kram nicht delete[]en soll.

Das hätte ich natürlich einfach mal ausprobieren können , trotzdem danke!

1. Nein, du kannst vector nicht beibringen dass er seinen Kram nicht delete[]en soll.

Edit: Nein, ist natuerlich Unsinn.

Pseudocode:

template <class C>
struct basic_storage {
  virtual T* data()=0;
  virtual size_t size()=0;
  virtual ~basic_storage(){}
};
template <class C>
struct container_storage : basic_storage<C> {
  C storage;
  container_storage(C&& c) : storage(std::move(c)); }
  T* data() { return storage.data(); }
  size_t size() { return storage.size(); }
};
template <class T>
struct default_storage_holder : basic_storage {
  ...
};
template<class T>
class MyContainer
{
    T* data_;
    size_t size_;
    std::unique_ptr<basic_storage<T> > storage_holder;

    void init()
    {
       data_ = storage_holder->data();
       size_ = storage_holder->size();
    }

public:
    MyContainer(std::vector&& rhs)
    : storage_holder(new container_storage_holder(std::move(rhs)))
    { init(); }
    MyContainer(size_t n)
    : storage_holder(new default_storage_holder(n))
    { init(); }

    ...
};

Wenn du den Allocator im Typ mitführst (was etwas Umständlicher ist, aber bei sehr vielen sehr kleinen Vektoren [was man besser vermeiden sollte] einen Unterschied machen kann), kann das Type-Erasure umgangen werden.

PS:

Arcoth schrieb:

Edit: Nein, ist natuerlich Unsinn.

So stimmt zumindest schon die Formulierung

...

Toll, du haeltst dann einfach intern einen zweiten vector , damit waere das lediglich ein Adapter.

Edit: Nein, das koennte in der Tat das sein, was der TE wollte. Die Frage ist, was dieser ueberhaupt braucht - bzw. welches Problem er damit loest.

Die interne Datenstruktur verschiedener Container zu verschieben ist meist unmöglich (da du keinen Zugriff hast und sie sich unterscheidet).

3. Gibt es überhaupt Fälle, in denen ein Konstruktor dieses Typs (nimmt rValue-reference eines anderen Typs) in Ordnung wäre?

Ich nehme an dass die Frage unabhängig vom konkreten Fall "Container" zu verstehen ist.

Dann: ja, klar. Ich könnte mir z.B. vorstellen dass man zwecks Kapselung ein und die selben Daten einmal in "editierbarer" und einmal in "nur lesbarer" Form haben möchte.

Könnten verschiedenste Dinge sein, z.B. irgendwelche Datenobjekte mit Business-Rules, 3D-Meshes - was auch immer.
Einen Grossteil davon könnte man noch mit const erschlagen. Aber die "nur lesbare" Form könnte vielleicht deutlich weniger Dependencies haben, und verwendet werden um an Modulgrenzen den Dependency-Wildwuchs einzudämmen.
Wenn man die Objekte dann von einer Form in die andere bringen kann, und die interne Repräsentation gleich ist, dann kann so ein "konsumierender Konvertierungskonstruktor" schon Sinn machen.

Bzw. eine andere Sache wo const nicht ausreicht wäre wenn man nur einen Teil der Daten der "editierbaren" Form übernehmen will -- weil diverse Hilfsobjekte/Indexe/Einträge in der "nur lesbaren" Form nicht nötig sind. Dann kann die nur lesbare Form die editierbare beklauen, und einfach alles freigeben was sie nicht braucht.

Oder ein FileLogger wo ich das zu Output-File beim Konstruieren des Loggers "reinmoven" kann hätte auch so einen Konstruktor. Wäre semantisch dann zwar kein Kopierkonstruktor mehr, formal aber genau das selbe (Rvalue Konvertierungskonstruktor halt).

Arcoth schrieb:

Nein, das koennte in der Tat das sein, was der TE wollte. Die Frage ist, was dieser ueberhaupt braucht - bzw. welches Problem er damit loest.

Vielleicht noch einmal ein paar Worte zum Hintergrund:
In den Softwaremodulen, an denen ich mitarbeite, werden selbst implementierte Container verwendet, sind an sehr vielen Stellen im Einsatz und haben gegenüber den STL-Containern einige Limitationen. In Fällen, in denen man die STL-Algorithmen gerne einsetzen würde, das aber nicht ohne weiteres kann, weil die Daten in einem eigenen Container liegen, werden dann oft einfach "STL-Kopien" erstellt und auf diesen gearbeitet.
Ich hatte mir dann die Frage gestellt, ob sich zumindest in manchen Fällen die Kopien vermeiden ließen, indem man die Daten an einen STL-Container transferiert. Und weil das Thema move-semantics für mich recht neu ist, kamen auch ein paar grundsätzliche Fragen auf. So kam es zu diesem Thread.

Vielleicht geht dieser Ansatz aber ohnehin in die komplett falsche Richtung und es müsste z.B. über die Iteratoren gehen...
Wenn es diesbezüglich bessere Ideen gibt, höre ich mir die natürlich gerne an.

In den Softwaremodulen, an denen ich mitarbeite, werden selbst implementierte Container verwendet, sind an sehr vielen Stellen im Einsatz und haben gegenüber den STL-Containern einige Limitationen.

Warum zum Teufel schreibt ihr die STL neu?

In Fällen, in denen man die STL-Algorithmen gerne einsetzen würde, das aber nicht ohne weiteres kann, weil die Daten in einem eigenen Container liegen

Moment, das ist kein Grund. STL-Algorithmen arbeiten über Iteratoren, die kann jeder Container anbieten, auch über Zeiger. Gerade deswegen ist es ja so sexy.

`boost::trim(str); // yeah

std::sort(str.begin(), str.end()); // fuck off!`

Moment! Wieso darf hustbaer das f-Wort schreiben, und ich nicht!? fuck !

Edit: Natürlich besser:

#define RANGE(r) std::begin(r), std::end(r)

boost::sort(str)

Moment! Wieso darf hustbaer das f-Wort schreiben, und ich nicht!? love !

Dafür musst du mehr als 10K Beiträge haben.

Ne, ernsthaft - guck einfach nach wie ich es gemacht hab, ist ja nicht schwer rauszufinden