Так передавай

правда?))) точно this, а не weak_ptr на this с проверкой в лямбде?))

правда?))) точно this, а не weak_ptr на this с проверкой в лямбде?))

зависит же от того, можно гарантировать что this будет жить или нет

зависит же от того, можно гарантировать что this будет жить или нет

можно гарантировать, что если this содержит future<T> в котором есть onSuccess, то этот onSuccess не переживет this

Я мб чего то забыл, но разве нельзя сделать MessageBox забитый NULL вместо хендлов и инстансов?

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

можно гарантировать, что если this содержит future<T> в котором есть onSuccess, то этот onSuccess не переживет this

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

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

я как раз и спрашивал, есть ли такие гарантии у вас)

у нас в 99% случаев есть гарантия что this живет дольше, да. В остальом 1% придется вик, но мы этот 1% пока не встретили

эта гарантия должна даваться реализацией future<T>

при условии выполнения onSuccess в том же потоке, который владеет this

в какой-нить generic либе - наверно

у нас - похер вообще, мы же не делаем дженерик либу с футурами

я плохо понимаю тогда, что вы пишете и, главное, что вы собираетесь рассказывать профессиональным С++ разработчикам)

там специально даже в заголовке написано про велосипеды в продакшене. Речь про in-house решение. Знаешь, есть такая категория докладов, про наступание на грабли и их мужественное преодолевание. Вот это примерно так же

Вангую, что твой фьючер не дает умирать this именно из-за шаредптра

это мне или Константину?

Константину

Вангую, что твой фьючер не дает умирать this именно из-за шаредптра

У меня в коде концепция, что shared_ptr последнее дело

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

не только у тебя, не только у тебя

я пока совершенно не понял специфику вашей задачи

в которой нет вопросов с умирающими this)

задачи в целом? или зачем нам фьючеры? или почему мы живем на этом свете?

У меня в коде концепция, что shared_ptr последнее дело

В коде должна быть только одна концепция - стабильная и оптимальная работа приложения. Любыми способами и методами

задачи в целом? или зачем нам фьючеры? или почему мы живем на этом свете?

почему this?

зачем нам this в хендлерах? потому что в большинстве случаев этот this - объект, характеризующий бекенд или его составную часть. Короче то, что содержит средства обратной коммуникации с фронтендом и что живет пока живо приложение

В коде должна быть только одна концепция - стабильная и оптимальная работа приложения. Любыми способами и методами

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

зачем нам this в хендлерах? потому что в большинстве случаев этот this - объект, характеризующий бекенд или его составную часть. Короче то, что содержит средства обратной коммуникации с фронтендом и что живет пока живо приложение

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

прямо таки ни одной точки отзыва?

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

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

что-то у вас прямо пони на радуге какие-то)

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

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

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

у нас такие вещи обычно в облаке делаются

не на клиенте

да ну там любая картинка в файл кодируется

и файл надо сразу отпускать, ибо нехрен блокировать файл при отмене

мы не обрабатываем изображения на клиентах, только в сервисах, возможно это нас спасает

а это точно разумно?)

быстрее отправить на сервер и получить назад?)

ну у нас обработка изображений только тех, что пришли с других сервисов

у нас нет обработки того, что юзер загрузил. У нас юзеры потому что - работники фабрик

а зачем вам вообще плюсы локальные?

потому что кьют

а почему не полностью managed все?

в смысле

я что-то не знаю в современных реалиях?

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

у нас референс платформы - линукс десктопы и андроид телефоны. Изначально был линукс и винда

шарп я просто люто бешено ненавижу

осталась джавка

писать на джаве гуй - то еще удовольствие

понял

но вообще это странный вопрос имхо. Он сокрее потому что так повелось и были такие люди

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

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

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

лол, нет, спасибо, если там у тебя мфц, то без вариантов

мы винду вообще почти не поддерживаем сейчас

лол, нет, спасибо, если там у тебя мфц, то без вариантов

мфц используется как прослойка на винду

там над ней лежит реактивная модель с чисто фунциональными рендерерами)

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

я плохо представляю, что творится в куте

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

ERROR: S client not available

ну тогда как-то странно отправлять его на помойку вот так категорично, как мне кажется

я плохо представляю, что творится в куте

краткий экскурс https://qmlbook.github.io/

ну тогда как-то странно отправлять его на помойку вот так категорично, как мне кажется

ну я точно уверен, что qt реализует сигнал-слотовую модель для записи настроек

каких настроек

ну вот например, у меня есть кнопка и я хочу ей условный enable/disable прописать по условию со сложной функцией проверки данных формы

функция сложная, т.е. я прямо таки хочу её в коде писать, а не как-там-в-qml-это-пишется-в-xml

кумль это код, а не xml, если что

ну скажем, она хочет произвести RSA-декодирование одного из параметров формы

и проверить, что там написано

пускай запрашивает у бекенда плюсового это, да и все

ответ получит сигналом

примерно псеводкод можно?)

псевдокод чего?

ну как примерно это пишется в итоге на куте

с бекэндом

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

у меня это пишется button is-enabled="#function(такая-то-функция)" где такая-то-функция пишется как "вернуть результат вызова вот этой функции с вот этими параметрами формы"

последнее в C++ коде

вот один из вариантов, как это делается в кьюте http://doc.qt.io/qt-5/qtqml-cppintegration-topic.html

краткий экскурс https://qmlbook.github.io/

*утащил*

вот один из вариантов, как это делается в кьюте http://doc.qt.io/qt-5/qtqml-cppintegration-topic.html

тут разница в том, что с точки зрения qt есть сигнал изменения состояния кнопки, а с точки зрения моей модели состояние кнопки это реактивное значение

вы не можете ошибиться в записях типа emit userNameChanged(); просто потому, что таких записей вообще нет

Добрый вечер, подскажите , кто пишет на qt , как вывести в окно, какой нибудь результат выражения типа int a+int b , чтобы при нажатии на клавишу выводился результат этого выражения, что можно использовать, просто я новичок а очень нужно

тут разница в том, что с точки зрения qt есть сигнал изменения состояния кнопки, а с точки зрения моей модели состояние кнопки это реактивное значение

ну сигналы это низкий уровень, на уровень выше в кумле свойства и их биндинги. То есть, если ты напишешь text: objA.first + "-" + objB.second где first и second - свойства плюсовых или кумльных объектов, то при их изменении text тоже изменится

ну сигналы это низкий уровень, на уровень выше в кумле свойства и их биндинги. То есть, если ты напишешь text: objA.first + "-" + objB.second где first и second - свойства плюсовых или кумльных объектов, то при их изменении text тоже изменится

у меня аналогично можно писать в C++ коде

ну вот видишь

здесь разница

зачем тогда выбрасывать кьют

Добрый вечер, подскажите , кто пишет на qt , как вывести в окно, какой нибудь результат выражения типа int a+int b , чтобы при нажатии на клавишу выводился результат этого выражения, что можно использовать, просто я новичок а очень нужно

попробуй еще @supapro, я не понял что же ты в итоге хочешь. это вопрос не для этого чата, в любом случае

зачем тогда выбрасывать кьют

разница в том, что у меня нет одного лишнего языка с динамическим выполнением