передача QString функции собственному классу Опции

[Алексей1153]

Так перегрузку или параметр по умолчанию

про перегрузку

myMethod(const QString &string); //тут можно передать ссылку на QString
myMethod(const QString string); // а тут можно просто строку символов. Объект QString создастся и будет равносильно передаче по значению

но зато гибко

QString копирует данные,

мфсишный CString себя так же ведёт Я однажды это для себя открыл вдруг - передал в функцию CString по значению, потом в функции редактировал внутренний буфер вручную. Хоп! Смотрю, внешний объект тоже поменялся )) Костыль - сначала явно скопировать в другой объект.

[Obey-Kun]

Да, забыл об implicit sharing.

Но в любом случае, для передачи объектов, sizeof которых больше sizeof указателя (а это ограничивается почти всеми стандартными типами и элементами enum'ов), в качестве аргументов, во всех методах в Qt применяются именно константные ссылки, куда ни глянь.

Возможно, потому, что тут всё равно приходится совершать какие-никакие действия по копированию объекта.

[BRE]

Что-то я не пойму о чем речь?
И первый и второй метод спокойно можно вызывать так:

myMethod( "text" );

В обоих случаях будет создан временный объект QString.

[Obey-Kun]

Если ты о моём примере, то нет, при передаче по ссылке никакой копии создаваться не будет.
При передаче по копии, будет создана копия, но содержимое QString (буковки) не будут копироваться (из-за Impicit Sharing).

Сообщение отредактировал Obey-Kun - 1.12.2010, 12:09

[Алексей1153]

BRE, да, но когда передаёшь QString, не происходить аллокации для строки, а когда передаётся строку символов, происходит создание объекта и аллокация памяти под копию буфера символов. Вот об этом речь

[Obey-Kun]

По моему, чем делать заведомо менее эффективный метод для иллюзии удобства, лучше делать так:

myFunc(const QString &string) {
    qDebug() << string;
}

QString s("tatata");
myFunc(s);
myFun(QString("nanana"));

[Алексей1153]

Obey-Kun, визуальное загромождение кода тоже мало способствует удобству Мы же знаем, что QString так работает (да и сами разработчики так его применяют - это о чём-то говорит).
А в общем случае, конечно, по ссылке или по указателю большие объекты передавать следует. За исключением случаев, когда внутренний объект будет меняться - тогда проще сразу на стеке его и создать

[BRE]

Если методу нужен в качестве параметра QString, то по любому нужно создавать объект.
А передача константной ссылки всегда "легче" чем передача по значению, хотя с классами используемыми implicit sharing это и не так явно.

[Obey-Kun]

Obey-Kun, визуальное загромождение кода тоже мало способствует удобству Мы же знаем, что QString так работает (да и сами разработчики так его применяют - это о чём-то говорит).
А в общем случае, конечно, по ссылке или по указателю большие объекты передавать следует. За исключением случаев, когда внутренний объект будет меняться - тогда проще сразу на стеке его и создать

Поищите, например, setName в документации. Да у них там везде QString передаётся по константной ссылке. Абсолютно везде.
При создании копии QString, несмотря на общее использование данных, кое-какие лишние действия всё равно будут проводиться.

А передача константной ссылки всегда "легче" чем передача по значению, хотя с классами используемыми implicit sharing это и не так явно.

Вот именно. Но разница всё равно есть. И разработчики Qt, видимо, посчитали её значительной, иначе в собственных методах использовали бы передачу QString по значению.

Сообщение отредактировал Obey-Kun - 1.12.2010, 12:21

[Алексей1153]

Obey-Kun, непонятно, о чём такой долгий спор Всем и так известно, что ссылка (или указатель) передаётся быстрее и меньше стека есть. Думаешь, Антарктиду открыл ?
Только в каждом случае , когда пишешь свою функцию, нужно продумывать интерфейс, так как тупо всегда ссылку или указатель нельзя передавать. Бывает так, что надо именно объект, чтобы он сразу скопировался