Russian Qt Forum
Май 02, 2024, 10:30 *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

Войти
 
  Начало Форум WIKI (Вики)FAQ Помощь Поиск Войти Регистрация  
  Просмотр сообщений
Страниц: 1 [2] 3 4 ... 33
16  Программирование / С/C++ / Re: C++ Object Token Library : Февраль 10, 2020, 16:06
Я вашим пользоваться точно не буду

если ты про emplace, то это не мой способ.
эта техника сегодня применяется повсеместно.

17  Программирование / С/C++ / Re: C++ Object Token Library : Февраль 10, 2020, 15:43
Ну и зачем потёрли свою сентенцию о том, что мои токены оказались на хрен не нужны? Улыбающийся Так я вам об этом сразу сказал. Решайте свои задачи, у меня другие.

решил, что излишняя эмоциональность не нужна.

у меня такое впечатление сложилось,
что ты занимаешься не задачами, а философией.

18  Программирование / С/C++ / Re: C++ Object Token Library : Февраль 10, 2020, 15:12
А если просто двигатель помощнее нужно установить взамен существующего? Или он сломался. Менять авто целиком? Очень практично Улыбающийся.

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

сломался двигатель?
ну так почини его.

менять сам объект для этого не нужно.

Код:
void clear_input()
{
    std::wcin.clear(),
    std::wcin.ignore(std::numeric_limits<std::streamsize>::max(), L'\n');

    assert(std::wcin);  // <--- и о боже! наш двигатель снова работает!
}

на практике, от иньекций зависимостей больше головняков, чем пользы.


В реальном приложении Car будет знать только об интерфейсе Engine,
и функциональность по созданию двигателя в авто может быть избыточной или вообще невозможной.

а! я понял.
ты просто не понимаешь, как работает emplace.
если хочешь, я тебе подробно расспишу как правильно готовят это блюдо.

если вкратце,
Car не нужно ничего знать ни о каких наследниках Engine
это никак не мешает сконструировать двигатель по месту.

Вы начинаете какие-то свои задачи придумывать и их решать. Вот эту конкретную с указанными требованиями можете решить? Впрочем, можете опять спросить: "А зачем это всё нужно?" Улыбающийся.

вот это поворот.

ты хотел машинку с кучкой мониторов, и 1 нерасшариваемым двигателем.
ты её получил.

ну и чего тебе не нравится?
19  Программирование / С/C++ / Re: C++ Object Token Library : Февраль 10, 2020, 14:20
Двигатель в BMW заменить на другой нельзя? Это как называется? Улыбающийся

я называю это "практичность"
нех лазить куда не надо.

хочешь двигатель от мерседеса - возьми мерседес.


ежели очень надо отхватить гемморой  сделать иньекцию зависимостей,
тогда вытащи в паблик метод setEngine<type of engine>(params...);

И здесь this->setEngine<BMW_Engine>() откуда двигатель берётся?

по месту (emplace) конструируется.
20  Программирование / С/C++ / Re: C++ Object Token Library : Февраль 10, 2020, 13:32
Я и не сомневался. Но там и другие требования есть. Например:
Один Engine можно установить только в один Car. Установка одного и того же Engine в несколько разных Car недопустима.

Как его соблюдать предлагаете?

Код:
class BMW: public Car
{
    BMW() { this->setEngine<BMW_Engine>(); }
};

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

это называется "инкапсуляция".



21  Программирование / С/C++ / Re: C++ Object Token Library : Февраль 10, 2020, 13:14
Ну так в однопоточной среде можно проверить еще раз:
...

Вот пример задачи Car. Даже для однопоточного варианта, какое решение предложите?

формулировка задачи: "один движок - много мониторов"
"один ресурс - множество потребителей" - привет, shared!



22  Программирование / С/C++ / Re: C++ Object Token Library : Февраль 10, 2020, 13:09
хочется держать сам юник в одном месте,
а вики на него - в 10 других местах.
А тут возникает следующая проблема. Мы держим сырой указатель на юник, а в процессе выполнения разрушается объект, который хранил этот юник и указатель становится не валидным. Улыбающийся

Придется добавлять свой умный указатель и шарить юник. Так зачем шарить юник если есть shared. Улыбающийся

ну вот они не хотят ничего не шарить.

а хотят просто получить вик с юника,
который им скажет: протух ресурс или нет?

Код:
if(weak)
    weak->work();  // то, что это не безопасно, их не смущает.



23  Программирование / С/C++ / Re: C++ Object Token Library : Февраль 10, 2020, 12:50
Зато если он протух, это признак того, что объект помер и можно выполнить соответствующие похоронные действия. Или ничего не делать. Вот и весь функционал expired, не более.
Ну так в однопоточном режиме expired юника как раз:
Код
C++ (Qt)
if( (auto p = unique_ptr.get()) )
{
 p->do();
 p->bar();
}
 
Пока вы контролируете поток исполнения вы видите в каком месте этот юник может умереть. И если такой момент присутствует, то просто проверяете валидность указателя после него еще раз.
В однопоточной среде с этим нет никаких проблем.



хочется держать сам юник в одном месте,
а вики на него - в 10 других местах.

и вот в этих местах нужно знать: протух ресурс, или нет.


грубо говоря, можно раздавать обычный сырой указатель на сам юник.
и через этот указатель спрашивать: "ты там живой ещё?"

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

Код:
auto*& example::get_weak()
{
    return &owner; // std::unique_ptr<some>
}







24  Программирование / С/C++ / Re: C++ Object Token Library : Февраль 10, 2020, 12:40
weak не контролирует время жизни ресурса.
то, что он ещё не протух, не значит, что не протухнет в след. мгновение.

Зато если он протух, это признак того, что объект помер и можно выполнить соответствующие похоронные действия. Или ничего не делать. Вот и весь функционал expired, не более.

его завезли только ради возможности не лочить шаред зазря.

если бы получение шареда было быстрым,
тогда expired бы сейчас не существовало.

25  Программирование / С/C++ / Re: C++ Object Token Library : Февраль 10, 2020, 12:19
Быстро же вы ответы изменяете )).

я пришел к выводу, что для std::unique_ptr нельзя без приседаний получить pointer&
а значит для поддержки expired потребуется совершить некоторые телодвижения.

сразу закономерный вопрос: нафига это нужно?

Я так понял: "зачем ... нужен?" - это ваш коронный вопрос. А зачем нужен std::weak_ptr::expired()?

очень правильный вопрос.
дело в том, что std::weak_ptr::expired() - это очень вредный метод

это - зло, ставшее причиной множества багов.

у этого зла есть имя: "функционал, который даёт ложное чувство безопасности"

я сам лично неоднократно встречал такой код:

Код:
if(!weak.expired())
    weak.lock()->work();  // <--- баг


weak не контролирует время жизни ресурса.
то, что он ещё не протух, не значит, что не протухнет в след. мгновение.


правильный код должен быть:

Код:
if(!weak.expired())
{
    auto shared = weak.lock();
    if(shared)
       shared ->work();  // <--- ok
}

только шаред может дать гарантию.

так зачем же все таки нужен метод weak_ptr::expired() ?
собака зарыта в методе lock.
lock лочит разделяемые между потоками данные shared.
что как известно - не бесплатно.

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

Код:
if(!weak.expired())  // <--- быстрая проверка
{
    auto shared = weak.lock();  // <--- медленный лок

    if(shared) // <--- окончательная проверка
       shared ->work();  // <--- можно работать
}




26  Программирование / С/C++ / Re: C++ Object Token Library : Февраль 10, 2020, 11:59
Используйте конкретный термин "not thread-safe" - ведь именно его Вы имели ввиду.
Даже если бы это и было так, это не может быть основанием "невозможности", просто пишем что данный класс/фича "not thread-safe",
и спокойно ее юзаем.
Да, если дело дойдет до multi-threading - придется прилагать усилия, лочить и.т.п.
Но это обычная работа которую приходится делать во многих случаях, нередко и с "продленным" weak.

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

Эту песню я слышал много раз.
Голые указатели = плохо. Давайте сделаем все указатели вумными! И будет счастье!
Ну а поскольку возможности юника на практическом нуле - остается делать все shared.
Вас не смущает что это чисто ход мысли начинающего?
Что давать такие советы не требует никакого (ну совсем никакого) ума?
Вы сами-то пробовали так делать? И что, хорошо получилось?
Может лучше поменять взад на голые?  Улыбающийся

ты вообще понимаешь зачем нужны умные указатели?
если умный указатель не даёт никаких приимуществ по сравнению с обычным сырым указателем,
то нахера он нужен?

Да, и чисто технически "продлить юник" несложно. Причем используя совершенно легальные средства предоставляемые std.
Несколькими постами выше ViTech кинул ссылочку, интересно - почитаете.

остановок "туда" и "здеся" не существует.
существуют только конкретные остановки.
и конкретные ссылки.




27  Программирование / С/C++ / Re: C++ Object Token Library : Февраль 10, 2020, 11:51
И где тут "weak становится expired, когда unique помирает"?

зачем он нужен?
28  Программирование / С/C++ / Re: C++ Object Token Library : Февраль 10, 2020, 11:35
А для однопоточного случая?

не плоди сущности без необходимости.

Код:
auto* weak = unique.get();
29  Программирование / С/C++ / Re: C++ Object Token Library : Февраль 09, 2020, 17:39
Хотите сказать, что не может существовать такая пара unique-weak, в которой weak становится expired, когда unique помирает?

хочу сказать, что невозможно организовать безопасный доступ к ресурсу юника через weak,
не сделав при этом сам юник шаредом.
30  Программирование / С/C++ / Re: C++ Object Token Library : Февраль 09, 2020, 17:35
В текущей реализации std - увы, обязательно. Никаких др способов получить weak нет.

смахивает на какой то бред.

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

ты никогда не думал о том, почему юник называется "юником" ?
Утверждается что владелец один (и только один). И что? Почему я не могу иметь любое число weak ("потребителей")?  Уникальности (единственности владения) это никак не противоречит.

в том то и дело, что противоречит.

ты вообще понимаешь, как работают с weak?

конкретно, ответь на вопрос:
почему напрямую через weak нельзя получить доступ к ресурсу,
а вместо этого приходится сначала расшаривать владельца?

Код:
#include <iostream>
#include <memory>

struct data
{
    int val = 333;
};

std::shared_ptr<data> holder = std::make_shared<data>();
 
int main()
{
    std::weak_ptr<data> weak = holder;
   
    // так нельзя
    // std::cout << "value = " << weak->val << '\n';
   
    // нужно сначала расшарить ресурс:
    std::shared_ptr<data> owner = weak.lock();     
    std::cout << "value = " << owner->val << '\n';
}

это связанно с тем, что поскольку weak не является владельцем,
то он не контролирует время жизни ресурса.
а значит, прямой доступ к ресурсу через него - всё равно что доступ через обычный голый указатель.
те же самые проблемы с безопасностью:
ресурс в любой момент может сдохнуть.
и потом ищи баги по всему коду.

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

однако в случае с unique_ptr, создание второго владельца противоречит самой идее существования юника.
хочешь рассшаривать - используй shared_ptr,
и не морочь голову ни себе, ни людям.


резюмируя:

если ты - наркоман, который не дружит с головой, тогда вот тебе твой weak специально для юника:

Код:
auto* weak1 = smart.get();
auto* weak2 = smart.get();
auto* weak3 = smart.get();

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

такие гарантии предоставляет shared_ptr

любая попытка сделать безопасный weak для юника приведет к тому,
что из юника получится shared

Страниц: 1 [2] 3 4 ... 33

Страница сгенерирована за 0.363 секунд. Запросов: 23.