The OpenNET Project / Index page

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

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


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

Оглавление

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

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


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ообщить модератору

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

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




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

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