Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
public enable_shared_from_this
|
|||
|---|---|---|---|
|
#18+
alexy_blackAnatoly Moskovskyalexy_black, То что вы предлагаете, подразумевает что каждый юзерский класс должен описывать friend для всех внутренностей shared_ptr. Это то что я назвал "через одно место" Хотели большей инкапсуляции, а получили полную зависимость от реализации shared_ptr.вот и выразили смысл моего первого поста. я бы хотел чтобы можно было добавить какой-нибудь класс в друзья и это бы гарантированно разрешало protected наследование. но в реале так нельзя сделать, потом учто полуится именно что через одно место. это проиходит не из-за ограничений языка, а из-за такой реализации enable_shared_from_this. а публичное наследование в некоторых случаях логически не верно. вот то, о чем я тут и пишу :) я вообще не понимаю ни одного слова из того, что ты пишешь. да, я не напрягаюсь и читать в метро, но других людей в такой ситуации я как правило понимаю. вообще, в чем проблема то наследования от ESFT? и ты все время путаешь случаи, когда нужно использовать SPtr и когда это не нужно вообще. даже больше - в твоем примере на сигнал об изменении нужна вообще ссылка, а не указатель. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.10.2016, 11:26 |
|
||
|
public enable_shared_from_this
|
|||
|---|---|---|---|
|
#18+
MasterZivя вообще не понимаю ни одного слова из того, что ты пишешь. вот жежешь! а что не понят-но то? MasterZivвообще, в чем проблема то наследования от ESFT? не просто наследования,а публичного наследования. если построить диаграмму, то получится, что, например, chevrolet ЕСТЬ (is a) estf. chevrolet is a car, но не estf. MasterZivи ты все время путаешь случаи, когда нужно использовать SPtr и когда это не нужно вообще. даже больше - в твоем примере на сигнал об изменении нужна вообще ссылка, а не указатель.да, можно и ссылку сделать. дело в сокритии информации. что если какому-то слоту понадобится указатель на сигнальщика? ему придется "знать" что это shared_ptr. таким образом эта информация не сокрыта. если передам ссылку, то слоты должны "знать", что нужно вызвать публичный метод shared_from_this для того, чтобы полуичть указатель. во, может так понятнее - нет сокрытия информации. обычно можно сдеать typedef и скрыть конкретный тип, но тут так не получится. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.10.2016, 11:46 |
|
||
|
public enable_shared_from_this
|
|||
|---|---|---|---|
|
#18+
alexy_blackне просто наследования,а публичного наследования. если построить диаграмму, то получится, что, например, chevrolet ЕСТЬ (is a) estf. chevrolet is a car, но не estf. Похоже на ООП головного мозга ))) Наследование это не всегда реализация отношений. За пределами ООП это иногда просто наиболее удобный инструмент среди всех доступных. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.10.2016, 13:29 |
|
||
|
public enable_shared_from_this
|
|||
|---|---|---|---|
|
#18+
alexy_blackMasterZivвообще, в чем проблема то наследования от ESFT? не просто наследования,а публичного наследования. если построить диаграмму, то получится, что, например, chevrolet ЕСТЬ (is a) estf. chevrolet is a car, но не estf.здесь нет противоречия. С точки зрения shared_prt - chevrolet есть esft, с точки зрения car: chevrolet есть car. C++ позволяет множественное наследование же, поэтому класс может себе позволить ЯВЛЯТЬСЯ в нескольких ипостасях )) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.10.2016, 15:27 |
|
||
|
public enable_shared_from_this
|
|||
|---|---|---|---|
|
#18+
alexy_blackему придется "знать" что это shared_ptr. таким образом эта информация не сокрыта. если передам ссылку, то слоты должны "знать", что нужно вызвать публичный метод shared_from_this для того, чтобы полуичть указатель. Какое ещё сокрытие информации может обеспечить простой указатель? Ты не данные и не методы по этому указателю рассматриваешь (должен рассматривать) в данном случае, а сам указатель. У тебя есть два классических способа сослаться в программе на объект: с помощью ссылки, и с помощью указателя. Сейчас появился ещё один способ -- с помощью умного (разделяемого) указателя. семантика при этом никак не меняется (меняется способ создания объекта, но тут он ни при чём)-- это просто указатель. О каком таком сокрытии информации тут может ещё идти речь ? Кроме этого, ещё раз, ты не понял, что тебе говорят. Если ты обрабатываешь где-то событие на изменение объекта по типу subject/observer, observer при обработке события обязан иметь валидную на всё время обработки этого события ссылку на subject, при этом ссылка эта обязана быть непустая. ПРи этом объект observer не должен управлять временем жизни объекта subject, и , в частности, не может его продлевать. отсюда следуют две вещи: ссылка должна быть ссылкой С++, а не указателем, потому что она дожна быть непустой. умный указатель тут применять не нужно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.10.2016, 17:44 |
|
||
|
public enable_shared_from_this
|
|||
|---|---|---|---|
|
#18+
egorychalexy_blackпропущено... не просто наследования,а публичного наследования. если построить диаграмму, то получится, что, например, chevrolet ЕСТЬ (is a) estf. chevrolet is a car, но не estf.здесь нет противоречия. С точки зрения shared_prt - chevrolet есть esft, с точки зрения car: chevrolet есть car. C++ позволяет множественное наследование же, поэтому класс может себе позволить ЯВЛЯТЬСЯ в нескольких ипостасях ))гы, прикольно :) я чего-то об этом не подумал. MasterZiv, почему обсервер не может продлить жизнь объекта? например происходит какое-то событие, observer хочет его обработать в потоке. как раз хорошо бы чтобы поток имел умный указатель на объект, потому что его жизнь может закончиться в другом потоке. под сокрытием информации я подразумевал сокрытие информации о том, какой указатель используется. раньше был единственный указатель, скрывать нечего, сейчас есть куча указателей, например boost::shared_ptr std::shared_ptr, intrusive_ptr, unique_ptr, собственная реализация.. если пользоваться только raw указатели и ссылки, то их легко друг ко другу преобразовывать. с умными указателями не так легко. получается, нужно обеспечить коду, который будет использовать указатель или ссылку возможность отказаться от преобразования. то есть если клиенсткому коду понадобится преобразовать объекты, он должен будет "знать" какой именно указатель используется и можно ли в него вобще преобразовать. универсального способа нет. легче просто отказаться от такого преобразования. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.10.2016, 13:15 |
|
||
|
public enable_shared_from_this
|
|||
|---|---|---|---|
|
#18+
alexy_blackMasterZiv, почему обсервер не может продлить жизнь объекта? попросту потому что это не его дело. если надо что-то обрабатывать в фоне, то следует вытянуть данные из модели, скопировать, и затем уже запускать с ними фоновый поток. но это уже выглядит очень странно. alexy_black, он должен будет "знать" какой именно указатель используется и можно ли в него вобще преобразовать. универсального способа нет. легче просто отказаться от такого преобразования. да, он ДОЛЖЕН будет знать, какой указатель используется. Просто обязан. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.10.2016, 21:32 |
|
||
|
|
start [/forum/topic.php?fid=57&msg=39323067&tid=2018413]: |
0ms |
get settings: |
11ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
71ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
46ms |
get tp. blocked users: |
1ms |
| others: | 17ms |
| total: | 177ms |
| 0 / 0 |
