Comments 20
Несмотря на вдохновенное выступление, автору так и не удалось убедить меня в необходимости массового копирования иммутабельных данных. Использовать строки в качестве идентификаторов, копируя их по значению? Хорошо ли это, правильно ли? Зря что ли придуманы хэши и атомы?
Атомарный Rc в однопоточном коде, отличный совет, а главное нулевой оверхед. Если автор не понимает даже этого и вообще никак не упоминает обычный Rc, такая огромная статья от него не заслуживает прочтения
В целом совет хороший, но очевидный: если никак не модифицируете массив, то не делайте его расширяемым, чтоб не тратить ресурсы на capacity. Но так Rc тут ничем не особен: сравнение можно было проводить и с Box, а другие контейнеры упомянуть в одном пункте
Но ведь автор упоминает
Подскажите, пожалуйста, в каком месте/пункте?
В самом начале, в разделе "Arc<str> vs String" целый абзац посвящен как раз Rc.
А, хорошо, спасибо, был неправ. Тогда моя претензия в том, что автор решил указать везде менее оптимальный, но работающий в большем числе случаев способ, хотя говорит о системном языке. Казалось бы, философия всего этого направления в том, чтобы так не делать: выжимать из кода всю производительность и понимать устройство того, чем работаешь. А об оптимальном варианте автор лишь оговорился в одном абзаце, который невозможно заметить при беглом просмотре, в пункте, который вообще не про это. Но абзац хороший, да, просто находится не там, где хотелось бы (а именно в самом начале)
А в сложном и небезопасном С++ ребята долго запрягали, и таки ввели move-семантику, чтобы не натягивать сову на глобус, и не использовать shared ptr как костыль в данном случае.
Но ведь в Rust move-семантика вшита в язык по дефолту. А статья вовсе не про то как замувить, а про то как дешево копировать. Ну и последняя глава как раз про Box<str> для тех, кто хочет мувить
Я так понимаю, на Хабре присутствует жесткая сегрегация по языкам, и в теме про богоугодный РАСТ все неистово минусуют любому, кто не считает его хорошим ЯП?
Ну ОК.
Что значит "move-семантика вшита по дефолту"? В С++ для true rvalue это тоже "по дефолту". Но как быть с пользовательским типом?
Или если ты хочешь мувнуть именованную переменную, зная что она тебе больше не понадобится? Какой может быть "дефолт" в данном случае?
Чтобы "дешево копировать" - прожженным РАСТаманам для этого нужны целые статьи?
Что значит "move-семантика вшита по дефолту"?
y = x // это мув в Rust - x мувится в y и больше к нему нельзя обратиться
Возможно, поэтому и минусуют, потому что штуки вида "С++ ребята долго запрягали, и таки ввели move-семантику", "натягивать сову на глобус" вызывают недоумение и непонимание, поскольку они нерелевантны ни по отношению к Rust, ни по отношению к тому, что излагается в статье.
Ибо у Rust move-семантика есть с самого начала языка как ключевая фича, а статья так и вовсе не про мув-семантику. Поэтому не ясно, к чему вы ведете, где здесь сегрегация (я С++ программист, если что), и главное — как ваши слова связаны со статьей?
Далее по тексту часто будет употребляться термин "копирование", но в этой статье под ним подразумевается исключительно операция Clone::clone()
В чем проблема использовать общепринятый термин "клонировать"?
Если честно, я было начал с "клонировать", но быстро стушевался, потому что когда увидел на русском много слов "клонировать, клонировать", мне показалось, что я сумасшедший ученый, клонирующий людей. Насчет общепринятости в русском языке тоже засомневался, "копировать" выглядело более приемлемым.
В общем, если отвечать на вопрос "в чем проблема?", то скорее всего во мне)
когда увидел на русском много слов "клонировать, клонировать", мне показалось, что я сумасшедший ученый, клонирующий людей
В принципе, термин "клонировать" подходит идеально, ведь по сути он означает, что вы создаёте клон из другой материи, но с идентичными свойствами и характеристиками. Копирование, в данном случае, не очень подходит, т.к. это иной процесс.
Да и клонировать можно не только людей, в основном клонируют не их) Также и в расте, т.к. он - объектный ЯП, то логично, что там можно клонировать объекты какого-то типа. И, если уж вам захочется, то можно и создать тип "Person" (или "Human", раз аналогия биологическая) и клонировать их, уж это не запрещено всеми странами мира)))
Во время прочтения меня не покидала всего одна мысль: а почему нельзя было взять обычную ссылку, раз данные всё равно иммутабельные?.. А оригинальную строку аллоцировать в каком-нибудь AllMonsterIdVec.
Потому что подход спорный, и макаронистый, в какой то момент данные могут и вовсе оказаться полностью не нужны, и придётся продумывать способ, как их удалить, и как отслеживать, что данные были удалены, и обращаться к ним не нужно.
И придётся ещё аннотировать времена жизни частенько, чтобы компилятор был уверен, что объект на который ваша ссылка, жив на протяжении всего времени, что на него ссылаются.
Коротко
Вариант из статьи: Объект валиден - пока на него есть хотя бы одна ссылка в любой части программы, и сам удалится из памяти, когда последняя ссылка будет удалена.
Вариант ваш: Ссылки валидны - пока объект существует, если объект не нужен, вам нужно точно точно убедиться, что он больше не нужен ни в одной части программы, и удалить все ссылки на него прежде чем удалить оригинал
Используйте Arc<[T]> вместо Vec<T>