rust для микроконтроллеров уже готов?

все огранилось твоим фейлом и надуванием щек

Ты случайно не разлогиненный царь? Характерное невежество и самоуверенность.

Ты случайно не разлогиненный царь? Характерное невежество и самоуверенность.

Невежество проявил только ты, не зная, что такое виртульный метод, и даже не зная полного определения статического в конкретно С++. Именно потому я и просил у тебя конкретику, мало ли что ты опять себе нафантазировал. Но так как конкретики нет, а теоретические знания у тебя практически отсутствуют, то о чем вообще можно говорить с тобой? Общайся с TrueTsar1C77, это твой уровень, вот и он к тебе тянется.

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

Я и не говорил о «виртульном методе».

даже не зная полного определения статического в конкретно С++

static

Inside a class, declares members not bound to specific instances.

На этом и закончим.

Я и не говорил о «виртульном методе».

Говорил:

- Вообще-то он виртуальный - В него не передается this.

Inside a class, declares members not bound to specific instances.

А еще, внезапно, «A static member function shall not be virtual.». Что очевидно и прямо указывает на то, что метод в моем примере изначально не был статическим в том числе по терминологии С++.

На этом и закончим.

Окай.

О чем вы спорите? Метод в том коде статический, но виртуальный. Просто в C++ статический метод не может быть виртуальным.

Но, в общем, никто не против добавления одиночного наследования - может, будет в Rust 2.0

А сейчас есть описания того как оно должно будет выглядеть?

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

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

С возможностью переопределения отдельных методов?

Но, в общем, никто не против добавления одиночного наследования - может, будет в Rust 2.0

А сейчас есть описания того как оно должно будет выглядеть?

Там было аж 4 RFC, потом еще один, потом я перестал следить :)

http://www.smallcultfollowing.com/babysteps/

С возможностью переопределения отдельных методов?

Ну да. Или с этим какие-то принципиальные сложности есть?

http://www.smallcultfollowing.com/babysteps/

По ссылке нашёл вот это:

https://github.com/rust-lang/rfcs/issues/349

Самое актуальное, вроде.

После этого https://internals.rust-lang.org/t/summary-of-efficient-inheritance-rfcs/494/44 вроде ничего определенного не было.

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

Это уже есть и используется (через Deref), буквально пару строк кода.

Покажи.

Как-то так: http://is.gd/Gk41gO

Ну и, конечно, обращаться к полям можно тоже в обход «parent». Так что реализацию Deref можно убрать в какой-нибудь #[extend(A)] struct B; (при написании плагинов возможно изменять структуру, реализовывать и т.д.) и вот готовое наследование.

Причём работает и с передачей &B в функцию, ожидающей &A. Т.е. полноценное одиночное наследование в 7 строк мусорного кода, которые можно убрать в плагин.

Заставят уран для боевой части ракеты добывать. Кайлом.

Это уже есть и используется (через Deref), буквально пару строк кода.

А если у нас есть структура А реализующая трейт T1 и структура B реализующая T2. Ведь не получится включить в структуру C и A и B и делегировать им реализацию Т1 и Т2?

... полноценное одиночное наследование ...

Плюс, если нужна мутабельность, надо еще DerefMut дописывать. Все-таки костыли все это, нужен нормальный механизм.

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

Я хз, можно ли говорить что «GameState логически наследует Fow» или нет, но, если бы был реализован такой механизм, я бы просто тут вот вклячил бы два анонимных поля и переопределил бы только apply_event (потому что тут неоднозначность и он обоим полям должен делегировать вызов). Мало ли какие у тумана войны в последствии методы появятся, простой проверки видимости клетки для сложной игровой логики маловато будет, не хочется их все вручную пробрасывать.

Эту - да.

Так а что оно еще должно делать, чем ты недоволен? О.о

Все-таки костыли все это, нужен нормальный механизм.

О том и речь. Ведь помимо одиночности так и отдельные методы не переопределить.

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

Да, интересная идея.

отдельные методы не переопределить

В смысле? В том же примере loyd`а bar переопределен.

    let a: &A = &b;
    a.bar();

A::bar()

fail

let a: &A = &b; a.bar(); A::bar
fail

Это просто делегация, почему фэйл-то? Для полиморфизма используй трейты.

В том же примере loyd`а bar переопределен.

Да, невнимательно смотрел. Но с трейтами так ведь не получится - придётся реализовывать все методы.

Потому, что это не наследование и не его имитация, как утверждает автор данного кода.

Вот самое свежее предложение об ООП: http://smallcultfollowing.com/babysteps/blog/2015/08/20/virtual-structs-part-...

Мрак.

А конкретнее?

По микроконтроллерам бы простым (не arm) лучше рассказал чего. Какой размер рантайма, планируют ли раст туда активно двигать, то-сё.

Что там бакенд LLVM со всеми вытекающими я в курсе, но между этим фактом и реальностью наверняка вагон нюансов.

По микроконтроллерам бы простым (не arm) лучше рассказал чего. Какой размер рантайма, планируют ли раст туда активно двигать, то-сё.

Я слышал только о zinc-rs, но это ARM. На профильном reddit периодически бывают разговоры о микроконтроллерах, но я STM от AVR не отличаю, поэтому просто пропускаю эти топики.

Не очень понятно, зачем делать иерархии из enum. Это ортогональные вещи. В scala же наоборот сделали АлгТД через классы(с определенными ограничениями), что вполне логично для инфраструктуры JVM.

Почему просто не сделать делегирование реализации trait'а полю с возможностью переопределения отдельных методов? Это покроет всю функциональность ООП, даже множественное наследование.

// другой анонимус

В scala же наоборот сделали АлгТД через классы(с определенными ограничениями), что вполне логично для инфраструктуры JVM.

Scala и JVM нерелевантны - там всё ссылочное.

Почему просто не сделать делегирование реализации trait'а полю с возможностью переопределения отдельных методов?

Им нужны очень дешевые upcasting и downcasting.

Если в очень-очень грубом приближении, то arm-ы обычно несут больше флеша и озу на борту. И поэтому слегка дороже. Отсюда вопрос, какие минимальные требования у рантайма. Если 50 килобайт озу, как у LUA, то дальше копать особо смысла не будет.

Им нужны очень дешевые upcasting и downcasting.

Для конкретных типов? Зачем? Пусть работа будет всегда через trait'ы.

Им нужны очень дешевые upcasting и downcasting.

Для конкретных типов? Зачем?

Про конкретные типы не понял, ответ на вопрос «зачем» - «чтобы можно было работать со скоростью Си++».

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

Про минимум ХЗ, рекорд хелловорлда - 151 байт.

Если 50 килобайт озу, как у LUA, то дальше копать особо смысла не будет.

Я, конечно, совершенно не в теме, но думаю, что и 50к сейчас недостижимо. В будущем - возможно.

тред конвульсирующих паралитиков :P сокращаемся, парни!

Я, конечно, совершенно не в теме, но думаю, что и 50к сейчас недостижимо. В будущем - возможно.

Это про рантайм или про контроллеры? На ARM-овских флешка подбирается к мегабайту, память к 256К. Эта вундервафля почему-то до сих пор называется микроконтроллером, прикинь. Можешь по сайту атмела полазать, там прямо с прайсами всё висит.

думаю, что и 50к сейчас недостижимо

Почему? Я не пробовал такого делать, но, вроде ж, можно все лишнее отпилить, не?

Потому, что это не наследование и не его имитация, как утверждает автор данного кода.

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

Что? Изволь выражаться нормально.

но, вроде ж, можно все лишнее отпилить, не?

Теоретически - да, но товарищу нужно готовое решение. О готовом я не слышал (хотя, повторюсь, я не в теме).

Это про рантайм или про контроллеры?

Про рантайм.

На ARM-овских флешка подбирается к мегабайту, память к 256К. Эта вундервафля почему-то до сих пор называется микроконтроллером, прикинь.

Не то, что в старые времена - 4к ROM и 128 байт оперативки (при везении) %)

Можешь по сайту атмела полазать, там прямо с прайсами всё висит.

Ну с ARM я чуть-чуть знаком, но тебе же не-ARM нужен?

Ну с ARM я чуть-чуть знаком, но тебе же не-ARM нужен?

Там лежат и те и те. Просто удобно сравнивать, сколько памяти кладут и как цена меняется.

У меня нет четкой установки «только не ARM». Если знаешь кто делает SOIC-и по 1-2 бакса от сотни - это было бы интересно. Скорость и разновидность ядра не имеет значения.

Вот самое свежее предложение об ООП:

Спасибо, читаю...