Вышел Rust 1.23

DSP есть без байтовой адресации. Впрочем никто не мешает сделать как в С для pdp-10 с семибитными байтами, упакованными по пять штук в 36-жирное слово.

DSP есть без байтовой адресации.

Эм, какой же?

Впрочем никто не мешает сделать как в С для pdp-10 с семибитными байтами, упакованными по пять штук в 36-жирное слово.

Ну т.е. Вы признаете, что нет современных процессоров с байтом размерностью <> 8 бит и машинным словом не 32\64.

TMS320C54x - это первый попавшийся

ещё вспомни про 31битный s390... ненужно. есть [ui]128

Есть ещё другие компиляторы, например mrustc

ещё вспомни про 31битный s390

s390 - 32битовый; 31 бит - это разрядность адреса.

DSP есть без байтовой адресации.

Эм, какой же?

NM6403 и некоторые линии TMS320

т.е. Вы признаете, что нет современных процессоров с байтом размерностью <> 8 бит и машинным словом не 32\64.

В MSP430 16-бит слово. И на нем даже есть кое-какой Rust.

Окей, по сути надо будет клонировать, да.

Не совсем то

Есть ещё другие компиляторы, например mrustc

«In-progress», «mrustc works by comping assumed-valid rust code (i.e. without borrow checking) into a high-level assembly (currently using C)» - нет.

«mrustc works by comping assumed-valid rust code (i.e. without borrow checking) into a high-level assembly (currently using C)» - нет.

И что с этим не так?

И что с этим не так?

Т.е. компилятор, который успешно компилирует невалидный код, не вызывает никаких вопросов?

Т.е. компилятор, который успешно компилирует невалидный код, не вызывает никаких вопросов?

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

Он пишется для целевых платформ, где нет LLVM, так что нет, не вызывает

Это откуда? В описании «This project is an attempt at creating a simple rust compiler in C++, with the ultimate goal of being a separate re-implementation». И в планах есть и проверки, и LLVM и пр. Так что это просто проект на раннем этапе, и что из него выйдет, и не забросят ли его, будет видно только потом.

ты просил компилятор rust, который будет работать там где нет llvm.

ты просил компилятор, который будет работать там где нет llvm.

Во-первых я ничего не просил, во-вторых не надо записывать каждый проект с github в список альтернатив, особенно, если он еще только в разработке и не было ни одного релиза.

Он пишется для целевых платформ, где нет LLVM, так что нет, не вызывает

Это откуда?

Это с reddit.

with the ultimate goal of being a separate re-implementation

ultimate

В неопределенном будущем.

Так что это просто проект на раннем этапе, и что из него выйдет, и не забросят ли его

Да. Но сейчас он есть.

одно время у них были типы int/uint полностью аналогичные C-шным, как я понимаю

Вроде аналогичный uintptr_t, всё таки инты сейчас везде (или почти везде) 32 бита.

И ещё вопрос - как у Rust с поддержкой типа long double который 80 бит?

Я так полагаю идеально: поддержки нет совсем, но можно реализовать библиотекой,перегрузить все операторы и компилятор всё заинлайнит.

Возможно, хотя imho, uintptr_t это не совсем int. Это что-то, что может вмещать как int, так и адрес. Для реального режима 86 процессора, он-бы был (если-бы тогда о нём озаботились), например, 32 бита, несмотря на то, что int там - 16 бит, ну и сейчас, насколько я понимаю, для x86_64 в Unix-ах (LP64) int вполне себе 32 бита, а uintptr_t - 64.

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

NM6403

С wiki =>

Разработан в 90-х годах, изготовлен в 1998 году на фабрике Samsung.

Второй же

It was introduced on April 8, 1983 through the TMS32010 processor, which was then the fastest DSP on the market.

Я писал ранее =>

Ну т.е. Вы признаете, что нет современных процессоров с байтом размерностью <> 8 бит и машинным словом не 32\64.

Чувак, первому DSP уже 20 лет, какой разумный человек будет его использовать в проекте? Я уже не говорю, что второму 35 лет. Если для Вас это офигительно современный процессор, то мне Вас жаль

TMS320C54x

1998 года, офигительно современные у Вас примеры с анонимусом

1998 года, офигительно современные у Вас примеры

Эти процессоры до сих пор выпускаются, так что да, они современные.

Чувак, первому DSP уже 20 лет, какой разумный человек будет его использовать в проекте?

Ну вот, началось - выши доказательства не доказательства.

Ну вот, началось - выши доказательства не доказательства.

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

А по теме объективно, современных архитектур нет где бы int был не в 4/8 байт. А современный байт исключительно 8 бит.

Вывод из этого, что поддержка иной битности в байте и плавающая от платформы размерность чисел - это атавизм. И Си не имеет значимого преимущества перед Rust'ом. Ну конечно, если Вам вдруг не захотелось по программировать для Cray-1 или ранних PDP, но на сколько я знаю, за это сейчас денег не платят.

Именно поэтому drop превратился в финализатор, как и в других языках программирования с автоматическим управлением памяти

Астановись

Ну закидай меня ещё в добавок тупыми вопросами.

У меня нет к тебе вопросов.

если Вам вдруг не захотелось по программировать для Cray-1 или ранних PDP, но на сколько я знаю, за это сейчас денег не платят.

Кстати, хорошее определение «современного процессора» - тот, за программирование на котором платят деньги.

Можно же сделать swap(self, &emptyObjectSomewhereElse)

1) В сравнении с плюсами, rust не предоставляет ничего особенного, т.к. концепция rust - есть всего-навсего плюсовое RAII, сделанное обязательным

2) Несмотря на то, что RAII в rust вроде бы обязательно, rust не может контролировать его обязательность по всему проекту, т.к. есть unsafe => как и в случае с плюсами без кодгайдов не обойтись

3) Это отдельный язык, для которого существует отдельный компилятор и вместо того, чтобы улучшать компиляторы для уже существущих языков, ребята продолжают пилить 115-й язык.

4) Его придётся учить. Зачем?

5) Плюсы ругают за закорючки и невменяемые сообщения об ошибках, в раст это не поправлено.

6) убогое ООП по сравнению с плюсами

из всех сишкозаменителей: D, Go и плюсов раст выглядит самым плохим вариантом, т.к. достоинств перед ними у него нет, а недостатки есть, хотя каждый из его недостатков по отдельности не критичен.

из всех сишкозаменителей: D, Go и плюсов раст выглядит самым плохим вариантом, т.к. достоинств перед ними у него нет, а недостатки есть, хотя каждый из его недостатков по отдельности не критичен.

Как хорошо, что borrow checker и lifetimes уже давно внедрили во все указанные языки, а твой пост не эталонное 4.2.

1) В сравнении с плюсами, rust не предоставляет ничего особенного, т.к. концепция rust - есть всего-навсего плюсовое RAII, сделанное обязательным

Это, конечно же, вранье. Из того, чего в Си++ нет совсем, в Rust есть pattern matching, лайфтаймы и модули.

2) Несмотря на то, что RAII в rust вроде бы обязательно, rust не может контролировать его обязательность по всему проекту

unsafe отключается прагмой или (если нужно по всему проекту) отыскиваются стандартным линтером.

5) Плюсы ругают за закорючки и невменяемые сообщения об ошибках, в раст это не поправлено.

Сообщения об ошибках в Rust вполне вменяемы.

Из того, чего в Си++ нет совсем, в Rust есть pattern matching, лайфтаймы и модули.

Вот Pattern matching, как ни странно, есть: https://github.com/solodon4/Mach7. Но да, это не из коробки и boost::variant в зависимостях.

Это proof of concept, не более. Ждем C++26... или не ждем.

Вот Pattern matching, как ни странно, есть: https://github.com/solodon4/Mach7

Этот pattern matching умеет матчить что-то, кроме variant? А проверка на exhaustiveness в нем есть? А можно уточнить case условием? Если нет, то это Си++-акробатика, а не pattern matching. Это лучше, чем ничего, но это эрзац.

pattern matching плюсах делается на макросах, lifetimes - частный случай RAII, a модулей действительно нет, но они есть в D и Go и я не стал упоминать про эту мелочь

отыскиваются стандартным линтером

так случаи нераишного использования плюсов вообще грепом по исходникам легко найти (ну ладно, придётся всё же написать небольшой скриптик)

lifetimes - частный случай RAII

фейспалм.жпг

по поводу ошибок: наверное поэтому самый популярный запрот о раст «Why does Rust borrow checker reject this code?»

Оба - попытки сделать RAII обязательным. Если бы не unsafe, то достаточно успешные.

Оба - попытки сделать RAII обязательным

Обязательный RAII можно сделать и в плюсах запретом на new, delete и указатели. Но от этого lifetimes и borrow checker в плюсах не появится, а твой коммент не перестанет быть 4.2

Обязательный RAII можно сделать и в плюсах

можно

запретом на new, delete и указатели

Ясно. Рекомендую вам всё же ознакомиться с концепцией RAII.

от этого lifetimes и borrow checker в плюсах не появится

они станут не нужны, т.к. всю их работу возьмёт нв себя RAII, причём с меньшим геморроем

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

На stackoverflow описаны причины нескольких классов таких ошибок и как от них избавиться. И это, похоже, уже большинство классов ошибок - новые появляются редко.

можно

Ну же, продемонстрируй

Рекомендую вам всё же ознакомиться с концепцией RAII.

А тебе всё же стоит ознакомиться с lifetimes и borrow checker в Rust

Ну так это и будет копирование. Причём такой swap надо будет реализовывать самому: в этом разница мувов раста и плюсов. В плюсах на уровне синтаксиса нет понятия перемещения, есть просто особый вид ссылок и перегрузка. То, что это перемещение, для класса нужно реализовать самому. В Расте перемещения реализованы на уровне языка, любая структура умеет копироваться или перемещаться сама. В результате, ситуацию «объект уже перемещён, вызывать деструктор не надо» в C++ решает программист в рантайме, меняя что-то в источнике перемещения (например присваивая умному указателю null) и обрабатывает эту ситуацию в деструкторе. В Расте за этим следит компилятор, либо статически выясняя, что объект переместился и вызывать деструктор не надо, либо сохраняя эту информацию где-то сбоку. Поэтому стандартная move-семантика недоступна для заимствованых даже эксклюзивно объектов, чтоб реализовать ваш метод необходимо колхозить мувы как в C++ самому.

В C++ есть std::move

Ну же, продемонстрируй

Ok. Пиши тему в разделе job. О цене, сроках, деталях выполнения заказа договоримся там.

А тебе всё же стоит ознакомиться с lifetimes и borrow checker в Rust

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

Т.е., полный перечень проблем от которых защищают растоспецифичные механизмы в однопотоке: утечка ресурсов, выход за пределы Околлекции, чтение из неинициализированного указателя, чтение по нулевому адресу, освобождение памяти неподходящими средствами (грубо говоря, вызов free() для памяти выделенной через new). И даже от переполнения стека, он, например, не защищает.

Поправьте меня, если я не прав.

В C++ есть std::move

Почувствуй разницу.

#include <iostream>
#include <utility>
#include <vector>

int main() {
    std::string s = "str";
    std::string m(std::move(s));
    std::cout << "s = \"" << s << "\"" << std::endl;
    return 0;
}

$ g++ -Wall move.cpp -o move-cpp
$ ./move-cpp 
s = ""

fn main() {
    let s = String::from("str");
    let _m = s;
    println!("s = \"{}\"", s);
}

$ rustc move.rs 
error[E0382]: use of moved value: `s`
 --> move.rs:4:28
  |
3 |     let _m = s;
  |         -- value moved here
4 |     println!("s = \"{}\"", s);
  |                            ^ value used here after move
  |
  = note: move occurs because `s` has type `std::string::String`, which does not implement the `Copy` trait

error: aborting due to previous error

Я прекрасно знаю об этой разнице, дорогой капитан. Я отвечал на сообщение о том, что: «То, что это перемещение, для класса нужно реализовать самому».

Я прекрасно знаю об этой разнице, дорогой капитан. Я отвечал на сообщение о том, что: «То, что это перемещение, для класса нужно реализовать самому».

Как же std::move избавляет от необходимости писать конструктор и оператор перемещения? Ваш. Кэп.

Не избавляет, но упрощает перемещение.

Не избавляет, но упрощает перемещение.

Упрощает? Кастом в xvalue expr? Перемещение, перевод объекта в неопределённое состояние, реализуется программистом. Компилятор не проводит никаких проверок во время компиляции, то есть «семантика» проверяется программистом. Ооооочень упрощает. Ага.

Ваш Кэп.

Ну а без std::move как ты это хотя бы так сделаешь? До C++11.

Ну а без std::move как ты это хотя бы так сделаешь? До C++11.

Можешь посмотреть как это сделано в Boost.Move.

Ваш Кэп.

Почувствуй разницу.
g++

test.cpp:8:30: error: 's' used after it was moved [hicpp-invalid-access-moved,-warnings-as-errors]
    std::cout << "s = \"" << s << "\"" << std::endl;
                             ^
test.cpp:7:17: note: move occurred here
    std::string m(std::move(s));
                ^