ReSQL.ru
     
powered by simpleCommunicator - 2.0.59     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / C++ [игнор отключен] [закрыт для гостей] / public enable_shared_from_this
25 сообщений из 33, страница 1 из 2
  1  все
public enable_shared_from_this
    #39317737
alexy_black
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
alexy_black
Участник
народ, вам не кажется, что шалон enable_shared_from_this сделан плохо?
от него надо наследоваться обязательно public, но это по большому счету не верно, ведь это больше деталь реализации. я бы хотел наследоваться от него только protected, что было бы логически верно.
например, если я пишу класс автомобиля, то мой авто - это не enable_shared_from_this, это например запорожец или ферари, но не enable_shared_from_this

в связи с этим я попытался сделать его protected, а в друзья добавить какой-нибудь класс, который это реализует. но я так понял, что это, в общем случаи, не возможно :(
вы не пробовали?
...
Рейтинг: 0 / 0
29.09.2016, 12:45
| Ответить | Цитировать | Написать  
public enable_shared_from_this
    #39317757
Фотография Anatoly Moskovsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Anatoly Moskovsky
Участник
alexy_blackнарод, вам не кажется, что шалон enable_shared_from_this сделан плохо?
от него надо наследоваться обязательно public, но это по большому счету не верно, ведь это больше деталь реализации. я бы хотел наследоваться от него только protected, что было бы логически верно.
Нет, не кажется.
Это не деталь реализации.
Объект поддерживающий shared_from_this например нельзя создавать на стеке, поэтому юзер класса должен об этом знать.
...
Рейтинг: 0 / 0
29.09.2016, 13:09
| Ответить | Цитировать | Написать  
public enable_shared_from_this
    #39317770
alexy_black
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
alexy_black
Участник
почему нельзя? если не вызывать shared_from_this то можно :)
а юзер узнает когда она упадет. все равно ведь чтобы это узнать ему нужно заглянуть в список наследования. а там он может увидеть и protected.

да и вобще, в таком случаи лучше сделать какой-нибудь атрибут, вроде on_heap_only или такой класс.
...
Рейтинг: 0 / 0
29.09.2016, 13:19
| Ответить | Цитировать | Написать  
public enable_shared_from_this
    #39318274
alex_k
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
alex_k
Участник
alexy_blackа юзер узнает когда она упадет.
Вот чтобы юзер этого не узнал,
Anatoly Moskovskyюзер класса должен узнать об этом на этапе компиляции.
...
Рейтинг: 0 / 0
30.09.2016, 06:02
| Ответить | Цитировать | Написать  
public enable_shared_from_this
    #39318922
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
[quot alexy_black]народ, вам не кажется, что шалон enable_shared_from_this сделан плохо?
от него надо наследоваться обязательно public, но это по большому счету не верно, ведь это больше деталь реализации

Нет, это не деталь реализации, а часть контракта интерфейса с клиентом данного класса, поэтому наследование
должно быть публичным.
...
Рейтинг: 0 / 0
30.09.2016, 19:09
| Ответить | Цитировать | Написать  
public enable_shared_from_this
    #39320160
alexy_black
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
alexy_black
Участник
MasterZivконтракта интерфейса с клиентом данного классане понял. то есть если клиенты никогда не вызывают shared_from_this, эта функция вызывается только внутри класса?

например я могу определить что-нибудь в духе
Код: plaintext
1.
2.
class my_super_class;
typedef std::shared_ptr<my_super_class> my_super_class_ptr;

дальше я могу юзать это определение и не знать какой именно там указатель, а просто знать, что он не протухнет, пока он у меня есть.
но потом дизан программы может измениться, и он не протухнет в любом случаи, так что я могу там поставить просто
Код: plaintext
1.
2.
class my_super_class;
typedef my_super_class* my_super_class_ptr;

или могу определить его как unique_pt r или intrussive_ptr . клиентам должно быть все равно какой это указатель, они же просто вызывают функции сущности (разумеется, за исключением фабрики, например).
(если использовать unique_ptr, то нужно передавать его как rvalue, но так же можно передавать и shared_ptr, это даже эффективнее).
...
Рейтинг: 0 / 0
04.10.2016, 11:25
| Ответить | Цитировать | Написать  
public enable_shared_from_this
    #39320172
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
alexy_blackMasterZivконтракта интерфейса с клиентом данного классане понял. то есть если клиенты никогда не вызывают shared_from_this, эта функция вызывается только внутри класса?



Наоборот.

Что ты понимаешь под "контрактом класса" или "интерфейсом" ?
Погугли, почитай.
...
Рейтинг: 0 / 0
04.10.2016, 11:37
| Ответить | Цитировать | Написать  
public enable_shared_from_this
    #39320197
alexy_black
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
alexy_black
Участник
про контракты я заню. только в чем тут контракт?

вот например такой класс не нарушит принципа лиски какой бы указатель тут ни использовался.
Код: plaintext
1.
2.
3.
4.
5.
6.
class some {
public:
  some(foo_ptr&& f);
private:
  foo_ptr foo_field_;
};

дальше такой класс может использовать foo_ptr вызываея его методы и все. классу some не нужно знать что foo_field_ - shared_ptr или еще что-нибудь в этом духе. у него есть указатель и ему без раницы какой он.
если например это shared_ptr то перемещение будет полезным, потому что при копировании должно атомарно увеличится значение счетчика, а так просто перемащает указатель.

зачем классу foo иметь публичного предка std::enable_shared_from_this<foo>, если он, например, вызывает shared_from_this только в одной из своих приватных функций?

выходит, я могу, как бы, создать шаблонну функцию принимающюю ссылку на объект std::enable_shared_from_this<T> и вызывать для него shared_from_this. но если я захочу провести рефакторинг, то мне придется это менять.
...
Рейтинг: 0 / 0
04.10.2016, 12:04
| Ответить | Цитировать | Написать  
public enable_shared_from_this
    #39320394
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
alexy_blackпро контракты я заню. только в чем тут контракт?

В том, что ты даёш пользователю возможность вызвать с экземпляром класса метод shared_from_this
...
Рейтинг: 0 / 0
04.10.2016, 16:15
| Ответить | Цитировать | Написать  
public enable_shared_from_this
    #39320404
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
alexy_black
вот например такой класс не нарушит принципа лиски какой бы указатель тут ни использовался.


Принцип Лисков тут ни при чём.

alexy_blackдальше такой класс может использовать foo_ptr вызываея его методы и все. классу some не нужно знать что foo_field_ - shared_ptr или еще что-нибудь в этом духе. у него есть указатель и ему без раницы какой он.
если например это shared_ptr то перемещение будет полезным, потому что при копировании должно атомарно увеличится значение счетчика, а так просто перемащает указатель.

зачем классу foo иметь публичного предка std::enable_shared_from_this<foo>, если он, например, вызывает shared_from_this только в одной из своих приватных функций?

выходит, я могу, как бы, создать шаблонну функцию принимающюю ссылку на объект std::enable_shared_from_this<T> и вызывать для него shared_from_this. но если я захочу провести рефакторинг, то мне придется это менять.


У тебя тут в примере нет класса, который наследуется от std::enable_shared_from_this .
Так что обсуждать нечего.

И, боюсь, в твоей голове всё очень сильно перемешано, до возникновения лёгкого бардачка...

авторзачем классу foo иметь публичного предка std::enable_shared_from_this<foo>, если он, например, вызывает shared_from_this только в одной из своих приватных функций?

Если классу foo надо вызывать shared_from_this только внутри реализаций своих методов, то очевидно, что это -- фиксированный определённый скоуп, и там shared_ptr просто не нужен вообще. Если shared_from_this вызывается в реализации методов, а результат отдаётся наружу, то это уже становится частью интерфейса этого класса.
Да, в таком случае можно наследоваться от std::enable_shared_from_this непублично.
...
Рейтинг: 0 / 0
04.10.2016, 16:25
| Ответить | Цитировать | Написать  
public enable_shared_from_this
    #39320551
Фотография Anatoly Moskovsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Anatoly Moskovsky
Участник
Господа, о чем вы спорите?
Класс, имеющий enable_shared_from_this, по-другому обрабатывается классом shared_ptr, причем это делается именно за счет того что enable_shared_from_this это публичный интерфейс, т.е. существует неявная конверсия к нему.
Так что можно закрыть этот интерфейс, но тогда shared_ptr придется делать через одно место ))
...
Рейтинг: 0 / 0
04.10.2016, 19:27
| Ответить | Цитировать | Написать  
public enable_shared_from_this
    #39320582
alexy_black
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
alexy_black
Участник
класс some я привел в качестве примера использования указателя на какой-то объект. этому классу по баробану какой там указатель и является ли foo enable_shared_from_this или нет.. это пример того, что не обязательно такое должно быть в контракте.

предположим у меня есть foo. я могу получать сигнал о том, что объект foo именился. в сигнале я бы хотел получить указатель на foo. для этого foo может держать у себя сигнал, и когда изменится активировать его. но вопрос - а что передать в параметрах?
если передавать foo*, а мне потом понадобится shared_ptr<foo>, то да, я могу вызвать f->shared_from_this(). но это коряво - что если я потом захочу не shared_ptr использовать, а что-нибудь другое? если передавать сразу shared_ptr, то мне нужно наследоваться публично от std::enable_shared_from_this. и никакой это ни локальный скоуп.

вот к примеру
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
class foo;
typedef std::shared_ptr<foo> foo_ptr;
class foo : public std::enable_shared_from_this<foo> {
public:
 typedef boost::signals2::signal<void (foo_ptr)> change_signal;

 foo();

 void change(int i) {
   // set some field to i
   // как тут вызывать ch_sign_ ?
   // вот для этого метода мне понадобится унаследоваться от std::enable_shared_from_this<foo>
   // я бы хотел унаследоваться protected, но получится только public, иначе не скомпилится.
   ch_sign_(shared_from_this());
 }

 boost::signals2::connection on_change(const change_signal::slot_type& slot);
protected:
 using std::enable_shared_from_this<foo>::shared_from_this;
private:
 change_signal ch_sign_;
};

тут все работает, но смущает что это foo "есть" std::enable_shared_from_this, до чего другим классам и дела нет. это типичный случай, когда нужно делать наследование protected.
публичное наследование хорошо подходит, если хочешь всем сообщить, что ты всегда будешь заворачиваться в shared_ptr. но если ты хочешь одним typedef'ом поменять место, куда будешь заворачивать объект, тогда лучше наследоваться protected, так ты говоришь, что это деталь реализации. но stl этого не позволяет. как и boost.
...
Рейтинг: 0 / 0
04.10.2016, 20:55
| Ответить | Цитировать | Написать  
public enable_shared_from_this
    #39320583
alexy_black
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
alexy_black
Участник
Anatoly Moskovsky, что определяет что это через "одно место"? просто тебе нужно где-нибудь внутри класса получить shared_ptr на себя.

если какой-то оъект имеет другие объекты, контейнер как бы. при добавлении к нему объекта, возомжно, нужно будте передать ему указатель на себя, чтобы он мог сделать из него weak и хранить у себя. для этого внутри класс тебе понадобится получить shared_ptr на this. вот почему бы и не наследоваться protected в таком случаи?
...
Рейтинг: 0 / 0
04.10.2016, 21:02
| Ответить | Цитировать | Написать  
public enable_shared_from_this
    #39320599
Фотография Anatoly Moskovsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Anatoly Moskovsky
Участник
alexy_black,

Я же объяснил выше уже.
У класса реализующего shared_from_this есть как минимум один гарантированный пользователь - это конструктор класса shared_ptr. И ему для работы нужно чтобы наследование от enable_shared_from_this было публичным, т.к. он работает с объектом через интерфейс enable_shared_from_this .
...
Рейтинг: 0 / 0
04.10.2016, 21:59
| Ответить | Цитировать | Написать  
public enable_shared_from_this
    #39320618
alexy_black
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
alexy_black
Участник
Anatoly Moskovskyalexy_black,

Я же объяснил выше уже.
У класса реализующего shared_from_this есть как минимум один гарантированный пользователь - это конструктор класса shared_ptr. И ему для работы нужно чтобы наследование от enable_shared_from_this было публичным, т.к. он работает с объектом через интерфейс enable_shared_from_this .
да, вот я об этом и говорю. а я хочу чтобы оно было protected. я даже готов добавить этот конструктор в друзья. но так не получяется :(
ну или я что-то не так делаю. там какие-то уродские шаблонные классы нужно добавлять, и, я так понял, они специфичны для реализации библиотеки.
...
Рейтинг: 0 / 0
04.10.2016, 23:28
| Ответить | Цитировать | Написать  
public enable_shared_from_this
    #39320622
Фотография Anatoly Moskovsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Anatoly Moskovsky
Участник
alexy_blackа я хочу чтобы оно было protected
Это невозможно реализовать.
Для того чтобы shared_ptr имел доступ к полям и функциям внутри enable_shared_from_this через наследник S (а это нужно потому что именно shared_ptr инициализирует в объекте ссылку), должно существовать преобразование от S* к enable_shared_from_this<S>* , а это возможно только если наследование публичное.
...
Рейтинг: 0 / 0
04.10.2016, 23:51
| Ответить | Цитировать | Написать  
public enable_shared_from_this
    #39320974
alexy_black
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
alexy_black
Участник
Anatoly Moskovskyalexy_blackа я хочу чтобы оно было protected
Это невозможно реализовать. ... это возможно только если наследование публичное.вы прочитали что я писал?
 
опа
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
#include <iostream>

class base {
    public:
        void do_some() {std::cout<<"base::do_some"<<std::endl;}
};

class drived;
void foo(drived& d);
class drived : protected base {
    friend void foo(drived& b);
    public:
        void so_nothing(){}
};

void foo(drived& d) {
    d.do_some();
//    ^^^^^^^
    base& b = d;
    b.do_some();
}

int main(int,char**){
    drived d;
    foo(d);
    return 0;
}

...
Рейтинг: 0 / 0
05.10.2016, 13:11
| Ответить | Цитировать | Написать  
public enable_shared_from_this
    #39321016
Фотография Anatoly Moskovsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Anatoly Moskovsky
Участник
alexy_black,
То что вы предлагаете, подразумевает что каждый юзерский класс должен описывать friend для всех внутренностей shared_ptr.
Это то что я назвал "через одно место"
Хотели большей инкапсуляции, а получили полную зависимость от реализации shared_ptr.
...
Рейтинг: 0 / 0
05.10.2016, 13:44
| Ответить | Цитировать | Написать  
public enable_shared_from_this
    #39321068
alexy_black
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
alexy_black
Участник
Anatoly Moskovskyalexy_black,
То что вы предлагаете, подразумевает что каждый юзерский класс должен описывать friend для всех внутренностей shared_ptr.
Это то что я назвал "через одно место"
Хотели большей инкапсуляции, а получили полную зависимость от реализации shared_ptr.вот и выразили смысл моего первого поста.
я бы хотел чтобы можно было добавить какой-нибудь класс в друзья и это бы гарантированно разрешало protected наследование. но в реале так нельзя сделать, потом учто полуится именно что через одно место. это проиходит не из-за ограничений языка, а из-за такой реализации enable_shared_from_this.

а публичное наследование в некоторых случаях логически не верно.

вот то, о чем я тут и пишу :)
...
Рейтинг: 0 / 0
05.10.2016, 14:35
| Ответить | Цитировать | Написать  
public enable_shared_from_this
    #39321112
Фотография Anatoly Moskovsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Anatoly Moskovsky
Участник
alexy_blackэто проиходит не из-за ограничений языка, а из-за такой реализации enable_shared_from_this.
Нет, это происходит от того что вы не понимаете как устроен shared_ptr ))
...
Рейтинг: 0 / 0
05.10.2016, 15:17
| Ответить | Цитировать | Написать  
public enable_shared_from_this
    #39321119
alexy_black
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
alexy_black
Участник
Anatoly Moskovsky,

и чего же я не понимаю?
...
Рейтинг: 0 / 0
05.10.2016, 15:21
| Ответить | Цитировать | Написать  
public enable_shared_from_this
    #39321152
Фотография Anatoly Moskovsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Anatoly Moskovsky
Участник
alexy_blackи чего же я не понимаю?
Того, что там гораздо больше функциональности чем в том примитивном примере что вы привели и она разнесена по многим классам и функциям.
И никто не будет заставлять юзера разбираться где какие friend ставить, и в прочие детали реализации вникать.
А вы можете и дальше думать что это ограничения )))
...
Рейтинг: 0 / 0
05.10.2016, 15:47
| Ответить | Цитировать | Написать  
public enable_shared_from_this
    #39321268
alexy_black
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
alexy_black
Участник
думаю можно создать шаблонный класс для нужд shred_from_this, который и объявить другом. это не добавит реального ассемблерного кода (потому что функция из одной строчки просто встроится), но зато разрешит protected наследование.

Anatoly Moskovsky, у меня склдывается впечатление, что вы то, что я пишу читаете по диагонали, и отвечаете на недочитанные предложения.
...
Рейтинг: 0 / 0
05.10.2016, 17:53
| Ответить | Цитировать | Написать  
public enable_shared_from_this
    #39321278
Фотография Anatoly Moskovsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Anatoly Moskovsky
Участник
alexy_black,

Я вам еще раз говорю прямым текстом. Дизайн, где в пользовательском коде требуется оператор friend для служебного кода - ужасный. Именно поэтому так как вы хотите создатели этой либы не сделали и не будут делать.
...
Рейтинг: 0 / 0
05.10.2016, 18:06
| Ответить | Цитировать | Написать  
public enable_shared_from_this
    #39321468
alexy_black
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
alexy_black
Участник
например было бы круто
Код: plaintext
1.
2.
3.
4.
5.
class foo : protected std::enable_shared_from_this<foo> {
  friend class std::shared_from_this_enablie<foo>;
public:
  // ...
};


что-то подобное используют для сериализации например иногда.

Anatoly Moskovsky, так мое впечатление было правильным? :)
...
Рейтинг: 0 / 0
05.10.2016, 23:39
| Ответить | Цитировать | Написать  
25 сообщений из 33, страница 1 из 2
  1  все
Форумы / C++ [игнор отключен] [закрыт для гостей] / public enable_shared_from_this
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]