LINUX.ORG.RU

История изменений

Исправление www_linux_org_ru, (текущая версия) :

не странно ли вообще передавать указатель по ссылке?

конечно странно

но это, похоже, проблема с++

т.е. в рамках «не выпендривайся, ешь такой с++, как дают!» скорее всего надо передавать по константной ссылке

но предположу, что если бы с++ был сделан правильно, то тогда по значению

т.е. если у нас есть «листовая» функция f (или почти листовая), которая хочет содержимое объекта QString (т.е. строку), то можно было бы кидать туда пойнтер (назовем его QNonIncrementedPointerToStringData), который бы *не инкрементировался* на входе в f и не декрементировался на выходе из f

интересно бы это забенчить — но думаю будут случаи, когда профит всего 0.5 такта, но будут, видимо, и гораздо большие профиты — может ты забенчишь?

вообще основное возражение против gc на refcount — это именно такие случаи

(остается вопрос: а что если кто-то сделает reference_count=0 в параллельном потоке? но тогда и константная ссылка не спасет)

Исходная версия www_linux_org_ru, :

не странно ли вообще передавать указатель по ссылке?

конечно странно

но это, похоже, проблема с++

т.е. в рамках «не выпендривайся, ешь такой с++, как дают!» скорее всего надо передавать по константной ссылке

но предположу, что если бы с++ был сделан правильно, то тогда по значению

т.е. если у нас есть «листовая» функция f (или почти листовая), которая хочет содержимое объекта QString (т.е. строку), то можно было бы кидать туда пойнтер (назовем его QNonIncrementedPointerToStringData), который бы *не инкрементировался* на входе в f и не декрементировался на выходе из f

интересно бы это забенчить — но думаю будут случаи, когда профит всего 0.5 такта

(остается вопрос: а что если кто-то сделает reference_count=0 в параллельном потоке? но тогда и константная ссылка не спасет)