C++ 11 вектор индексирования интеллектуальных указателей как член класса

Question

В моем проекте есть следующие классы: Neuron, ActivationNeuron, Layer и ActivationLayer, как это частично указано ниже.

class Neuron { }; /* abstract class */ 
class ActivationNeuron : public Neuron { }; 

class Layer { 
protected: 
    vector<shared_ptr<Neuron>> neurons; 
public: 
    Neuron& operator[](const int index) { 
     return *this->neurons[index]; 
    } 
}; 

class ActivationLayer : public Layer { 
public: 
    ActivationNeuron& operator[](const int index) { 
     return *static_pointer_cast<ActivationNeuron>(this->neurons[index]); 
    } 
}; 

У меня есть два вопроса:

• Реализация/Синтаксис Связанные: Слой теперь использует shared_ptr е нейроны. Как изменить мою реализацию, если я планирую использовать unique_ptr с вместо этого, учитывая, что static_pointer_cast недоступен для unique_ptr?

• Семантика Связанный: Должен ли я использовать unique_ptr с при всех в этом случае, учитывая, что код в других классах (в том числе моих тестов) часто ссылаются оператор индексирования для вызова функции на ActivationNeuron ссылки?

• Больше Семантики: Данных гарантированно будет использоваться только до тех пор, как Layer экземпляра находится в области видимости (без отложенной регистрации). Как влияет действие типа указателя, если вместо этого я вместо этого вернусь pointer<Neuron> и pointer<ActivationNeuron>? Меня больше интересует семантика перемещений/копий и политика владения, а не (некритические) эффекты в производительности.

Я также приветствую улучшения в моей текущей реализации.

Answer 1

Согласно http://www.cplusplus.com/reference/memory/static_pointer_cast/, что у вас есть эквивалентно

return *static_cast<ActivationNeuron*>(this->neurons[index].get()); 

Заявление выше будет работать на unique_ptr, а также.

С семантической стороны вы меняете модель собственности. Прежде чем кто-то мог удержать указатели. Теперь они будут связаны с Layer. Если все используется в то время как Layer существует, все должно быть хорошо. Если вам нужны некоторые компоненты для доступа к данным после того, как Layer будет уничтожен (например, отложенное ведение журнала), тогда у вас возникнут проблемы.

Не зная, что приложение большего размера сложно сказать, есть ли какие-либо проблемы.

Производительность: статические литье, индексирование и .get() почти тривиальны (сложность O (1), просто индексирование памяти), и я бы не стал слишком беспокоиться об их производительности. Вы можете сделать профиль, чтобы убедиться, что это так в вашем приложении. Вы определенно только немного хуже по сравнению с vector<Neuron*>.