А вот это совершенно нет. Хотя я не знаю, какую модель вы реализуете

Ну у меня больше про фп часть. У нас фьючеры по интерфейсу скопированы из скалы

Ну у меня больше про фп часть. У нас фьючеры по интерфейсу скопированы из скалы

Интерфейс интерфейсами, модель моделями. Смотрите. Вот я храню future<T>, я имею право без дополнительных делать BIND_THIS на future::then?

Что такое bind this и что такое then. А то у всех разная терминология. Бинд это как в хачкеле бинд?

Что такое bind this и что такое then. А то у всех разная терминология. Бинд это как в хачкеле бинд?

Ладно, окай. У меня диаложек хочет по кнопке от пользователя пингануть сайт и потом плюнуть MessageBox с результатом. Чистая функция ping_result ping(url) прилагается. Как это пишется в вашей модели?

pingUrl->onSuccess, если нужен только сайдэффект. Показ мессаджбокса вроде как раз оно и есть, никаких преобразований не надо, дальше никуда отдавать не надо

pingUrl->onSuccess, если нужен только сайдэффект. Показ мессаджбокса вроде как раз оно и есть, никаких преобразований не надо, дальше никуда отдавать не надо

теперь у нас кнопка "пинговать" дизаблится во время выполнения пинга и энаблится при завершении

теперь у нас кнопка "пинговать" дизаблится во время выполнения пинга и энаблится при завершении

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

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

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

а, у нас нет таких проблем. Что может умереть - в викпоинтерах. UI - вообще кумль, туда тупо уходит сигнал, если кто-то умер и не получил - его проблемы

а, у нас нет таких проблем. Что может умереть - в викпоинтерах. UI - вообще кумль, туда тупо уходит сигнал, если кто-то умер и не получил - его проблемы

т.е. у вас все классы обернуты на maybe? печально вам)

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

т.е. у вас все классы обернуты на maybe? печально вам)

В смысле? Это нормальное

В смысле? Это нормальное

конечно же нет

Поведение - писать плбсовый код на шаредах

shared_ptr не является значением, он является указателем

конечно же нет

Поэтому у тебя какой-то пиздец а у всех "ненормальных" все работаете и они уже начали пить пиво

Поэтому у тебя какой-то пиздец а у всех "ненормальных" все работаете и они уже начали пить пиво

У меня нет никакого пиздеца)

Поэтому у тебя какой-то пиздец а у всех "ненормальных" все работаете и они уже начали пить пиво

я еще даже утренний офисный кофе не налил :)

Поэтому у тебя какой-то пиздец а у всех "ненормальных" все работаете и они уже начали пить пиво

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

Чувак, ты пишешь на чем? Кути?

Не, я не пишу на куте

А на чем? Диалоги чем показываешь?

Немного велосипедов над MFC

С реактивной моделью

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

у чуваков с qtшной моделью реактивности никаких проблем нет с этим

Более того - твоя ситуация совсем простая. Показывай сообщение, только если диалог жив. Ибо нормальные люди не ждут ответ в таком кейсе, когда диалог закрыт

у чуваков с qtшной моделью реактивности никаких проблем нет с этим

Это вот

Более того - твоя ситуация совсем простая. Показывай сообщение, только если диалог жив. Ибо нормальные люди не ждут ответ в таком кейсе, когда диалог закрыт

Ну т.е. по-вашему все оконные компоненты должны быть shared_ptr? Кажется, вы пришли с явы)

Ну т.е. по-вашему все оконные компоненты должны быть shared_ptr? Кажется, вы пришли с явы)

у нас нет плюсовых оконных компонентов :D у нас кумль вообще

Только идиоты, пишущие на Си забывают предоставить процедурную обертку для жабы для чтения тега из xml

Только идиоты, пишущие на Си забывают предоставить процедурную обертку для жабы для чтения тега из xml

уточни контекст твоего высказывания.

сегодня с ужасом обнаружил, что разрабы процедурного API на си для чтения xml забыли очень важное поле.

а я уж обрадовался - не нужно на шарпе собственный парсер писать

а что забыли и что за либа-то

у нас нет плюсовых оконных компонентов :D у нас кумль вообще

В этом вся и фишка, вы хотите скалу из плюсов сделать

В этом вся и фишка, вы хотите скалу из плюсов сделать

потмоу что юзаем кумль?

потмоу что юзаем кумль?

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

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

не вижу ничего плохого в смеси парадигм, если честно

не вижу ничего плохого в смеси парадигм, если честно

это не смесь парадигм, это портирование managed парадигмы в язык, в котором есть деструкторы)

это не смесь парадигм, это портирование managed парадигмы в язык, в котором есть деструкторы)

эм, мы все еще про плюсы говорим? особенно, если кьют юзать. Где своя система парентов для автоудаления. И где есть шареды

но нет, у нас много деструкторов и ручного вызова delete на самом деле

эм, мы все еще про плюсы говорим? особенно, если кьют юзать. Где своя система парентов для автоудаления. И где есть шареды

кто сказал, что разработчики кути не сделали то же самое

просто это локализовано

но нет, у нас много деструкторов и ручного вызова delete на самом деле

ручной вызов delete это не про плюсы

там, где нет разделенной работы с ресурсами

а что забыли и что за либа-то

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

короче я вообще не понимаю в чем претензия-то. В том, что фьючеры с преобразованиями? В том что шареды юзаем? В том что кьют используем?

нет, в том, что в плюсы портируете схемы работы не плюсов

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

и optional

но у нас и так половины из перечисленного нет...

никто не говорит, что для плюсов лямбды, концепты и вообще функциональные идеи являются не родными

но как только вы мне говорите, что вас не волнует время жизни обработчика onSuccess, вы пытаетесь managed C++ написать

Ну т.е. по-вашему все оконные компоненты должны быть shared_ptr? Кажется, вы пришли с явы)

При чем тут окна. Окна не должны.

Потому что оно никого не волнует.

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

а не на хранимках

Потому что оно никого не волнует.

Волнует, MessageBox нельзя показывать без родительского окна

Обработчик или есть - или нет. Это не действие, которое требует ожидания ответа

А, хотя вы пишете на куте, возможно, вам можно ?

Волнует, MessageBox нельзя показывать без родительского окна

Нам можно

Нам можно

Угу, кутя же не поддерживает винду

Лол, че

Еще бы. Линукс онли

ERROR: S client not available

Лол, че

Ну в куте можно, а в винде нельзя)

А, хотя вы пишете на куте, возможно, вам можно ?

нам даже больше чем можно, нам вообще пофиг чо там фронтенд не на плюсах делает. Дело плюсового бекенда маленькое - ответить сигналом на запрос. Поймали-не поймали - проблемы фронтенда и шерифа не волнуют

Потому что позиционирование по монитору надо вычислять

нам даже больше чем можно, нам вообще пофиг чо там фронтенд не на плюсах делает. Дело плюсового бекенда маленькое - ответить сигналом на запрос. Поймали-не поймали - проблемы фронтенда и шерифа не волнуют

ну вот у вас и получается managed C++ потому что у вас mixed разработка и managed концепции вам роднее

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

У нас просто реальная разработка.

А у меня виртуальная, ага)

какой-то не очень аргумент, и правда :)

Ну в куте можно, а в винде нельзя)

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

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

можно, но неправильно сработает

А чем будет отличаться?

А чем будет отличаться?

на каком мониторе показывать мессаджбокс?

В общем

Мне кажется, что мы отошли от темы

а она была? :D

на каком мониторе показывать мессаджбокс?

Хендл окна нужен чтобы показать на мониторе с окном а не первом попавшемся?

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

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

Давай ты еще раз скажешь, чем тебе помочь и мы спокойно объясним, где ты неправ

Хендл окна нужен чтобы показать на мониторе с окном а не первом попавшемся?

я не расскажу за винду

Давай ты еще раз скажешь, чем тебе помочь и мы спокойно объясним, где ты неправ

у меня нет никаких проблем, все работает

что характерно, без maybe оберток окон

я не расскажу за винду

Вроде ты ж только что про нее топил вместо кьюта, но ладно

Вроде ты ж только что про нее топил вместо кьюта, но ладно

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

я не изучал детали

Ах, ок

что характерно, без maybe оберток окон

Ну раз у тебя все ок - то и обсуждать нечего. Вот и решилось все

Ну раз у тебя все ок - то и обсуждать нечего. Вот и решилось все

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

что характерно, без maybe оберток окон

в кьюте ее тоже нет для чего-либо связанного с гуем

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

логику работы с mfc, ты хотел сказать?

логику работы с mfc, ты хотел сказать?

мы в 2к18, никто не собирается использовать С++98 обертки напрямую

вот про модель future/promises могу рассказать

которая позволяет лямбды с this в onSuccess передавать