Не AnyAny едины, есть еще похожая реализация этого подхода, которая вроде как обещает избавить от ручного заполнения VTable на каждый трейт (не ииспользовал в бою, но выглядит интересно на первый взгляд):
Но подозреваю, автор хотел сказать, что вызвав print_array ещё раз после push_back функция пройдётся по всему вектору нового размера. Хотя это конечно очевидно, ведь просто два разных span подаётся в эту функцию
Эммм, ну там как бы implicit конструктор std::span вызывается при вызове print_array (обратите внимание на сигнатуру функции). Вы не видите, а он есть))
Хотя конечно, стоило написать, что std::spand неявно может конструироватся от std::vector
Это не совсем так, пока еще пропозал в стандарт не приняли, но они предлагают как интроспекцию (о чем вы говорите) так и полноценную кодогенрацию, ничем почти не ограниченную. Рекомендую этот видос с cppcon, от человека реализовашего пропозал в форке EDG:
Я всё таки имел ввиду, что в р*ст c implicit move и borrow check не позволит вам сделать вот такую вещб:
fn foo(Vec<i32> x) {
!println("{}", x);
}
fn main () {
let x = vec![1, 2, 3];
foo(x);
// ... smth
foo(x); // compilation failed
}
Хотя в C++ аналогичный код скомпилируется, и сделает две лишние аллокации. А в р*сте надо как минимум в первую функцию добавить x.clone() , чтобы скомпилировать, а во вторых из-за implicit move будет всё равно на аллокацию меньше чем в С++, т.к. там explicit move для lvalue.
И мне кажется, что "оратор выше" как раз это и имел в виду, что implicit move в rust всё таки тяготит пргромистов либо явно копирование звать, либо принимать что-то по ссылке.
И на практике, я довольно таки много мест в рабочем проекте на C++ подчищал за неумелыми погромистами, которых не смущало передавать вектор в фу-ию по значению, чисто для readonly целей
Как будто вы тут в заблуждение вводите. Очевидно что move для структур с тривиальными типами в полях ничем не будет отличаться от copy. Но это обычно и не создаёт проблем (но опять же, если дурак будет по значению жирные структуры подавать, то ни rust, ни c++ тут не спасут).
Если бы в примере использовалась бы структура владеющая дин. памятью, то тут бы implicit move дал бы выйгрыш по числу аллокаций по сравнению с C++, где для того же эффекта надо было бы звать для аргумента std::move явно
Но ведь и учебники по математике тоже пишутся на каком-то языке, да и формулы имеют свой синтаксис и семантику. Так что без этой самой лингвистики вообще никуда с передачей информации между людьми)
Не AnyAny едины, есть еще похожая реализация этого подхода, которая вроде как обещает избавить от ручного заполнения VTable на каждый трейт (не ииспользовал в бою, но выглядит интересно на первый взгляд):
https://github.com/microsoft/proxy
Но вообще, с рефлексией C++26 это дело можно будет здорово так автоматизировать, осталось только дождаться реализаций))
Я не автор)
Но подозреваю, автор хотел сказать, что вызвав print_array ещё раз после push_back функция пройдётся по всему вектору нового размера. Хотя это конечно очевидно, ведь просто два разных span подаётся в эту функцию
Эммм, ну там как бы implicit конструктор std::span вызывается при вызове print_array (обратите внимание на сигнатуру функции). Вы не видите, а он есть))
Хотя конечно, стоило написать, что std::spand неявно может конструироватся от std::vector
Это не совсем так, пока еще пропозал в стандарт не приняли, но они предлагают как интроспекцию (о чем вы говорите) так и полноценную кодогенрацию, ничем почти не ограниченную. Рекомендую этот видос с cppcon, от человека реализовашего пропозал в форке EDG:
https://youtu.be/wpjiowJW2ks?si=OHtr9sdDYPfBhJz3
Я всё таки имел ввиду, что в р*ст c implicit move и borrow check не позволит вам сделать вот такую вещб:
Хотя в C++ аналогичный код скомпилируется, и сделает две лишние аллокации. А в р*сте надо как минимум в первую функцию добавить
x.clone(), чтобы скомпилировать, а во вторых из-за implicit move будет всё равно на аллокацию меньше чем в С++, т.к. там explicit move для lvalue.И мне кажется, что "оратор выше" как раз это и имел в виду, что implicit move в rust всё таки тяготит пргромистов либо явно копирование звать, либо принимать что-то по ссылке.
И на практике, я довольно таки много мест в рабочем проекте на C++ подчищал за неумелыми погромистами, которых не смущало передавать вектор в фу-ию по значению, чисто для readonly целей
Как будто вы тут в заблуждение вводите. Очевидно что move для структур с тривиальными типами в полях ничем не будет отличаться от copy. Но это обычно и не создаёт проблем (но опять же, если дурак будет по значению жирные структуры подавать, то ни rust, ни c++ тут не спасут).
Если бы в примере использовалась бы структура владеющая дин. памятью, то тут бы implicit move дал бы выйгрыш по числу аллокаций по сравнению с C++, где для того же эффекта надо было бы звать для аргумента std::move явно
"чуть более многословное", а под спойлером 124 строчки кода вместо 10 )))
Но ведь и учебники по математике тоже пишутся на каком-то языке, да и формулы имеют свой синтаксис и семантику. Так что без этой самой лингвистики вообще никуда с передачей информации между людьми)