without further questions or postings, we will consider this topic as solved by Friday, the 11th of august 2023 and flag it accordingly.

Thank you for your understanding,
Maxon SDK Group

Have a nice weekend!

Thank you for reaching out to us. Please remember to consolidate your postings for the initial question of a topic, so that it remains compact. Please also remember to put your question at the beginning of a topic, ideally into the first sentence and not to the end of it. Finally, it is often best to describe what you want to achieve, which has been done here at best implicitly. I have fixed these points here, but please follow them in future threads.

In short, you cannot have classes with virtual member functions that use the macro MAXON_OPERATOR_MOVE_ASSIGNMENT as stated in its documentation:

This macro can't be used for classes with virtual functions for the sake of safety. Because the created move assignment operator would invoke the constructor, the vtable pointer of the object would be changed if one accidentally used the assignment operator of a base class for an object of a derived class.

This macro must not be used for classes which support concurrent move assignment calls from multiple threads to the same object because the sequence of destructor and move constructor is not thread safe.

You could of course implement the move-operator yourself (you should obey the three/five/zero rule then). But such implementation would then also have exactly that problem the docs talk about. For your case, it could look something like shown in [1]. You could also specialize the relevant operators and constructors for the derived classes, but that could be quite a bit of work, depending on how many there are.

I personally would not bother with all this and simply would not store the objects in the collection. The type maxon::PointerArray you mentioned is one option, although it also takes over the memory management of the "stored" objects for you, so in the end it sort of works like a BaseArray.

Depending on what you are trying to do, a WeakRawPtr or a maxon reference based approach might be better. [2][3]

Cheers,
Ferdinand

[1]

  // The move assignment operator, we just move the internal data which must be moved. But it will not rectify
  // the general problems described in the docs.
  //
  // We should also implement the copy and move constructors.
  SomeClass& operator =(SomeClass&& src)
  {
    _vectorArray = std::move(src._vectorArray);
    return *this;
  }

[2] WeakRawPtr Manual: No memory management, but guards against access violations for deleted objects.

maxon::BaseArray<maxon::WeakRawPtr<SomeClass>> _data;

[3] References Manual: Varying degrees of memory management, up to the degree of automated deallocation over ref counting. E.g., a copy-on-write ref, the fanciest type of refs:

maxon::BaseArray<maxon::StrongCOWRef<SomeClass>> _data;