Russian Qt Forum

Одна из рекомендаций в Google Code Style (http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#Copy_Constructors) звучит следующим образом: Обоснование приводится следующее: Как вы считаете, действительно ли это стоящая рекомендация и следует её придерживаться, или это просто преверженность привычному C-стилю и страх перед новым, мол какая-то это новая неведамая фигня, давайте не будём её использовать?

И небольшой частный случай, привёдший к такому вопросу. Есть класс ConstMatrix (матрица, элементы которой нельзя изменять) и Matrix (просто матрица). Matrix наследует от ConstMatrix. Оба типа матриц нужно транспонировать. Результат транспонирования всегда будет ConstMatrix. Важно заметить, что сложность копирования матрицы при такой архитектуре стремится к O(1). Соответственно вижу два подхода к решению этой задачи:

• Запрещаем конструктор копирования и присваивания

C++ (Qt)
void ConstMatrix::transpose(ConstMatrix &transposed) const
{
// Проверяем в runtime действительно ли transposed - объект класса ConstMatrix, а не объект дочернего класса.
// Если это объект дочернего класса - получаем потенциальную проблему безопасности.
transposed=...
}
 
void someFunction(const Matrix &A)
{
ConstMatrix transposed;
A.transpose(transposed);
....
}
 

• Разрешаем конструктор копирования и присваивания

C++ (Qt)
ConstMatrix ConstMatrix::transposed() const
{
Const Matrix transposed;
...
return transposed;
}
 
void someFunction(const Matrix &A)
{
ConstMatrix transposed = A.transposed();
....
}
 

Мне больше нравится второй вариант потому что
1. Отсев ошибок на этапе компиляции предпочтительней отсева ошибок на этапе выполнения.
2. Минимизируется время между объявлением и инициализацией переменной transposed
3. Такой код легче читается, более понятен
НО! Может быть есть какие-то подводные камни из-за разрешения присваивания/копирования (лично я-то ничего плохого/опасного в этом не вижу)?

Или реализовываешь свой вариант, или запрещаешь, чтобы не огрести проблем со сгенерированными компилятором.

Мое мнение - безусловно стоящая рекомендация которой стоит придерживаться. Может быть та или иная "модернуха" которая выглядит заманчиво/элегантно, но после применения я лично часто убеждался что выигрыш не так уж велик, а вот ненужных раздумий выплывает много. Короче - действовать по классике никогда не плохо, на то она и классика.

Ну далее в приведенном Вами коде вы (борзо) возвращаете по значению, поэтому надо ставить вопрос раньше - хотите ли Вы возвращать по значению? Для простых структур это нормально, напр

C++ (Qt)
QRect R = ...
 

Здесь глупо каждый раз возиться с QRect по ссылке/указателю. Но если Ваша Matrix - потенциально большие данные - то ну его нафиг тот модерн, тут "подальше положишь - поближе возьмешь". Как правило отслеживание "а не сделал ли я чего" займет куда больше времени и сил чем чуть более развесистый код

Ну конечно об оптимизации компилятора все в курсе, об implicit sharing также, давайте не тратить на это время

Я же написал, что сложность копирования стремится к O(1). Матрица неизменяемая, поэтому Shallow Copy.

Но Вы же не написали что зарядили в класс матрицы implicit sharing (само оно ниоткуда не возьмется). Если так то вопрос "исперчен" - действуйте в духе Qt, по существу Вы приняли решение раньше. 

А вот запрещаете ли вы явно конструктор копирования и оператор присваивания в классах, наследуемых от классов, где эти операции уже запрещенны?

Если не запрещаете, то конструктор копирования и оператор присваивания формально будут доступны, но пользоваться ими будет нельзя, т.к. они недоступны в базовом классе. Результат - compile-time error.

В Qt для QObject-типов пендюрят везде Q_DISABLE_COPY.

Ясен пень, что если запрещать, то везде надо :)