язык разве гарантирует синхронизацию на доступе к статическому объекту функции?

он гарантирует только синхронизацию создания

а, речь об инициализации

это же по сути и есть синглтон

namespace { class SomeSingleton : public SomeSingletonInterface { }; } SomeSingletonInterface & get_SomeSingletonInstance { static SomeSingleton object; return object; //я ой как не уверен, что вы можете это повторить }

на такое решение уже нужно auto, и в качестве параметра его не передать

ну вернее можно, наверное, исхитриться и передать всякими decltype от функции, но это уже извращение какое-то

нет, не нужно

потому что это функция в CPP файле и последнее невозможно

анонимный неймспейс вообще нельзя писать в .h-нике

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

void doAcion(<Singleton?> &obj);

хм... зачем нужно синглтон передавать как параметр?

чтобы работал полиморфизм

синглтоны выражают глобальные ресурсы же

их запрашивают как глобальные ресурсы

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

например, базовый конфиг-синглтон и переопределенный конфиг, скажем, для тестов

угу, система с депенденси инжекшн

да

в данном случае источник синглтона - глобальный ресурс

одна лишняя косвенность, там shared_ptr лежит

и метод guard_object tests::register_injection()

короче, рассуждать можно долго, да спать пора)

приятно было поговорить, спокойной ночи

ну я пока не рассуждаю, просто рассказываю, как это написано :)

спасибо, я реализовывал свой простой DI)

там еще куча шаманской магии типа this_thread_register_injection и this_thread_register_isolation

правда не на плюсах, да

стоит заняться как-нибудь

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

т.е. формально если у вас есть ребро A -> B, то пока живо состояние А, должно быть живо и состояние В

Какой то странный граф. Проверять наличие вершин по граням? Если это направленый граф то если нет вершины А то нет ничего дальше что было от этой вершины исходящим

Я думаю граф ненаправленный

Без разницы. Тогда удаление основания ветки приведет к созданию 2 полностью независимых графов

вы не сможете сделать это на shared/weak ptr

Так как вы это обьясняете конечно не сможет. Но если касаться графов то изначально нужно понимать что граф это инструмент для описания множества множеств и отношений между этими множествами. То есть если вы хотите создать какой то инструмент который будет производить определенную работу при наличии конечного списка условий. То с точки зрения графа. У вас будет множество описаное одной вершиной (работа) и набор связаных вершин (условий), каждое из которых является множеством само по себе. Ничто не мешает вам реализовать простой алгоритм. Когда при каких то внешних событиях будет отрабатываться множество и результатом будет работа, например какая то глобальная переменная изменит свое значение. А если множество сделало изменение то оно может вызвать любое количество вышестоящих множеств и те в свою очередь проверив например связаный список глобальных переменных либо сделают какую работу либо ничего не произойдет. Никаких циклов.

Подходя ближе к задаче. Организовать убийство связаных процессов не проблема. Достаточно просто помнить процессы и как они связаны. А то дерево это очень частный случай графа

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

здесь могла быть ваша реклама...

здесь могла быть ваша реклама...

Точно блин. И тут реклама ЕНОТА. ?

Система которая превратит кучу ваших данных в связанные множества и вы обнаружите ранее не очевидные связи и зависимости. :) Как Палантир только полностью автоматический и гораздо дешевле.

Ребятааа

Ищу криптор

Продукт на сях написан, но нужен крипт ?

Доброе утро/между тем

Так как вы это обьясняете конечно не сможет. Но если касаться графов то изначально нужно понимать что граф это инструмент для описания множества множеств и отношений между этими множествами. То есть если вы хотите создать какой то инструмент который будет производить определенную работу при наличии конечного списка условий. То с точки зрения графа. У вас будет множество описаное одной вершиной (работа) и набор связаных вершин (условий), каждое из которых является множеством само по себе. Ничто не мешает вам реализовать простой алгоритм. Когда при каких то внешних событиях будет отрабатываться множество и результатом будет работа, например какая то глобальная переменная изменит свое значение. А если множество сделало изменение то оно может вызвать любое количество вышестоящих множеств и те в свою очередь проверив например связаный список глобальных переменных либо сделают какую работу либо ничего не произойдет. Никаких циклов.

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

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

Так и будем. Расматриваем каждую функцию как множество. Функция проверяет переменные которые получает от функций ниже или внешнего мира. И согласно условий изменяет или нет переменную на выходе. Изменение переменной на выходе вызывает вышестоящую функцию и так пока не доберется до действия. А запускать цепочку можно по прерыванию от внешнего события.

Так и будем. Расматриваем каждую функцию как множество. Функция проверяет переменные которые получает от функций ниже или внешнего мира. И согласно условий изменяет или нет переменную на выходе. Изменение переменной на выходе вызывает вышестоящую функцию и так пока не доберется до действия. А запускать цепочку можно по прерыванию от внешнего события.

А можно чуть ближе к С++ коду? Я там уже ява-прототип набросал class AutomatonState { Map<char, AutomatonState> next; };

А можно чуть ближе к С++ коду? Я там уже ява-прототип набросал class AutomatonState { Map<char, AutomatonState> next; };

В яве есть вложения и так. Статья была на хабре пару месяцев назад.с картинками

Я не очень большой специалист по яве

Не знаю, что там называется вложением

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

(изначально дискуссия была, почему shared_ptr / weak_ptr не описывают структуру владения)

А то пока получается смешная ситуация вроде "как перевести intmax_t в wstring локаленезависимым образом в С++14?"

Много что можно использовать, но пример набросать... :)

И главное, детским недостатком языка это никто так и не признал

да, кстати, @AsGreyWolf, окна должны быть неперемещаемыми, чтобы без проблем в лямбдах биндаться

Я же сказал что для такого есть пимплы

Но сами окна типа перемещаемые

Короче интерфейс нормальный а кишки упороты

Я упорюсь пимплы писать

Главное, зачем?)

Короче интерфейс нормальный а кишки упороты

Чтобы

Ты же понимаешь, что пимпл это два раза весь контракт окна описать?

А не как в кьюте

Ты же понимаешь, что пимпл это два раза весь контракт окна описать?

Ну и чо

Ну второй может быть уже

Ну... это * константа времени разработки непонятно зачем

ERROR: S client not available

За такое на эту константу зарплату делят)

Я так понял у тебя щас архитектура дико похожа на кьют

Наверняка

А меня от него подташнивает

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

Просто потомучто это джава ебаная

На виртуальном полиморфизме

Ну сделай мне модули компиляции

У меня сейчас 44 минуты сборка

С неперемещабельными окнами и ссылками на родителя

И COW со всех щелей

Ссылки на родителей и COW нет

Там чуть сложнее

Вместо ссылки на родителя

Она скрыта в реактивной модели

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

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

Много что можно использовать, но пример набросать... :)

http://en.cppreference.com/w/cpp/utility/optional

Оказывается есть такая утилитка уже

Зачем мне std::optional?

Оказывается есть такая утилитка уже

Есть в С++17, можно портировать на более ранние с некоторыми танцами с бубном

Зачем мне std::optional?

Ну так ты хотел же чего то там описывать. Ну вот и описывай в одном так сказать флаконе. Как флакон наполнится так делай чего там нужно. Оно ж для этого и сделано.

Ну так ты хотел же чего то там описывать. Ну вот и описывай в одном так сказать флаконе. Как флакон наполнится так делай чего там нужно. Оно ж для этого и сделано.

Я хочу конечный автомат и плохо понимаю, как мне поможет std::optional

Я хочу конечный автомат и плохо понимаю, как мне поможет std::optional

Тут вот за жабу. Но общий смысл тот же. https://habr.com/post/347576/

Тут вот за жабу. Но общий смысл тот же. https://habr.com/post/347576/

Классно, у меня внедрено года полтора назад, но зачем в этом примере?)

Классно, у меня внедрено года полтора назад, но зачем в этом примере?)

Начни с начала в чем цель конечного автомата? При соблюдении определенных условий произвести какие то действия? И что не так с опшинал?

Начни с начала в чем цель конечного автомата? При соблюдении определенных условий произвести какие то действия? И что не так с опшинал?

С опшнал? Ну я могу еще использовать QWindow, только зачем? Цель конечного автомата - описать множество принимаемых строк

С опшнал? Ну я могу еще использовать QWindow, только зачем? Цель конечного автомата - описать множество принимаемых строк

Насколько большое множество?

Ты хочешь составить список зависимостей процессов. что бы прибивать автоматом дочернии процессы? Причем тут конечный автомат и графы и прочая хрень?

Ты хочешь составить список зависимостей процессов. что бы прибивать автоматом дочернии процессы? Причем тут конечный автомат и графы и прочая хрень?

Нет, я хочу конечный автомат

Пиши их в список друг за другом. Потому что это не дерево. Это векторы. И прибивай каждый вектор согласно списка.