Здравствуйте, ViTech, Вы писали:

VT>Терзают меня смутные сомнения, что такой mirror_ptr может на что-нибудь полезное сгодиться. И долго хранить в куче ссылку на указатель (да и вообще на что либо) я бы поостерёгся.

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

Здравствуйте, rg45, Вы писали:

S>>Да тут тред не про это. Тут тред про "шеридан дурак"
R>Тред создал ты, если ты уже забыл. "Помогите, мои идеальные программы крешатся".
У меня ничего не крешится. Крешится из за "умных" указателей в урхо, криво прикрученных везде подряд.

BFE>

BFE>   int*& ptr;
BFE>

Это как защититься от простреливания ноги, засунув ее в дуло пушки.

Здравствуйте, Sheridan, Вы писали:

S>Здравствуйте, rg45, Вы писали:

S>>>Да тут тред не про это. Тут тред про "шеридан дурак"
R>>Тред создал ты, если ты уже забыл. "Помогите, мои идеальные программы крешатся".
S>У меня ничего не крешится. Крешится из за "умных" указателей в урхо, криво прикрученных везде подряд.

"Сказ про то, как Шеридан в чужой монастырь со своим уставом ходил, или Туда и обратно".

Здравствуйте, Sheridan, Вы писали:

S>Дело было не в бобине.
S>Похоже, внутри urho3d отсутствуют проверки внутри их "умных" указателей. Причём они, похоже, это монго встроили везде куда могли дотянуться.
S>Что делаю:
S>

S>class cobject
S>{
S>  cobject () { buf = new urho3d::vertexbyffer(); }
S>  ~cobject () { delete buf; }
S>  urho3d::vertexbyffer *buf;
S>}
S>

S>Казалось бы — валидный код.

Перекрестись.

---
UPD. Я частично просмотрел ответы в этой подветке.

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

Я обычно пишу так (копирую из первого попавшегося файла):

class IBP_OLEDB_Props2__Handler__PrepareSetValue__Prop__ext_props
 :public IBP_OLEDB_Props2__Handler__PrepareSetValue
{
 private:
  typedef IBP_OLEDB_Props2__Handler__PrepareSetValue__Prop__ext_props   self_type;

  IBP_OLEDB_Props2__Handler__PrepareSetValue__Prop__ext_props(const self_type&); //без реализации
  self_type& operator = (const self_type&); //без реализации

Современные плюсы позволяют еще писать еще более конкретно:

  IBP_OLEDB_Props2__Handler__PrepareSetValue__Prop__ext_props(const self_type&)=delete;
  self_type& operator = (const self_type&)=delete;

В твоем cobject этого нет.

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

cobject x1;
cobject x2(x1); //x2 указывает на тот же buf что и x1

Соответственно она будет дважды удаляться.

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

cobject x1;
cobject x2;

x1=x2; //x1 потерял указатель на память, которую он выделил в конструкторе

Наверное это можно было отследить поставив точку прерывания в деструкторе.

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

И пришлось бы эти копирующие конструкции определять.

---
Тут по-моему советовали засунуть buf в смарт-указатель. Это решило бы проблему с освобождением памяти buf.

Но скорее всего создало бы другую — если предполагается, что cobject единственный владелец у памяти, на которую указывает buf.

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

Здравствуйте, Sheridan, Вы писали:

S>Но нафига в шаред реализовывать первую часть и в остальных объектах вторую часть умных указателей блин?

Интрузивный указатель же. Старая и известная всем идиома.

Здравствуйте, reversecode, Вы писали:

R>зачем люди занимаются то в чем они не разбираются или разбираются плохо ?
Ну захотелось админу попрограммировать, ты чем против?

Здравствуйте, wander, Вы писали:

W>Интрузивный указатель же. Старая и известная всем идиома.
Нарушать инкапсуляцию — бредовая идея. Объекты обязаны быть самодостаточными и явно требовать нужное им для жизни при инициализации.

Здравствуйте, Sheridan, Вы писали:

S>Нарушать инкапсуляцию — бредовая идея. Объекты обязаны быть самодостаточными и явно требовать нужное им для жизни при инициализации.

Она не нарушается. Работа со счетчиком ссылок — это часть контракта класса.
Смарт-пойнтер — использует этот контракт.
Примеры использования можно встретить в COM, CORBA, boost::intrusive, Ipopt, в некоторых игровых движках и много где еще.

Вы слишком самоуверенно судите о вещах, о которых узнали не больше недели назад.
А убеждение в собственной непогрешимости чести вам тоже не делает.
Хотя и понятно, что при наличии подобного убеждения, мои слова просто дадут вам еще +1 человека, которого вы сочтете идиотом.

Здравствуйте, wander, Вы писали:

S>>Нарушать инкапсуляцию — бредовая идея. Объекты обязаны быть самодостаточными и явно требовать нужное им для жизни при инициализации.

W>Она не нарушается. Работа со счетчиком ссылок — это часть контракта класса.
W>Смарт-пойнтер — использует этот контракт.
Говённые значит приёмы написания кода, которые нарушают логику. Контракты какието... Как эти контракты описываются в коде? Специфический синтаксис? Или просто "мы тут поговорили и решили!" (кто бы ни был этими "мы")?

W>Примеры использования можно встретить в COM, CORBA, boost::intrusive, Ipopt, в некоторых игровых движках и много где еще.
Там тоже нарушается инкапсуляция? Тоже один объект ВНЕЗАПНО думает что его используется совместно с другим, при этом "другой" никак не инициализируя или хотя бы проверяется жив ли?

W>Вы слишком самоуверенно судите о вещах, о которых узнали не больше недели назад.
Если я вижу говно — я говорю что это говно. Не приемлю фанатичную толерантность.

W>А убеждение в собственной непогрешимости чести вам тоже не делает.
Откуда это? Я гдето писал что непогрешим и что я истина в последней инстанции? о0

W>Хотя и понятно, что при наличии подобного убеждения, мои слова просто дадут вам еще +1 человека, которого вы сочтете идиотом.
Ещо одного человека, который привык к подобному поведению объектов. Но почему то считает что подобное поведение — хорошо.

Здравствуйте, Sheridan, Вы писали:

W>>Она не нарушается. Работа со счетчиком ссылок — это часть контракта класса.
W>>Смарт-пойнтер — использует этот контракт.
S>Говённые значит приёмы написания кода, которые нарушают логику. Контракты какието...
Вот о чем я и говорю. Безапелляционная, или, как вы говорите — фанатичная, уверенность в собственной правоте.
Я-то тут не свое личное мнение озвучиваю, а принятую практику на определенном классе задач.
Опять же, никто не говорит, что такое нужно везде и всегда, но и то, что это всегда безальтернативно "говно" — может говорить только очень самоуверенный человек.
Хотите разобраться — почитайте мотивацию для применения интрузивных объектов, благо, сейчас информация всем доступна через поиск.

S>Как эти контракты описываются в коде? Специфический синтаксис? Или просто "мы тут поговорили и решили!" (кто бы ни был этими "мы")?
У объекта есть функции: "увеличить счетчик" и "освободить себя", функция освобождения уменьшает счетчик и вызывает деаллокацию при его нуле.
Вы нарушили контракт объекта, начав владеть им без увеличения счетчика, за что и получили ошибку.
Понимаю, идиома может показаться сложной для неопытного* человека или неочевидной, но у нее есть области применения, обоснованные и признанные сообществом.
Критикуя ее на базе вашего недельного опыта — вы ставите под сомнение весь опыт сообщества и это выглядит крайне самонадеяно.
(И, пожалуйста, не надо возражать мне фразой про "миллионы мух", если кто-то сравнивает квалифицированных инженеров с мухами, то я даже не знаю на какой орбите его самооценка находится — думаю, где-то на уровне библейского Икара, который, все мы помним как закончил).

W>>Примеры использования можно встретить в COM, CORBA, boost::intrusive, Ipopt, в некоторых игровых движках и много где еще.
S>Там тоже нарушается инкапсуляция? Тоже один объект ВНЕЗАПНО думает что его используется совместно с другим, при этом "другой" никак не инициализируя или хотя бы проверяется жив ли?
Если объект предполагает совместное использование, то это не может являться нарушением его инкапсуляции.

W>>А убеждение в собственной непогрешимости чести вам тоже не делает.
S>Откуда это? Я гдето писал что непогрешим и что я истина в последней инстанции? о0
Конечно. Ошибку сделали вы, а виноваты вокруг все остальные

W>>Хотя и понятно, что при наличии подобного убеждения, мои слова просто дадут вам еще +1 человека, которого вы сочтете идиотом.
S>Ещо одного человека, который привык к подобному поведению объектов. Но почему то считает что подобное поведение — хорошо.
Не бывает такого "хорошо" или "плохо" — это же не религия. Бывает "уместно", "обосновано" или наоборот.
Естественно есть множество ситуаций, когда подобный объект будет не уместен.
Но то, что он был неуместен именно в данной ситуации еще нужно доказать, и явно не утверждениями "все это бред и глупость".
И даже если вы это докажете, это все равно не будет означать, что идиома "бредовая", а лишь только то, что ее в данной ситуации неверно
или небезопасно применили.

R>Правильно, потому, что у них любой класс, в том числе и этот вертексбуффер, заточен на использование с их умным указателем: Urho3D::SharedPtr. И выглядеть это, по их задумке, должно бы примерно так:

Непонятно только почему они оставили деструктор у RefCounted публичным. Иначе может и Шеридан не споткнулся бы об ручное разрушение объекта.

Хотя...))

Здравствуйте, std.denis, Вы писали:


SD>Непонятно только почему они оставили деструктор у RefCounted публичным. Иначе может и Шеридан не споткнулся бы об ручное разрушение объекта.

Как я догадываюсь, они допускали, все-таки, кастомное владение объектами и прямой доступ к управлению счетчиками ссылок. Включая возможность создания объектов на стеке и написание собственных умных указателей. По соображениям оптимизации и предоставлению пользователю большей гибкости. Но возможно и зря они это делали. Пользователь — это такой юзверь, который прострелит себе ногу и скажет, что виноват тот, кто сделал ружье.

SD>Хотя...))

Здравствуйте, Sheridan, Вы писали:

W>>Интрузивный указатель же. Старая и известная всем идиома.
S>Нарушать инкапсуляцию — бредовая идея. Объекты обязаны быть самодостаточными и явно требовать нужное им для жизни при инициализации.

Есть такое выражение — цивилизация потребления. Так вот, нужно создать потребителя данных создаваемого по запросу пользователя, но зависящего от третьей стороны. И создателя (отправителя) данных, который не владеет целью и которая, опять таки, не имеет прямой связи с временем жизни сервера (принимаемой стороны).

Наверное, как аналогию — можно привести TCP соединение, когда наши команды могут завершаться неудачей. Однако в случае прямой посылки сообщений (вызовов методов), нам нужно или владеть объектами или иметь механизм овладевать целью на время, для того, что отправлять те самые сообщения.

Даже, если, предположить, что время жизни можно сделать заранее известным (что, как правило, не так) — твой подход лишает систему типов (и нас программистов) об этом самом факте, кто там и чем владеет или не владеет.

По сути, я так понял, ты говоришь, что достаточно указателей. И формально, это правда — но лишь для исполнительной машины. Она кстати и указатель от натурального целого не отличает, не находишь это странным? Можно и указатель стереть из стстемы типов и это будет работать.

Но, т.к. мы люди — мы не можем знать о комментарии в начале файла, в конце файла или где-то между, не будем из все читать, видя просто указатель. Поэтому такого рода информация, всегда должна быть in-place, что смарт-поинтеры и дают.

Ну, это так, можно не отвечать, отвечать не буду все равно (не дотянусь).

С наступающим!