так структура не создалась ж а деструктор как раз на структуре создан new это просто "функция"

+1

где она спокойно вышла из new

я про твой пример

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

я вас затроллел, насколько я понимаю если будет реальный файл - то это будет растовская структура а для неё дроп уже вызовется и хендл файла ос закроется

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

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

потому что метод не статический

как это влияет

v.drain(..).collect() (Vec) когда эта штука будет аллоцировать память?

Ну смотря где, автор того поста ругался про аллокацию стека, так что каждый метод будет выделять

ну метод же захватил &self

при панике вызывается Drop на структурках

https://doc.rust-lang.org/beta/std/ops/trait.Drop.html

как это влияет

Потому что паника разворачивает стек по дефолту

и при развороте все дропы вызываются?

> Given that a panic! will call drop as it unwinds, any panic! in a drop implementation will likely abort.

и при развороте все дропы вызываются?

Это и называется развернуть стек

а, ок

А есть какие-то отличия от C++ тут? (ну, кроме того, что Drop это трайт)

потому что метод не статический

к слову в расте нет различия между статическими и фабрическими методами

второе синтаксический сахар для первого

А есть какие-то отличия от C++ тут? (ну, кроме того, что Drop это трайт)

В с++ что-то определено?

к слову в расте нет различия между статическими и фабрическими методами

я знаю но привычными словами проще объяснять ))) (я понял что ты имеешь ввиду)

Он хендл дропнул

хендл это структура? все равно все сводится к инту как в си, в реализации собственной обертки над файлом можно допустить такую ошибку

к слову в расте нет различия между статическими и фабрическими методами

Что такое фабричные методы?

Что такое фабричные методы?

в ооп это методы прикрепленные к инстансу

хендл это структура? все равно все сводится к инту как в си, в реализации собственной обертки над файлом можно допустить такую ошибку

Ну не допускай

ладно

В расте не принято работать с паниками, так что не страшно

Ты точно так же можешь безопасно утечь файлом без дропа

Течь безопасно

В с++ что-то определено?

В смысле? Как отрабатывают деструкторы - определено.

В смысле? Как отрабатывают деструкторы - определено.

Как он отработает с паниками?

С вложенными паниками?

Ну тоесть "бросанием исключений"

вложенные паники - это что конкретно?

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

2 паники = std::terminate

но надо вызвать (в с++) деструктору у того, что успело сконструироваться (поля, локальные переменные)

в расте 2 паники это тоже наверное завершение программы

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

Вот вот, при этом в с++ это неявно

все равно все ваши паники поверх плюсовых исключений

в расте 2 паники это тоже наверное завершение программы

Да, abort вместо unwind

Вот вот, при этом в с++ это неявно

э? про это вроде явно написано в стандарте :-)

э? про это вроде явно написано в стандарте :-)

Явно про неявность

кто его читал

там 1500 страниц

Я про то, что создаётся объект в конструкторе неявно

1000+ страниц - это со стандартной либой. ядро языка - меньше

Подразумевается что он уже существует когда конструктор вызывается, ведь ты имеешь указатель на него

а дроп в расте явно вызывается

ты или крестик сними или штаны надень

а дроп в расте явно вызывается

Так raii зачем дроп явно

А что же, js-guys интересуются Rust'ом?

Ага.

ну Эшли ж интересуется

Я слышал, в Rust система типов настолько выразительная и строгая, что компилятору удается про некоторое количество ARC-managed объектов доказать, что счетчик ссылок падает до нуля в одном конкреном месте при любом исполнении программы, и полностью заменить и инкременты / декременты счетчика, и сам счетчик, и всю дополнительную косвенность (лишние указатели на указатели), и заменить это все на чистые malloc / free в нужных местах. Не знаю, насколько это правда и как часто происходит на практике.

Посоны такое бывает? Звучит как сказка

IDA в помощь

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

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

Посоны такое бывает? Звучит как сказка

нет конечно

если тривиальные случаи игнорировать где просто Arc::new(val)

тогда llvm может убрать лишние атомик_инстрикт вызовы

Бля

Кто там кговонил

Кто чтоб

Набухаться в гов но

Надо ехать на думскую

Ху там

@Mosolov Соси хуй

тебе нормально, да?

Хах

у кого то классно прошла ночь ? ))

Ребзя

как избежать дублирования кода

или оставить только Into<String> ?

Макросы?

в случае From я сделал так

макросы это прям такое

enum Loading { A, B } fn converter<'a>(so: &Loading) -> &'a str { match *so { Loading::A => "warning", _ => "error" } } impl Into<String> for Loading { fn into(self) -> String { converter(&self).to_string() } } impl<'a> Into<&'a str> for Loading { fn into(self) -> &'a str { converter(&self) } } а почему не так?