Практика кодирования: возврат по значению или по ссылке в матричном умножении?

Проблема, с которой вы столкнулись, заключается в том, что выражение a * b создает временный объект, а в C ++ временному объекту не разрешено связываться с непостоянной ссылкой, что и принимает ваш Matrix& operator=(Matrix& m). Если вы измените его на:

Matrix& operator=(Matrix const& m);

Теперь код должен скомпилироваться. Помимо очевидного преимущества создания компилируемого кода :), добавление const также сообщает вашим вызывающим абонентам, что вы не будете изменять аргумент m, что может быть полезной информацией.

Вы также должны сделать то же самое для своего operator*():

Matrix operator*(Matrix const& m) const;

[EDIT: дополнительный const в конце указывает, что метод также обещает не изменять *this, объект в левой части умножения. Это необходимо, чтобы справиться с такими выражениями, как a * b * c - подвыражение a * b создает временное выражение и не будет связываться без const в конце. Спасибо Грегу Роджерсу за указание на это в комментариях. ]

P.S. Причина, по которой C ++ не позволяет временному привязывать непостоянную ссылку, заключается в том, что временные файлы существуют (как следует из названия) очень короткое время, и в большинстве случаев было бы ошибкой пытаться их изменить.

Вам действительно стоит прочитать Эффективный C ++ Скотта Мейерса, у него есть отличные темы по этому поводу. Как уже было сказано, лучшими подписями для operator= и operator* являются

Matrix& operator=(Matrix const& m);
Matrix operator*(Matrix const& m) const;

но я должен сказать, что вы должны реализовать код умножения в

Matrix& operator*=(Matrix const& m);

и просто используйте его в operator*

Matrix operator*(Matrix const &m) const {
    return Matrix(*this) *= m;
}

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

Примечание: начните с предложений Вадима. Следующее обсуждение спорно, если мы говорим только об очень маленьких матрицах, например если ограничиться матрицами 3х3 или 4х4. Также я надеюсь, что не пытаюсь навязать вам много идей :)

Поскольку матрица потенциально является тяжелым объектом, вам определенно следует избегать глубоких копий. Умные указатели - это одна из утилит для реализации этого, но они не решают вашу проблему из коробки.

В вашем сценарии есть два общих подхода. В обоих случаях любая копия (например, a=b) копирует только ссылку и увеличивает счетчик ссылок (это то, что могут сделать за вас интеллектуальные указатели).

При использовании Копировать при записи глубокое копирование откладывается до тех пор, пока не будут внесены изменения. например вызов функции-члена, такой как void Matrix.TransFormMe() на b, увидит, что на фактические данные ссылаются два объекта (a и b), и создаст глубокую копию перед выполнением преобразования.

В итоге ваш матричный класс действует как «нормальный» объект, но количество фактически сделанных глубоких копий резко сокращается.

Другой подход - неизменяемые объекты, когда сам API никогда не изменяет существующий объект - любое изменение создает новый объект. Таким образом, вместо члена void TransformMe()' member transforming the contained matrix, Matrix contains only aMatrix GetTransformed () `, возвращающего копию данных.

Какой метод лучше, зависит от реальных данных. В MFC CString - это копирование при записи, в .NET String - неизменяемый. Неизменяемые классы часто нуждаются в классе построителя (например, StringBuilder), который избегает копий многих последовательных модификаций. Объекты копирования при записи требуют тщательного проектирования, чтобы в API было ясно, какой член изменяет внутренние элементы, а какой возвращает копию.

Для матриц, поскольку существует множество алгоритмов, которые могут изменять матрицу на месте (т.е. самому алгоритму не требуется копия), копирование при записи может быть лучшим решением.

Однажды я попытался построить указатель копирования при записи поверх интеллектуальных указателей Boost, но я не касался его, чтобы выяснить проблемы с потоками и т. Д. Псевдокод будет выглядеть так:

class CowPtr<T>
{
     refcounting_ptr<T> m_actualData;
   public:
     void MakeUnique()
     {
        if (m_actualData.refcount() > 1)
           m_actualData = m_actualData.DeepCopy();
     }
     // ...remaining smart pointer interface...
}

class MatrixData // not visible to user
{
  std::vector<...> myActualMatrixData;
}

class Matrix
{
  CowPtr<MatrixData> m_ptr; // the simple reference that will be copied on assignment

  double operator()(int row, int col)  const
  {  // a non-modifying member. 
     return m_ptr->GetElement(row, col);
  }

  void Transform()
  {
    m_ptr.MakeUnique(); // we are going to modify the data, so make sure 
                        // we don't modify other references to the same MatrixData
    m_ptr->Transform();
  }
}

… Все они кроме const, поскольку все они вызывают (при необходимости):

void lupp();

Это обновит кешированные L, U и P. То же самое означает get_inverse(), который вызывает lupp(), а также устанавливает Matrix* Matrix::inverse. Это вызывает проблемы с:

Matrix& operator=(Matrix const& m);
Matrix operator*(Matrix const& m);

техника.

Пожалуйста, объясните, почему это вызывает проблемы. Обычно этого не должно быть. Кроме того, если вы используете переменные-члены для кэширования временных результатов, сделайте их mutable. Затем вы можете изменять их даже в const объектах.

Да, оба предложения хороши, и я признаю, что не знал о проблеме временного объекта с неконстантными ссылками. Но мой класс Matrix также содержит средства для получения факторизации LU (исключения Гаусса):

const Matrix& get_inverse();
const Matrix& get_l();
const Matrix& get_u();
const Matrix& get_p();

Все, кроме const, поскольку все они вызывают (при необходимости):

void lupp();

Это обновляет кешированные L, U и P. То же самое означает get_inverse(), который вызывает lupp (), а также устанавливает Matrix* Matrix::inverse. Это вызывает проблемы с:

Matrix& operator=(Matrix const& m);
Matrix operator*(Matrix const& m);

техника.