Лучшая практика: QT4 QList <Mything *> ... on Heap или QList <Mything>с использованием ссылки?

Question

Изучаю C ++, так что будь осторожен:) ...

Я разрабатывал свое приложение в основном с использованием переменных кучи (из C), поэтому я разработал структуры, подобные этой:

QList<Criteria*> _Criteria;
// ...
Criteria *c = new Criteria(....);
_Criteria.append(c);

На протяжении всей моей программы я передаю указатели на определенные критерии или часто в список. Итак, у меня есть функция, объявленная так:

QList<Criteria*> Decision::addCriteria(int row,QString cname,QString ctype);
Criteria * Decision::getCriteria(int row,int col)

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

Мне интересно, если бы я как-то использовал ссылки. Так как я всегда хочу вернуть этот точный критерий, я должен был сделать:

QList<Criteria> _Criteria;
// ....
Criteria c(....);
_Criteria.append(c);

...

QList<Criteria>& Decision::addCriteria(int row,QString cname,QString ctype);
Criteria& Decision::getCriteria(int row,int col)

(не уверен, что последняя строка синтаксически верна, но вы получаете смещение).

Все эти элементы являются определенными, квазиглобальными элементами, которые являются ядром моей программы.

Итак, вопрос в следующем: я, конечно, могу выделить / освободить всю свою память без проблемы в методе, который я использую сейчас, но есть ли еще способ C ++? Если бы ссылки были лучшим выбором (еще не поздно изменить на моей стороне).

ТИА

Mike

Answer 1

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

Мой совет: если у вас нет действительно веской причины усложнять ситуацию, сохраняйте ее простой.

Однако, с точки зрения Qt, вы обычно не должны передавать указатели или ссылки на объекты Qt. Эти объекты do используют неявное совместное использование, поэтому они не действуют как "нормальные" объекты C ++. Если вы все еще изучаете C ++, я бы предложил пока оставить эту технику вне собственного кода. Но чтобы эффективно использовать Qt, вам нужно понять, как он работает, поэтому я рекомендую прочитать об этом здесь:

http://qt.nokia.com/doc/4.6/implicit-sharing.html

Удачи!

EDIT:

Одна вещь, которую я забыл упомянуть. Если вы знаете, что не хотите, чтобы ваш класс копировался, вы можете применить это, объявив конструктор частной копии и operator = overload:

class A
{
    //Code goes here
private:
    A(const A&);
    A& operator=(const A&);
};

Answer 2

Я бы вернул QList<Criteria> в виде простого значения. QList является одним из общих классов Qt , что означает, что его внутреннее представление совместно используется несколькими экземплярами, если ни один из них не изменен.

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

У этого подхода есть два недостатка: во-первых, копирование, если оно есть, является неявным и может происходить, когда вы этого не ожидаете, и во-вторых, оно не допускает полиморфное использование Criteria. Если у вас Criteria в качестве корня иерархии классов, то вы должны использовать указатели. В этом случае я бы использовал shared_ptr из Boost или C ++ TR1, чтобы избежать проблем с управлением памятью, или заставил бы Critera публично наследовать от QObject и сделать все Critera объекты дочерними для Decision.