JC
всю - это 8 мб?
Гигабайт
Size: a a a
2020 September 06
JC
В том чтоб увеличить немного размер стэка в принципе ничего плохого не вижу
P
Рост стека меняется
так ещё раз: в чём сакральность стека? ты можешь поменять стек вызовов на стек на хипе, но зачем?
D
Пытаюсь при помощи structopt сделать параметр, который принимает значения из enum, но компилятор ругается, что для энама не определён FromStr, может ли structopt генерировать их сам?
Рылся в здоровенной доке https://docs.rs/structopt/0.3.17/structopt/ нашёл, что автоматическая конверсия работает для subcommand, но у меня уже есть такая для другой цели, а несколько одновременно использовать нельзя.
Рылся в здоровенной доке https://docs.rs/structopt/0.3.17/structopt/ нашёл, что автоматическая конверсия работает для subcommand, но у меня уже есть такая для другой цели, а несколько одновременно использовать нельзя.
AV
так ещё раз: в чём сакральность стека? ты можешь поменять стек вызовов на стек на хипе, но зачем?
Нет сакральности стека, но экономить память имеет смысл
MB
Тот трюк, который я скидывал выше, уменьшает максимальную глубину рекурсии до log(N) (и на каждом уровне по-прежнему тратится O(1)).
То есть память действительно будет экономиться.
То есть память действительно будет экономиться.
H
так ещё раз: в чём сакральность стека? ты можешь поменять стек вызовов на стек на хипе, но зачем?
да, точно, спасибо за поддержку
P
Спасибо, выглядит как то что нужно, но немного бойлерплейтно
D
Спасибо, выглядит как то что нужно, но немного бойлерплейтно
по-другому никак, дерайв-макрос не имеет доступа к другим типам
MB
Другой вопрос, что дерево все равно нужно хранить в памяти, поэтому сильного выигрыша нет.
P
по-другому никак, дерайв-макрос не имеет доступа к другим типам
но ведь для subcommand как-то работает
D
но ведь для subcommand как-то работает
а, ты имеешь в виду, что они могли бы это дело как-то встроить в structopt.. ну, наверное, да, но бойлерплейта бы от этого меньше практически не стало
P
а, ты имеешь в виду, что они могли бы это дело как-то встроить в structopt.. ну, наверное, да, но бойлерплейта бы от этого меньше практически не стало
ну смотри, для SceneType работает, а для RenderType — нет, хотя определения вариантов в принципе одинаковые, тоесть, достаточно реализации FromStr для вариантов.
P
а, ты имеешь в виду, что они могли бы это дело как-то встроить в structopt.. ну, наверное, да, но бойлерплейта бы от этого меньше практически не стало
AV
Другой вопрос, что дерево все равно нужно хранить в памяти, поэтому сильного выигрыша нет.
Оно же в куче хранится)
D
ну смотри, для SceneType работает, а для RenderType — нет, хотя определения вариантов в принципе одинаковые, тоесть, достаточно реализации FromStr для вариантов.
ну сделай, в чём проблема-то, код-то открытый :)
P
ну сделай, в чём проблема-то, код-то открытый :)
ну вот я и думаю, может оно сделано, но я не вижу, вроде бы очевидный кейс
D
дык сделано через arg_enum, это ж то же самое
D
что так надо оборачивать енум в макрос, что эдак, что так надо хинт у поля писать (
#[structopt(subcommand)]), что эдакP
дык сделано через arg_enum, это ж то же самое
case_insensitive = true мне кажется значит что оно берёт имена из имён вариантов, а не из аннотаций