std::unique_ptr<T[]> with an array of derived objects, use of deleted function

The problem with your design is that objects are derived and polymorphic, but not the arrays of objects.

For example, Electron could have additional data that a Particle doesn't have. Then the size of an Electron object would no longer be the same size as a Particle object. So the pointer arithmetic that is needed to access array elements would not work anymore.

This problem exist for raw pointers to array as well as for unique_ptrto array. Only the objects themselves are polymorphic. If you want to use them without the risk of slicing, you'd need an array of pointers to polymorphic objects.

If you look for additional arguments explaining why this design should be avoided, you may have a look at the section of Scott Meyers' book "More effective C++" titled "Item 3: never treat arrays polymorphically".

Alternative: change your design

For example, use a vector of the real type to create your objects. And use a vector to a polymorphic Particle pointer to use these objects polymorphically:

vector<Electron>myelectrons(count);   // my real object store 
vector<Particle*>ve(count, nullptr);  // my adaptor for polymorphic access
transform(myelectrons.begin(), myelectrons.end(), ve.begin(), 
                [](Particle&e){return &e;} );  // use algorithm to populate easlily 
for (auto x: ve)  // make plain use of C++11 to forget about container type and size
   x->function(); 

Here a live demo:

std::unique_ptr is preventing from shooting yourself in the foot, as std::default_delete<T[]> calls delete[], which has the behaviour specified in the standard

If a delete-expression begins with a unary :: operator, the deallocation function’s name is looked up in global scope. Otherwise, if the delete-expression is used to deallocate a class object whose static type has a virtual destructor, the deallocation function is the one selected at the point of definition of the dynamic type’s virtual destructor (12.4). 117 Otherwise, if the delete-expression is used to deallocate an object of class T or array thereof, the static and dynamic types of the object shall be identical and the deallocation function’s name is looked up in the scope of T.

In other words, code like this:

Base* p = new Derived[50];
delete[] p;

is undefined behaviour.

It may have seem to work on some implementations - there, the delete[] call looks up the size of the allocated array and calls destructors on the elements - which requires the elements to have a well known size. Since the size of derived objects may differ, the pointer arithmetic goes wrong, and the destructors are called with the wrong address.

Let's review what you tried:

std::unique_ptr<Particle[]> electrons(new Electron[count]);

there's a code in std::unique_ptr's constructor that detects these violations, see cppreference.

std::unique_ptr<Particle, std::default_delete<Particle[]>> electrons(new Electron[count]);

is undefined behaviour, you essentially tell the compiler that delete[] is a valid way to release the resources you push to the constructor of electrons, which isn't true, as mentioned above.

The only safe way with polymorphism is to use std::unique_ptr pointing to derived objects, like std::vector<std::unique_ptr<Particle>>

Since you mention that performance is critical, then dynamically allocating every Particle will be slow - in this case you can:

• use an object pool
• make use of flyweight pattern
• refactor it to avoid inheritance
• use std::vector<Electron> or std::unique_ptr<Electron[]> directly.

Use a std::vector or std::array (if you know how many) of std::unique_ptr. Something like this:

#include <vector>
#include <memory>

class A
{
public:

    A() = default;
    virtual ~A() = default;
};

class B : public A
{
public:

    B() = default;
    virtual ~B() = default;
};

int main(void)
{
    auto v = std::vector<std::unique_ptr<A>>();

    v.push_back(std::make_unique<A>());
    v.push_back(std::make_unique<B>());

    return 0;
}

Edit: In terms of speed I did a quick test with the 3 methods and this is what I found:

Debug

6.59999430  : std::vector (with reserve, unique_ptr)
5.68793220  : std::array (unique_ptr)
4.85969770  : raw array (new())

Release

4.81274890  : std::vector (with reserve, unique_ptr)
4.42210580  : std::array (unique_ptr)
4.12522340  : raw array (new())

Finally, I did a test where I used new() for all 3 versions instead of unique_ptr:

4.13924640 : std::vector
4.14430030 : std::array
4.14081580 : raw array

So you see there's really no difference in a release build, all else being equal.