[Qt] & vs *

указатели

*

чего ж тогда в офф доке ссылки?
http://doc.trolltech.com/4.5/model-view-creating-models.html

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

угу.

bool StringListModel::removeRows(int position, int rows, const QModelIndex &parent)

тогда почему &parent если это объект QModelIndex? или по ссылке принято передавать любые сущности, если они выступают в качестве параметра метода?

> тогда почему &parent

Потому что он - const.

K.O.

Сколько вижу ссылок, они все const. Иначе - указатели.

почему б тогда везде не применять ссылки? или считается, что профит указателя в арифметике?

почему б тогда везде не применять ссылки?

А в чем профит ссылок?

писанины меньше, поведенее очевиднее и применение безопаснее. ради этого, собвственно, их в плюсы и добавили.

Наследники QObject - по указателю, прочие - по ссылке.

А чорт его помнит. Где-то в был разбор, почему так, но не помню где :(

То есть свои классы, которые QObject не наследуют, следует тоже по ссылке передавать?
А ежели такие классы QObject в include имеют, но не наследуют (сигнал-слот не надо, а вот контейнеры надо) - как тут быть?

Тут все очень спорно, лично я делаю так, как и они в библиотеке (как я написал выше). Вообще это беда С++, т.к. достаточно сильно функциональность ссылок и указателей дублируют друг друга.

Ссылки нельзя переприсвоить, это существенный плюс, так как прячутся детали реализации. Иногда руки чешутся написать:

void someFunction( const int someValue )

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

Константные ссылки как минимум ликвидируют потенциальное копирование типов сложнее int, заметьте, QPoint тоже передаются как константные ссылки, это даёт большее пространство для манёвра компилятору, так как он заранее знает, что значение не предназначено для копирования.

То есть свои классы, которые QObject не наследуют, следует тоже по ссылке передавать?

QObject - частный случай, скажем так, по указателю следует передавать экземпляры неразделяемых классов.

А ежели такие классы QObject в include имеют, но не наследуют (сигнал-слот не надо, а вот контейнеры надо) - как тут быть?

Здесь QObject работает как обычный указатель, передавать всю структуру по значению или константной ссылке.

> по указателю следует передавать экземпляры неразделяемых классов

что есть неразделяемый класс? формулировка не гуглится толком

Блджад, да что ж вы так тупите?

Параметры передаются в двух вариантах:

void f(const type &arg1, type *arg2);

Разница очевидна пятилетнему младенцу.

> что есть неразделяемый класс?

Класс с неразделяемыми данными, use case: экземпляры таких классов уникальны. Как правило это полиморфные классы, у которых запрещён оператор копирования. К примеру QFile нельзя склонировать, его состояние уникально внутри процесса.

> Параметры передаются в двух вариантах

открой для себя уже:

void f( type& arg1, const type* arg2 );

и как ни странно - то что я копипастил для соседней темы подходит и тут:

http://pastebin.com/tVVh0ast

самая верхняя функция - именно такой способ передачи параметров

> void someFunction( const int someValue )

но это раскрывает детали реализации

«Да, белый, горячий, совсем белый»©

> открой для себя уже

Когда придешь на работу, тебе его быстро закроют )))

> Когда придешь на работу, тебе его быстро закроют )))

еще один «гений», ну давай - вот тебе функция была дана, покажи как ты ее напишешь, или тоже «стесняешься»?

Что в Qt принято использовать: ссылки или указатели?

да ровно то же что и в С++, потому что :)

гугль учит так: когда параметр идёт со словом const - используй ссылку, если без - жучку

> гугль учит так: когда параметр идёт со словом const - используй ссылку, если без - жучку

а гугль не рассказывал про ссылки на указатели, а также константные указатели( вроде const char* )? :)

для QObject оператор и конструктор копирования закрыты, но что мешает передать его ссылкой? копирование при этом тоже не происходит.

> вот тебе функция была дана, покажи как ты ее напишешь, или тоже «стесняешься»?

Да ты весь код показывай. Там же везде такой звиздец как SomeFunc(wchar_t*& ch, ...

> гугль учит так: когда параметр идёт со словом const - используй ссылку, если без - жучку

а гугль не рассказывал про ссылки на указатели, а также константные указатели( вроде const char* )? :)

давайте не мешать зелёное и квадратное

во-первых как Ваше замечание относится к вопросу ТС?

а во-вторых в идеальном (!) случае char* вообще в C++ не должен встречаться, есть std::string/std::wstring

> Да ты весь код показывай.

зачем? там дальше ничего нового не будет, вся логика как на ладони( и комментарий понятный вроде ) - есть строка разделенная '\n' - читаем имя «объекта» и тянем для него параметры

Там же везде такой звиздец как

этот «звиздец» уделает по скорости твой аналогичный «мега-кул» код без использования wchar_t* в разы

> а гугль не рассказывал про ссылки на указатели,

Разумеется, нет. Чё, гугль, изрващенец, чтоле, использовать такие вещи?

а также константные указатели( вроде const char* )? :)

Вот чего тебе гугль точно не рассказывал, так это разницу между константным указателем и указателем на константу. ;)

> а во-вторых в идеальном (!) случае char* вообще в C++ не должен встречаться, есть std::string/std::wstring

ага, когда парсишь текст( рядовая задача ) - просто идеально каждый токен ложить в новый wstring, а потом удалять

> Вот чего тебе гугль точно не рассказывал, так это разницу между константным указателем и указателем на константу. ;)

не надо придираться к словам - просто оговорился

> для QObject оператор и конструктор копирования закрыты, но что мешает передать его ссылкой?

Здесь решает роль use case. Ссылку нельзя скопировать, обнулить и переприсвоить. Как правило при передаче ссылкой подразумевается синоним переменной, которую метод призван поменять и вернуть.

> а во-вторых в идеальном (!) случае char* вообще в C++ не должен встречаться, есть std::string/std::wstring

ага, когда парсишь текст( рядовая задача ) - просто идеально каждый токен ложить в новый wstring, а потом удалять

во-первых, почему сразу в новый, используй старый, только clear() вызывай и будет весело и вкусно, в смысле быстро и безопасно :)

во-вторых std:string ничем особо не отличается по методам применения от char*

в-третьих таки зависит от задачи (если у Вас выделяется строка, а потом с ней должен руками поработать негр, то пофиг чё там происходит, честное слово, всё равно негр на порядки медленнее :))

> во-первых, почему сразу в новый, используй старый, только clear() вызывай и будет весело и вкусно, в смысле быстро и безопасно :)

для этого нужно вызывать resize() + memcpy() для каждого токена - если я правильно понял, вместо того, чтоб просто отдать указатель

> там дальше ничего нового не будет, вся логика как на ладони

Логика там кошмар. По-нормальному было бы так:

item.init_from_wstr(wchar_t *wstr)
{
...
pos.x = wcstol( start, &ch, 10 );
...
pos.y = wcstol( start, &ch, 10 );
...
}

Но до ООП там у тебя еще пахать и пахать...

Самое же смешное, что у тебя ошибка в коде.

Тогадайся с трех раз, что будет, если в ReadClipItem( wchar_t*& ch, const wchar_t* end ) передадут массив только с тремя '\n'? ;))

этот «звиздец» уделает по скорости

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

Здесь решает роль use case.

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

> Как правило при передаче ссылкой подразумевается синоним переменной, которую метод призван поменять и вернуть.

4.2

Это подразумевается передачей по указателю. По ссылке - либо конст, либо никак.

> во-первых, почему сразу в новый, используй старый, только clear() вызывай и будет весело и вкусно, в смысле быстро и безопасно :)

для этого нужно вызывать resize() + memcpy() для каждого токена - если я правильно понял, вместо того, чтоб просто отдать указатель

эм? я Вас не очень понял

во-первых не обязательно resize() + memcpy(), можно и потоньше

во-вторых можно делать так: &mystring[0] и вот он Ваш указатель на первый элемент массива char*

в-третьих как это Вас спасает от того же самого в случае с char*

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

> Логика там кошмар. По-нормальному было бы так:

я тебе открою секрет:
1. там не только long читается, но и шрифт, например, а ты уже смело начал копиапстить код
2. «наверх» надо новое смещение отдавать

Но до ООП там у тебя еще пахать и пахать...

LOL

Тогадайся с трех раз, что будет, если в ReadClipItem( wchar_t*& ch, const wchar_t* end ) передадут массив только с тремя '\n'? ;))

а ничего не будет - item.size.y просто будет с дефолтным значением

Ты дурачок, шотле?

Сначала возвращаешь через стэк объект

по-моему дурачок тут ты - где ты такое увидел?

> во-первых не обязательно resize() + memcpy(), можно и потоньше

покажите же

во-вторых можно делать так: &mystring[0] и вот он Ваш указатель на первый элемент массива char*

спасибо К.О., если вы посмотрите мой код - то увидите, что я про то знаю

в-третьих как это Вас спасает от того же самого в случае с char*

от чего?

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

а я не собираюсь выделять память - у меня есть wstring и я использую его буфер

> где ты такое увидел?

а... ты просто не знаешь ключевое слово inline, бывает...

> а ничего не будет - item.size.y просто будет с дефолтным значением

Бггг.

где ты такое увидел?

LDCPlayerItem item;

...

return item;

Это чтоа? Или ты наивно думаешь, что inline спасет тебя от лишнего вызова конструктора копий? ;)))

> Бггг.

а по-твоему программа должна упасть на ассерте что-ли? это данные для preview - если они внезапно оказались битые, то не надо паниковать

Это чтоа? Или ты наивно думаешь, что inline спасет тебя от лишнего вызова конструктора копий? ;)))

я уже наивно проверил на gcc на msvc - ты не поверишь

давайте не играть в шланг, Вы авторитетно заявили что char* нужен (пусть иносказательно, но всё же), хотелось бы чтобы Вы привели обоснование своего высказывания

> давайте не играть в шланг

я только за, вы два раза «прошланговали» мой вопрос про то, что без использования char* надо копировать все токены один за одним

хотелось бы чтобы Вы привели обоснование своего высказывания

не надо копировать все токены один за одним

давайте не играть в шланг

я только за, вы два раза «прошланговали» мой вопрос про то, что без использования char* надо копировать все токены один за одним

хотелось бы чтобы Вы привели обоснование своего высказывания

не надо копировать все токены один за одним

это почему Вы так считаете? давайте-ка поподробнее с этого места, в чём тут будет разница между char* и std::string?

> давайте-ка поподробнее с этого места, в чём тут будет разница между char* и std::string?

ну вот смотрите - дошел я разделителя, получил, что нужная строка лежит от 'start' до 'end', теперь я могу использовать 'start' как строку саму по себе, т.е. например вызвать тот же wcstol или передать моему объекту как указатель, а в случае со string нужно сначала скопировать кусок от 'start' до 'end' в string - т.е. лишние действия

LDCPlayerItem item;
...
return item;

Это чтоа? Или ты наивно думаешь, что inline спасет тебя от лишнего вызова конструктора копий? ;)))

Я вас сейчас сильно удивлю:

#include <stdio.h>

class A
{
public:
	A() :
		value( 0 )
	{
		printf( "A()\n" );
	}

	~A()
	{
		printf( "~A()\n" );
	}

	A( const A & a ) :
		value( a.value )
	{
		printf( "A(const A&)\n" );
	}

	A & operator=( const A & a )
	{
		value = a.value;
		printf( "operator=(const A&)" );
	}

	int value;
};

inline A inline_func()
{
	A a;
	a.value = 7;
	return a;
}

int main( int argc, char ** argv )
{
	printf( "Some value: %d\n", inline_func().value );
	return 0;
}

Проверяем:

$ ./a 
A()
Some value: 7
~A()
$

давайте-ка поподробнее с этого места, в чём тут будет разница между char* и std::string?

ну вот смотрите - дошел я разделителя, получил, что нужная строка лежит от 'start' до 'end', теперь я могу использовать 'start' как строку саму по себе, т.е. например вызвать тот же wcstol или передать моему объекту как указатель, а в случае со string нужно сначала скопировать кусок от 'start' до 'end' в string - т.е. лишние действия

я Вас не понимаю, что мешает сделать тоже самое с std::string (с учётом что исходная строка в нём родимом)?