Здравствуйте, alex_public, Вы писали:
_>Ты это сейчас про Rust (в нём вроде нет "заголовков") или про C++ (а тут "заголовков" недостаточно и нужны ещё lib файлы)?
Про оба.
В Расте есть крейт с заголовками, если кому хочется поупарываться с окнами. И стандартная либа наверняка внутри зовёт ВинАПИ, когда компилишь под винду. То есть я опять не понимаю, зачем нужен специальный линкер.
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Здравствуйте, ArtDenis, Вы писали:
_>>Даже близко не похожи. Ты вообще сам в курсе стандартного кода при использование обеих этих библиотек или нет? AD>Ну покажи свой (или чужой) код с использованием stm32-rs. Инициализацию периферии, устройств, которые к ней подключены и т.п.
// за что либа меня мучает тем, что я должен знать регистр управления флэшем - acr? let clocks = rcc.cfgr.freeze(&mutflash.acr);
// за что либа меня мучает тем, что я должен знать что регистр тактирования порта GPIOB - это apb2?let mut gpiob = dp.GPIOB.split(&mutrcc.apb2);
// за что либа меня мучает тем, что я должен знать что управление настройками
// порта разделено на два регистра и один из них crh (для пинов с 8 по 15)?let mut led = gpiob.pb12.into_push_pull_output(&mutgpiob.crh);
Код с использованием HAL будет удачнее хотя бы из-за того, что программист не должен знать тонкости тактирования и устройства регистров перифирии. При всех своих больших недостатках HAL является именно hardware abstraction layer, а не поделкой в стиле "смотри, я могу программировать МК на расте!!!"
Повторюсь: даже если закрыть глаза на эти косяки, то всё равно это те же яйца, только в профиль. Если раст даёт преимущества перед С++ на "большом компе", то для МК пока таких преимуществ не видно
Здравствуйте, T4r4sB, Вы писали:
_>>Сомнительная архитектура что для Rust, что для C++. TB>Да нормальная.
Ну не знаю как для тебя, а для меня голые (не инкапсулированные в RAII) указатели/ссылки приемлемы только если речь про глобальные объекты. А так, ситуация с потенциально дохлыми ссылками на локальные объекты — это очень не хорошо, даже если и контролируется административно.
TB>Ты предлагаешь вместо ссылок индексы. Это лишняя индирекция, а ещё тебе надо протаскивать мутабельную ссылку на граф во все методы вершин.
Главное что это безопасно. Ну и протягивать ничего не требуется, просто надо весь функциональный код делать в Graph, а не Node. В данной задаче явно лучше функциональный подход, а не ООП (т.е. Node — это просто хранилище данных, а не сложная ООП сущность с внутренними состояниями).
TB>Это надёжнее и легче отлаживать, но и исходный вариант оптимален.
Насчёт оптимальности (речь про быстродействие, как я понимаю?) на самом деле мне так с сходу не всё очевидно. Точнее в C++ коде твой вариант конечно же однозначно быстрее будет. А вот в Rust с учётом всех манипуляций в Rc и RefCell не факт что это будет быстрее механизма доступа по таблице.
Здравствуйте, alex_public, Вы писали:
_>Главное что это безопасно. Ну и протягивать ничего не требуется, просто надо весь функциональный код делать в Graph, а не Node.
Не получится, если Node это полиморфный тип (dyn trait если по-растовски).
_>Насчёт оптимальности (речь про быстродействие, как я понимаю?) на самом деле мне так с сходу не всё очевидно. Точнее в C++ коде твой вариант конечно же однозначно быстрее будет. А вот в Rust с учётом всех манипуляций в Rc и RefCell не факт что это будет быстрее механизма доступа по таблице.
Ну пока что я сделал на Rc<RefCell> потому мне ещё надо в калбаки распихивать ссылки на элементы.
Жаль что в Расте нету связки UniquePtr-WeakPtr. Вообще странно, потому что хотя бы будет сложнее наделать циклических ссылок
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Здравствуйте, T4r4sB, Вы писали:
TB>С того, что RefCell содержит внутри некую Lang Item. То есть компилятор знает, что именно для определённой структуры из std не надо генерить этот атрибутик. TB>Если у тебя есть rust на компе, то всегда можешь сгенерить релизный код с --emit=llvm-ir и посмотреть.
Так ты это всё про UnsafeCell писал? )))
_>>Ты лучше расскажи какие такие ужасы могут возникнуть из-за твоего атрибутика при условие отсутствия одновременной работы с несколькими мутабельными ссылками (но при одновременном существование этих ссылок). TB>Как ты думаешь, что делается с кодом при наличии этого атрибутика?
Возникает определённая оптимизация. Которая никак не повлияет на ситуацию, в которой нет одновременного использования двух ссылок.
Здравствуйте, T4r4sB, Вы писали:
_>>Ты это сейчас про Rust (в нём вроде нет "заголовков") или про C++ (а тут "заголовков" недостаточно и нужны ещё lib файлы)? TB>Про оба. TB>В Расте есть крейт с заголовками, если кому хочется поупарываться с окнами. И стандартная либа наверняка внутри зовёт ВинАПИ, когда компилишь под винду. То есть я опять не понимаю, зачем нужен специальный линкер.
Ну а если ты захочешь использовать C/C++ библиотеку? Что весьма часто внутри Rust библиотек...
Здравствуйте, ArtDenis, Вы писали:
_>>Ну вот https://habr.com/ru/post/495948/ например. AD>Это антипример какой-то AD>Несколько строк оттуда: AD>... AD>Код с использованием HAL будет удачнее хотя бы из-за того, что программист не должен знать тонкости тактирования и устройства регистров перифирии. При всех своих больших недостатках HAL является именно hardware abstraction layer, а не поделкой в стиле "смотри, я могу программировать МК на расте!!!"
Ну это дело вкуса уже. В любом случае думаю ты не будешь спорить, что приведённый пример просто в разы компактнее и проще, чем портянка генерируемая Кубом.
AD>Повторюсь: даже если закрыть глаза на эти косяки, то всё равно это те же яйца, только в профиль. Если раст даёт преимущества перед С++ на "большом компе", то для МК пока таких преимуществ не видно
Я с этим и не спорил (более того, именно это я и заявлял изначально). Только вот можно увидеть готовые библиотеки (скажем для STM32) на C++, написанные в подобном же современном стиле?
Здравствуйте, T4r4sB, Вы писали:
_>>Главное что это безопасно. Ну и протягивать ничего не требуется, просто надо весь функциональный код делать в Graph, а не Node. TB>Не получится, если Node это полиморфный тип (dyn trait если по-растовски).
Ну вот этим и плох тут ООП подход.
_>>Насчёт оптимальности (речь про быстродействие, как я понимаю?) на самом деле мне так с сходу не всё очевидно. Точнее в C++ коде твой вариант конечно же однозначно быстрее будет. А вот в Rust с учётом всех манипуляций в Rc и RefCell не факт что это будет быстрее механизма доступа по таблице. TB>Ну пока что я сделал на Rc<RefCell> потому мне ещё надо в калбаки распихивать ссылки на элементы.
А если сделать по моей схеме, то в колбек можно было бы кидать просто целочисленный индекс, плюс статическую ссылку на глобальный graph.
TB>Жаль что в Расте нету связки UniquePtr-WeakPtr. Вообще странно, потому что хотя бы будет сложнее наделать циклических ссылок
Так Box в отличие от Rc/Arc может быть мутабельным. Так что наличие Weak для него как раз обеспечит нарушение того самого базового правила ссылок.
Здравствуйте, alex_public, Вы писали:
_>Возникает определённая оптимизация. Которая никак не повлияет на ситуацию, в которой нет одновременного использования двух ссылок.
Я могу накидать код на пару строк, в котором повлияет.
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Здравствуйте, alex_public, Вы писали:
_>А если сделать по моей схеме, то в колбек можно было бы кидать просто целочисленный индекс, плюс статическую ссылку на глобальный graph.
На глобальный RefCell<Graph> ты хотел сказать? Я же в колбаке ещё и менять данные хочу.
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Здравствуйте, alex_public, Вы писали:
_>Ну это дело вкуса уже. В любом случае думаю ты не будешь спорить, что приведённый пример просто в разы компактнее и проще, чем портянка генерируемая Кубом.
Думаю, это дело привычки. Куба нету, чтобы проверить )
_>Я с этим и не спорил (более того, именно это я и заявлял изначально). Только вот можно увидеть готовые библиотеки (скажем для STM32) на C++, написанные в подобном же современном стиле?
С этим проблема. Общей удобной либы нету. Когда-то давно была одна огромная либа монструозная либа на шаблонах, но я её сейчас даже не смог найти. Конкретно сейчас на гитхабе полно таких либ, но я не степени знаю их охвата, удобства и безглючности.
Но на то они и С++-ники, чтобы городить свой велосипед. У меня своя либа практически на всю периферию STM32 + набор шаблонов для разных устройств (экраны, память, радио, точскрины и т.п.), которые параметризуются шаблонами периферии.
Та же инициализация порта GPIOB у меня выглядит как
PB::clock_on();
В целом использование либы выглядит примерно так:
// Объявляем перифирию для подключения к дисплеюusing DisplayCSPin = PA1;
using DisplayResetPin = PA2;
using DisplayDCPin = PA3;
using DisplayMisoPin = PA6;
using DisplaySckPin = PA5;
using DisplayMosiPin = PA7;
using DispSpi = Spi1;
using DispDma = Dma2_Stream2;
...
// далее идут уже другие либы (тоже шаблонные)
// тип подключения к дисплеюusing DispSpiConn = mgfxpp::HardSpiDma6WireConnection<
DisplayResetPin,
DisplayCSPin,
DisplayDCPin,
DispSpi,
DispDma
>;
...
// тип дисплеяusing Display = mgfxpp::ili9341_display<DispSpiConn, DelayForDisplay>;
// реализация дисплея - 16 бит, частичная отрисовка в буфер по 64 строки
MGFXPP_DISPLAY_PART_BUF_565_IMPL(Display, 64)
...
// тут инициализируем почти всю периферию, которая участвует в подключении кроме SPI. Его отдельно
DispSpiConn::init();
Здравствуйте, T4r4sB, Вы писали:
_>>Возникает определённая оптимизация. Которая никак не повлияет на ситуацию, в которой нет одновременного использования двух ссылок. TB>Я могу накидать код на пару строк, в котором повлияет.
Был бы благодарен, т.к. очень интересно взглянуть на подобное. )
Здравствуйте, T4r4sB, Вы писали:
_>>А если сделать по моей схеме, то в колбек можно было бы кидать просто целочисленный индекс, плюс статическую ссылку на глобальный graph. TB>На глобальный RefCell<Graph> ты хотел сказать? Я же в колбаке ещё и менять данные хочу.
Мы же вроде уже обсудили, что в &'static mut нет ничего магического.
AK>При чём здесь Clang? Это же компилятор. AK>Более экономичным по определению он может быть, например, там, где он избавляется от vtable и, как следствие, от "лишнего" разыменования указателя при вызове метода. Это если сравнивать с плюсами.
Такто никто не заставляет тебя в плюсах делать классы с виртуальными методами.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, ArtDenis, Вы писали:
AD>Писать на расте можно, но код на расте по структуре и идеологии будет похож на код на си. И особо не понятно, зачем в данном случае нужен именно раст. Лично мне в расте пока не хватает некоторых фич, чтобы на него перейти для использования при написании прошивок
Так константные параметры были уже год как в языке. ) А в этом релизе добавили всего лишь возможность задания дефолтного значения (что конечно же тоже полезно, но не так чтобы принципиально).
Здравствуйте, T4r4sB, Вы писали:
_>>Был бы благодарен, т.к. очень интересно взглянуть на подобное. ) TB>Пишем в одну ссылку, потом читаем из другой. Это не одновременно. Это по очереди. Оптимизатор может решить, что эти события не связаны.
Так это у тебя опять же две ссылки в одном коде (кстати я бы тебе тут легко более гарантированный вариант с ошибкой привёл бы, который кстати и в C++ работает). А я уж думал что ты реально что-то неизвестное мне покажешь...
Возвращаясь к твоему исходному вопросу (с колбеками), то две мутабельные ссылки (одна в основном коде и одна переданная в колбек) будут превосходно работать, при условие однопоточности кода.
