crossplatform.ru

Здравствуйте, гость ( Вход | Регистрация )


  Ответ в weak_ptr from intrusive
Введите ваше имя
Подтвердите код

Введите в поле код из 6 символов, отображенных в виде изображения. Если вы не можете прочитать код с изображения, нажмите на изображение для генерации нового кода.
 

Опции сообщения
 Включить смайлы?
Иконки сообщения
(Опционально)
                                
                                
  [ Без иконки ]
 


Последние 10 сообщений [ в обратном порядке ]
Iron Bug Дата 17.4.2015, 11:24
  обычная схема перерисовки данных - это чтение данных по сигналу обновления виджета. поток, получающий данные, складывает их в память. а поток, который отрисовывает виджет, берёт их оттуда. и не нужно никаких сильных-слабых указателей и прочих велосипедов.
lanz Дата 16.4.2015, 18:17
 
Цитата
1. ну да.. а что в этом такого?

Ничего, если нет несинхронизированных сторонних эффектов.
Цитата
2. сам виджет thradsafe.

Ну это меняет все дело :lol:
Только нужно следить чтобы deadlockов не было. С очередью попроще.
alexy Дата 16.4.2015, 15:46
 
Цитата(lanz @ 16.4.2015, 16:15) *
1. При такой архитектуре вы можете удалить виджет из другого потока, создав его в одном. Фактически его удалит тот поток, который будет держать последний shared_ptr.

2. Обновлять данные из другого потока на виджете не безопасно. Вы уверенны что не придет событие отрисовки в середине вашего обновления?

Для многопоточной работы лучше исползуйте систему сообщений. Т.е. другой поток постит сообщение для отображения, а виджет смотрит - есть у него такой потомок или нет. Если нет, ничего страшного, если есть - информация безопасно обновляется. Разделяемые между потоками данные - это большая мина, с которой надо очень аккуратно обходится.


1. ну да.. а что в этом такого?
#include <thread>
int main() {
    int * i = new int(0);
    std::thread th([i](){delete i;});
    th.join();
}


2. сам виджет thradsafe. то есть даже если придет, ничего страшного, максимум данные потеряются. ну, вообще, это сам пользователь если ступит. то есть виджет же не рисуется прямо на мониторе, он передается по сети, там, у клиента, только один поток. так что если он исправляет значение виджета, не дожидается ответа сервера и начинает что-то еще править, то.. ну это как нажать кнопку сохранить, потом еще текст начать править.. он ведь не сохранится, если не нажать еще раз.

мне кажется с очередью сообщений труднее. сейчас у меня виджет содержит данные и мутекс, также функционал от widget_base - слабый казатель на родителя, который и так thread_safe
сообщения они передают клиенту по thradsafe каналу, то есть там мутекс перед тем как оправить данные, так что пользователю каша не придет.


кстати, не понял что-то функционала boost::intrusive_ptr если в конструкторе ему передать (some_raw_pointer, false). это же вызовет ошибку в деструкторе его. или intrusive_ptr_release нужно делать if(counter && --counter == 0) delete p;
lanz Дата 16.4.2015, 15:15
  1. При такой архитектуре вы можете удалить виджет из другого потока, создав его в одном. Фактически его удалит тот поток, который будет держать последний shared_ptr.

2. Обновлять данные из другого потока на виджете не безопасно. Вы уверенны что не придет событие отрисовки в середине вашего обновления?

Для многопоточной работы лучше исползуйте систему сообщений. Т.е. другой поток постит сообщение для отображения, а виджет смотрит - есть у него такой потомок или нет. Если нет, ничего страшного, если есть - информация безопасно обновляется. Разделяемые между потоками данные - это большая мина, с которой надо очень аккуратно обходится.
alexy Дата 16.4.2015, 15:04
 
Цитата(Iron Bug @ 16.4.2015, 15:29) *
если нужно делать сразу
std::shared_ptr<foo> sptr = shared_ptr<foo>(new foo());


проблема в том, что смешивать обычные указатели и shared_ptr хотя и можно чисто технически, но сильно не рекомендуется. ибо тогда вообще теряется смысл shared_ptr'а.


да, только при таком подходе я не смогу полчить shared_ptr в конструкторе, или у меня будут разные shared_ptr


тут проблема в моногопоточности.
например есть какой-то поток, который генерирует очень полезные цифры. он должен показывать их на клиенте (постоянное дуплексное соединение). у него есть слабый казатель на виджет, на какой-нибудь widget::label . когда у него появляется новое число, он берет сильный указатель, проверяет не здох ли виджет (смотри ли этот пользователь или уже закрыл все и свалил) и обновляет данные. в этот момент, пока обновляет, даже если пользователь закроет, виджет никуда не денется, т.к. указатель сильный. потом сильный казатель уходит и вижет может исчезнуть за время, пока его не нужно будет обновлять.

нет, дети не "владеют" родителем. они имееют слабый казатель на родителя. тут такое дело - если родителя прикончат в одном потоке, а другой поток в этот мемент работает с каким-нибудь ребенком и если ему нужно вызвать несколько методов... то у него могут прямо под носом убить объект с которым он работает и мутексы помочь не смогут, так как он берет указатель на объект и..
// плохо, если some_spin - raw pointer
int val = some_spin->value();
// тут другой поток убивает родителя...
if(!do_somthis(val)) some_spin->value(0);

а weak_ptr'а нет, если иметь дело с raw pointer
Iron Bug Дата 16.4.2015, 14:29
  а зачем делать
auto sptr_ = new foo();
std::shared_ptr<foo> sptr = sptr_->get_shared();


если нужно делать сразу
std::shared_ptr<foo> sptr = shared_ptr<foo>(new foo());


проблема в том, что смешивать обычные указатели и shared_ptr хотя и можно чисто технически, но сильно не рекомендуется. ибо тогда вообще теряется смысл shared_ptr'а.
lanz Дата 16.4.2015, 14:25
  shared_ptr подразумевает некую семантику - когда shared_ptr является членом класса, это значит что класс совместно владеет этим объектом вместе с кем-то. Когда у вас указатель parent shared_ptr, значит потомок владеет своим родителем.
Вот если родитель владеет(shared_ptr а то и unique_ptr) своим потомком, а потомок ссылается (raw pointer) на своего родителя, то нет никаких противоречий.
Единственное чтобы время жизни родителя перекрывало время жизни ребенка.

Цитата
ну, я ввел понятие токена. сессия без логина, не принимает никаких параметоров, сессия с логином, принимает строку токена, ну и не создается (throw login_error) если токен не верен.

В случае исключения никогда не вызовется деструктор сессии.




И насчет возврата из фабрики
http://herbsutter.com/2013/05/30/gotw-90-solution-factories/
alexy Дата 16.4.2015, 13:44
 
Цитата(lanz @ 16.4.2015, 10:33) *
Просто если логинится в конструкторе, то как обрабатывать ошибки?

ну, я ввел понятие токена. сессия без логина, не принимает никаких параметоров, сессия с логином, принимает строку токена, ну и не создается (throw login_error) если токен не верен.

я вот гуглил. виджеты, на сколько я понимаю, так создать нельзя. потому что везде они создаются обычным new. и действительно, у меня есть виджет, который содержит другие виджеты, то есть у него прямо в конструкторе создаются неслько других виджетов, которые он должен удалить когда удалится сам. как им указать родителя в конструкторе?

я просто делаю клиента html, сделал виджетами. один может содержать другой, но есть root - это как бы <html></html> и у него несколько виджетов - <head> <body> и пара других. изначально сделал widget_ptr, и метод parent возращает widget_ptr, но оказалось, что так не получится если я хочу создать в конструкторе виджеты, то есть если он составной.
мне кажется как-то не правильно создавать в фабричном методе внутренние детали виджета.

Цитата(Iron Bug @ 16.4.2015, 14:20) *
один фиг непонятно, чего хотели получить в итоге. а можно пример использования класса и что конкретно не получается?
можно создавать shared_ptr и использовать инициализацию в конструкторе, при этом можно в конструктор передавать shared_ptr'ы на другие объекты. можно через enable_shared_from_this создавать weak_ptr на себя и потом возвращать shared_ptr, полученный из this, через какой-то метод.

да, я об этом писал в первом посте. мне не нравится shared_from_this() то есть если он public, то выходит что это реализация в интерфейсе. я делаю его protected. но в конструкторе все равно не получается. то есть получится, если сделать какой-нибудь метод, get_shared, тогда выйдет
auto sptr_ = new foo();
std::shared_ptr<foo> sptr = sptr_->get_shared();

а сам get_shared, после первого использования должен сделать shared_to_this.release(); или что-нибудь в этом духе, чтобы остался только weak_to_this...

по мне лучше что-нибудь в таком духе (в конструкторе)
// в заголовочном файле
// typedef boost::intrusive_ptr<widget_base> widget_ptr;

root_widget::root_widget()
    : root_html_(new with_contenet()), body_(new with_content()), head_(new with_content())
{
    *root_html_ << *head_ << *body_;
    // shared_ptr здесь не передать
    //root_html _.parent(/*shared_from_*/this);

    // только пока с этим тоже облом - все равно будет вызванно intrusive_ptr_release
    // это баг в intrusive_ptr?
    boost::intrusive_ptr<widget_base> this_ptr (this, false);

    root_html_->parent(this_ptr); // здесь он преобразуется в weak_ptr
}

// в другом файле, где определяется with_content
widget_ptr with_content::parent() const
{
    return parent_.lock();
}
Iron Bug Дата 16.4.2015, 13:20
  один фиг непонятно, чего хотели получить в итоге. а можно пример использования класса и что конкретно не получается?
можно создавать shared_ptr и использовать инициализацию в конструкторе, при этом можно в конструктор передавать shared_ptr'ы на другие объекты. можно через enable_shared_from_this создавать weak_ptr на себя и потом возвращать shared_ptr, полученный из this, через какой-то метод.
lanz Дата 16.4.2015, 9:33
 
Цитата
может, я не совсем понимаю идею, но чем не устраивает make_shared, например?

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

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

Это как раз не страшно. Введите состояния сессии и отслеживайте их.
Просто если логинится в конструкторе, то как обрабатывать ошибки?
Просмотр темы полностью (откроется в новом окне)
RSS Текстовая версия Сейчас: 28.3.2024, 17:35