Да сколько уж можно-то переливать из пустого порожнее?

0

Сообщение от nullxdth Да сколько уж можно-то переливать из пустого порожнее?

Дык, вбрось че-нить новое что-ли. А то ничего другого-то больше нет

0

Сообщение от Voivoid Да ну? https://godbolt.org/g/A0Dlnm

а если мы ее вызовем этот фанкшн? в любом случае два размена и сравнение. А расказывают сказку про гонку указателей с виртуальным вызовами. в STL все указатели так сидят. А weak это вообще нечто.

0

Сообщение от Fulcrum_013 а если мы ее вызовем этот фанкшн?

Ну, вызови, мне не жалко

Сообщение от Fulcrum_013 в любом случае два размена и сравнение

Ты где там сравнение нашел, болезный?

Сообщение от Fulcrum_013 А расказывают сказку про гонку указателей с виртуальным вызовами. в STL все указатели так сидят. А weak это вообще нечто.

Ты внятно своим мысли можешь выражать?

0

Сообщение от Voivoid Ты внятно своим мысли можешь выражать?

По русски - нам тут уже второй десяток лет некоторые продвинутые пытаются рассказать что виртуальные вызова зло и вообще автономные объекты зло и они должны типа быть пассивными хранилищами данных и сидеть в контейнерах STL. а то промахи стека при доступе потому как два раза локап по указателю при вызове виртуального метода. И даже книги с диссертациями на эту тему пишут реально. А оказывается к шаредам и викам тоже доступ через двойной лукап. Так это указатели которые типа должны быть повсеместно а не виртуальные методы которых обычно не более 15%.
При этом концепция веака умиляет - лечим висячие ссылки утечкой в надежде что эта утечка будет временной.

0

Сообщение от Fulcrum_013 некоторые продвинутые пытаются рассказать

Кто? Где? Больше похоже, что ты сам на пустом месте сделал выводы космических масштабов.

Сообщение от Fulcrum_013 виртуальные вызова зло и вообще автономные объекты зло и они должны типа быть пассивными хранилищами данных и сидеть в контейнерах STL. а то промахи стека при доступе потому как два раза локап по указателю при вызове виртуального метода. И даже книги с диссертациями на эту тему пишут реально. А оказывается к шаредам и викам тоже доступ через двойной лукап. Так это указатели которые типа должны быть повсеместно а не виртуальные методы которых обычно не более 15%.

В огороде бузина, а в Киеве - дядька. Как у тебя shared pointer'ы связаны с виртуальными функциями-то, лол? Хотя подозреваю, что ты опять про свои, всем уже надоевшие, владеющие контейнеры

Добавлено через 58 секунд

Сообщение от Fulcrum_013 При этом концепция шареда умиляет - лечим висячие ссылки утечкой в надежде что эта утечка будет временной.

Да ради бога, не нравится - не пользуйся

0

Сообщение от Voivoid Как у тебя shared pointer'ы связаны с виртуальными функциями-то, л

Фактически та же манипуляция с памятью что и у виртуального метода. двойной лукап.

0

0

Сообщение от Fulcrum_013 а если мы ее вызовем этот фанкшн? в любом случае два размена и сравнение.

Пропустил ответ на

Сообщение от Voivoid Ты где там сравнение нашел, болезный?

А мне тоже интересно. И про 2 размена не понятно.

0

Сообщение от nimazzzy А мне тоже интересно. И про 2 размена не понятно.

Ну что не понятного? шаред хранит указатель не на сам объект а на дескриптор в котром записан рефкаунт и указатель на объект. соответственно при доступе сначала разыменовывается указатель на дескриптор потом разыменовывается указатель на объект.
Кстати способы избежать этого существуют. т.е. объект заранее создается с интегрированным в него а не навешенным сверху рефкаунтингом. Для этого он должен так в исходе конструироваться а не рефккаунтинг извне навешиваться. при этом еще один заяц убивается - невозможность существования двух дескрипторов рефкаунтинга для одного объекта (ушатать рефкаунтинг поимением двух шаед дескрипторов на один и тот же объект средствами stl вообще не проблема). Минус только один - на такие объекты сырыми указаателями нельзя ссылаться. Но такие смартпоинтеры для реализации должны быть нативными в языке а не библиотечными средствами делаться. Пример таких расширений - оператор gcnew и указатели ^ в MSVC++.Net и анонсированный эмбаркодеро автоматический рефкаунтинг вообще всего что возвращает new.

Добавлено через 23 минуты

Сообщение от nimazzzy А мне тоже интересно.

по поводу сравнения. Шаред может быть и пустым. т.е. указатель на дескриптор = nullptr. Соответсвенно это тоже нужно проверить перед тем как читать дескриптор.

0

Я все еще не вижу ни 2 размена, ни сравнения. Код приведенный идентичен сырому указателю. Ты можешь не пускаться в словоблудие, а прям построчно указать, в какой строке в этих двух строках 2 размена и в какой сравнение? Спасибо.

0

Сообщение от nimazzzy Код приведенный идентичен сырому указателю.

Где он идентичный? два чтения QWORD [reg] у сырого одно. При этом при каждом чтении имеешь шанс отдохнуть 500 и более тактов.

0

Fulcrum_013, те же 2. Значение указателя сначала так же надо положить в регистр, потом так же обратиться по адресу из регистра. Разница лишь в том будет, что при передаче указателя в функцию, первая операция будет до вызова.
Так что, будет 2 размена и сравнение?

0

Сообщение от nimazzzy Значение указателя сначала так же надо положить в регистр, потом так же обратиться по адресу из регистра. Разница лишь в том будет, что при передаче указателя в функцию, первая операция будет до вызова. Так что, будет 2 размена и сравнение?

При чтении из шареда нужно положить значение указателя в регистр. потом прочитать значение по этому указателю и положить его в регистр. И только мотом прочитать данные.
т.е (*a)++
для сырого указателя:
для шареда:
Добавлено через 21 минуту
другими словами аналог *raw для шареда получается *(Descriptor->Object) т.е. 2 размена

0

Сообщение от Fulcrum_013 Для шареда: mov reg,a mov reg,[reg] inc [reg]

Неа, чувак:
Где ebp-18h - это есть указатель внутри shared_ptr. Который и есть сырой указатель, то есть адрес данных.
И довольно уже уходить от темы. Построчно, плиз. Где там сравнение потерял?

0

Сообщение от Fulcrum_013 шаред хранит указатель не на сам объект а на дескриптор в котром записан рефкаунт и указатель на объект.

gcc 4.8.4
shared_ptr_base.h:
shared_ptr.h:

0

Сообщение от Fulcrum_013 шаред хранит указатель не на сам объект а на дескриптор в котром записан рефкаунт и указатель на объект

Нет. shared_ptr ( в не зависимости как созданный, хоть через make_shared, хоть руками ) хранит в себе, а не в дескрипторе, указатель на объект. Соответственно ассемблреный код будет аналогичен коду с сырым указателем.

Сколько уж можно разговаривать о том, о чем ничего не знаешь? Сложно что-ли взять и проверить?

0

Сообщение от 0x10 gcc 4.8.4 shared_ptr_base.h:

Гораздо более печальный способ который тоже никоим образом не ликвидирует возможность наличия двух дескрипторов для одного объекта. Такой способ кстати не гарантирует и отсутствие двух объектов для одного дескриптора. При этом передается куда то в функцию такая штука все равно по ссылке а не напрямую. соответственно двойного размена все равно не избежать.
А избеэать его можно только если __shared_count<_Lp> _M_refcount; // Reference counter. интегрировать в сам объект при его создании по отрицательному смещению. Но этим заниматься должен компилятор а не библиотека.

0

Сообщение от Fulcrum_013 не ликвидирует возможность наличия двух дескрипторов для одного объекта

омг, опять дескрипторы...

Сообщение от Fulcrum_013 При этом передается куда то в функцию такая штука все равно по ссылке а не напрямую. соответственно двойного размена все равно не избежать.

Без разницы. C сырым указателем будет то же самое. Чтобы передать указатель в функцию - это копия адреса. Чтобы сделать копию адреса для передачи в функцию, его надо взять и положить в стек (ia32), либо в регистр (intel64). Потом внутри функции так же обращаться по переданному адресу. И, как писал уже выше, разница будет лишь в том, что первое обращение будет до вызова функции. Пример дизасма с шаред_птр был выше.
Вот пример с сырым указателем:
Вызов:
Внутри функции:
Все то же самое, что и для shared_ptr.

Добавлено через 7 минут

Сообщение от Fulcrum_013 двойного размена

И вообще, размен чего? Ты как будто про деньги говоришь. Что за размен? Откуда ты такие слова берешь? И почему я до сих пор, все еще, еще пока, не увидел строчку ассемблера со сравнением?

0

Сообщение от nimazzzy Потом внутри функции так же обращаться по переданному адресу. И, как писал уже выше, разница будет лишь в том, что первое обращение будет до вызова функции. Пример дизасма с шаред_птр был выше. Вот пример с сырым указателем: C++

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

Сообщение от nimazzzy И вообще, размен чего?

В этой же теме таким термином разыменовывание назвали

0