The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы
правила/FAQ
поиск
регистрация
вход
слежка
RSS


Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Фронтэнд для языка Rust доведён до готовности для интеграции в GCC 13, opennews (??), 06-Дек-22, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


2. "Фронтэнд для языка Rust доведён до готовности для интеграции..."  +2 +/–
Сообщение от раст переусложнён (?), 06-Дек-22, 21:21 
чем смартпоинтеры в c++ хуже раста?
Ответить | Правка | Наверх | Cообщить модератору

7. "Фронтэнд для языка Rust доведён до готовности для интеграции..."  –3 +/–
Сообщение от Бьерн Страуструп (?), 06-Дек-22, 21:26 
Тем что они имеют фатальный недостаток
https://ru.wikipedia.org/wiki/%D0%A1%D0%...
Ответить | Правка | Наверх | Cообщить модератору

43. "Фронтэнд для языка Rust доведён до готовности для интеграции..."  +1 +/–
Сообщение от анонимус (??), 06-Дек-22, 22:32 
В плюсах нет таких сильных гарантий для поинтеров
Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

54. "Фронтэнд для языка Rust доведён до готовности для интеграции..."  +/–
Сообщение от AlexCr4ckPentest (?), 06-Дек-22, 22:43 
А что, в расте разве есть какие-то гарантии на по указателям в unsafe?
Ответить | Правка | Наверх | Cообщить модератору

62. "Фронтэнд для языка Rust доведён до готовности для интеграции..."  +4 +/–
Сообщение от Аноним (28), 06-Дек-22, 22:51 
Сам факт присутствия слова unsafe в синтаксисе уже о многом говорит про язык.
Ответить | Правка | Наверх | Cообщить модератору

142. "Фронтэнд для языка Rust доведён до готовности для интеграции..."  –1 +/–
Сообщение от Аноним (140), 07-Дек-22, 06:16 
Что говорит?
Ответить | Правка | Наверх | Cообщить модератору

154. "Фронтэнд для языка Rust доведён до готовности для интеграции..."  +2 +/–
Сообщение от Аноним (28), 07-Дек-22, 08:16 
> Что говорит?

- Ты что, глухонемой?
- Да!
(с)

Ответить | Правка | Наверх | Cообщить модератору

217. "Фронтэнд для языка Rust доведён до готовности для интеграции..."  –1 +/–
Сообщение от Аноним (140), 07-Дек-22, 18:51 
Присутствие слова unsafe говорит что аноним глухонемой?
Или что анонимный эксперт недалёкий?
Ответить | Правка | Наверх | Cообщить модератору

192. "Фронтэнд для языка Rust доведён до готовности для интеграции..."  +/–
Сообщение от Аноним (192), 07-Дек-22, 14:42 
Да, говорит что язык правильно спроектирован. Без unsafe не написать низкоуровневых примитивов и взаимодействия со всякими кривыми сишным апи, а вот прикладной код должен писаться без ансейфов со следующими из этого гарантиями.
Ответить | Правка | К родителю #62 | Наверх | Cообщить модератору

267. "Фронтэнд для языка Rust доведён до готовности для интеграции..."  +1 +/–
Сообщение от Аноним (-), 09-Дек-22, 17:41 
>Да, говорит что язык правильно спроектирован.

Ловите дотнетчика!

Ответить | Правка | Наверх | Cообщить модератору

74. "Фронтэнд для языка Rust доведён до готовности для интеграции..."  +1 +/–
Сообщение от AlexCr4ckPentest (?), 06-Дек-22, 23:07 
> В плюсах нет таких сильных гарантий для поинтеров

Ну смотри, плюсах есть 2 вида умных указателей:

- std::shared_ptr, в котором запрятан счетчик ссылок, его можно копировать сколько угодно раз, и пока счетчик не будет == 0, память не будет освобождена. Ну из минусов - это то, что управляющий блок (там где хранится счетчик ссылок и указатель) выделены в куче, а сам счетчик атомарный (проблема для многопоточки). Используя std::shared_ptr, ты можешь быть уверен, что N раз скопированный указатель будет удален только после того, как счетчик ссылок станет == 0.
Очень удобен, если нужно шарить указатель с кем-то еще.
- std::unique_ptr, в котором запрещено любое копирование, но разрешено перемещение, что так же решает проблемы владения (мы просто перемещаем состояние в новый объект, оставляя старый объект в несогласованном, но консистеном состоянии для его корректного удаления). Тем самым тут отказались от счетчика ссылок и решили еще 1 проблему: выделение управляющего блока в куче. Используя std::unique_ptr, ты можешь быть уверен, что указателем под этим классом всегда владеет только один единственный объект. Удобен, когда нужно сделать что-то похожее на PIMPL или просто автоматически освободить память при выходе из скоупа.

Согласно стандартам C++14 и C++17, эти классы гарантируют тебе одинаковое поведение на всех существующих платформах вне зависимости от компилятора и стандартной библиотеки. C чего ты решил, что тут нету гарантий?

Ответить | Правка | К родителю #43 | Наверх | Cообщить модератору

78. "Фронтэнд для языка Rust доведён до готовности для интеграции..."  +6 +/–
Сообщение от Бьярн Страуструп (?), 06-Дек-22, 23:21 
Да толку объяснять, если они в глаза даже стандарт С++98 не видели, использовали С++ с классами в свои студенческие годы.
Ответить | Правка | Наверх | Cообщить модератору

141. "Фронтэнд для языка Rust доведён до готовности для интеграции..."  +1 +/–
Сообщение от name (??), 07-Дек-22, 06:16 
В расте аналог для shared_ptr это Rc\Arc. А для unique_ptr - Box.
Это полноценные объекты с владениями, однако лайфтаймовые ссылки с их валидацией во время компиляции по-прежнему в плюсах не наблюдаются.
Ответить | Правка | К родителю #74 | Наверх | Cообщить модератору

177. "Фронтэнд для языка Rust доведён до готовности для интеграции..."  +2 +/–
Сообщение от Аноним (177), 07-Дек-22, 12:02 
> C чего ты решил, что тут нету гарантий?

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

Чтобы в C/C++ получить одинаковое поведение на всех существующих платформах, тебе придётся а) перерыть документацию по всем тем платформам, и б) научиться видеть все UB в коде глядя на название файла с кодом. Это не достаточное условие, но необходимое. Я не перечисляю другие, потому что уже глядя на это видно, что эти условия не выполняются никогда. А значит и одинакового поведения на всех существующих платформах от программ на C/C++ ждать не приходится.

> Согласно стандартам C++14 и C++17

Эти стандарты никогда не давали никаких гарантий. Они давали лишь устные обещания, и когда эти обещания не выполнялись, они начинали говорить "сама виновата", "ССЗБ", "вон из профессии" и прочие такие штуки.

Ответить | Правка | К родителю #74 | Наверх | Cообщить модератору

198. "Фронтэнд для языка Rust доведён до готовности для интеграции..."  –1 +/–
Сообщение от AlexCr4ckPentest (?), 07-Дек-22, 15:26 
Для начала уточню, речь идет про С++.

> А значит и одинакового поведения на всех существующих платформах от программ на C/C++ ждать не приходится.

Смотри, у тебя есть стандарт языка С++, согласно которому для полной реализации абстрактной машины языка С++, тебе необходимо:
  - компилятор, поддерживающий встроенные типы, исключения и шаблоны;
  - стандартная библиотека с поддержкой всех встроенных типов, исключений, шаблонов и потоков ввода вывода.
Даже если на целевой платформе не поддерживаются потоки и исключения, тот, кто пишет стандартную библиотеку - обязан это предоставить.
Реализация стандартной библиотеки может быть абсолютно разной, однако для С++ она обязана быть, и к тому же иметь ровно точно такое же поведение, что и на других платформах.
Ну например, у тебя есть шаблон класса std::vector, аллокатор которого должен знать, как ему выделять память (что-то на подобие malloc()), исключений и поддержки как минимум встроенных типов. Стандарт гарантирует, что например, std::vector<int>::push_back() для любой платформы, где есть поддержка стандартной библиотеки, сделает абсолютно одинаковые вещи везде: а именно - аллокатор std::vector`а выделит память (если не получилось - выбросит std::bad_alloc), в эту память он скопирует значение, которое ты передал в качестве параметра.
Если у тебя на платформе нету хотя бы одного, из вышеперечисленных компонентов в реализации стандартной библиотеки, то у тебя нет и компилятора С++. А значит, у тебя нету и С++.

Ответить | Правка | Наверх | Cообщить модератору

206. "Фронтэнд для языка Rust доведён до готовности для интеграции..."  +1 +/–
Сообщение от Аноним (-), 07-Дек-22, 16:21 
К чему ты всё это пишешь, если UB -- это Undefined Behavior, про который явно говорится, что никаких гарантий относительно его поведения нет?
Ответить | Правка | Наверх | Cообщить модератору

199. "Фронтэнд для языка Rust доведён до готовности для интеграции..."  +/–
Сообщение от AlexCr4ckPentest (?), 07-Дек-22, 15:35 
> Эти стандарты никогда не давали никаких гарантий.

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

Ответить | Правка | К родителю #177 | Наверх | Cообщить модератору

190. "Фронтэнд для языка Rust доведён до готовности для интеграции..."  +1 +/–
Сообщение от Аноним (192), 07-Дек-22, 14:40 
> Ну из минусов - это то, что управляющий блок (там где хранится счетчик ссылок и указатель) выделены в куче

Не существует такого термина как "управляющий блок". И счётчик ссылок рядом с указателем храниться не может. Иди доучивать, пентестер мамкин. Есть сам объект shared_ptr, там хранятся два указателя - на хранимый объект и на счётчик ссылок. При этом при использовании make_shared они смотрят в одну аллокацию. Так в чём здесь минус?

> счетчик атомарный (проблема для многопоточки)

Что за бред?

> Используя std::unique_ptr, ты можешь быть уверен, что указателем под этим классом всегда владеет только один единственный объект

Не можешь.

> C чего ты решил, что тут нету гарантий?

С того что ничто не мешает разыменовать `unique_ptr` хранящий nullptr, или взять два `unique_ptr` на один объект.

Ответить | Правка | К родителю #74 | Наверх | Cообщить модератору

196. "Фронтэнд для языка Rust доведён до готовности для интеграции..."  +/–
Сообщение от AlexCr4ckPentest (?), 07-Дек-22, 15:03 
> Не существует такого термина как "управляющий блок".

https://en.cppreference.com/w/cpp/memory/shared_ptr
Прочитай раздел "Implementation notes".

Тоже самое касается атомиков в реализации счетчика ссылок:
To satisfy thread safety requirements, the reference counters are typically incremented using an equivalent of std::atomic::fetch_add with std::memory_order_relaxed (decrementing requires stronger ordering to safely destroy the control block).

> С того что ничто не мешает разыменовать `unique_ptr` хранящий nullptr, или взять два `unique_ptr` на один объект

Это не проблема С++, это логическая ошибка, в растее точно так же в unsafe контексте можно взять 2 смарт поинтера на один и тот же объект. Ровно тоже самое про nullptr: в расте тоже можно создать указатель, хранящий нечто похожее на nullptr из С++ и разыменовать его.

Ответить | Правка | Наверх | Cообщить модератору

221. "Фронтэнд для языка Rust доведён до готовности для интеграции..."  +/–
Сообщение от Аноним (192), 07-Дек-22, 19:51 
> Тоже самое касается атомиков в реализации счетчика ссылок

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

> Это не проблема С++, это логическая ошибка, в растее точно так же в unsafe контексте можно взять 2 смарт поинтера на один и тот же объект. Ровно тоже самое про nullptr: в расте тоже можно создать указатель, хранящий нечто похожее на nullptr из С++ и разыменовать его.

Это полнейшее непонимание принципов безопасности языка. Это проблема C++ потому что там это можно сделать, всегда, везде, в любом месте и любым способом, и язык никак этому не помешает. В Rust так сделать по умолчанию нельзя. В этом и заключается безопасность.

Ответить | Правка | Наверх | Cообщить модератору

224. "Фронтэнд для языка Rust доведён до готовности для интеграции..."  +1 +/–
Сообщение от Аноним (224), 07-Дек-22, 22:57 
Простите, я тут из джавы к вам заглянул, сильно не серчайте, но у нас "хорошо" атомики для многопоточности или "плохо" зависит от того, насколько многопоточность конкурентная (речь про contention), так как атомики у нас на compare-and-swap неблокирующих операциях. Если потоков много и все они конкурируют за один атомарный счётчик, то это место становится бутылочным горлышком, потому что потоки постоянно уходят в бессмысленный и беспощадный spin loop.
Ответить | Правка | Наверх | Cообщить модератору

126. "Фронтэнд для языка Rust доведён до готовности для интеграции..."  +2 +/–
Сообщение от Аноним (119), 07-Дек-22, 03:57 
Тем, что в расте, не пользуясь ансейфом, нельзя работать с кучей не через смартпоинтер. А если говорить в целом, чем он лучше - так это тем, что, первое что пришло в голову:
1) нет null, вместо этого обязательная обработка обоих вариантов развития событий у местного опшинала
2) система типов линейная, в силу чего деструктор будет всегда тривиальным и автосгенеренным компилятором (трейт Drop способом реализовать нетривиальный деструктор нельзя, это тупо коллбек на выполнение кастомной логики при уничтожении объекта, например, закрытия дескриптора, про который раст ничего не знает, потому что он пришел через FFI вызов из сишной DLL/SO).
3) боров чекер и zero-cost имитация reader-writer блокировки через зашитые в компилятор правила работы с mutable/immutable ссылками (у тебя не будет гонки потоков в программе, если тебе язык синтаксически не позволяет выразить стейт, приводящий к гонке).
Короче, то, что в С++ идиома и бест практис, который программсту один хрен нужно будет реализовать, потирая в 4 утра красные слипающиеся глаза перед дедлайном, в Rust является частью compile-time семантики, тупо не позволяющей собрать приложуху, если что-то написано не по феншую.
Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

132. "Фронтэнд для языка Rust доведён до готовности для интеграции..."  +/–
Сообщение от _ (??), 07-Дек-22, 05:12 
Поэтому поргромисД на Rust, потирая в 4 утра красные слипающиеся глаза перед дедлайном влупенитЪ(С) unsafe и накропает кусок на плохом С.
Идите в Ж пЫонеры! (С) Одна бабушка
Ответить | Правка | Наверх | Cообщить модератору

236. "Фронтэнд для языка Rust доведён до готовности для интеграции..."  +/–
Сообщение от Прохожий (??), 08-Дек-22, 08:07 
От идиотов ни один язык не страхует.
В твоём случае другой, более адекватный программист на Расте, легко найдёт проблему по маркеру unsafe. В плохом Си глаза у него таки останутся красными в попытке потом найти баг.
Ответить | Правка | Наверх | Cообщить модератору

277. "Фронтэнд для языка Rust доведён до готовности для интеграции..."  +/–
Сообщение от Вячеслав (??), 12-Дек-22, 05:18 
При чём тут идиоты. Иногда надо сделать быстро, из говна и палок. Так и получается технический долг.
Ответить | Правка | Наверх | Cообщить модератору

170. "Фронтэнд для языка Rust доведён до готовности для интеграции..."  +1 +/–
Сообщение от Аноним (-), 07-Дек-22, 11:28 
#include <iostream>
#include <memory>

int main() {
    auto i = std::unique_ptr<int>(new int);
    *i = 5;
    std::cout << "i = " << *i << "\n";
    std::unique_ptr<int> j = move(i);
    std::cout << "i = " << *i << "\n";
        // можно написать return 0, но бестолку, потому что предыдущая строчка сегфолтнется
}

Смартпоинтеры не дают никаких гарантий, они лишь немного упрощают статический анализ.

Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

187. "Фронтэнд для языка Rust доведён до готовности для интеграции..."  +/–
Сообщение от Аноним (187), 07-Дек-22, 14:29 
А зачем ты читаешь из перемещённого указателя?
Ответить | Правка | Наверх | Cообщить модератору

189. "Фронтэнд для языка Rust доведён до готовности для интеграции..."  +/–
Сообщение от Аноним (189), 07-Дек-22, 14:37 
Чтобы показать, что C++ ничего не гарантирует. Программист на C++ может гарантировать, но только на словах: "мамойклянус". А C++ не гарантирует ничего.
Ответить | Правка | Наверх | Cообщить модератору

195. "Фронтэнд для языка Rust доведён до готовности для интеграции..."  –1 +/–
Сообщение от AlexCr4ckPentest (?), 07-Дек-22, 14:47 
Гений инвалидировал указатель, создав для него moved-from state контекст, это черным по белому прописанно в стандарте. Почитай, что такое moved-from sate и почему у тебя тут сегфолт, а потом уже ной, что ты не знаешь стандарта.
Ответить | Правка | Наверх | Cообщить модератору

197. "Фронтэнд для языка Rust доведён до готовности для интеграции..."  +/–
Сообщение от Аноним (197), 07-Дек-22, 15:08 
> Почитай, что такое

Скажи мне, ты действительно настолько тупой, что не понимаешь, что код был скрафчен руками так, чтобы показать UB, и сделано это было с опорой на знание дебилизма стандарта C++?

> Гений инвалидировал указатель

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

Ответить | Правка | Наверх | Cообщить модератору

202. "Фронтэнд для языка Rust доведён до готовности для интеграции..."  +2 +/–
Сообщение от AlexCr4ckPentest (?), 07-Дек-22, 15:49 
Почти аналогичный код на твоем любимом и "самом безопасном" расте.

use std::ptr;

pub fn main() {
    unsafe {
        let ptr: *mut i32 = std::ptr::null_mut();
        *ptr = 111;
        println!(*ptr);
    }
}

Догадайся, что будет выведено на экран?
Это еще кстати к слову об "отсутствии" nullptr )

Ответить | Правка | Наверх | Cообщить модератору

203. "Фронтэнд для языка Rust доведён до готовности для интеграции..."  +1 +/–
Сообщение от AlexCr4ckPentest (?), 07-Дек-22, 15:52 
Интересно, если в документации у растоманов это помечено как UB, для них это типа не счиатеся UB?
P.S:
Разумеется, println! принимает формат-строку: по этому коррентнее будет println!("{}", *ptr)
Ответить | Правка | Наверх | Cообщить модератору

216. "Фронтэнд для языка Rust доведён до готовности для интеграции..."  +/–
Сообщение от анон (?), 07-Дек-22, 18:30 
Ничоси! 11 метровый файл на выходе!! Что за нах?
Ответить | Правка | К родителю #202 | Наверх | Cообщить модератору

218. "Фронтэнд для языка Rust доведён до готовности для интеграции..."  +/–
Сообщение от AlexCr4ckPentest (ok), 07-Дек-22, 18:51 
> Ничоси! 11 метровый файл на выходе!! Что за нах?

У меня около 9.2 МиБ получился.

А это вот раст, который "легковесный" и в котором все "безопасно" и "без оверхеда" )
Как у них круто реализована концепция "Не платим за то, что не используем".
Вообще у меня такое ощущение, будт-то компилятор туда еще и отладочную информацию запихнул, хотя флаг -g не выставлен.

Ответить | Правка | Наверх | Cообщить модератору

238. "Фронтэнд для языка Rust доведён до готовности для интеграции..."  +1 +/–
Сообщение от Прохожий (??), 08-Дек-22, 08:15 
Если бы ты, кроме форума, читал ещё документацию по обсуждаемому предмету, то  знал, что это так и есть. По умолчанию компилятор впихивает отладочную информацию и использует статическую линковку. Если нужно, всё это отключаемо. Но чукча (точнее очередной опеннетный "эксперт") не читатель.
Ответить | Правка | Наверх | Cообщить модератору

239. "Фронтэнд для языка Rust доведён до готовности для интеграции..."  +/–
Сообщение от AlexCr4ckPentest (ok), 08-Дек-22, 10:31 
> По умолчанию компилятор впихивает отладочную информацию и использует статическую линковку. Если нужно, всё это отключаемо.

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

Ответить | Правка | Наверх | Cообщить модератору

241. "Фронтэнд для языка Rust доведён до готовности для интеграции..."  +/–
Сообщение от AlexCr4ckPentest (ok), 08-Дек-22, 11:05 
> Если бы ты, кроме форума, читал ещё документацию по обсуждаемому предмету, то
>  знал, что это так и есть. По умолчанию компилятор впихивает
> отладочную информацию и использует статическую линковку. Если нужно, всё это отключаемо.
> Но чукча (точнее очередной опеннетный "эксперт") не читатель.

Кстати, а почему бы не пойти дальше, и не запихать вообще все "так нужные" библиотеки в core раста?
Ну а что, было бы удобно: и 100500 реализаций спецификации OpenGL, чтобы GUI рисовать, например.
Вот почему линковаться статически научились по умолчанию, а в реализацию компилятора под такое же кол-во архитектур и написание собственного рантайма без libc - не смогли?

Ответить | Правка | К родителю #238 | Наверх | Cообщить модератору

234. "Фронтэнд для языка Rust доведён до готовности для интеграции..."  +/–
Сообщение от Прохожий (??), 08-Дек-22, 07:59 
По умолчанию в программу включается отладочная информация. Плюс используется статическая линковка. Всё это можно отключить при необходимости. Об этом уже на этом сайте говорилось огромное количество раз.
Ответить | Правка | К родителю #216 | Наверх | Cообщить модератору

229. "Фронтэнд для языка Rust доведён до готовности для интеграции..."  +3 +/–
Сообщение от anonymous (??), 08-Дек-22, 02:39 
Так ты ж сам написал unsafe. Зачем?
Сделай UB без unsafe, тогда поговорим
Ответить | Правка | К родителю #202 | Наверх | Cообщить модератору

235. "Фронтэнд для языка Rust доведён до готовности для интеграции..."  +1 +/–
Сообщение от Прохожий (??), 08-Дек-22, 08:03 
Похоже, твой оппонент таки был прав. Ты реально глуп. В Расте, если не использовать unsafe, ты подобного не напишешь. В плюсах у тебя нет никаких опций для этого.
Ответить | Правка | К родителю #202 | Наверх | Cообщить модератору

240. "Фронтэнд для языка Rust доведён до готовности для интеграции..."  +/–
Сообщение от AlexCr4ckPentest (ok), 08-Дек-22, 10:57 
> Похоже, твой оппонент таки был прав. Ты реально глуп. В Расте, если
> не использовать unsafe, ты подобного не напишешь. В плюсах у тебя
> нет никаких опций для этого.

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

Как-то опять двойные стандарты пошли: программистам на расте можно говорить что-то про UB в C++, а вот если им начинаю предъявлять за самые глупые ошибки даже в их собственной стандартной библиотеке и про ровно точно такой же код в unsafe, то они плачут и оправдывают это словами "ну это же логическа ошибка" и "по умолчанию так нельзя" и бла-бла-бла.

Кстати, почему вы вообще сравниваете С++ и Rust? По-моему это вообще никак не сравнимо, это абсолютно 2 разных языка с разными подходами к их использованию.

Я согласен, проверка всего этого в compile-time - это здорово, но не нужно это возносить как средство от всего. Кроме того, существование подобной штуки в языке наоборот препядствует адекватному восприятию безопасного кода (логические и семантически ошибки твои compile-time проверки никак не исправят). Не надо натягивать маску клоуна, чтобы выступать в цирке.

Ответить | Правка | Наверх | Cообщить модератору

250. "Фронтэнд для языка Rust доведён до готовности для интеграции..."  +/–
Сообщение от Аноним (-), 08-Дек-22, 13:27 
> Использование unsafe контекста для данного примера как раз необходимо

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

Попробуй скомпилять вот это, вот тебе unsafe но со смарт-поинтерами:

fn main() {
    unsafe {
    let i = Box::new(5i32);
    println!("i = {i}");
    let _j = i;
    println!("i = {i}");
    }
}

Этот код не компилируется:

rustc tmp.rs
error[E0382]: borrow of moved value: `i`
--> tmp.rs:6:17
  |
3 |     let i = Box::new(5i32);
  |         - move occurs because `i` has type `Box<i32>`, which does not implement the `Copy` trait
4 |     println!("i = {i}");
5 |     let _j = i;
  |              - value moved here
6 |     println!("i = {i}");
  |                    ^ value borrowed here after move
  |

Попробуй найти способ получить в i невалидный указатель, разадресация которого приведёт к UB. Используй unsafe или не используй, как тебе покажется удобнее. Вот когда ты найдёшь такой способ, я смогу тебе на нём объяснить, чем смарт-поинтеры Rust'а лучше C++. А пока не найдёшь, тебе придётся оставаться в неведении.

> Кстати, почему вы вообще сравниваете С++ и Rust?

А ты зачем сравниваешь C++ и Rust? Ты тут самый активный участник обсуждения, и вдруг ты начинаешь всех обвинять, что они это обсуждение ведут. У тебя какая-то конкретная некогерентность в поведении наблюдается.

Ответить | Правка | Наверх | Cообщить модератору

257. "Фронтэнд для языка Rust доведён до готовности для интеграции..."  +/–
Сообщение от AlexCr4ckPentest (ok), 08-Дек-22, 15:41 
>> Использование unsafe контекста для данного примера как раз необходимо
> Нет, оно нужно для того, чтобы у тебя появилась возможность заменить смарт-поинтеры
> raw-указателями.
> Попробуй скомпилять вот это, вот тебе unsafe но со смарт-поинтерами:

Вот код на расте: https://godbolt.org/z/8hPrK7ddv
Вот аналогичный код на C++: https://godbolt.org/z/j63E6jh4o
И там, и там - это ошибка компиляции, дальше что?

> Попробуй найти способ получить в i невалидный указатель, разадресация которого приведёт к UB.

Любой volatile указатель, или указатель, который используется в коде на C. Очевидно, если он приходит от C API, то управляешь им не ты, а значит нужно использовать "сырые" указатели, относительно которых нету гарантий.

Ответить | Правка | Наверх | Cообщить модератору

262. "Фронтэнд для языка Rust доведён до готовности для интеграции..."  +/–
Сообщение от Аноним (-), 08-Дек-22, 17:17 
> Вот код на расте

Сори. Там js нужен, у меня не работает.

Но, глядя вот на это:

> И там, и там - это ошибка компиляции, дальше что?

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

Вчитайся в эту фразу. Я её укоротил как мог, чтобы тебе проще логику было бы применять. Оно из-за этого не совсем верное стало: я выкинул оговорку об ограничении классов глупостей программистов. Но ты тем не менее вчитайся, и пойми что приводя примеры когда C++ что-то ловит на этапе компиляции ты ничего не докажешь. Тебе надо показать, что невозможно написать код на смартпоинтерах C++, который не сфейлится на компиляции но сфейлится в рантайме.

> Любой volatile указатель, или указатель, который используется в коде на C.

В смысле смарт-поинтер, или raw-поинтер? Если второе, то тебя опять заносит в raw-поинтеры, хотя мы говорим о смарт-поинтерах. Если первое... Ну я не знаю, например, может ты можешь рассказать как взять raw-pointer, который по логике volatile, завернуть его в Volatile[1], и потом получить UB, работая с Volatile, то расскажи нам об этом. Или может у тебя в голове какой-то другой сценарий? Расскажи нам об этом.

[1] https://docs.rs/volatile/latest/volatile/

Ответить | Правка | Наверх | Cообщить модератору

259. "Фронтэнд для языка Rust доведён до готовности для интеграции..."  +/–
Сообщение от AlexCr4ckPentest (ok), 08-Дек-22, 15:52 
> Этот код не компилируется ...

Так же некоторый вопрос: чем же смарт-поинтеры в расте лучше, если компилятор зачем-то перемещает состояние, когда копирование запрещено? Причем делает это неявно, даже не выдавая диагностики.
Хотя C++, например, это вообще-то ошибка компиляции, и компилятор обязан выдать диагностику.

Ответить | Правка | К родителю #250 | Наверх | Cообщить модератору

260. "Фронтэнд для языка Rust доведён до готовности для интеграции..."  +/–
Сообщение от Аноним (-), 08-Дек-22, 16:24 
> компилятор зачем-то перемещает состояние, когда копирование запрещено?

Компилятор перемещает, потому что я попросил его переместить значение. Я в курсе что Copy не реализован для Box'а, в этом фишка Box'а, это смарт-поинтер, а не член собачий. Box гарантирует, что он будет в единственном экземпляре. Если бы мне нужно было клонировать, я бы сделал:

let j = i.clone();

Но тогда я бы получил вторую аллокацию памяти и в i и j лежали бы разные Box<i32>, которые по значению бы совпадали, но были бы разные. В терминах lisp'а, они были бы equal, но не eq.

> Причем делает это неявно,

Да, это дефолтное поведение типов в ответ на =, описанное в любом материале для личинок растоманов. Clone и Copy -- это дополнительные трейты, которые разработчик этих типов может навешивать на них, а может нет. Таким образом move -- это дефолт в расте.

Но это иррелевантно нашему разговору, разговор о том, что UB не возникает. И ты так и не придумал, как его создать на смарт-поинтерах.

Или может не совсем иррелевантно... Это ведь суть отличий смарт-поинтеров C++ и Rust'а, так? Та самая суть которая делает смарт-поинтеры Rust'а смарт-поинтерами, и оставляет смарт-поинтеры C++ членами собачьими.

> даже не выдавая диагностики.

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

> Хотя C++, например, это вообще-то ошибка компиляции, и компилятор обязан выдать диагностику.

В C++ это не ошибка компиляции, выше по треду есть аналогичный C++ код, и компилятор C++ его радостно компилирует и выдаёт на выходе бинарь. А вот в Rust'е это ошибка, и раст как раз выдаёт ошибку компиляции и диагностику.

Ты чо, крeмлeвcкoй пpoпaгaнgы пересмотрел, и решил что обвинять других в своих грехах -- это хороший способ вести дискуссию? Нет, это может быть эффективным способом пpoпaгaнgы -- не знаю, но в дискуссии тебя будут макать в чан с известной субстанцией за каждую такую попытку.

Ответить | Правка | Наверх | Cообщить модератору

273. "Фронтэнд для языка Rust доведён до готовности для интеграции..."  +/–
Сообщение от Аноним (-), 10-Дек-22, 02:37 
> move occurs because `i` has type `Box<i32>`, which does not implement
> the `Copy` trait

Вот чем rust приколен так это абсолютно марсианской диагностикой.

Ответить | Правка | К родителю #250 | Наверх | Cообщить модератору

276. "Фронтэнд для языка Rust доведён до готовности для интеграции..."  +/–
Сообщение от Аноним (-), 10-Дек-22, 11:40 
Это не марсианский, это английский.
Ответить | Правка | Наверх | Cообщить модератору

242. "Фронтэнд для языка Rust доведён до готовности для интеграции..."  +/–
Сообщение от Аноним (242), 08-Дек-22, 11:11 
Санитайзер, да даже clang-tidy тебе об этом скажет
Ответить | Правка | К родителю #170 | Наверх | Cообщить модератору

252. "Фронтэнд для языка Rust доведён до готовности для интеграции..."  +/–
Сообщение от Вы забыли заполнить поле Name (?), 08-Дек-22, 14:16 
clang-tidy скажет об этой ошибке

> used after it was moved [bugprone-use-after-move,-warnings-as-errors]

не говоря уже о санитайзерах.

Ответить | Правка | К родителю #170 | Наверх | Cообщить модератору

180. "Фронтэнд для языка Rust доведён до готовности для интеграции..."  +2 +/–
Сообщение от Px (?), 07-Дек-22, 12:58 
Странно сравнивать абстракцию для контроля над временем жизни объекта и языком, но: cмартпоинтеры добавляют оверхед в рантайме; смартпоинтеры не устраняют проблемы рейсов; cмартпоинтеры используются и в расте, но по возможности, лучше обходиться без них. А ещё, у раста удобный синтаксис.
Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

204. "Фронтэнд для языка Rust доведён до готовности для интеграции..."  +/–
Сообщение от Аноним (204), 07-Дек-22, 15:56 
И unique_ptr добавляет оверхед в рантайме?
Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей 		Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру