Си с классами

соорудите мне std::vector

Нет. Сперва ты сооруди на любимом своем языке без аллокаций похожую конструкцию и чтоб без аллокаций даже статических.

Вопросы уровня «соглашайтесь со мной или вон»? Нет уж, спасибо. Вы победили. Я сдаюсь.

google: rust traits

Статика, полиморфизм, без vtable. Всё как надо.

На форуме поселился фанат Оберона. Хорошо, прям как в благословенных 00-х. Ностальжи!

static const Derived derived;
std::vector<std::reference_wrapper<const Base>> v = {
  std::cref(derived)
};

чё тебе ещё соорудить? давай заказывай, у нас же тут стол заказов.

Динамический полиморфизм без vtable?

А ассемблерный листинг покажешь?

Вопросы уровня «соглашайтесь со мной или вон»?

Вы взялись рвать шаблоны. Но каким-то только вам понятным методом. Отсюда просьбы пояснить как именно вы эти самые шаблоны рвать собрались.

Не более того.

Я сдаюсь.

Флакон традиционно порвался. Рот зачем было открывать, если вопрос не вам адресовался? Но это риторический вопрос.

Вы победили. Я сдаюсь.

пакеда.

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

Следите за нитью разговора. Динамический конечно через vtable. Тут всё как в плюсах, только явно.

Статика, полиморфизм, без vtable. Всё как надо.

Не, так не пойдет.

Давай сооружай вектор из объектов, и чтобы эти объекты были статическими, а не динамичесие (динамически аллоцированные) объекты с изменяемым размером, и чтоб не содержали vtable.

vector конечно только через ссылки или указатели. Тут разницы нет между C++ и Rust нет.

разницы нет между C++ и Rust нет

В том то и дело. Что эти заумные закорючки в rust (&, mut, dyn, box, unbox и их сочетания) - это все лишь (не)сахар над такими же закорючками в c++ (&, *, std::smart_ptr и др). Разница в том, что неоднозначный анализатор borrow check насильно включен на уроне генерирования ошибок компиляциии. Вот вся разница. И эту разницу можно легко компенсировать, обмазавшись такими же неоднозначными статическими анализаторами для с++.

Ну а по делу высера есть что возразить, мне просто интересно.

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

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

По треду создаётся впечатление что понятного и читабельного кода на плюсах здесь почти никто не пишет.

Если коротко - наиболее эффективно улучшающее C подмножество плюсов - C++ без приватности, почти без своих шаблонов, без своих методов, без своих namespace, без наследования и виртуальности.

Но обязательно c автоматическим управлением ресурсов - RAII и готовыми классами из stl или boost, в т.ч. типизированными путями std::filesystem::path

Исключения - использовать для необрабатываемых ошибок, ловить только в считынах единицах мест - чтоб показать сообщение что «всё упало, завершаемся». Свои можно не делать, хватит std::logic_error, std::runtime_error

Почему именно так? Потому что все фичи, предлагаемые к НЕиспользвованию - по факту лишь направляют разработчика. То есть если УЖЕ есть умение не стрелять в ногу в C - то замена в хорошем C-коде функций на методы, макросов на шаблоны и длинных имён на namespace - даст незначительное повышение читабельности.

А вот использование RAII и stl-ных классов - делает код компатнее и более читабельным.

Насчёт RAII в отношении памяти более подробно.

• Переменная на куче - 95% std::make_unique
• Переменная на куче которая хрен знает когда удалится (плохой дизайн)- 4% std::make_shared
• malloc, free, new, delete, и boost::intrusive_ptr - оставшиеся 1% случаев.

Голые указатели никогда не должны владеть памятью. (Зачем?)

массив неизвестнной заранее длинны в 99% случаев через std::vector.

Нетривиальные коснтрукторы/деструкторы у структур - делать только в случае, если это обёртка над чем-то обеспечивающая RAII. И 1000 раз подумать, там есть много путей накосячить.

А вот структуры просто содержащие поля стандартных типов, классов и других структур - без проблем. Не передавать int x, int y, делать struct Point, это собственно и в C так.

И, да, в production я пишу и с теми фичами, которые тут забраковал. Они улучшают читабельность, но не столь сильно как RAII и stl, время на изучение окупится очень не бытсро. А RAII и понадобившиеся подмножество stl/boost - окупится очень быстро.

box, unbox

Вам приснилось. Нет такого. И речь изначально шла про трейты, аля концепты из C++20.

И эту разницу можно легко компенсировать

Ага, заодно ADT, паттерн матчин и выражения мне запилите. Я не уверен, что даже трейты можно повторить в С++20.

Трейты в расте - это динамически аллоцированная структура, уловно struct { type_t type; void* data; } + таблица виртуальных методов.

https://doc.rust-lang.org/reference/types/trait-object.html

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

+1

Раст мог еще выглядеть убедительно, если бы C++ продолжал стагнировать, а растеры смогли бы вкатить Раст как промышленный стандарт с чёткой спецификацией, а не с питон-стайл «реализация является спецификацией».

Но современный C++ делает эти потуги ненужными.

Царь, залогинся.

trait != trait object. Это разные вещи.

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

пофиксил во имя справедливости.

Раст, к сожалению, судя по всему ждёт судьба лиспа с его lisp curse. И дело даже не в стандарте с спецификацией, её не будет пока не будут строго определны правила по которым работает borrow checker, а это произойдёт скорее всего никогда.

А в чем дело?

С++ все равно не угонится за растом, но попытки неплохие.

дело в том, что там где хаос порядка нет, его нет и в С++, но этот ублюбок уже плотно прижился на теле IT, сможет ли такой же фокус провернуть маленькая горстка RUSTрельных жертв? Думаю, весьма сомнительно, не продавят ни хватит энтузиазма )

trait != trait object

Дело в том, что trait object как раз описывает как хранится trait.

Ты покажешь vector из traits? Без аллокаций и vtable? Посмотрим, как там решили вопросы std::variant с генерацией vtable в статике.

Так мономорфизация жеж. Параметр типа T с ограничением в виде трейта превращается в конкретный тип на этапе компиляции.

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

Тип T надо где-то хранить (type_t type). Естественно сами данные тоже надо где-то хранить (void* data). И таблицу «мономорфов» тоже надо где-то хранить (vtable).

И таблицу «мономорфов» тоже надо где-то хранить (vtable).

Хранить на этапе компиляции имеете ввиду?

Про что проект-то хоть?

Хранить на этапе компиляции имеете ввиду?

Хранить vtable - значит у тебя должно быть отображение (type, trait_func_index) -> func.

Так вы не ответили на вопрос, на каком этапе хранить это отображение? Если во время выполнения программы, то этого в Rust нет (для параметрического полиморфизма). Во время выполнения программа ничего не знает о типах, трейтах и прочем.

Во время выполнения программа ничего не знает о типах, трейтах и прочем.

И вытаскивает эти знания при помощи libastral?

Во время выполнения программы раст знает и тип и вызываемую функцию, и вытаскивает из таблицы соответствия (vtable) адрес конкретной реализации функции трейта для конкретного типа.

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

https://rust.godbolt.org/z/PrMP71 (131 строка ассемблера)

В каждом элементе вектора из трейта с одной функцией хранит

1. Адрес функции деструктора

2. Какие-то два числа

3. Адрес метода трейта.

 .quad   core::ptr::drop_in_place
        .quad   0
        .quad   1
        .quad   <example::Cat as example::Animal>::say

Еще раз: на этапе компиляции в следствии мономорфизации параметрический полиморфизм превращается в ad-hoc-полиморфизм, то есть генерируются конкретные реализации для конкретных используемых типов, а вся информация об обобщении стирается: https://godbolt.org/z/zcWj55

131 строка ассемблера

Делать мне нечего, кроме как ассемблер читать. Без этого знаю как это работает (должно). На 100% уверен, что std::visit (аналог трейтов) будет работать намного быстрее.

Конечно, потому что вы используете трейт-объекты, а не параметрический полиморфизм.

Спасибо кэп,

В принципе да

На этом принципиальном согласии можно было и остановиться :)

Ты неоптимизированный вариант показывай, а лучше даже неоптимизированный llvm байт-код. А не то что llvm наоптимизировал, сам rust-то практически туп и в оптимизации на уровне языка ничего не умеет.

И у тебя не вектор (массив) трейтов, а легко выводимые на стадии компиляции конкретные функции. Что ты хотел показать?

Вам сказали, что trait != trait object. Хотите использовать trait object и динамическую диспетчеризацию? Пожалуйста. Только не надо их совать тем, кто обходится одними trait в параметрическом полиморфизме со статической диспетчеризацией.

fn foo() -> Vec<dyn Trait> { ... }

fn foo<T: Trait>() -> Vec<T> { ... }

Чувствуете разницу?

Чувствуете разницу?

Убери оптимизацию ‘-O’ из флагов для компилятора и почувствуй разницу.

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

Убрал, и что?

А вектор где?

А для кого std filesystem?

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

На этом принципиальном согласии можно было и остановиться :)

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

Бери C++ и пиши. Однако, если тебе не нужно C++, то бери Python3.7+ или C#, если религия позволяет.

ЗЫ

Если мсье знает толк, то можно взять Rust, но надо познать толк и быть готовым к нему.

Опа как царь-то жопой заелозил. Уже и оптимизацию ему выключи и байткод ему не кошерный.

Прописываю Царю глистогонное!

Начинаю проект (личный), выбираю на чём писать: C или C++

Хочешь, рецепт борща дам?

Это дин. полиморфизм. Аноним про другое.

Еще раз: на этапе компиляции в следствии мономорфизации параметрический полиморфизм превращается в ad-hoc-полиморфизм, то есть генерируются конкретные реализации для конкретных используемых типов, а вся информация об обобщении стирается

Я не уверен, что даже трейты можно повторить в С++20.

Это просто частичная специализация + проверка что специлизация существует, транслируется на С++, почти строчка в строчку:

https://godbolt.org/z/8Gn86v

Это можно повторить даже на С++98(более многословно, но шаблоны Тюринг полны, так что возможно всё…)