надо наверно начать с того что на расте UI фреймворков нихера нет?

наоборот, их дохрена. Но все сырые

gtk-rs же есть

шутник

@Golodnyi ну как, вышло у меня ответить или все равно не понятно?

@Golodnyi ну как, вышло у меня ответить или все равно не понятно?

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

а тьфу, это let имеет конструктор

конструктор? если это не примитивный тип, то это просто функция обычно, LLVM такое статически выоптимизирует начисто почти всегда

ну я когда спросил, каким образом приложение чистит память, если там нет GC, ты там дал линк на вики, в ней написано что траля-ля, есть конструктор вызываемый при создании переменной и диструктор вызываемый при выходе из области видимости. Получается что переменная имеет диструктор? Тоесть она хранит больше чем просто ссылку на значение или это let так работает или еще какой механизм?

если реализован трейт дроп - он вызывается. Если нет - просто чистится память

Простейшие типы транслируются в типы llvm

Большинство переменных в расте живут на стеке и деструктор нужен не очень часто

"просто чистится память" звучит слишком просто

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

Ах, ну да

тоесть в этой ситуации let a = 1 { let b } b будет недоступна за пределами, но при этом память не очистит?

тип того. она просто станет мусором на стеке, пока на ее место что-то другое не запишут

Фууух, я уж испугался, что зайду с утра в расточатик и придётся реально про раст читать

+1

но такой конкретно код llvm выкинет)

(и если это просто целое число, то вообще не факт что оптимизатор ее тупо мимо стека в регистр процессора не положит)

https://doc.rust-lang.org/book/second-edition/ch15-03-drop.html советую полистать

я перевод читаю, пока утомился читать, зашел узнать от практиков)

https://doc.rust-lang.org/book/second-edition/ch04-01-what-is-ownership.html - ну и может тут вот про владение, стек и время жизни

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

кстати, насколько вторая редакция отличается от первой?

Сильно

Она с нуля писалась

спс

@notplhk да полно там копипасты

не, не сказал бы что вообще все не так

язык то один и тот же)

перефразировали, улучшили

но откровений нет

Да понятно что нового там ничего не может быть

Как связаны вызов деструктора и стек? Про какой вы деструктор, про Drop в расте?

Да

V изначальный вопрос

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

Каким образом переменные в си уничтожаются, если там нет gc 🤔?

Каким образом переменные в си уничтожаются, если там нет gc 🤔?

ну человек же явно на си\плюсах\чем-то-такого-уровня не писал

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

я вот думал с плюсов на раст переписать приложение, чтоб почуять разницу на своем дилетантском уровне, у вас же вроде биндинги qt и qml есть?

вон выше обсуждалось что все gui в ржавчине сейчас сырые. вряд ли это очень офигенный опыт будет

http://play.integer32.com/?gist=86e6c686562fbf5df489926a34bfef58&version=stable структура выделяется на стеке, после выхода из фрейма стека вызывается drop

А чем принято превращать разные типы в вектор u8? Хочу вместо 16-битного числа получить его байтовое представление, например.

деструктор он не освобождает память, он освобождает объект концептуально. в расте в unsafe я могу явно выделить память на хипе или освободить? эти операции должны быть запрятаны в Box и т.д.

А чем принято превращать разные типы в вектор u8? Хочу вместо 16-битного числа получить его байтовое представление, например.

Byteorder

А чем принято превращать разные типы в вектор u8? Хочу вместо 16-битного числа получить его байтовое представление, например.

Byteorder

я вот думал с плюсов на раст переписать приложение, чтоб почуять разницу на своем дилетантском уровне, у вас же вроде биндинги qt и qml есть?

биндинги есть, и даже вроде работают. Но все равно будет больно

Начинать лучше с консольных приложений

@vlad20012 при ренейминге полей в объявлении структуры - ренейминг внутри инициализаций не происходит.

https://doc.rust-lang.org/stable/std/heap/struct.Heap.html это в найтли, значит в стейбле я свой вектор не напишу? в стейбле нельзя память на хипе выделять?

через libc::malloc выделяй))

можно еще по crates.io полазать насчет всяких более удобных оберток вроде https://github.com/dropbox/rust-alloc-no-stdlib

вы меня затролели, библиотека для выделения памяти на хипе

хотел еще https://docs.rs/slab скинуть, но он сам на Vec основан)

а ваш раст же на микроконтроллерах есть, на cortex-m, без std, там этой либой память что-ли выделяют?

или свой alloc.c пишут и линкуют его с растом?

https://doc.rust-lang.org/1.14.0/book/lang-items.html

на микроконтроллерах хип вообще юзают?

на микроконтроллерах libc часто урезанная, я не удивлюсь если libc растовский из-за недостающих функций работать не будет

да там даже c++ с его std юзают

на микроконтроллерах хип вообще юзают?

Только упоротые

да ладно микроконтроллеры, redox'ерам (https://redox-os.org/) всяким в ядре же тоже может быть нужно динамически память выделять? kmalloc там всякий

они уже сделали свой аллокатор, ralloc или как-то так

https://github.com/redox-os/ralloc ага, вижу. занятно

Ты из битлби сюда пишешь?

Нет, а надо?

gtk-rs же есть

Это не на расте, а бинды к сям же

https://github.com/redox-os/ralloc ага, вижу. занятно

Когда там кастомные аллокаторы то стабилизируют?

Или все ещё неизвестно

наоборот, их дохрена. Но все сырые

Из растовых только глиум вроде и все. Остальные биндятся AFAIK

Когда там кастомные аллокаторы то стабилизируют?

я не слышал о подвижках в ближайшем будущем :(

Нет, а надо?

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

Из растовых только глиум вроде и все. Остальные биндятся AFAIK

glium ооочень косвенное отношение к GUI имеет, нет?

я не слышал о подвижках в ближайшем будущем :(

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

тоесть в этой ситуации let a = 1 { let b } b будет недоступна за пределами, но при этом память не очистит?

В этом примере б скорее всего даже в финальный код не попадёт

ну суть же не в примере

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

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

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

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

Из растовых только глиум вроде и все. Остальные биндятся AFAIK

как минимум конрод. И еще куча проектов разной степени готовности

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

Щас бы ещё safety space в чате строить

glium ооочень косвенное отношение к GUI имеет, нет?

Ну там вроде фреймворк поверх глиума был с уями, название запамятовал. На awesome rust можно подглянуть