Потоки (QThread) и сигналы

[vunder]

Есть приложение с потоком. Поток предназначен для работы с сетью и при получении данных высылает сигналы с результатами. В качестве результатов выступают классы. Как лучше их передавать, чтобы не было утечки памяти?

[kibsoft]

В качестве результатов выступают классы

Не путай объекты и классы.

Как лучше их передавать, чтобы не было утечки памяти?

Передавать указатели и удалять в нужный момент (delete). Надо смотреть код, чтобы понять что тебе нужно.

[vunder]

А что на счет передачи объектов по ссылке?

Код

C++ (Qt)
void MainWindow::onSpectrumResult(const ResultItem &result)

[kibsoft]

Можно и так. Не пойму о какой утечке памяти идет речь. Если объект создается(в стеке например, не через new) в функции принятия данных, то проблем вообще никаких. Ты передаешь ссылку, сигнал отработает и вернет управление в функцию, в конце которой твои объекты сами удалятся. Так что никаких утечек не будет.

[vunder]

Можно и так. Не пойму о какой утечке памяти идет речь. Если объект создается(в стеке например, не через new) в функции принятия данных, то проблем вообще никаких. Ты передаешь ссылку, сигнал отработает и вернет управление в функцию, в конце которой твои объекты сами удалятся. Так что никаких утечек не будет.

Это в случае прямого вызова функций. У меня это сигналы, причем в разных потоках. В параметрах connect стои тип соединения auto. Насколько я помню, в этом случае, если получатель и отправитель в разных потоках, то вызов ставиться в очередь (или что-то подобное). Что-то я не уверен, что вызов отправителя при этом блокируется

[Amigo_sa]

А что на счет передачи объектов по ссылке?

Код

C++ (Qt)
void MainWindow::onSpectrumResult(const ResultItem &result)

Нужно иметь в виду что для сигналов-слотов параметры копируются, это во-первых, лишний вызов копирующего конструктора для ResultItem, а во-вторых, если исходный item поменяется, слот об этом ничего не узнает.

[explosionhead]

А что на счет передачи объектов по ссылке?

Код

C++ (Qt)
void MainWindow::onSpectrumResult(const ResultItem &result)

Нужно иметь в виду что для сигналов-слотов параметры копируются, это во-первых, лишний вызов копирующего конструктора для ResultItem, а во-вторых, если исходный item поменяется, слот об этом ничего не узнает.

параметры-ссылки не копируются. Но в данном случае тип соединения QueuedConnection и ссылки передавать нельзя
Используй умный указатель, например std::auto_ptr

[Igors]

параметры-ссылки не копируются. Но в данном случае тип соединения QueuedConnection и ссылки передавать нельзя
Используй умный указатель, например std::auto_ptr

С точностью до наоборот  Для QueuedConnection - ссылки как раз копируются. в остальном QueuedConnection - это как PostMessage в Вындоуз. Привлекать auto_ptr не имеет смысла, т.к. он создается в контексте сигнала и может грохнуть данные в неподходящий момент.

В параметрах connect стои тип соединения auto. Насколько я помню, в этом случае, если получатель и отправитель в разных потоках, то вызов ставиться в очередь

Если получатель и отправитель были СОЗДАНЫ в разных потоках, это важно.

(или что-то подобное). Что-то я не уверен...

Возникает впечатление что Вас заставляют заниматься программированием. Может лучше переключиться на живопись или музыку, где интуитивная компонента больше? 

[explosionhead]

да, действительно я ошибался относительно QueuedConnection - он скопирует данные. Тогда нечего волноваться относительно вызова копирующего конструктора - он будет вызван в любом случае при этом виде соединений.
Хотя если автор уточнит постановку задачи, то ситуация прояснится. Возможно устроит и обычный DirectConnection

[vunder]

Итак, как я понял лучше передавать ссылку на объект, избегая тем самым дополнительный вызов конструктора, а в слоте необходимо будет вызвать delete <object>?

[galilley]

А какой объект-то хоть передаётся, и чем плох вызов копирующего конструктора.
Я у себя через сигналами кидаюсь объектами, меньше возни с delete <object> и об утечках не надо заботиться, однако тут надо смотреть на объём этих самих данных и частоту сигналов.

[vunder]

А какой объект-то хоть передаётся, и чем плох вызов копирующего конструктора.
Я у себя через сигналами кидаюсь объектами, меньше возни с delete <object> и об утечках не надо заботиться, однако тут надо смотреть на объём этих самих данных и частоту сигналов.

Код

C++ (Qt)
class SpectrumResultItem: public CustomResultItem
{
public:
    SpectrumResultItem();
    QList<float> floatSpectrum;
    QList<float> floatPhases;
    SpcKind kind;
    void setSpectrumData(const QString &strKind, QByteArray &data);
};
 

Отсчетов может быть до 300 (на оба поля floatSpectrum и floatPhases), т.е. до 1200 байт. Но это максимум. Обычно 150, т.е. 600 байт.
Данные будут приходить около 3-4 раз в секунду. Да и то это не постоянный режим работы. Это может длится несколько минут (а то и несколько секунд)

[explosionhead]

по идее если ты не будешь изменять содержимое контейнеров floatSpectrum и floatPhases, то оно не будет копироваться
да, кстати, а чем оправдано использование QList<T>? для твоей задачи правильнее использовать QVector<T>

[vunder]

по идее если ты не будешь изменять содержимое контейнеров floatSpectrum и floatPhases, то оно не будет копироваться
да, кстати, а чем оправдано использование QList<T>? для твоей задачи правильнее использовать QVector<T>

Да, действительно. Я как-то забыл про него

[Igors]

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