почему upcast при использовании арифметики и операторов доступа

Question

Что может быть причиной обновления в C ++ в коде, который будет использоваться для численных расчетов на огромных объемах данных (библиотека, которую я использую)?

Рассмотрим следующую иерархию:

template<class T>
class unallocatedArray
{
    public: 
        unallocatedArray(int size, T t)
            : size_(size), t_(0) 
        {

        }

        // Copy constructor. This is the only way to 
        // actually allocate data: if the array is 
        // passed as an argument to the copy constr.
        // together with the size. 

        // Checks. Access operators. Iterators, etc.  
        // Wrappers for stl sorts...

    private:
        int size_;
        T* t_;
};


template<class T>
class myArray 
: public unallocatedArray<T>
{
    public:
        // This type actually allocates the memory.
        myArray (int size)
            : unallocatedArray<T>(size)
        {
            // Check if size < 0..  

            // Allocate.
            this->t_ = new T[size];
        }

        myArray (int size, T t)
        {
            this->t_ = new T[size];

            for (int i = 0; i < this->size_; i ++ )
            {
                this->t_[i] = t;
            }
        }

        // Some additional stuff such as bound checking and error handling. 
        // Append another array (resizing and memory copies), equality 
        // operators, stream operators, etc...

};

template<class T>
class myField
: public myArray<T>
{
    public: 
        // Constructors call the parent ones. No special attributes added. 

        // Maping operations, arithmetical operators, access operator.
};

//

template<class T>
class geomField
: public myField<T>
{
    // myField but mapped on some kind of geometry, like surface meshes, 
    // volume meshes, etc.  
};

Это очень очень упрощенная модель, просто для того, чтобы утверждать, что оператор доступа определен полностью, а арифметические операторы помещены в класс myField. Теперь, что было бы причиной для выведения geomField на myField, если нужно выполнить, скажем, 1e07 раз следующее:

доступ к элементу выполнить арифметическое выражение

следующим образом:

GeomField<myType> geomFieldObject;

myField<myType>&  downCast = geomFieldObject;

// Do the arithmetical operations on the downCast reference. 

для двух таких полей? Разве апскейт не вводит какое-то наказание? Не являются ли арифметические операторы общедоступными для geomField: не в этом ли смысл публичного наследования?

Я не спроектировал это, это из библиотеки ОС, в которой я работаю.:)

Спасибо!

Answer 1

Я могу только догадываться, но некоторые арифметические операции могли быть перезаписаны в geomField для реализации геометрического отображения.

Если у вас есть данные в geomField, но вы хотите выполнить несопоставленные операции, это может быть причиной для обновления.

Если, с другой стороны, ни одна из операций, выполняемых над приведенной ссылкой, не будет перезаписана в geomField, то вы правы, что приведение не требуется.

И вообще, апскейлинг не имеет никаких недостатков в производительности, потому что обычно (или даже в каждом случае, я не уверен прямо сейчас ...) это делается полностью во время компиляции: Рассмотрим следующие классы:

class A {
public:
  void f();
};

class B : public A {
public:
  void f(); // Overwrites A::f
};

Когда ваш код выглядит как

B obj;
obj.f();

это переводится компилятором в нечто вроде

B::f(&obj);

и

static_cast<A>(obj).f();

результат в

A::f(&obj);

т.е. нет никаких накладных расходов во время выполнения, приведенных к кастингу.