Просто есть минлевел СП, чтобы об этом знать)

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

не понял

не понял

а как?

напомню, циклы в конечных автоматах совершенно естественны

Просто есть минлевел СП, чтобы об этом знать)

Просто это не всем нужно, поэтому стенфорды и mit не шибко башляют в это направление

Просто это не всем нужно, поэтому стенфорды и mit не шибко башляют в это направление

У стенфорда емнип медальки были

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

не вижу проблем

У стенфорда емнип медальки были

ну да, качественное есть в единичном)))

представьте, что А == В

для начала

в каком смысле равно?

один и тот же обьект?

одно и то же состояние автомата

петля

что там про сильные ссылки?

одно и то же состояние автомата

хочу твою теорию на примере ассемблерного кода в gas синтаксисе

дальше представьте себе минимальный конечный автомат для (ab)*

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

struct automaton_state : public std::enable_shared_from_this<automaton_state> { /*удачки*/ };

халтура

зачем состоянию такой интерфейс?

я вам прямую задачу ставлю

мне нужен конечный автомат

ты хочешь выразить переходы между состояниями смартпоинтерами на состояние-цель? это неверно

да

это не неверно

смартпоинтеры не реализуют переходы а реализуют владение

в Java я просто напишу class AutomatonState { Map<char, AutomatonState> edges; };

они из плоскости владения а не из плоскости автомата

напишите это на С++

через weak_ptr / shared_ptr

в Java я просто напишу class AutomatonState { Map<char, AutomatonState> edges; };

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

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

отлично, что дальше?

у вас вечное хранение и неявная утечка памяти

вы храните недостижимые состояния

это структура владения, но вы не можете априорно ручками задать ей остов и не можете поэтому реализовать её на weak_ptr / shared_ptr

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

у вас вечное хранение и неявная утечка памяти

не вечное а пока жива стейтмашина

угу

вечное

я делаю 1млрд операций с вашей машиной и она падает, хотя содержит пустой автомат

если я храню список шаред поинтеров это тоже вечное хранение?

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

нет. вечное хранение это когда чтото храниться вечно

хорошо, называйте как хотите

давайте назовем это "неявная утечка памяти"

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

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

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

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

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

вы понимаете, что состояние, единственное входящее ребро которого - петля, тоже недостижимо?

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

я ведь правильно понял?

нет, это простейший пример

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

по построению автомата

весь цикл может быть недостижимым

и в действительности вы не умеете на shared/weak структурах описывать такое владение

потому что strong ref должны образовать остов из достижимых состояний

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

зачем тогда weak_ptr вообще нужен

потому что strong ref должны образовать остов из достижимых состояний

куча умных слов. дело не в этом а в том что я выше написал

если у вас все окна - один объект

и все состояния конечного автомата тоже

а еще все сущности внутри одного потока

зачем тогда weak_ptr вообще нужен

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

вы понимаете, что поток связан отношением владею с текущим стеком, а текущий стек - с потоком?

ERROR: S client not available

что такое поток?

thread

да. вот что он такое

не знаю, не очень хочется давать определения

но я плохо представляю, как вне контекста потока будет выполняться код

или как поток будет выполняться без кода

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

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

я веду речь про то, оберткой для чего является std::thread

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

пример. у меня класс А, в нем одно поле типа Б. кто чем владеет?

а почему текущий стек связан с потоком?

стек - это просто область памяти

пример. у меня класс А, в нем одно поле типа Б. кто чем владеет?

Класс А объектом Б

но это не тот же пример

вот связь thread -> stack_ptr я вижу, а обратной - никак

объект Б может наблюдать, что не захвачен класс А, но в случае с потоком ни одна функция не может наблюдать, что текущего потока не существует

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

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

это отношение нельзя назвать владением. если ты едешь на автобусе, ты всегда будешь в автобусе. но ты не владеешь автобусом

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

ибо ссылки владеющие указывают на один обьект. а тут потоки могут быть разные (как и автобусы разные)

И да, без кода поток - не поток. Но это сказать так же тупо, как и что без регистров программа- не программа

Вывод с такой логикой- регистры владеют программой, а программа регистрами? далеко пойдете с такой логикой

Кидаешь туда кнопки "Пуск, Панель управления и чото там"

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

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

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

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

boost.system точно ничего не тянет

а ПТ кстати точно нужен? просто там есть косяки лютые которые потом могут всплыть

boost.system точно ничего не тянет

значит опакечен криво requires = ( "boost_package_tools/1.66.0@bincrafters/stable", "boost_config/1.66.0@bincrafters/stable", "boost_assert/1.66.0@bincrafters/stable", "boost_core/1.66.0@bincrafters/stable", "boost_predef/1.66.0@bincrafters/stable", "boost_winapi/1.66.0@bincrafters/stable" )

а ПТ кстати точно нужен? просто там есть косяки лютые которые потом могут всплыть

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