LINUX.ORG.RU

Rust и создание больших массивов

 ,


3

6

Вот этот очень простой код потенциально легко вызовет stack overflow (если нет, то надо просто увеличить 16777216), хотя не должен (мы ведь на самом деле выделяем место в куче в итоге).

#[derive(Copy, Clone)]
pub struct Item {
    a: i32,
    b: i32
}

pub struct Items {
    items: [Item; 16777216]
}

impl Items {
    pub fn new() -> Items {
        Items {
            items: [Item { a: 0, b: 1 }; 16777216]
        }
    }
}

fn foo() -> Box<Items> {
    Box::new(Items::new())
}

Пруф: https://rust.godbolt.org/z/8sWsoKojx

Для Ъ: Массив сначала создаётся на стеке, а только потом выделяется память и происходит memcpy в кучу. Максимальные оптимизации не спасут.

К тому же не забываем про оверхед копирования. Я готов поверить разработчикам Rust, что копирование при создании структур из нескольких сотен байт не создаст заметной просадки, но я верю, что пример выше будет статистически значимо работать медленнее уже на нескольких тысячах элементов, а не обязательно 16 миллионов.

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

Мне нравится Rust последнее время, сколько я к нему присматриваюсь, но вот такая очевидная мелочь как copy elision не предусмотрена для типа системного языка... Или я просто всё делаю не так и Items::new надо писать как-то иначе?

★★★★★

Последнее исправление: KivApple (всего исправлений: 2)
Ответ на: комментарий от khrundel

C++ - отвратительный язык. Но ничего лучше с теми же преимуществами что и у C++ нам пока не завезли.

peregrine ★★★★★
()
Ответ на: комментарий от kvpfs

А ты добавь вызов в какой-нибудь библиотечный метод.

Хотя даже не в этом дело, цпп намеренно себе много не позволяет и запрещает двум объектам иметь один адрес. Тут можно много кейсов придумать - взял адрес объекта А, передал в lib.so, взял адрес объекта В, отдал туда же. А тут приходит раст и начинает всё оптимизировать (или же нет, если видит, что адрес утёк). Может я хотел мувнуть? А может нет? Один лишь я знаю в конкретном кейсе.

Короче, в общем попахивает это какой-то кривой фигнёй и радываться такой фиче я бы не спешил. Либо ваш мов лишь в тривиальных кейсах (что скорее всего), либо там грабли на граблях.

kvpfs ★★
()
Последнее исправление: kvpfs (всего исправлений: 1)
Ответ на: комментарий от kvpfs

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

[[no_unique_address]]

anonymous
()
Ответ на: комментарий от khrundel

Все понимают, что язык плохой. Все понимают, что язык плохой

«Хороших» языков в принципе не существует. Можно придраться к любому.

anonymous
()
Ответ на: комментарий от anonymous
 The attribute-token no_unique_address specifies that a non-static data member is a potentially-overlapping subobject (6.6.2 [intro.object]). It shall appear at most once in each attribute-list and no attribute-argument-clause shall be present. The attribute may appertain to a non-static data member other than a bit-field.

Example:
template<typename Key, typename Value,
         typename Hash, typename Pred, typename Allocator>
class hash_map {
  [[no_unique_address]] Hash hasher;
  [[no_unique_address]] Pred pred;
  [[no_unique_address]] Allocator alloc;
  Bucket *buckets;
  // ...
public:
  // ...
};

Here, hasher, pred, and alloc could have the same address as buckets if their respective types are all empty. — end example ] 
  1. «could have» Реализация может игнорировать атрибут, и при этом соответствовать стандарту. (Например, Visual Studio пока игнорирует этот атрибут, возможно будет поддерживать в VS 2025)

  2. Только если «their respective types are all empty». То есть, это лишь другой вариант empty base class optimization, которая уже есть в С++…

fsb4000 ★★★★★
()
Ответ на: комментарий от fsb4000

Например, Visual Studio пока игнорирует этот атрибут, возможно будет поддерживать в VS 2025

Вообще-то уже поддерживает, они в рамках 2019 выпускают крупные обновляения.

Только если «their respective types are all empty»

Ты цитируешь «Example», а не стандарт, может быть и не для пустых, объекты будут пересекаться в памяти.

anonymous
()
Ответ на: комментарий от fsb4000

https://imgur.com/a/Kuu10S6

MS в своем стиле, раньше выдавали предупреждение, что не поддерживают, потом написали, что в VS 2019 16.9 реализовано, но видимо по факту просто убрали предупреждение, ничего больше не сделав.

anonymous
()
Ответ на: комментарий от anonymous

Было «warning C4648: standard attribute 'no_unique_address' is ignored», а теперь то же самое, но без предупреждения, но формально все честно и записана поддержка аттрибута, вот же ленивые жопы :)

anonymous
()
Ответ на: комментарий от khrundel

Разница с Растом в том, что в Расте компилятор следит, чтоб ты не допускал некоторый класс ошибок.

Смотрим на эти потуги. Это именно то, о чём я говорил. Этих бездарностей дрессируют на то самое «раст всегда включает A&B» и одновременно на то, что «ну A&B» можно не юзать.

Ты не можешь заменить A&B на раст, только если эти свойства всегда существуют. Но они не существуют всегда, что я выше доказал.

И да, эту защиту можно обойти, но случайно ты этого не сделаешь.

Далее макака попыталась как-то это починить, но опять же. Выше что она блеяла? «ну не используешь A&B не получаешь». А тут вдруг какая-то защита, обойти её случайно нельзя и прочее блеяние. Как же так?

Так же смотрим за тем, как эта макака в очередной раз игнорирует большую часть моих аргументов.

Ведь я задал конкретный вопрос - почему в методички написано «раст - быстрый», при это имеется ввиду раст без A&B - это я доказал выше. А во второй строчке уже написать «раст гарантирует», при этом имеется ввиду раст с A&B. В рамках одной методички у нас два раста? Как же так?

anonymous
()
Ответ на: комментарий от anonymous

Так ты ни одного аргумента не привел, просто повторяешь другими словами тоже самое, что и твои оппоненты, делая вид что «это другое». Как был Д’Артаньян, так и остался. При всем этом, твоя душнота вообще смысла не имеет, так как не несет какой-то дополнительной смысловой нагрузки, ты просто выскочка хочешь всем доказать что лишь ты один единственный имеешь правильное представление о теме разговора, сдвг калека в чистом виде.

anonymous
()
Ответ на: комментарий от khrundel

В расте нет конструктора вектора принимающего массив. Тем более принимающего его по значению, чтоб в стек пихать. Ты превратишь массив в итератор и запустишь на нём функцию collect. Collect спросит о размере, так как итератор массива размер знает, будет зарезервировано достаточно места и вектор заполнится, а массив исчезнет. Ты вообще реально думал, что такой идиот как ты за 5 минут найдёт дыру в языке, разработанном умными людьми?

Зачем ты это повторяешь 10ый раз? Вектор это не то. Выкрутится можно, но если бы всё было так гладко в расте не было бы рфц на тему placement new.

Уже сказали выше несколько отличий. Box<(Vec<T>, X)> это две сущности на хипе Box<([T;N], X)> - одна. У вектора есть ещё куча лишних методов, которые топикастеру не нужны - у него размер не фиксированный. Больше подходит Box<[T]> но тут размер не константа компиляции.

Далее вот так тоже получается конструктор вектора из массива:

From<[T; N]> for Box<[T], Global>
From<Box<[T], A>> for Vec<T, A>

В итоге вообще вопрос к муву и копированию не относится. Вопрос относится к emplace конструкторам. Их может быть сделают в расте только для боксов, но тогда это локальный костыль будет, который не покроет все случаи.

technic93
()
Ответ на: комментарий от anonymous

Что-то ты, сцарёк, быстро слился в этом треде. Говорок уже не тот, напористости не хватает, трюков всё меньше. Наверное потому что осознал свою несостоятельность )))

Признай уже, что Rust будущее системной разработки, а твои плюсцы скоро выкинут на свалку. Людям нужны надёжные и универсальные инструменты, а не твой статический полиморфизм и многочасовая компиляция 100% ho проекта.

Кстати, кто желает потренироваться кодить на раст, можно запилить бложек и утереть нос сцарьку )))

anonymous
()
Ответ на: комментарий от kvpfs

Он вообще не про это говорил. Идея в том, что в раст у тебя для каждого типа есть мув, причём из коробки. А в плюсах ты должен написать тривиальную операцию руками, по дороге словив сегфолт и пару утечек памяти. И use-after-move исключается полностью, даже в unsafe.

anonymous
()
Ответ на: комментарий от anonymous

Признай уже, что Rust будущее системной разработки

У вас, людишек, уже нет никакого будущего. Вы чипированный скот который будет танцевать под дудку Шваба. В следющем году будут отключены эти ваши интернеты. Потом электричество. Вы запищите, но не долго. Потому что затем настанет голод. Вам нечего будет жрать, кроме как своих соседей. Наше климатическое оружие прошло все испытания. Темперратура будет поднята до +45. Многие територии будут затоплены. Остальные будут выженны. К сентябрю 2022 года, по вашему счёту, планета будет снова наша (хотя она и так уже наша). Те кто выживут будут нашими рабами. Число рабов будет равнятся 666666. Остальные отправятся за rust, то есть в небытиё.

anonymous
()
Ответ на: комментарий от anonymous

Рептилоиды с планеты Нибиру не одобряют твои высказывания и просят пройти в 6 палату.

peregrine ★★★★★
()
Ответ на: комментарий от anonymous

Идея в том, что в раст у тебя для каждого типа есть мув, причём из коробки.

В плюсах мув тоже из коробки и писать ничего не надо (ну в 95% точно), максимум что потребуется - удалить мув/копирование/или всё вместе.

А в плюсах ты должен написать тривиальную операцию руками, по дороге словив сегфолт и пару утечек памяти.

Бред

И use-after-move исключается полностью, даже в unsafe

Опять брехня какая-то, кто тебе сказал, что use-after-move это что-то запретное? Это абсолютно нормальный и лаконичный код:

string s = "init string";
ostringstream ssm{move(s), ios_base::ate};
ssm << 454;
s = move(ssm.str());

таскай ресурс в нужно место на здоровье.

kvpfs ★★
()
Ответ на: комментарий от kvpfs

В плюсах мув тоже из коробки

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

kvpfs ★★
()
Ответ на: комментарий от kvpfs

В плюсах мув тоже из коробки и писать ничего не надо (ну в 95% точно), максимум что потребуется - удалить мув/копирование/или всё вместе.

Ага, настолько не надо, что ты ниже в 4 строках написал его 2 раза. Фанаты крестцов такие фанаты.

Бред

Пок-пок-пок, бред, пок-пок-пок, никаких сегфолтов. Знакомая песня крестофанатиков.

Опять брехня какая-то, кто тебе сказал, что use-after-move это что-то запретное? Это абсолютно нормальный и лаконичный код:

Это может и лаконичный код, только проблему ты не проиллюстрировал. Где у тебя use-after-move? Постой ка, да ты не знаешь, как работает stringstream! Крестофанатик as is.

anonymous
()
Ответ на: комментарий от kvpfs

а в твоем недоязычке вообще никакого мува нет

Фанатик сцаря детектед! Сачки к бою!

если же капнуть глубже и разобраться, то обделаешь ты жидко и ретируешься с позором

капнуть

ахахах

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

Чувак, у тебя от волнения расстройство речи случилось. Успокойся, выдохни и напиши нормально, что сказать хотел.

anonymous
()
Ответ на: комментарий от kvpfs

в твоем недоязычке вообще никакого мува нет

use std::vec;
fn create_vector() -> Vec<i32> {
    let vect = vec![0, 1, 2];
    return vect;
}
fn append_vector(mut vector: Vec<i32>) -> Vec<i32> {
    vector.push(-1);
    return vector;
}
fn clear_vector(mut vector: Vec<i32>) -> Vec<i32> {
    vector.clear();
    return vector;
}
fn main() {
    let mut x = create_vector();
    x = append_vector(x);
    x = clear_vector(x);
}

Попробуй найти здесь копирование, если мува нет. Вот это и есть нормальный мув, а не move(), move(), move(), как в плюсцах.

anonymous
()
Ответ на: комментарий от anonymous
fn create_vector() -> Vec<i32> {
    let vect = vec![0, 1, 2];
    return vect;
}
fn append_vector(mut vector: Vec<i32>) -> Vec<i32> {
    vector.push(-1);
    return vector;
}
fn clear_vector(mut vector: Vec<i32>) -> Vec<i32> {
    vector.clear();
    return vector;
}
fn main() {
    let mut x = create_vector();//копирование миниму 1, реально сколько угодно.
    x = append_vector(x);//алаогично 2+
    x = clear_vector(x);//аналогично. 
}

Вот это и есть нормальный мув, а не move(), move(), move(), как в плюсцах.

Макака, в плюсах move никакого отношения к move не имеет. Я выше показывал тоже самое как в крестается мувается без мува.

В крестах возможно любая модель. Чини методичку, клоун.

К тому же в крестах это ненужно. В крестах везде пишется auto && и ничего не копируется. Ни объекты, ни хип. А у тебя копируются объекты десятки раз.

anonymous
()
Ответ на: комментарий от anonymous

Макака, в плюсах move никакого отношения к move не имеет.

Сцарёк припёрся. Где блог на крестах трепло?

Я выше показывал тоже самое как в крестается мувается без мува.

Это всё твои бредни, потому как весь существующий код без мува не мувать не будет, неуч-теоретик.

В крестах возможно любая модель. Чини методичку, клоун.

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

К тому же в крестах это ненужно. В крестах везде пишется auto && и ничего не копируется. Ни объекты, ни хип. А у тебя копируются объекты десятки раз.

И это правильно. Софт на раст просто работает, в то время как крестофанатики размышляют написать им &, && или по значению принимать.

anonymous
()
Ответ на: комментарий от anonymous

Ещё вопрос. Ты там как, несостоятельность-то свою осознал или нет? А то кукарекаешь много, а программ написал 0.

anonymous
()
Ответ на: комментарий от anonymous

Ты там как, несостоятельность-то свою осознал или нет?

Гм.
А может быть он состоятельный человек …

anonymous
()
Ответ на: комментарий от anonymous

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

anonymous
()
Ответ на: комментарий от anonymous

Видел. На ЛОР, каждый второй …

Проблема в том, что

Настоящих буйных мало.  
Вот и нету вожаков.
anonymous
()
Ответ на: комментарий от technic93

Зачем ты это повторяешь 10ый раз? Вектор это не то.

Это «то» во всех имеющих значение свойствах. Контейнер с компактным размещением и индексированным доступом O(1). А вот «но мне нужно через задницу, как в сишечке привык» - это как раз и «не то», это голову лечить надо.

но если бы всё было так гладко в расте не было бы рфц на тему placement new.

Если бы это было важно, добавили бы до 1.0.

Уже сказали выше несколько отличий. Box<(Vec, X)> это две сущности на хипе Box<([T;N], X)> - одна.

Внешний Box слайсу нужен только потому, что структура большая. Соответственно сравнивать нужно Box<([T;N], X)> и (Vec, X). Vec<(Vec, X)> при этом будет обладать локальностью, можно будет просматривать элементы и в зависимости от X выбрать в каком лазить по вектору.

Вообще, все мы понимаем, что ([T;N], X) не нужен. Сишникам нужен (X, [T; *]), не имеющий фиксированного размера.

khrundel ★★★★
()
Ответ на: комментарий от anonymous

Царь! Я решил избавить от тебя этот форум. Я опущу тебя и выложу в ютуб …

Владимир

Он сам себя давно опустил, поэтому у тебя ничего не получится 🤣

anonymous
()
Ответ на: комментарий от anonymous

Макака, в плюсах move никакого отношения к move не имеет.

Ну, доля правды в этих словах есть, move - это просто каст ссылки. Однако разработчики плюсов - не идиоты и этот move проектировали не в 50х, уже слышали что функция должна называться осмысленно. Назвали так именно потому, что вся эта мутотень с r-value ссылками и правилами, по которым параметр T&& foo по-умолчанию является T& поскольку у него есть имя, всё это нужно исключительно чтоб можно было наколхозить мув в языке с неявным автоматическим копированием.

крестах везде пишется auto && и ничего не копируется. Ни объекты, ни хип.

auto&&… Так это же скриптуха получается. Как так?

К тому же 1 раз std::move вверху забыл написать или std::forward в глубине и всё, дальше по вложенности ушла обычная ссылка и получай копирование вектора на пару мегабайт.

А у тебя копируются объекты десятки раз.

Поэтому и не нужно в структурки запихивать массивы. Но сишники никак не успокаиваются.

khrundel ★★★★
()
Ответ на: комментарий от anonymous

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

Прям про раст итория. Лозунги, громкие обещания, красивые методички, мама говорила, что он лучший. Но время шло, а «вау» в массах не произошло, остаётся лишь активно навязывать себя хоть куда-то как барышне под конец срока годности. Правда слетевшая корона и обгаженный зад - такой себе бэкграунд, логичный итог трёпа - да я сейчас приду и все умрут, да у меня … . А по факту даже мува нет, лишь активная оптимизация с удалением гарантий для прогеров, но не поможет везде, только что-то уровня хелоу ворлд написать.

kvpfs ★★
()
Последнее исправление: kvpfs (всего исправлений: 1)
Ответ на: комментарий от kvpfs

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

И у тебя стокгольмский синдром, судя по всему. Тебя там сцарёк осадил с std::variant, и ты теперь его изображать пытаешься. Лишнее доказательство того, что на плюсцах сидят манипулируемые неучи с раздутым самомнением.

anonymous
()
Ответ на: комментарий от anonymous

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

Я тебе детально объяснил почему расто подход не сработает везде, перечитай, если интересно. В итоге что-то работающее не везде, через раз, на то это и оптимизация компилятора, он её вообще не обязан делать, это вообще не заслуга раста ни разу, оптимизировать можно любой помоечный недоязычек.

kvpfs ★★
()
Ответ на: комментарий от kvpfs

он её вообще не обязан делать

Чего не скажешь о плюсах, кстати. Если у меня на выходе rvalue, то move будет железно

vector = create_vectore();
...
return vectore;
...
и подобное
kvpfs ★★
()
Ответ на: комментарий от kvpfs

Я тебе детально объяснил почему расто подход не сработает везде, перечитай, если интересно.

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

Ещё ты говорил что мува нет. Я тебе там пример по быстрому накидал, так ты снова ничего сказать не смог. Объект летает между стореджами, копирования нет, мува, по словам поехавших, тоже нет. Интересно, как это тогда работает.

С use-after-move так совсем эпично вышло. Оправдывайся теперь.

anonymous
()
Ответ на: комментарий от anonymous

С use-after-move так совсем эпично вышло.

Ну вообще-то там самый настоящий «use after move» стринга, которым ты здесь всех пугаешь.

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

kvpfs ★★
()
Ответ на: комментарий от kvpfs

Ну вообще-то там самый настоящий «use after move» стринга, которым ты здесь всех пугаешь.

Там нет use, там rewrite. Ты просто недостаточно знаешь плюсцы, ем и объясняются попытки защищать их недостатки.

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

Ну да, как сказать нечего, так сразу переубеждать бесполезно.

Кстати, у тебя опять стокгольмский синдром. Как только я сказал тебе про твои попытки копировать сцарька, ты сразу же перестал это делать. Вывод один - у тебя просто нет собственного мнения, ты примыкаешь к тому, кто тебе кажется наиболее сильным. Соответственно, и ценности у твоих слов нет.

anonymous
()
Ответ на: комментарий от anonymous

Там нет use, там rewrite. Ты просто недостаточно знаешь плюсцы, ем и объясняются попытки защищать их недостатки.

Вообще-то мовнутый объект остаётся валидным и я могу его использовать как угодно - вызывать size(), что ещё, оператор =. Короче это у тебя там какие-то пробелы.

Кстати, у тебя опять стокгольмский синдром. Как только я сказал тебе про твои попытки копировать сцарька, ты сразу же перестал это делать. Вывод один - у тебя просто нет собственного мнения, ты примыкаешь к тому, кто тебе кажется наиболее сильным. Соответственно, и ценности у твоих слов нет.

Это лучше, чем вовсе остаться незамеченным. Сейчас когда увидишь доклад на конференции «Cpp_cool_Rust_sucks» от какого-нибудь KelVin PeFoS - то сразу подумаешь: «не тот ли это парень, что размазал меня как ребёнка»?

kvpfs ★★
()
Последнее исправление: kvpfs (всего исправлений: 1)
Ответ на: комментарий от kvpfs

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

anonymous
()
Ответ на: комментарий от anonymous

Вот потому плюсовый подход в виде ручного мува в неочевидных местах - правильный, ибо иначе правильно все равно не сделать. То есть твой тезис - в цпп говно, а правильно так - ещё один пустой лозунг.

kvpfs ★★
()
Ответ на: комментарий от kvpfs

Во-первых не мой, во-вторых все говно, это если кратко.

anonymous
()
Ответ на: комментарий от kvpfs

Во-первых не мой, во-вторых все говно, это если кратко. Правильного нет, есть сорта говна.

anonymous
()
Ответ на: комментарий от kvpfs

Вообще-то мовнутый объект остаётся валидным и я могу его использовать как угодно - вызывать size(), что ещё, оператор =. Короче это у тебя там какие-то пробелы.

Ну да, ну да.

Это лучше, чем вовсе остаться незамеченным.

С точки зрения незрелого человека - да. Если других способов обратить на себя внимание нет, то можно и так. Но ценность слов при подобном поведении остаётся нулевой вне зависимости от мотивов.

Сейчас когда увидишь доклад на конференции «Cpp_cool_Rust_sucks» от какого-нибудь KelVin PeFoS - то сразу подумаешь: «не тот ли это парень, что размазал меня как ребёнка»?

ахахах, всё ещё хуже. С другой стороны, да - когда нет собственной системы ценностей, всё загадочное импонирует. Это всё те же фантазии, о которых я говорил - в глубине души надеешься, что это не просто сумашедший, а человек знающий больше обычного. И конечно же, ложная ассоциация «если я буду копировать внешнее поведение - стану таким же». К счастью, это проходит с возрастом и опытом.

anonymous
()
Ответ на: комментарий от anonymous

если я буду копировать внешнее поведение - стану таким же

Еслим вам там чего-то показалось, то это не значит, что я что-то целенаправленно копировал, это первое. Второе - все мы друг на друга влияем, и если некто говорит - «сектант обгадился», то почему я должен намеренно обходить этот оборот? Что бы тебе понравиться и твоим друзьям растоадептам? Я буду пользоваться тем, что считаю уместным, от царя, принца или от кого другого - без разницы. Ну и третье - странные претензии от людей, которые как школьницы бегут за модой и большими дядями, которые за раст вписались. Ваши адепты прямо говорили: «мелкомягкие за раст, значит и я в этой команде». И теперь мне про собственное мнение рассказывают? Для начала свое заимейте, потом и поговорить можно.

kvpfs ★★
()
Последнее исправление: kvpfs (всего исправлений: 2)
Ответ на: комментарий от kvpfs

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

ЛОЛ. Чё ты несёшь вообще? Оптимизация - это нечто, что по определению не меняет поведение программы. Нет, возможны, конечно, случаи, когда оптимизатор удаляет лишнее и это приводит к исчезновению переполнения стека, например, но в остальном неоптимизированная программа должна отработать корректно. Если отключая фичу ты получаешь сегфолт из-за двукратного вызова деструктора, то это явно была не оптимизация, а наоборот, какая-то важная часть языка.

Поэтому вы с псевдоцарём и дурачки: вам говорят о наличии в Расте мува на уровне языка. Это реально существующий функционал, компилятор Раста следит, чтоб структура не содержала случайно указателей на собственные поля (хотя это следствие борроучекера, тем не менее важное свойство для мува), Раст следит, чтоб после мува к источнику не обращались, в том числе не вызывался деструктор. Если я мувнул что-то, а потом попытался использовать, то я получу не предупреждение, а ошибку, язык требует не использовать после мува. Это очень простые правила, но именно они позволяют делать мув простым memcpy.

А что в ответ предлагаете вы? Рассказы что в плюсах тоже компилятор memcpy умеет вызывать и то, что в библиотеках для каждого конкретного случая умные дядьки реализовали для вас мув руками. Особенно это интересно на фоне того, что большинство плюсовых проектов это легаси, что там в 90х или нулевых наколхозили до вас неизвестно, в 90х вообще было модно аналоги вектора руками пилить, а в нулевых ещё перемещения не было. Работает там или не работает мув в этом говне мамонта - неизвестно.

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

khrundel ★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.