Russian Qt Forum

В силу не очень хорошего знания С++ хочу задать вопрос

не будет ли утечки памяти в строчке
    a=getValue();
тоесть будет ли удалена или перераспределена память используемая для хранения значений a в момент присвоения этой переменной нового значения ?
и вообще можно ти делать такие функции, которые будут приниматть или возвращать контейнеры, не является ли это плохим стилем ?

Утечки не будет.

>>будет ли удалена или перераспределена память используемая для хранения значений a
В данном случае будет, т.к. в контейнере хранятся значения. Подробности о том, как разные типы данных хранятся в контейнерах смотри тут (http://www.doc.crossplatform.ru/qt/4.4.3/containers.html#the-container-classes)

>>не является ли это плохим стилем ?
Посмотри на QObject::findChildren и ей подобные функции.

поясните.

еже либ там были указатели на объекты, то объекты надо было бы прибивать руками, т.к. контейнер сам этим не занимается.

А как такое объяснить? Вектор очищяется перед заполнением новыми значениями, следовательно - нет утечки

удаляется d_ptr, а данные - нет

>>Вектор очищяется
именно вектор, а не объекты созданные с помощью new.

Из документации по Tulip:

Вместо хранения указателей в контейнерах вполне можно использовать QSharedPointer, тогда при вызове clear() указатели удаляться автоматически.

Хотя делать такие ф-ции не запрещено, это является плохим стилем (и не стоит смотреть/уповать на то что Qt это частенько делает). Память будет освобождена (как обсуждалось выше) но ценой выполнения очень многих действий, в Вашем конкретном примере Вы погасили скорость выполнения в несколько раз без всякой необходимости. По классике это звучит примерно так:

 
Это совсем нетрудно и никак не диннее, например:

 
Это совсем нетрудно и никак не диннее, например:

[/quote]

Спасибо за ответы. Я почему спрашивал, из-за недостаточности опыта. Вот например если этот вектор есть закрытим членом какого-то класса. Нас учили (не знаю правильно или нет) что доступ к данным должен осуществляться с помощью соответствующих функций. Я могу вернуть указатель  на данные, но не будет ли правильнее вернуть сами данные ?

Разработчики Qt сначала потрудились и реализовали все классы-контейнеры с механизмом Implicit Sharing. Поэтому объекты этих классов можно спокойно возвращать из функций и никакого оверхеда это не вызовет.
Другое дело, что с любыми объектами так делать не всегда хорошо...

   
Кем рекомендуется?

Правильнее то как нужно в задаче  :) Возвращая "сами данные" Вы тем самым вызываете их копирование (и последующее удаление). А это совсем недешево, особенно для сложных данных. Если Вы делаете это намеренно/осознанно (да, здесь нужна копия) - на здоровье. А иначе надо использовать константные указатели и/или ссылки. 

Механизм Implicit Sharing (или shallow copy) встроен в конкретные классы, контейнеры сами по себе ничего не решают. Например:

QString умеет создавать "быстрые копии"

А std::string не умеет
Т.е. тот же самый контейнер может давать очень разную производительность в зависимости от "начинки".

"Никакого" - это для языков типа Clipper, с которого, возможно, Вы начинали  :) Расходы все равно будут и для скоростных задач они все равно неприемлемы. Др. дело что они будут намного меньше по сравнению с "копированием в лоб" напр. как в STL. Здесь конечно, Qt смотрится посильнее.

Мы говорим о возвращении из функции Qt-контейнеров, поэтому никакого копирования при этом не происходит. Копирование будет выполнено только при попытке изменения данных в результирующем контейнере.

Данные контейнера хранятся в разделяемом-объекте, так же как и данные QString. Поэтому, при присвоении/возвращении/передаче в параметрах контейнера реально передается  только указатель на приватный объект.
Никакого дополнительного копирования данных не происходит, до момента их изменения.

QString умеет, std::string нет, поэтому я написал:
Но, вопрос был про Qt-контейнеры, поэтому спокойно можно.

Начинал я с ассемблера для 6502, Клипер обошел меня стороной.  :)
Расходы будут такие же, как возвращение ссылки/указателя.
Для скоростных задач самое важное оптимизация алгоритмов, а не попытки оптимизировать код реализующий медленный алгоритм, путем отказа от конструкторов/деструкторов и т.д.

тоесть  моя функция, если б она была членом класса была бы такая
?

Так ты возвращаешь ссылку на локальный объект, который разрушиться при выходе из функции.
Для Qt-контейнеров, та функция, которую ты привел в первом посте, абсолютно корректная. Никакого копирования данных происходить не будет.
Лучше посмотреть самому, как реализованы контейнеры в Qt.

я вообще-то  имел ввиду примерно следующее
если не углубятся в особенности реализации контейнеров Qt то пока будет существовать экземпляр подобного класса его функция getValue(); будет возвращать не сами данные а ссылку на них ?

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

Давайте на примерах


Др. пример
Да, действительно, сама строка "text" копироваться не будет (пока s1 не изменена), не будет и выделения памяти при присваивании. Не будет и освобождения в деструкторе. Но ведь QString еще много чего имеет кроме самих данных ("text") - и все эти члены класса будут скопированы в s1. А это ну никак не скорость возврата по указателю/ссылке.

Ну и конечно, все это только до первой модификации s1.
И получаем все прелести копирования по значению - по полной программе.

Давай.
Речь идет о издержках при возвращении Qt-контейнеров по значению, т.е.:

C++ (Qt)
struct Test
{
	...
};
 
QVector<Test> buildVector()
{
	QVector<Test> vec;
	// Заполняем вектор
	return vec;
}
 
void func()
{
	QVector<Test> v = buildVector();
}
 

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

Вспомним, что вектор хранит данные в непрерывном блоке и может сообщить нам адрес его первого элемента.
Тогда меняем код и смотри:

C++ (Qt)
struct Test
{
	...
};
 
QVector<Test> buildVector()
{
	QVector<Test> vec;
	// Заполняем вектор
	qDebug() << vec.data() << vec.size();
	return vec;
}
 
void func()
{
	QVector<Test> v = buildVector();
	qDebug() << vec.data() << vec.size();
}
 

Что же мы видим? И в первом и во втором отладочном выводе адреса реального расположения данных не изменились, как лежали они в одном месте, там и лежат. Чудеса.  :o
А что же произошло на самом деле? А с этим нужно разобраться самому...
Еще удивительным может показаться вывод следующей команды:

C++ (Qt)
QVector<Test> vec;
qDebug << sizeof( vec );
 

Это к тем издержкам равным передаче ссылки/указателя...

Я полностью согласен с Вашим утверждением, но это не имеет никакого отношения к Qt контейнерам, ни к Qt вообще. Все то же самое будет работать с std::vector или просто с любым классом (даже и не контейнером). Как объяснил Rcus такая оптимизация встроена практически во все современные компиляторы. Для строки

выполнится один конструктор и ни одного деструктора QVector. Однако нет никаких оснований обобщать этот частный случай. Напр. попробуем присвоить еще раз

И "увы" - мы имеем вызванный деструктор (для возвращенного объекта) + оператор присваивания, который примерно = конструктор + деструктор

Это имеет прямое отношение к Qt-контейнерам. Можно сделать еще двадцать присвоений и для всех векторов будет одна копия данных.
Это легко проверяется с помощью вызова метода: vec.isDetached(), который сообщает, эксклюзивно или нет используются данные. А использует он для этого атомарную переменную ref, содержащую число объектов QVector, которые разделяю данные.
Стоит все таки заглянуть в исходники Qt.

Насчет того-же самого с std::vector...
Не умеет std::vector такого, не умеет... Поэтому, я и написал о том, что Тролли вначале поработали, а теперь могут использовать...

C++ (Qt)
#include <QApplication>          
#include <QVector>               
#include <vector>                
#include <QDebug>                
 
QVector<int> buildVector()
{                         
        QVector<int> vec; 
        for( int i = 0; i < 100; ++i )
                vec.append( i );
 
        qDebug() << vec.constData() << vec.size();
        return vec;
}
 
std::vector<int> buildVector_std()
{
        std::vector<int> vec;
        for( int i = 0; i < 100; ++i )
                vec.push_back( i );
 
        qDebug() << &vec[ 0 ] << vec.size();
        return vec;
}
 
int main( int /*argc*/, char */*argv*/[] )
{
        QVector<int> vec = buildVector();
        qDebug() << vec.constData() << vec.size();
        QVector<int> vec_new = vec;
        qDebug() << vec_new.constData() << vec_new.size();
 
        qDebug() << "-------------------------------------------------";
 
        std::vector<int> vec1 = buildVector_std();
        qDebug() << &vec1[ 0 ] << vec1.size();
        std::vector<int> vec1_new = vec1;
        qDebug() << &vec1_new[ 0 ] << vec1_new.size();
 
        return 0;
}
 

А я и не говорил, что не будет вызван деструктор для локального объекта. Он вызовется, также как и оператор присваивания, только данные копироваться не будут. Скопируется только указатель на внутренний shared-объект.

C++ (Qt)
inline ~QVector() { if (!d) return; if (!d->ref.deref()) free(p); }

А если вызов деструктора, который не делает никаких тяжелых операций, считать большими издержками, то для чего использовать C++?
На счет такой "оптимизации" я выше уже высказался.