"Если посмотрите ассемблерный выход то там ничего кроме ++/-- счётчиков-флажков и проверок указателей / переменных в стеке больше и нет. "
Если вкратце Rust вам не даст собрать чушь (без unsafe), он прямо скажет в чём проблема, и не даст никакого ассемблерного выхода, куда вы смотреть собрались, он научит правильно мыслить, а плюсы - приватное виртуальное наследование? исключение из исключения? Use after free? Конечно, дорогой, вот тебе бинарничек, используй на здоровье
В принципе у Вас здоровое мнение, ничего плохого не вижу, проблемой плюсов тоже считаю легаси, но взгляните на Си, они хоть и имеют легаси куда большую, я бы предпочтитал писать на них - потому что не метались за совершенное, я открываю С++ теряюсь в их glvalue, xvalue, prvalue, одна move-семантика чего стоит, у вас на руках была нормальная move-семантика, нет нужно изобретать свою, лишь бы работало старое, дальше initialization list, что это? В каких скобках {} или () какой из убойного набора конструкторов вызовется, ну честно, какие-то гикки до хрипоты спорят... Как на этом писать, в Rust невозможны вопросы "что выведет эта программа", там все инструкции явные, сильная, статическая, строгая типизация, никаких неявных преобразований, что написано то и будет
"Здесь мы явно говорим, — эта функция существует только для тех типов T, которые удовлетворяют концепту std::equality_comparable, и если попытаться вызвать её с типом, у которого нет оператора ==, компилятор не будет пытаться «протащить» нас внутрь шаблона, а сразу сообщит: ограничение не выполнено — данный тип не является сравнимым на равенство."
Очевидно какая-то попытка получить аналог трейтов из Rust, аля PartialEq, только в отсутствие сильной типизации на уровне компилятора прикрутить типы для типов выглядит как костыль
Чего вы тут обсуждаете вообще не ясно, вы работали в этом направлении как надёжность в embedded? Какое там нах-н C++, где даже непонятно сколько бит займет int по стандарту, убойный набор конструкторов и пойми что где вызовется в initialization list с такими скобками или с такими, у нас в надёжности принципы DRY, KISS, YAGNI, LL(1), только первому удовлетворяют плюсы, остальные мимо
"какие именно ошибки программирования способны снизить защищенность системы"
Очевидно ошибка в выборе плюсов, это как ты достал дробовик, зарядил и направил себе в колено и ждёшь что может быть что-то хорошее, ну вот когда ты пишешь какой-то там абстрактный адаптер с приватным наследованием неужели не понятно что где-то ты свернул не туда и не пора ли посмотреть на Rust?
Убрал строчку с макросом и нормально скомпилировались, намекает что есть неиспользуемое, но бинарничек дал
Да вообще что тут обсуждать если r иммутубельная, а вы про время жизни...
Вот попробуйте
fn main() {
let mut r;
{
let x = 5;
r = &x; // ошибка: x живет меньше, чем r
}
r = &7;
println!("{r}");
}
Собирается за силу душу, не смотря на вашу ошибку, эту строчку не тронул, таким приемом вполне можно пользоваться, чтобы ограничить тип r ссылкой на что-то
typedef struct {
uint32_t id;
uint32_t value;
} item_t;
uint64_t sum_values(const item_t *items, size_t n) {
uint64_t sum = 0;
size_t i = 0;
// простой цикл, который компилятор может векторизовать
for (; i + 3 < n; i += 4) {
sum += items[i].value;
sum += items[i+1].value;
sum += items[i+2].value;
sum += items[i+3].value;
Ужасная у вас тут векторизация, куча кэш-промахов будет, я бы за такое увольнял как профнепригодного, тут Struct of Arrays нужно, а не AoS
Не знаю о чём вы, но аллокаторов много разных бывает, хотите свой пишите, Rust явно не ограничивает вас, это не относится к языку вообще никак, пишите no_std и он не будет выделять в куче вообще ничего сам, как и в Си вообще никакого аллакатора нет и что? В ядре ОС никто в здравом уме не будет пользоваться динамическим распределением памяти, это приведёт к жёсткой дефрагментации
"Если посмотрите ассемблерный выход то там ничего кроме ++/-- счётчиков-флажков и проверок указателей / переменных в стеке больше и нет. "
Если вкратце Rust вам не даст собрать чушь (без unsafe), он прямо скажет в чём проблема, и не даст никакого ассемблерного выхода, куда вы смотреть собрались, он научит правильно мыслить, а плюсы - приватное виртуальное наследование? исключение из исключения? Use after free? Конечно, дорогой, вот тебе бинарничек, используй на здоровье
Что значит "хотя бы", Ньютона большая часть мира Айзеком называют, это у нас почему-то Исаак
У вас какая-то развлекуха заставлять llm то складывать числа, то в шахматы играть?
Был на соревнованиях по гольф-кодингу, Perl там вполне себе на равных с Ruby идёт)
В принципе у Вас здоровое мнение, ничего плохого не вижу, проблемой плюсов тоже считаю легаси, но взгляните на Си, они хоть и имеют легаси куда большую, я бы предпочтитал писать на них - потому что не метались за совершенное, я открываю С++ теряюсь в их glvalue, xvalue, prvalue, одна move-семантика чего стоит, у вас на руках была нормальная move-семантика, нет нужно изобретать свою, лишь бы работало старое, дальше initialization list, что это? В каких скобках {} или () какой из убойного набора конструкторов вызовется, ну честно, какие-то гикки до хрипоты спорят... Как на этом писать, в Rust невозможны вопросы "что выведет эта программа", там все инструкции явные, сильная, статическая, строгая типизация, никаких неявных преобразований, что написано то и будет
"Здесь мы явно говорим, — эта функция существует только для тех типов T, которые удовлетворяют концепту std::equality_comparable, и если попытаться вызвать её с типом, у которого нет оператора ==, компилятор не будет пытаться «протащить» нас внутрь шаблона, а сразу сообщит: ограничение не выполнено — данный тип не является сравнимым на равенство."
Очевидно какая-то попытка получить аналог трейтов из Rust, аля PartialEq, только в отсутствие сильной типизации на уровне компилятора прикрутить типы для типов выглядит как костыль
Что там учить? Если в языке есть приватное наследование, то скорее таких учеников нужно проверять на психическое здоровье
Надёжность языков в embedded:
1) Erlang/Elixir
2) rust, fpc, vhdl, ada
3) Си
Чего вы тут обсуждаете вообще не ясно, вы работали в этом направлении как надёжность в embedded? Какое там нах-н C++, где даже непонятно сколько бит займет int по стандарту, убойный набор конструкторов и пойми что где вызовется в initialization list с такими скобками или с такими, у нас в надёжности принципы DRY, KISS, YAGNI, LL(1), только первому удовлетворяют плюсы, остальные мимо
Работали, всё что он вытворял - лишние движения, достаточно было иметь китайский логический анализатор за 10 баксов
Пролог и Кобол, мммм ляпота, Потерянные люди... Я пытался на них писать, мозг сопротивляется, прямо говорит мне ты что-то не то делаешь...
"какие именно ошибки программирования способны снизить защищенность системы"
Очевидно ошибка в выборе плюсов, это как ты достал дробовик, зарядил и направил себе в колено и ждёшь что может быть что-то хорошее, ну вот когда ты пишешь какой-то там абстрактный адаптер с приватным наследованием неужели не понятно что где-то ты свернул не туда и не пора ли посмотреть на Rust?
LLM дектед, вам даже лень было корректировать что ли?
Убрал строчку с макросом и нормально скомпилировались, намекает что есть неиспользуемое, но бинарничек дал
Да вообще что тут обсуждать если r иммутубельная, а вы про время жизни...
Вот попробуйте
Собирается за силу душу, не смотря на вашу ошибку, эту строчку не тронул, таким приемом вполне можно пользоваться, чтобы ограничить тип r ссылкой на что-то
Походу вы не поняли Rust, ошибка будет на попытке распечатать r
"Если ты готов пыхтеть над задачей часами, а то и днями — велкам в разработку."
Интересами родного цеха жить обязан ты...
Неужели в самом деле я для этого рождён?
"Кодить" может любой, программировать не каждый, ну это примерно как говорить на русском можно любого идиота научить, в вот писать как Лев Толстой...
Ужасная у вас тут векторизация, куча кэш-промахов будет, я бы за такое увольнял как профнепригодного, тут Struct of Arrays нужно, а не AoS
Отключайте аллокатор, в чём проблема, он не будет ничего аллоцировать, как в чистом Си, проблема аллакатора не имеет отношения к языку
Ни одно из этого не входит в стандарт Си и нигде в языке не упоминается, аналогично можно приписать что проблема С в баге какого-то модуля firefox
Не знаю о чём вы, но аллокаторов много разных бывает, хотите свой пишите, Rust явно не ограничивает вас, это не относится к языку вообще никак, пишите no_std и он не будет выделять в куче вообще ничего сам, как и в Си вообще никакого аллакатора нет и что? В ядре ОС никто в здравом уме не будет пользоваться динамическим распределением памяти, это приведёт к жёсткой дефрагментации