The OpenNET Project / Index page

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

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


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

"Выпуск языка программирования Rust 1.77"  +/–
Сообщение от opennews (?), 22-Мрт-24, 14:05 
Опубликован релиз языка программирования общего назначения Rust 1.77, основанного проектом Mozilla, но ныне развиваемого под покровительством независимой некоммерческой организации Rust Foundation. Язык сфокусирован на безопасной работе с памятью и предоставляет средства для достижения высокого параллелизма выполнения заданий, при этом обходясь без использования сборщика мусора и runtime (runtime сводится к базовой инициализации и сопровождению стандартной библиотеки)...

Подробнее: https://www.opennet.dev/opennews/art.shtml?num=60827

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

Оглавление

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


3. "Выпуск языка программирования Rust 1.77"  –3 +/–
Сообщение от Аноним (3), 22-Мрт-24, 14:08 
Больше рекурсий богу рекурсий!
Обязательно используйте внутри рекурсии транзакцию, а то малоли вдруг.
Ответить | Правка | Наверх | Cообщить модератору

4. "Выпуск языка программирования Rust 1.77"  +1 +/–
Сообщение от Аноним (4), 22-Мрт-24, 14:08 
> Безопасная работа с памятью обеспечивается в Rust во время компиляции через проверку ссылок, отслеживание владения объектами, учёт времени жизни объектов (области видимости) и оценку корректности доступа к памяти во время выполнения кода. Rust также предоставляет средства для защиты от целочисленных переполнений, требует обязательной инициализации значений переменных перед использованием, лучше обрабатывает ошибки в стандартной библиотеке, применяет концепцию неизменяемости (immutable) ссылок и переменных по умолчанию, предлагает сильную статическую типизацию для минимизации логических ошибок.

Половину этого списка поддерживают другие языки.

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

7. "Выпуск языка программирования Rust 1.77"  +5 +/–
Сообщение от КО (?), 22-Мрт-24, 14:13 
Только не по умолчанию да? ЛОЛ
Ответить | Правка | Наверх | Cообщить модератору

9. "Выпуск языка программирования Rust 1.77"  +3 +/–
Сообщение от Аноним (4), 22-Мрт-24, 14:20 
> учёт времени жизни объектов (области видимости)
> требует обязательной инициализации значений переменных перед использованием

Это база даже для C++ и Python.

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

36. "Выпуск языка программирования Rust 1.77"  –2 +/–
Сообщение от Аноним (36), 22-Мрт-24, 15:09 
а где почитать про обязательную инициализацию и с++?
Ответить | Правка | Наверх | Cообщить модератору

49. "Выпуск языка программирования Rust 1.77"  +10 +/–
Сообщение от Аноним (49), 22-Мрт-24, 16:10 
Вот тут почитай: -Wall -Wextra -Wpedantic -Werror -Wuninitialized -Werror
Ответить | Правка | Наверх | Cообщить модератору

180. "Выпуск языка программирования Rust 1.77"  –1 +/–
Сообщение от Аноним (180), 23-Мрт-24, 15:34 
C++ вообще замечательная штука: из него посредством комбинирования флагов компилятора получается штук сто разных диалектов.
Ответить | Правка | Наверх | Cообщить модератору

184. "Выпуск языка программирования Rust 1.77"  +2 +/–
Сообщение от Аноним (184), 23-Мрт-24, 15:43 
> C++ вообще замечательная штука: из него посредством комбинирования флагов компилятора
> получается штук сто разных диалектов.

тока на опеннете можно почитать про разные языки лиспы, и диалекты с++ на основе флагов компилятора. За то и любим, ценим. Надеюсь кто-то, перед смертью проекта (желаю долгих лет жизни), сделает архив здешнего паноптикума. Потроллить гуманоидов в 2999 году.

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

264. "Выпуск языка программирования Rust 1.77"  +/–
Сообщение от Карлос Сношайтилис (ok), 08-Апр-24, 15:02 
Почитал. Связь с "обязательно" и "на уровне языка" не нашёл.
Ещё варианты есть? Или перестанешь глупо шутковать?
Ответить | Правка | К родителю #49 | Наверх | Cообщить модератору

53. "Выпуск языка программирования Rust 1.77"  +1 +/–
Сообщение от Аноним (53), 22-Мрт-24, 16:14 
https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html
Ответить | Правка | К родителю #36 | Наверх | Cообщить модератору

5. "Выпуск языка программирования Rust 1.77"  +/–
Сообщение от Аноним (36), 22-Мрт-24, 14:08 
> Третий уровень подразумевает базовую поддержку
> без проверки возможности сборки кода

🤦

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

51. "Выпуск языка программирования Rust 1.77"  +2 +/–
Сообщение от Аноним (-), 22-Мрт-24, 16:12 
Зато безопасно.
Ответить | Правка | Наверх | Cообщить модератору

65. "Выпуск языка программирования Rust 1.77"  +/–
Сообщение от Kuromi (ok), 22-Мрт-24, 17:06 
Классическая Tier-3 поддержка от Мозиллы. Предполагается что с доводкой до ума долбаются интерсанты и местные сопровождающие энтузиасты. Ничего нового.
Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

81. "Выпуск языка программирования Rust 1.77"  +/–
Сообщение от laindono (ok), 22-Мрт-24, 18:31 
https://doc.rust-lang.org/nightly/rustc/target-tier-policy.html

Для Tier 1/2 у тебя есть гарантии оффициальной поддержки. Tier 3 это грубо говоря "всё остальное".

Логично же, что для какой-нибудь BSD/Haiku/Hurd/Redox поддержка будет на уровне "оно работает в теории, а если нет, то обращайтесь в спортлото". Ибо человек, которые знают, что это такое, хорошо если полторы штуки во всём мире найдётся.

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

106. "Выпуск языка программирования Rust 1.77"  +4 +/–
Сообщение от Аноним (184), 22-Мрт-24, 20:00 
> Логично же, что для какой-нибудь BSD/Haiku/Hurd/Redox

Логично подтасовывать карты. Ставить в один ряд какой-нибудь ресдох и BSD. Или Haiku и iOS ARM64. Или Hurd и Android ARM64.

Сразу солиднее выглядит. Не словно "мы не осилили", а словно "маргинальщина", нучотакова. Маргинальщина, у которой маркетшара больше чем весь раст фундейшн. :-D

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

117. "Выпуск языка программирования Rust 1.77"  +1 +/–
Сообщение от laindono (ok), 22-Мрт-24, 20:42 
aarch64-apple-ios в Tier 2 (обычный 64-битный арм)
arm64e-apple-ios в Tier 3 (какая-то свежая приблуда от apple, в которую не успели ещё толком)

Под Redox/BSD/HURD/Haiku разработка ведётся по остаточному принципу или энтузиастами. По сравнению с мажорными платформами (Tier 1 платформы). С другой стороны нет никаких причин, почему ты не можешь пойти и добить поддержку до нужного тебе уровня для нужной тебе платформы.

По поводу конкретно BSD. 64-битные фряшечка и net вполне себе есть в Tier 2 с поставкой тулчейнов. А вот всякие sparc64-unknown-openbsd понятное дело для всяких энтузиастов.

> у которой маркетшара больше

Попадание в определённый тир определяется не тем, сколько оно используется. Требуемые требования я привёл. Читай.

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

176. "Выпуск языка программирования Rust 1.77"  +/–
Сообщение от Аноним (176), 23-Мрт-24, 15:06 
чем тайр 3 отличчается от "не поддерживается вообще"? - и там и там "е6итесь со своими проблемами сами"
Ответить | Правка | К родителю #81 | Наверх | Cообщить модератору

178. "Выпуск языка программирования Rust 1.77"  –1 +/–
Сообщение от laindono (ok), 23-Мрт-24, 15:21 
Тем, что если оно вообще не поддерживается, то этого кода нет в мейнстриме.

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

188. "Выпуск языка программирования Rust 1.77"  +/–
Сообщение от Аноним (184), 23-Мрт-24, 16:11 
> Тем, что если оно вообще не поддерживается, то этого кода нет в
> мейнстриме.

кода ресдоха или хайку и прочий Tier 3 тоже нет в апстриме раста. Всё что там есть - затычки. Которые даже не гарантируют сборку.

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

190. "Выпуск языка программирования Rust 1.77"  +/–
Сообщение от laindono (ok), 23-Мрт-24, 16:42 
Тут есть документация. Выше ссылку же кинул. Вот что говорится о третьем тире:

Tier 3 target policy

At this tier, the Rust project provides no official support for a target, so we place minimal requirements on the introduction of targets.

A proposed new tier 3 target must be reviewed and approved by a member of the compiler team based on these requirements. The reviewer may choose to gauge broader compiler team consensus via a Major Change Proposal (MCP).

A proposed target or target-specific patch that substantially changes code shared with other targets (not just target-specific code) must be reviewed and approved by the appropriate team for that shared code before acceptance.

    A tier 3 target must have a designated developer or developers (the "target maintainers") on record to be CCed when issues arise regarding the target. (The mechanism to track and CC such developers may evolve over time.)
    Targets must use naming consistent with any existing targets; for instance, a target for the same CPU or OS as an existing Rust target should use the same name for that CPU or OS. Targets should normally use the same names and naming conventions as used elsewhere in the broader ecosystem beyond Rust (such as in other toolchains), unless they have a very good reason to diverge. Changing the name of a target can be highly disruptive, especially once the target reaches a higher tier, so getting the name right is important even for a tier 3 target.
        Target names should not introduce undue confusion or ambiguity unless absolutely necessary to maintain ecosystem compatibility. For example, if the name of the target makes people extremely likely to form incorrect beliefs about what it targets, the name should be changed or augmented to disambiguate it.
        If possible, use only letters, numbers, dashes and underscores for the name. Periods (.) are known to cause issues in Cargo.
    Tier 3 targets may have unusual requirements to build or use, but must not create legal issues or impose onerous legal terms for the Rust project or for Rust developers or users.
        The target must not introduce license incompatibilities.
        Anything added to the Rust repository must be under the standard Rust license (MIT OR Apache-2.0).
        The target must not cause the Rust tools or libraries built for any other host (even when supporting cross-compilation to the target) to depend on any new dependency less permissive than the Rust licensing policy. This applies whether the dependency is a Rust crate that would require adding new license exceptions (as specified by the tidy tool in the rust-lang/rust repository), or whether the dependency is a native library or binary. In other words, the introduction of the target must not cause a user installing or running a version of Rust or the Rust tools to be subject to any new license requirements.
        Compiling, linking, and emitting functional binaries, libraries, or other code for the target (whether hosted on the target itself or cross-compiling from another target) must not depend on proprietary (non-FOSS) libraries. Host tools built for the target itself may depend on the ordinary runtime libraries supplied by the platform and commonly used by other applications built for the target, but those libraries must not be required for code generation for the target; cross-compilation to the target must not require such libraries at all. For instance, rustc built for the target may depend on a common proprietary C runtime library or console output library, but must not depend on a proprietary code generation library or code optimization library. Rust's license permits such combinations, but the Rust project has no interest in maintaining such combinations within the scope of Rust itself, even at tier 3.
        "onerous" here is an intentionally subjective term. At a minimum, "onerous" legal/licensing terms include but are not limited to: non-disclosure requirements, non-compete requirements, contributor license agreements (CLAs) or equivalent, "non-commercial"/"research-only"/etc terms, requirements conditional on the employer or employment of any particular Rust developers, revocable terms, any requirements that create liability for the Rust project or its developers or users, or any requirements that adversely affect the livelihood or prospects of the Rust project or its developers or users.
    Neither this policy nor any decisions made regarding targets shall create any binding agreement or estoppel by any party. If any member of an approving Rust team serves as one of the maintainers of a target, or has any legal or employment requirement (explicit or implicit) that might affect their decisions regarding a target, they must recuse themselves from any approval decisions regarding the target's tier status, though they may otherwise participate in discussions.
        This requirement does not prevent part or all of this policy from being cited in an explicit contract or work agreement (e.g. to implement or maintain support for a target). This requirement exists to ensure that a developer or team responsible for reviewing and approving a target does not face any legal threats or obligations that would prevent them from freely exercising their judgment in such approval, even if such judgment involves subjective matters or goes beyond the letter of these requirements.
    Tier 3 targets should attempt to implement as much of the standard libraries as possible and appropriate (core for most targets, alloc for targets that can support dynamic memory allocation, std for targets with an operating system or equivalent layer of system-provided functionality), but may leave some code unimplemented (either unavailable or stubbed out as appropriate), whether because the target makes it impossible to implement or challenging to implement. The authors of pull requests are not obligated to avoid calling any portions of the standard library on the basis of a tier 3 target not implementing those portions.
    The target must provide documentation for the Rust community explaining how to build for the target, using cross-compilation if possible. If the target supports running binaries, or running tests (even if they do not pass), the documentation must explain how to run such binaries or tests for the target, using emulation if possible or dedicated hardware if necessary.
    Tier 3 targets must not impose burden on the authors of pull requests, or other developers in the community, to maintain the target. In particular, do not post comments (automated or manual) on a PR that derail or suggest a block on the PR based on a tier 3 target. Do not send automated messages or notifications (via any medium, including via @) to a PR author or others involved with a PR regarding a tier 3 target, unless they have opted into such messages.
        Backlinks such as those generated by the issue/PR tracker when linking to an issue or PR are not considered a violation of this policy, within reason. However, such messages (even on a separate repository) must not generate notifications to anyone involved with a PR who has not requested such notifications.
    Patches adding or updating tier 3 targets must not break any existing tier 2 or tier 1 target, and must not knowingly break another tier 3 target without approval of either the compiler team or the maintainers of the other tier 3 target.
        In particular, this may come up when working on closely related targets, such as variations of the same architecture with different features. Avoid introducing unconditional uses of features that another variation of the target may not have; use conditional compilation or runtime detection, as appropriate, to let each target run code supported by that target.
    Tier 3 targets must be able to produce assembly using at least one of rustc's supported backends from any host target.

If a tier 3 target stops meeting these requirements, or the target maintainers no longer have interest or time, or the target shows no signs of activity and has not built for some time, or removing the target would improve the quality of the Rust codebase, we may post a PR to remove it; any such PR will be CCed to the target maintainers (and potentially other people who have previously worked on the target), to check potential interest in improving the situation.

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

191. Скрыто модератором  +/–
Сообщение от Аноним (184), 23-Мрт-24, 16:46 
Ответить | Правка | Наверх | Cообщить модератору

6. "Выпуск языка программирования Rust 1.77"  +/–
Сообщение от 111email (??), 22-Мрт-24, 14:12 
Годный язык.
Ответить | Правка | Наверх | Cообщить модератору

220. "Выпуск языка программирования Rust 1.77"  –1 +/–
Сообщение от голос из леса (?), 25-Мрт-24, 06:33 
Там ещё долго до завершения "В разряд стабильных переведена новая порция API..." ?
Ответить | Правка | Наверх | Cообщить модератору

18. "Выпуск языка программирования Rust 1.77"  +2 +/–
Сообщение от Вы забыли заполнить поле Name (?), 22-Мрт-24, 14:41 
Не понимаю какой вектор развития языка? Вот взять лисп - он уже как 50+ лет готов и стабилен к использованию, а тут в каждой новости что-то добавляют, переводят новое апи в разряд стабильных...
Ответить | Правка | Наверх | Cообщить модератору

27. "Выпуск языка программирования Rust 1.77"  +10 +/–
Сообщение от Аноним (27), 22-Мрт-24, 14:56 
Лисп уже 50+ готов к использованию, а никто его не использует
Ответить | Правка | Наверх | Cообщить модератору

102. "Выпуск языка программирования Rust 1.77"  +/–
Сообщение от Вы забыли заполнить поле Name (?), 22-Мрт-24, 19:53 
Его много кто использует, особенно common-lisp и clojure
Ответить | Правка | Наверх | Cообщить модератору

123. "Выпуск языка программирования Rust 1.77"  +2 +/–
Сообщение от вася (??), 22-Мрт-24, 21:11 
Расскажи это юзерам Автокад,пусть посмеются над тобой.
Ответить | Правка | К родителю #27 | Наверх | Cообщить модератору

219. "Выпуск языка программирования Rust 1.77"  +/–
Сообщение от vantoo (ok), 24-Мрт-24, 16:23 
Или над собой.
Ответить | Правка | Наверх | Cообщить модератору

30. "Выпуск языка программирования Rust 1.77"  +6 +/–
Сообщение от Аноним (-), 22-Мрт-24, 15:00 
Можно еще взять лиспмашину и запустить лисп на ней.
Но для этого придется грабить музеи))

Лисп насктолько готов, что аж стал ненужным (кроме совсем маленького кол-ва людей).
А помню как ему пророчили стать чуть ли не основным ЯП))

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

103. "Выпуск языка программирования Rust 1.77"  +1 +/–
Сообщение от Вы забыли заполнить поле Name (?), 22-Мрт-24, 19:55 
Он станет, просто время ещё не пришло. Его передовых идей до сих пор нет во многих сегодняшних язычках.
Ответить | Правка | Наверх | Cообщить модератору

173. "Выпуск языка программирования Rust 1.77"  +/–
Сообщение от Neon (??), 23-Мрт-24, 14:58 
Значит эти "передовые идеи" никому не нужны оказались. Ненужны и неудобны
Ответить | Правка | Наверх | Cообщить модератору

202. "Выпуск языка программирования Rust 1.77"  +/–
Сообщение от Вы забыли заполнить поле Name (?), 23-Мрт-24, 19:42 
> Значит эти "передовые идеи" никому не нужны оказались. Ненужны и неудобны

Ты бы ознакомился с ними для начала. Те же нормальные макросы и hot reload сейчас преподносятся как какая-то ультрафича новых язычков.

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

42. "Выпуск языка программирования Rust 1.77"  +2 +/–
Сообщение от Аноним (-), 22-Мрт-24, 15:48 
> Вот взять лисп - он уже как 50+ лет готов и стабилен к использованию

Лисп стабилен?! Этих лиспов как собак нерезаных, каждый так и норовит свой собственный запилить.

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

63. "Выпуск языка программирования Rust 1.77"  +2 +/–
Сообщение от Аноним (63), 22-Мрт-24, 16:58 
Ну, если под лиспами понимать любые языки, использующие s-выражения в качестве синтаксиса, то да. Но тогда встречный вопрос: зачем люди клепают столько языков с си-подобным синтаксисом?
Ответить | Правка | Наверх | Cообщить модератору

174. "Выпуск языка программирования Rust 1.77"  +/–
Сообщение от Аноним (-), 23-Мрт-24, 15:04 
> если под лиспами понимать любые языки, использующие s-выражения в качестве синтаксиса

Есть какие-то другие идеи? common lisp, scheme, elisp, racket, clojure -- это навскидку из сколь-нибудь популярных, и все они называют себя лиспами. У тебя есть какое-то определение которое не включает в список лиспов любые языки, использующие s-выражение в качестве синтаксиса?

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

107. "Выпуск языка программирования Rust 1.77"  +1 +/–
Сообщение от Вы забыли заполнить поле Name (?), 22-Мрт-24, 20:01 
> Лисп стабилен?! Этих лиспов как собак нерезаных,

Стабилен. У комона и схемы есть стандарт. А раз есть стандарт, то есть и разные реализации.

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

113. "Выпуск языка программирования Rust 1.77"  +1 +/–
Сообщение от Аноним (113), 22-Мрт-24, 20:22 
> Лисп стабилен?! Этих лиспов как собак нерезаных, каждый так и норовит свой собственный запилить.

Стандарт ANSI X3.226-1994 (Common Lisp) был принят 8 декабря 1994 года и с тех пор не изменялся. Это достаточно стабильно?

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

154. "Выпуск языка программирования Rust 1.77"  –1 +/–
Сообщение от Аноним (-), 23-Мрт-24, 04:59 
>Стандарт ANSI X3.226-1994 (Common Lisp) был принят 8 декабря 1994 года и с тех пор не изменялся. Это достаточно стабильно?

Почему нет? Вон в сишку каждое десятиление что-нибудь да и добавят. Хотя, сам язык совершеннен, в него нельзя ничего добавить, и из него ничего нельзя убавить.

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

187. "Выпуск языка программирования Rust 1.77"  +1 +/–
Сообщение от Аноним (180), 23-Мрт-24, 16:01 
Через 36 лет после создания языка он был стандартизирован. У Rust ещё время в запасе есть.
Ответить | Правка | К родителю #113 | Наверх | Cообщить модератору

19. "Выпуск языка программирования Rust 1.77"  +3 +/–
Сообщение от cheburnator9000 (ok), 22-Мрт-24, 14:46 
Как же меня трясет когда я читаю слово "типаж". ухх...
Ответить | Правка | Наверх | Cообщить модератору

24. "Выпуск языка программирования Rust 1.77"  +2 +/–
Сообщение от Аноним (24), 22-Мрт-24, 14:48 
А "кортеж"?
Ответить | Правка | Наверх | Cообщить модератору

38. "Выпуск языка программирования Rust 1.77"  +1 +/–
Сообщение от cheburnator9000 (ok), 22-Мрт-24, 15:23 
> А "кортеж"?

То же самое.

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

171. Скрыто модератором  +/–
Сообщение от Аноним (171), 23-Мрт-24, 13:13 
Ответить | Правка | Наверх | Cообщить модератору

162. "Выпуск языка программирования Rust 1.77"  +1 +/–
Сообщение от cheburnator9000 (ok), 23-Мрт-24, 09:45 
> А "кортеж"?

А еще слово "фьючерс"...

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

47. "Выпуск языка программирования Rust 1.77"  +/–
Сообщение от Пряник (?), 22-Мрт-24, 16:08 
Trait ещё можно перевести, как черта.
Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

146. "Выпуск языка программирования Rust 1.77"  –1 +/–
Сообщение от Аноним (146), 22-Мрт-24, 23:13 
Более однозначно "характеристика".
Ответить | Правка | Наверх | Cообщить модератору

67. "Выпуск языка программирования Rust 1.77"  +2 +/–
Сообщение от Аноним (-), 22-Мрт-24, 17:18 
Мне, как представителю театральной интелигенции слово "типаж" очень нравится.
Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

76. "Выпуск языка программирования Rust 1.77"  +1 +/–
Сообщение от Аноним (76), 22-Мрт-24, 17:50 
Предлагаю в Rust добавить ключевое слово Freier
Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

160. "Выпуск языка программирования Rust 1.77"  +/–
Сообщение от anodymus (?), 23-Мрт-24, 08:02 
freirer.push_back();
Ответить | Правка | Наверх | Cообщить модератору

28. "Выпуск языка программирования Rust 1.77"  +/–
Сообщение от Аноним (28), 22-Мрт-24, 14:59 
Тарболы для модулей еще не завезли? Почему нельзя загрузить модули как в Python, Perl?
Ответить | Правка | Наверх | Cообщить модератору

32. "Выпуск языка программирования Rust 1.77"  +2 +/–
Сообщение от Аноним (-), 22-Мрт-24, 15:02 
Руки просто не дошли.
Но ты всегда можешь создать PR и помочь сообществу сделать лучший язык еще лучше.
Уверен что такой специалист как ты справится быстро.
Ответить | Правка | Наверх | Cообщить модератору

163. "Выпуск языка программирования Rust 1.77"  +1 +/–
Сообщение от cheburnator9000 (ok), 23-Мрт-24, 09:50 
> Руки просто не дошли.
> Но ты всегда можешь создать PR и помочь сообществу сделать лучший язык
> еще лучше.
> Уверен что такой специалист как ты справится быстро.

Когда на твой PR набежит с пол сотни смузихлебов и будут в твой код тыкать палочкой по типа "вот тут нужно написать компактнее, тут можно зафигачить все в лямбды, а тут у тебя ошибка в правописании" и каждый со чувством собственной важности с медалями, дипломами и hello world проектами в github профиле, будет тебе всю душу выносить. Вот тогда ты сразу поймешь почему никто на собственном интузиазме не спешит заниматься подобным, по меньшей мере владельцы проекта могут тебя послать, а затем реализовать твою реализацию по _по своему_.

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

199. "Выпуск языка программирования Rust 1.77"  +2 +/–
Сообщение от namenotfound (?), 23-Мрт-24, 19:07 
>написал хрень
>ткнули, попросили переписать по-человечески
>"ыыы, смузихлебы!!"

только на опеннете

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

210. "Выпуск языка программирования Rust 1.77"  –1 +/–
Сообщение от cheburnator9000 (ok), 24-Мрт-24, 04:22 
>>написал хрень
>>ткнули, попросили переписать по-человечески
>>"ыыы, смузихлебы!!"
> только на опеннете

Читай как я написал, а не так как тебе нравится чтобы было написано.

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

211. "Выпуск языка программирования Rust 1.77"  +1 +/–
Сообщение от Аноним (113), 24-Мрт-24, 04:42 
И в чём проблема сделать как просят? Гонор мешает?
Ответить | Правка | К родителю #163 | Наверх | Cообщить модератору

34. "Выпуск языка программирования Rust 1.77"  +1 +/–
Сообщение от Amurzet (ok), 22-Мрт-24, 15:05 
Прошу знающих объяснить, как на Rust писать GUI. вариантов десятки. Многие выглядят нестабильными (судя по версиям). Хотелось бы (например) бинда к классическим winlib, qt.
Ответить | Правка | Наверх | Cообщить модератору

40. "Выпуск языка программирования Rust 1.77"  +/–
Сообщение от Аноним (40), 22-Мрт-24, 15:46 
Я использую egui: https://www.egui.rs/
Ответить | Правка | Наверх | Cообщить модератору

138. "Выпуск языка программирования Rust 1.77"  +/–
Сообщение от Вы забыли заполнить поле Name (?), 22-Мрт-24, 21:59 
Шрифты мыльные в браузере в их демках

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

155. "Выпуск языка программирования Rust 1.77"  +/–
Сообщение от Amurzet (ok), 23-Мрт-24, 05:16 
В том и дело, конечно egui всплывает первым после изучения. Но оно какое-то визуально "на любителя".
Но как делать классические приложения, нативно выглядящие с привычным api.

Разве это не ключевое, на что должны обратить внимание разработчики

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

175. "Выпуск языка программирования Rust 1.77"  –1 +/–
Сообщение от Neon (??), 23-Мрт-24, 15:05 
Шрифты мыльные - капризы, такие капризы
Ответить | Правка | К родителю #138 | Наверх | Cообщить модератору

181. "Выпуск языка программирования Rust 1.77"  +1 +/–
Сообщение от Вы забыли заполнить поле Name (?), 23-Мрт-24, 15:34 
> Шрифты мыльные - капризы, такие капризы

Ой, про либу на ржавом сказали правду, обиделся? Поплачь, снежинка.

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

207. "Выпуск языка программирования Rust 1.77"  +1 +/–
Сообщение от Вы забыли заполнить поле Name (?), 23-Мрт-24, 21:27 
> Шрифты мыльные - капризы, такие капризы

Ну давай я тебе в системе шрифты замылю, посмотрим как ты запоешь. Сомневаюсь, что ты как фанбой и защитничег раста используешь его в каждодневных задачах. У самого небось DE на сишечке.

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

45. "Выпуск языка программирования Rust 1.77"  +5 +/–
Сообщение от Аноним (-), 22-Мрт-24, 15:57 
> как на Rust писать GUI

Никак. Чисто гипотетически я могу предположить, что должны быть в природе качественные бинды к gtk, потому что тот, со своим наколенным ООП, должен хорошо оборачиваться, теоретически. А всё остальное сильно укопалось в прощупывание дизайн-спейса, то есть изучение того, что можно сделать, как сделать, и что в результате получится.

Не, ты можешь попробовать iced или вон egui. Они вполне работают, по-крайней мере для простых гуёв без наворотов. Но мне пришлось мозги себе вывихнуть, чтобы понять как это работает.

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

50. "Выпуск языка программирования Rust 1.77"  –3 +/–
Сообщение от Пряник (?), 22-Мрт-24, 16:11 
С такими вопросами вам лучше сначала без GUI. Вы не осилите слоты и сигналы в Qt.
Ответить | Правка | К родителю #34 | Наверх | Cообщить модератору

198. "Выпуск языка программирования Rust 1.77"  +1 +/–
Сообщение от Андрей (??), 23-Мрт-24, 18:42 
Из приличного: gtk-rs, Slint. Ещё Tauri если GUI на webview устраивает.
Ответить | Правка | К родителю #34 | Наверх | Cообщить модератору

43. "Выпуск языка программирования Rust 1.77"  +/–
Сообщение от Nicho (ok), 22-Мрт-24, 15:53 
Народ, какие преимущества будут, если ядро Windows, переведут на Rust?
И какие преимущества будут, если Firefox тоже переведут на Rust?
Ответить | Правка | Наверх | Cообщить модератору

183. "Выпуск языка программирования Rust 1.77"  +1 +/–
Сообщение от ptremail (ok), 23-Мрт-24, 15:41 
> какие преимущества будут, если ядро Windows, переведут на Rust?

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

Если без шуток, то следует понимать, что при наличии в API повсеместно вызовов, содержащих в параметрах <указатель на буфер> и <размер буфера>, обеспечивать контроль за переполнением буферов со стороны ядра при ошибках в userspace, несколько проблематично. И эта проблема решаема только созданием нового API ядра, несовместимого с текущим. Но это чуть ли не новая операционная система получится.

Так что сначала нужно разработать и стандартизировать некий POSIX-memory-safe API, и лишь затем внедрять его в существующие сейчас операционные системы. А так как переход на это API может занять десятилетия, то, вспоминая Ходжу Насреддина, за эти годы обязательно умрет (устареет) или эмир (rust), или ишак (новое API), или сам Ходжа (мы).

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

197. "Выпуск языка программирования Rust 1.77"  +/–
Сообщение от fidoman (ok), 23-Мрт-24, 18:17 
> <указатель на буфер> и <размер буфера>

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

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

200. "Выпуск языка программирования Rust 1.77"  +/–
Сообщение от ptremail (ok), 23-Мрт-24, 19:27 
Компилятор ядра ничего не знает о приложении. Так же как и компилятор приложения ничего не знает о ядре.
Один из возможных подходов - это выделение буферов только средствами ядра, а в API указывать не указатель на буфер, а уникальный в системе идентификатор буфера, ранее выделенного ядром, размер и адрес которого ядру заведомо известен. Права доступа приложения к такому буферу тоже должны контролироваться ядром.
Ответить | Правка | Наверх | Cообщить модератору

231. "Выпуск языка программирования Rust 1.77"  +/–
Сообщение от Аноним (-), 25-Мрт-24, 16:37 
> Один из возможных подходов - это выделение буферов только средствами ядра

Ответом на это будет повсеместное использование арен. Даже когда приложения пользуются юзерспейсной кучей, им не хватает производительности и они расчехляют арены. А уж если любой malloc будет сисколлом, то в юзерспейсе не останется ничего кроме арен.

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

262. "Выпуск языка программирования Rust 1.77"  +/–
Сообщение от ptremail (ok), 28-Мрт-24, 19:00 
При чем тут ЛЮБОЙ malloc? Речь только про буфера, которые в большинстве случаев выделяются однократно при старте приложения.
Ответить | Правка | Наверх | Cообщить модератору

218. "Выпуск языка программирования Rust 1.77"  +/–
Сообщение от BeLord (ok), 24-Мрт-24, 14:55 
Никаких, проблема виндов не в языке, а в организации разработки. Если бы они осилили модульность и оптимизации под железо это была бы совершенно другая операционная система, но их модели бизнеса это не надо, поэтому имеем глючный комбайн живущий своей жизнью.
Ответить | Правка | К родителю #43 | Наверх | Cообщить модератору

44. "Выпуск языка программирования Rust 1.77"  +3 +/–
Сообщение от Аноним (44), 22-Мрт-24, 15:55 
Кто-то из России делал анализ языков, какие-либо тесты реальные может опубликовать о разных ЯП? Агрессивный маркетинг от СГА начинает мне казаться несколько подозрительным. Возможно что он и не настолько производителен как о нем пишут и вполне возможно что он реально не настолько безопасен как об этом пишут. Вроде идея языка понятна, но он по личному мнению просто не удобен по синтаксису. Тот же Golang мне лично кажется более простым и читабельным. А с/с++ не намного менее производителен. Некоторые пишут про zig и исходя из публичной информации он очень близок по производительности к rust, но я о нем вообще ничего не знаю.
Ответить | Правка | Наверх | Cообщить модератору

56. "Выпуск языка программирования Rust 1.77"  +1 +/–
Сообщение от Аноним (-), 22-Мрт-24, 16:17 
> Вроде идея языка понятна, но он по личному мнению просто не удобен по синтаксису.

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

> Кто-то из России делал анализ языков, какие-либо тесты реальные может опубликовать о разных ЯП?

Это ещё одно палево. Языки невозможно сравнивать в формальных тестах. Могут быть всякие конкурсы, типа benchmarksgame, которые конечно же дают какое-то представление, но это всё вилами по воде, а самое главное: ничего лучше ты не получишь. Вне зависимости из какой страны представители будут делать "анализ языков".

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

> А с/с++ не намного менее производителен.

Где ты "узнал", что C/C++ менее производителен? Стоит полагать, что они одинаковы. Раст может быть быстрее в одних случаях, позволяя какие-то оптимизации за счёт большей строгости, но в других ситуациях C будет быстрее, потому что прямолинейнее к проблеме подходит.

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

71. "Выпуск языка программирования Rust 1.77"  +6 +/–
Сообщение от Аноним (76), 22-Мрт-24, 17:34 
Если хочешь быть лояльным, надо избегать разговоров о синтаксисе.
Ответить | Правка | Наверх | Cообщить модератору

118. "Выпуск языка программирования Rust 1.77"  –3 +/–
Сообщение от Аноним (118), 22-Мрт-24, 20:42 
Простой веб-сервер
```rust
extern crate iron;
#[macro_use] extern crate mime;

use iron::prelude::*;
use iron::status;

fn main() {
  println!("Сервер слушает на http://localhost:3000...");
  Iron::new(get_form).http("localhost:3000").unwarap();
}

fn get_form(_request: &mut Request) -> IronResult<Response> {
  let mut response = Response::new();

  response.set_mut(status::Ok);
  response.set_mut(mime!(Text/Html; Charset=Utf8));
  response.set_mut(r#"
    <title>Калькулятор двух чисел</title>
    <form action="/gcd" method="post">
      <input type="text" name="n"/>
      <input type="text" name="n"/>
      <button type="submit">Ну посчитай</button>
    </form>
  "#);
```
Больше всего мне лично синтаксис не нравится.

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

122. "Выпуск языка программирования Rust 1.77"  +5 +/–
Сообщение от Аноним (122), 22-Мрт-24, 21:08 
Это не "простой веб-сервер". Твой iron умер 5 лет назад и никем никогда не использовался.
Более того, extern crate уже давно не нужно использовать.

Какой-то коммент, застрявший во времени

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

133. "Выпуск языка программирования Rust 1.77"  +2 +/–
Сообщение от freecoder (ok), 22-Мрт-24, 21:47 
Вот вам актуальный вариант:
use std::io;
use axum::response::{Html, IntoResponse};
use axum::routing::get;
use axum::Router;
use tokio::net::TcpListener;
#[tokio::main]
async fn main() -> io::Result<()> {
    let app = Router::new().route("/", get(get_form));
    let listener = TcpListener::bind("0.0.0.0:3000").await?;
    axum::serve(listener, app).await
}
async fn get_form() -> impl IntoResponse {
    Html(
        r#"
            <title>Калькулятор двух чисел</title>
            <form action="/gcd" method="post">
                <input type="text" name="n"/>
                <input type="text" name="n"/>
                <button type="submit">Ну посчитай</button>
            </form>
        "#,
    )
}

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

135. "Выпуск языка программирования Rust 1.77"  –1 +/–
Сообщение от Аноним (184), 22-Мрт-24, 21:52 
>[оверквотинг удален]
>     <input type="text" name="n"/>
>            
>     <input type="text" name="n"/>
>            
>     <button type="submit">Ну посчитай</button>
>            
> </form>
>         "#,
>     )
> }

добавь сюда Cargo.lock, пожалуйста, плайнтекстом.

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

136. "Выпуск языка программирования Rust 1.77"  +1 +/–
Сообщение от freecoder (ok), 22-Мрт-24, 21:54 
> добавь сюда Cargo.lock, пожалуйста, плайнтекстом.

Зачем?


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

137. "Выпуск языка программирования Rust 1.77"  –3 +/–
Сообщение от Аноним (184), 22-Мрт-24, 21:59 
>> добавь сюда Cargo.lock, пожалуйста, плайнтекстом.
> Зачем?

Поржать, господи, что ты серьёзный такой, бро? (｡◕‿‿◕｡)

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

189. "Выпуск языка программирования Rust 1.77"  +/–
Сообщение от Sw00p aka Jerom (?), 23-Мрт-24, 16:26 
ага еще и CoC.md :)
Ответить | Правка | Наверх | Cообщить модератору

119. "Выпуск языка программирования Rust 1.77"  +/–
Сообщение от Аноним (119), 22-Мрт-24, 20:51 
А как тебе проблема с карго? Ну типа такого: https://www.reddit.com/r/rust/comments/pct3mz/adopting_rust_.../

> So this is a large topic with no good answers because everyone needs something different out of their dependency management solutions. In general I’d say that using cargo without connecting to crates.io isn’t well supported at the moment.

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

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

129. "Выпуск языка программирования Rust 1.77"  +2 +/–
Сообщение от Аноним (122), 22-Мрт-24, 21:28 
1) Можно использовать local path (скачав нужные крейты откуда тебе угодно заранее, естественно)
2) Можно указывать ссылки до git-репозитория с нужным crate
3) Можно использовать cargo vendor

В этом плане Cargo куда более легко поддаётся подобным оффлайн-процессам, чем Gradle/Maven в мире Java. Java собрать без подключения к Интернету крайне проблематично, ближе к невозможному

Собственно, надо было и искать ссылку не трёхлетней давности, а чуть посвежее
https://www.reddit.com/r/rust/comments/137hmah/rust_offline/

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

130. "Выпуск языка программирования Rust 1.77"  +1 +/–
Сообщение от freecoder (ok), 22-Мрт-24, 21:30 
Это трёхлетней давности пост. Уже давно cargo поддерживает пользовательские репозитории, и в компаниях их активно используют.
Ответить | Правка | К родителю #119 | Наверх | Cообщить модератору

182. "Выпуск языка программирования Rust 1.77"  +3 +/–
Сообщение от Аноним (-), 23-Мрт-24, 15:39 
> А как тебе проблема с карго? Ну типа такого: https://www.reddit.com/r/rust/comments/pct3mz/adopting_rust_.../

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

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

Ответ на этот вопрос очень простой: пользоваться пока получится пользоваться. Отказываться от технологий и переходить на доисторические технологии до того, как в этом возникла необходимость -- ну это так себе идея.

Проблема в том, что не-американских технологий не существует в принципе. C -- это американская разработка. gcc и clang -- это американские разработки. linux -- это американская разработка. glibc, musl и иже с  ними -- это американские разработки. Компьютер, с которого ты тут комменты пишешь -- это американская разработка. Техпроцесс, по которым твой процессор напечатан -- это американская разработка. Даже ASML, казалось бы, нидерландская компания, но она работала с трансфером технологий из США, и поэтому она будет делать то, что ей из США говорят.

Чисто теоретически, существуют ещё китайские технологии, но на них полагаться ещё опаснее. Если тебе crates.io прикроют, ты врубишь vpn и продолжишь им пользоваться. А если Китай тебе обрубит... ну успехов искать китайский vpn.

Пока технологии не обрубили -- это ситуация "или шах помрёт, или ишак помрёт". Вот скончается завтра человек, занимающий пост президента, и что будет? Сдадут dumbass и будут торговаться по Крыму, в поисках компромисса, между снятием максимума санкций и минимизацией унижения, так? И все твои опасения перестанут быть актуальными. Но если ты прямо сейчас начал предпринимать дорогостоящие шаги по подготовке к тому, что не случиться, то кому от этого хуже будет?

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

214. "Выпуск языка программирования Rust 1.77"  +/–
Сообщение от cheburnator9000 (ok), 24-Мрт-24, 05:52 
Самый производительный веб фреймворк Dragon написан на C++.
Ответить | Правка | К родителю #44 | Наверх | Cообщить модератору

61. "Выпуск языка программирования Rust 1.77"  +/–
Сообщение от Аноним (61), 22-Мрт-24, 16:53 
Вопрос к знатокам - на расте можно писать веб-сервисы? Есть что то зрелое для этого?
Ответить | Правка | Наверх | Cообщить модератору

64. "Выпуск языка программирования Rust 1.77"  –2 +/–
Сообщение от Аноним (64), 22-Мрт-24, 17:04 
> на расте можно писать веб-сервисы?

Только их и можно - кроме как плеваться в консоль и tcp-порт Раст ни на что не способен.
У него нет GUI, нет 2D/3D-графики, вобщем нет ничего для написания полноценного пользовательского приложения.

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

75. "Выпуск языка программирования Rust 1.77"  +1 +/–
Сообщение от laindono (ok), 22-Мрт-24, 17:47 
> У него нет GUI

Строго говоря гуй есть, но достаточно сырой (egui/iced и ещё пара-тройка разных вариаций). К маленьким утилиткам есть на чём кнопки прикрутить, но решений уровня GTK/QT ещё не успели написать.

> нет 2D/3D-графики

Штук пять либ векторной графики есть. Для кроссплатформенного 3д есть https://github.com/gfx-rs/wgpu. Если нужен игродвиг, то есть https://bevyengine.org/ и целая рассыпуха микродвижков на любой вкус.

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

151. "Выпуск языка программирования Rust 1.77"  +/–
Сообщение от fumanchez (ok), 23-Мрт-24, 04:31 
Говоришь как будто GTK (и даже Cairo) это не linux-only маргинальщина, сопоставимая с Qt
Ответить | Правка | Наверх | Cообщить модератору

179. "Выпуск языка программирования Rust 1.77"  +1 +/–
Сообщение от laindono (ok), 23-Мрт-24, 15:26 
Я сам по себе linux-only маргинал. Я говорю так, будто меня спросили, а я ответил.
Ответить | Правка | Наверх | Cообщить модератору

153. "Выпуск языка программирования Rust 1.77"  +/–
Сообщение от Аноним (-), 23-Мрт-24, 04:56 
Слушай ты случаем не перепутал тулкиты и сторонныие библиотеки с языком программирования. Или ты умеешь в RAD только окошечки рисовать, да и события на них навешивать? Такие как ты позорят профессию программиста. Вон из профессии!
Ответить | Правка | К родителю #64 | Наверх | Cообщить модератору

72. "Выпуск языка программирования Rust 1.77"  +2 +/–
Сообщение от laindono (ok), 22-Мрт-24, 17:37 
Попробуй https://actix.rs/ или https://rocket.rs/

Есть ещё https://github.com/tokio-rs/axum, но за него не скажу ибо не пробовал.

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

92. "Выпуск языка программирования Rust 1.77"  +/–
Сообщение от Аноним (-), 22-Мрт-24, 19:10 
> Вопрос к знатокам - на расте можно писать веб-сервисы?

можно даже на asm-е

> Есть что то зрелое для этого?

asm и C, которые оборачиваешь в расте и везде пишешь, что написано на расте

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

97. "Выпуск языка программирования Rust 1.77"  +1 +/–
Сообщение от freecoder (ok), 22-Мрт-24, 19:25 
И actix-web, и axum работают хорошо. Если нужен gRPC помимо HTTP, то лучше строить на стеке tokio + axum + tonic.
Ответить | Правка | К родителю #61 | Наверх | Cообщить модератору

68. "Выпуск языка программирования Rust 1.77"  +6 +/–
Сообщение от EP45DS3L (?), 22-Мрт-24, 17:26 
https://ibb.co/ZYfJDwM

Когда вижу такой синтаксис, моя рука тянется к нагану

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

78. "Выпуск языка программирования Rust 1.77"  +1 +/–
Сообщение от Аноним (78), 22-Мрт-24, 18:24 
А как же илитность? С таким синтаксисом, да на тайловом ВМ под вяланд как покажет погроммист своё поделие, так потенция работодателя сразу поймёт -- этот не женат, да и вообще деффками не интересуется. Хороший работник для галеры!
Ответить | Правка | Наверх | Cообщить модератору

96. "Выпуск языка программирования Rust 1.77"  +2 +/–
Сообщение от freecoder (ok), 22-Мрт-24, 19:22 
А какие претензии именно _к_синтаксису_ в данном фрагменте?
Ответить | Правка | К родителю #68 | Наверх | Cообщить модератору

98. "Выпуск языка программирования Rust 1.77"  –2 +/–
Сообщение от Аноним (184), 22-Мрт-24, 19:41 
> https://ibb.co/ZYfJDwM
> Когда вижу такой синтаксис, моя рука тянется к нагану

Не самый плохой пример, кстати. Или вот:


pub fn read<P: AsRef<Path>>(path: P) -> io::Result<Vec<u8>> {
  fn inner(path: &Path) -> io::Result<Vec<u8>> {
    let mut file = File::open(path)?;
    let mut bytes = Vec::new();
    file.read_to_end(&mut bytes)?;
    Ok(bytes)
  }
  inner(path.as_ref())
}

Тоже не самый плохой из возможных :)
Вырвиглаз в расте обречен из за перегруженной семантики. Тут ничего не поделаешь.

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

125. "Выпуск языка программирования Rust 1.77"  +2 +/–
Сообщение от freecoder (ok), 22-Мрт-24, 21:18 
Зачем писать бессмысленные нагромождения синтаксиса? Можно и лаконичнее.
pub fn read(path: impl AsRef<Path>) -> io::Result<Vec<u8>> {
    let mut bytes = Vec::new();
    File::open(path.as_ref())?.read_to_end(&mut bytes)?;
    Ok(bytes)
}

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

131. "Выпуск языка программирования Rust 1.77"  –1 +/–
Сообщение от Аноним (184), 22-Мрт-24, 21:45 
> Зачем писать бессмысленные нагромождения синтаксиса?

Не бессмысленное, а чтоб показать влияние семантики.

> Можно и лаконичнее.

Можно хоть в однострочник всё запихать. Всё равно вырвиглаз. Со временем можно привыкнуть, но... вырвиглаз.

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

217. "Выпуск языка программирования Rust 1.77"  –1 +/–
Сообщение от Вы забыли заполнить поле Name (?), 24-Мрт-24, 13:12 
> Зачем писать бессмысленные нагромождения синтаксиса? Можно и лаконичнее.
> 
pub fn read(path: impl AsRef<Path>) -> io::Result<Vec<u8>> { 
>     let mut bytes = Vec::new(); 
>     File::open(path.as_ref())?.read_to_end(&mut bytes)?; 
>     Ok(bytes) 
> }

Как определить какие возможные ошибки может вернуть данная функция? Для этого надо в код File::open и read_to_end смотреть?

Почему ошибки аллокации в Vew::new никак не обрабатываются? Считается нормной просто запаниковать и упасть?

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

225. "Выпуск языка программирования Rust 1.77"  +/–
Сообщение от Аноним (-), 25-Мрт-24, 12:12 
> Как определить какие возможные ошибки может вернуть данная функция?

Посмотреть на возвращаемое значение и увидеть там не Result, а io::Result; хлопнуть себя ладонью по лбу и сказать "аааа, это ж та обёртка над Result, которая Result<T, io::Error>".

Если это неочевидно, но интересно, то я бы рекомендовал не вопросы по форумам задавать, а пойти и почитать Rust Book.

> Почему ошибки аллокации в Vew::new никак не обрабатываются? Считается нормной просто запаниковать и упасть?

Да.

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

227. "Выпуск языка программирования Rust 1.77"  +/–
Сообщение от Вы забыли заполнить поле Name (?), 25-Мрт-24, 13:25 
>> Как определить какие возможные ошибки может вернуть данная функция?
> Посмотреть на возвращаемое значение и увидеть там не Result, а io::Result; хлопнуть
> себя ладонью по лбу и сказать "аааа, это ж та обёртка
> над Result, которая Result<T, io::Error>".

А если бы там кроме io::Error были бы другие, например от сторонней либы, что тогда писать?

>> Почему ошибки аллокации в Vew::new никак не обрабатываются? Считается нормной просто запаниковать и упасть?
> Да.

Кек. Нормально для системного языка.

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

233. "Выпуск языка программирования Rust 1.77"  +/–
Сообщение от Аноним (-), 25-Мрт-24, 18:45 
> А если бы там кроме io::Error были бы другие, например от сторонней либы, что тогда писать?

То есть, если функция генерирует ошибки разного типа, и их все хочется возвращать?

Есть разные подходы. Либо ты садишься и создаёшь свой тип ошибок, который включает все, либо берёшь anyhow и оставляешь эту задачу ему. anyhow конструирует типы ошибок в динамике, то есть ты получаешь vtables, аллокации памяти из кучи и все прочие неотъемлимые ООП гнусности.

> Нормально для системного языка.

Да. Бывают исключения, но это де факто статистическая норма.

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

235. "Выпуск языка программирования Rust 1.77"  +/–
Сообщение от Вы забыли заполнить поле Name (?), 25-Мрт-24, 22:47 
>> А если бы там кроме io::Error были бы другие, например от сторонней либы, что тогда писать?
> То есть, если функция генерирует ошибки разного типа, и их все хочется
> возвращать?

Ну кажется нормальная задача. Вот функция работает с io + разбирает какой-то формат и там могут быть свои ошибки.

> Есть разные подходы. Либо ты садишься и создаёшь свой тип ошибок, который
> включает все, либо берёшь anyhow и оставляешь эту задачу ему. anyhow
> конструирует типы ошибок в динамике, то есть ты получаешь vtables, аллокации
> памяти из кучи и все прочие неотъемлимые ООП гнусности.

В zig как я понял можно просто написать ?T в возваращаемом типе и все возможные ошибки функции будут выведены в compile time. Странно, что в расте для этого нужны какие-то приседния.


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

254. "Выпуск языка программирования Rust 1.77"  +/–
Сообщение от freecoder (ok), 27-Мрт-24, 10:16 
> В zig как я понял можно просто написать ?T в возваращаемом типе
> и все возможные ошибки функции будут выведены в compile time. Странно,
> что в расте для этого нужны какие-то приседния.

Допустим, внутри функции генерируется ошибка типа E и другая ошибка типа U. Чему будет равен обобщающий обе ошибки тип T?

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

261. "Выпуск языка программирования Rust 1.77"  +/–
Сообщение от Вы забыли заполнить поле Name (?), 27-Мрт-24, 22:49 
>> В zig как я понял можно просто написать ?T в возваращаемом типе
>> и все возможные ошибки функции будут выведены в compile time. Странно,
>> что в расте для этого нужны какие-то приседния.
> Допустим, внутри функции генерируется ошибка типа E и другая ошибка типа U.
> Чему будет равен обобщающий обе ошибки тип T?

https://ziglang.org/documentation/master/#Merging-Error-Sets

Мне вот интересно как это в расте будет.

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

263. "Выпуск языка программирования Rust 1.77"  +/–
Сообщение от Карлос Сношайтилис (ok), 31-Мрт-24, 21:21 
А мне вот непонятно, как сделано в зиге.
По твоей ссылке там джойн одинаковых типов - енамов (не знаю как они в зиге называются).
А если у тебя ошибки разных типов?
Енам, строка, число, объект. Зиг просто в кучу сваливает?
А если конфликт имён, как понять где какая ошибка? Или не скомпилируется?
Ответить | Правка | Наверх | Cообщить модератору

236. "Выпуск языка программирования Rust 1.77"  +1 +/–
Сообщение от Вы забыли заполнить поле Name (?), 25-Мрт-24, 22:49 
>> Нормально для системного языка.
> Да. Бывают исключения, но это де факто статистическая норма.

https://lkml.org/lkml/2021/4/14/1099

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

256. "Выпуск языка программирования Rust 1.77"  +/–
Сообщение от freecoder (ok), 27-Мрт-24, 10:30 
Это было 3 года назад.

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

260. "Выпуск языка программирования Rust 1.77"  +/–
Сообщение от Вы забыли заполнить поле Name (?), 27-Мрт-24, 22:47 
> Это было 3 года назад.

А что изменилось?

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

255. "Выпуск языка программирования Rust 1.77"  +/–
Сообщение от freecoder (ok), 27-Мрт-24, 10:25 
> Кек. Нормально для системного языка.

Так-то Rust не является специализированным языком для системного программирования, скорее это язык общего назначения, допускающий применение в системном программировании. Проблема с паниками при аллокации - со временем решается в языке. В случае с `Vec`, если вам нужно обработать ошибку аллокации, используйте метод `try_reserve`.

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

99. "Выпуск языка программирования Rust 1.77"  +/–
Сообщение от Вы забыли (-), 22-Мрт-24, 19:50 
> https://ibb.co/ZYfJDwM
> Когда вижу такой синтаксис, моя рука тянется к нагану

Просто прими факт что ты неосилятор.
Или это уже старческая деменция.
Или просто уровень дундучности превышает средний по населению.

Народ как-то осваивает последние С++, а там синтаксис ИМХО посложнее растовского
constexpr auto do(std::string_view param) noexcept -> std::string;

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

101. "Выпуск языка программирования Rust 1.77"  –1 +/–
Сообщение от Аноним (101), 22-Мрт-24, 19:52 
>constexpr auto do(std::string_view param) noexcept -> std::string;

а что не так, что именно тут выглядит сложным?

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

110. "Выпуск языка программирования Rust 1.77"  +5 +/–
Сообщение от Вы забыли (-), 22-Мрт-24, 20:09 
А что в растовском коде сложного?)
Мне растовский код понятен, хотя я прочитал всего одну книжку и написал пару мелких утилит.
Ответить | Правка | Наверх | Cообщить модератору

172. "Выпуск языка программирования Rust 1.77"  –2 +/–
Сообщение от Аноним (-), 23-Мрт-24, 14:19 
Ты не правильно составил своё предложение, вот так надо: "Я прочитал всего одну книжку и написал пару мелких утилит, поэтому мне растовский код понятен".
Ответить | Правка | Наверх | Cообщить модератору

115. "Выпуск языка программирования Rust 1.77"  +5 +/–
Сообщение от Вы забыли заполнить поле Name (?), 22-Мрт-24, 20:24 
> https://ibb.co/ZYfJDwM
> Когда вижу такой синтаксис, моя рука тянется к нагану

Ты впервые pattern matching увидел что ли? Я тебя разочарую, но в других языках он почти также выглядит, даже в питоне.

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

147. "Выпуск языка программирования Rust 1.77"  –3 +/–
Сообщение от Аноним (-), 22-Мрт-24, 23:22 
> Ты впервые pattern matching увидел что ли?

Тише! Тише!
Не пугаю любителей дыряшки такими сложными терминами.
Они застряли где-то в 80-90х, нужно немного подождать пока они эволюционируют)))

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

164. "Выпуск языка программирования Rust 1.77"  +3 +/–
Сообщение от Вы забыли заполнить поле Name (?), 23-Мрт-24, 10:00 
В середине 80х, а тем более 90х уже были ocaml, erlang, так что ты ерунду сказал.
Ответить | Правка | Наверх | Cообщить модератору

185. "Выпуск языка программирования Rust 1.77"  +/–
Сообщение от Аноним (180), 23-Мрт-24, 15:49 
В середине 80-х в СНГ только Turbo C был ворованный (впрочем, все писали на паскале), а в 90-х начали появляться нормальные книжки по C++. Ну о чём вы, какой ocaml, какой erlang.
Ответить | Правка | Наверх | Cообщить модератору

201. "Выпуск языка программирования Rust 1.77"  +1 +/–
Сообщение от Вы забыли заполнить поле Name (?), 23-Мрт-24, 19:40 
> Ну о чём вы, какой ocaml, какой erlang.

Рекомендую посмотреть год создания этих языков. В них есть pattern matching.

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

204. "Выпуск языка программирования Rust 1.77"  +/–
Сообщение от Аноним (204), 23-Мрт-24, 20:42 
Рекомендую ещё раз перечитать мой комментарий. У наших тогда были паскаль, сишечка и что-то краем уха про smalltalk слышали (но никто не видел). Оттуда и растут ноги обожествления ассемблера и сишечки — больше просто ни черта и не было.
Ответить | Правка | Наверх | Cообщить модератору

206. "Выпуск языка программирования Rust 1.77"  +1 +/–
Сообщение от Вы забыли заполнить поле Name (?), 23-Мрт-24, 21:20 
> Рекомендую ещё раз перечитать мой комментарий. У наших тогда были паскаль, сишечка
> и что-то краем уха про smalltalk слышали (но никто не видел).
> Оттуда и растут ноги обожествления ассемблера и сишечки — больше просто ни черта
> и не было.

Ты за всех говоришь? Книга "Автоматическая обработка данных: Язык лисп и его реализация / С.С. Лавров, Г.С. Силагадзе" была издана в 78 году. Прочитай также про реализации лиспа для БЭСМ-6

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

215. "Выпуск языка программирования Rust 1.77"  –2 +/–
Сообщение от Аноним (204), 24-Мрт-24, 11:44 
Узок был круг этих людей, страшно далеки они были от народа.
Ответить | Правка | Наверх | Cообщить модератору

221. "Выпуск языка программирования Rust 1.77"  +/–
Сообщение от n00by (ok), 25-Мрт-24, 11:45 
"Паттерн-матчинг" в СССР появился в 1966-м году, когда Турчин В.Ф. создал на основа нормальных алгорифмов Маркова язык Рефал.

А "в 90-х начали появляться нормальные книжки по C++" это пёрл из разряда "пытались писать ядро Linux на плюсах" или "STL означает стандард либрари". Язык стандартизован в 1998-м, а STL это первые буквы фамилий Степанов и Ли.

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

228. "Выпуск языка программирования Rust 1.77"  +/–
Сообщение от Вы забыли заполнить поле Name (?), 25-Мрт-24, 13:39 
>а STL это первые буквы фамилий Степанов и Ли

Почему Степнову выделили 2 буквы, а Ли всего одну?

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

239. "Выпуск языка программирования Rust 1.77"  +/–
Сообщение от n00by (ok), 26-Мрт-24, 10:06 
>>а STL это первые буквы фамилий Степанов и Ли
> Почему Степнову выделили 2 буквы, а Ли всего одну?

Потому что эксперты не умеют искать тривиальные ответы самостоятельно.

"Я вернулся к разработке обобщенной библиотеки в 1992, когда Билл Ворли, бывший заведующим моей лаборатории, запустил проект по алгоритмам со мной в качестве руководителя.
...
В 1992 г., когда проект был сформирован, в нём было 8 человек. Постепенно группа уменьшалась, и в итоге включала двоих — меня и Менг Ли."

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

241. "Выпуск языка программирования Rust 1.77"  +/–
Сообщение от Вы забыли заполнить поле Name (?), 26-Мрт-24, 10:11 
>>>а STL это первые буквы фамилий Степанов и Ли
>> Почему Степнову выделили 2 буквы, а Ли всего одну?
> Потому что эксперты не умеют искать тривиальные ответы самостоятельно.
> "Я вернулся к разработке обобщенной библиотеки в 1992, когда Билл Ворли, бывший
> заведующим моей лаборатории, запустил проект по алгоритмам со мной в качестве
> руководителя.
> ...
> В 1992 г., когда проект был сформирован, в нём было 8 человек.
> Постепенно группа уменьшалась, и в итоге включала двоих — меня и
> Менг Ли."

И как это отвечает на  вопрос?

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

242. "Выпуск языка программирования Rust 1.77"  +/–
Сообщение от n00by (ok), 26-Мрт-24, 10:15 
>[оверквотинг удален]
>>> Почему Степнову выделили 2 буквы, а Ли всего одну?
>> Потому что эксперты не умеют искать тривиальные ответы самостоятельно.
>> "Я вернулся к разработке обобщенной библиотеки в 1992, когда Билл Ворли, бывший
>> заведующим моей лаборатории, запустил проект по алгоритмам со мной в качестве
>> руководителя.
>> ...
>> В 1992 г., когда проект был сформирован, в нём было 8 человек.
>> Постепенно группа уменьшалась, и в итоге включала двоих — меня и
>> Менг Ли."
> И как это отвечает на  вопрос?

Это объясняет, почему эксперт спроецировал свой опыт и написал "Степнову выделили", вместо "Степанов так захотел". Проще говоря, вопрос не имеет смысла.

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

244. "Выпуск языка программирования Rust 1.77"  +2 +/–
Сообщение от Вы забыли заполнить поле Name (?), 26-Мрт-24, 11:12 
>[оверквотинг удален]
>>> "Я вернулся к разработке обобщенной библиотеки в 1992, когда Билл Ворли, бывший
>>> заведующим моей лаборатории, запустил проект по алгоритмам со мной в качестве
>>> руководителя.
>>> ...
>>> В 1992 г., когда проект был сформирован, в нём было 8 человек.
>>> Постепенно группа уменьшалась, и в итоге включала двоих — меня и
>>> Менг Ли."
>> И как это отвечает на  вопрос?
> Это объясняет, почему эксперт спроецировал свой опыт и написал "Степнову выделили", вместо
> "Степанов так захотел". Проще говоря, вопрос не имеет смысла.

Душно стало, надо проветрить.

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

246. "Выпуск языка программирования Rust 1.77"  –2 +/–
Сообщение от n00by (ok), 26-Мрт-24, 11:55 
>[оверквотинг удален]
>>>> заведующим моей лаборатории, запустил проект по алгоритмам со мной в качестве
>>>> руководителя.
>>>> ...
>>>> В 1992 г., когда проект был сформирован, в нём было 8 человек.
>>>> Постепенно группа уменьшалась, и в итоге включала двоих — меня и
>>>> Менг Ли."
>>> И как это отвечает на  вопрос?
>> Это объясняет, почему эксперт спроецировал свой опыт и написал "Степнову выделили", вместо
>> "Степанов так захотел". Проще говоря, вопрос не имеет смысла.
> Душно стало, надо проветрить.

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

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

253. "Выпуск языка программирования Rust 1.77"  +/–
Сообщение от Аноним (253), 27-Мрт-24, 03:50 
Почему тебя так STL волнует? Месяц назад ты зачем-то повторил эту фразу в ответ на рассуждения Страуструпа о стандартной библиотеке в 1988.

В принципе под STL имеют в виду то оригинальную библиотеку Степанова, то соответствующую часть стандартной библиотеки, то её целиком (жаловаться в Майкрософт, не сюда, это он так делает).

Ну и отдавая дань твоему умению лезть в бутылку, надо на "STL (что значит "Степанов и Ли")" возразить, что это Standard Template Library, ведь именно это написано в названии, а другое не написано и, следовательно, не существует.

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

258. "Выпуск языка программирования Rust 1.77"  +/–
Сообщение от n00by (ok), 27-Мрт-24, 11:33 
> Почему тебя так STL волнует?

Потому что так себя ведёт воображаемый я в твоём маня-мирке.

> Месяц назад ты зачем-то повторил эту фразу
> в ответ на рассуждения Страуструпа о стандартной библиотеке в 1988.

Да? Охотно верю, но не помню, хоть убей. Ты помнишь, значит волнует меня. Поздравляю.

> В принципе под STL имеют в виду то оригинальную библиотеку Степанова, то
> соответствующую часть стандартной библиотеки, то её целиком (жаловаться в Майкрософт,
> не сюда, это он так делает).

Если здесь пишут, что STL это стандартная библиотека, то в ответ я наверняка напишу, что это заблуждение. Как и про то, что ядро якобы пробовали писать на плюсах (стандартизованных значительно позже).

> Ну и отдавая дань твоему умению лезть в бутылку, надо на "STL
> (что значит "Степанов и Ли")" возразить, что это Standard Template Library,
> ведь именно это написано в названии, а другое не написано и,
> следовательно, не существует.

В названии чего? HP STL? SGI STL? STLPort? Или страницы в Википедии? В то, что ты видел оригинальные сорцы Степанова и Ли, я не верю.

"STL означает Степанов и Ли" - это слова самого Степанова. Он автор и авторитет в данном вопросе.

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

193. "Выпуск языка программирования Rust 1.77"  +2 +/–
Сообщение от Аноним (-), 23-Мрт-24, 17:03 
Паттерн матчинг растёт из 70х. В C++ перегрузка операторов явно под влиянием тех идей, только как обычно в C++ через известное место и с полной потерей исходной задумки.
Ответить | Правка | К родителю #147 | Наверх | Cообщить модератору

222. "Выпуск языка программирования Rust 1.77"  +/–
Сообщение от n00by (ok), 25-Мрт-24, 11:51 
Перегрузка не имеет отношения к паттерн-матчингу, поскольку она времени трансляции, а сопоставление с образцом происходит во время исполнения. Но когда в голове каша из темплейтов, генериков, шаблонов и образцов, и не то можно нафантазировать.
Ответить | Правка | Наверх | Cообщить модератору

234. "Выпуск языка программирования Rust 1.77"  +/–
Сообщение от Аноним (-), 25-Мрт-24, 18:47 
Совершенно верно, перегрузка -- это паттерн-матчин компайл-тайма. Причём нисколько не деструктурирующий, и вообще непонятно зачем это было запиливать. Обычная стауструповая позиция "у них есть, значит и у меня будет".
Ответить | Правка | Наверх | Cообщить модератору

240. "Выпуск языка программирования Rust 1.77"  +/–
Сообщение от n00by (ok), 26-Мрт-24, 10:10 
"Сигнатура функции" - это про тип функции, а не про значения её аргументов.
Ответить | Правка | Наверх | Cообщить модератору

186. "Выпуск языка программирования Rust 1.77"  +/–
Сообщение от Аноним (180), 23-Мрт-24, 15:49 
Вам в соседнюю новость про COBOL.
Ответить | Правка | К родителю #68 | Наверх | Cообщить модератору

223. "Выпуск языка программирования Rust 1.77"  +/–
Сообщение от n00by (ok), 25-Мрт-24, 11:54 
> https://ibb.co/ZYfJDwM
> Когда вижу такой синтаксис, моя рука тянется к нагану

Правильно тянется. Я не знаю Rust, но в коде всё понятно. Не понятно, однако, зачем же стреляться?

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

100. "Выпуск языка программирования Rust 1.77"  –2 +/–
Сообщение от Аноним (76), 22-Мрт-24, 19:52 
CHERI-расширения системы команд и компиляторы с поддержкой CHERI решат проблемы дыряшек https://riscv.org/blog/2024/03/securing-software-execution-w.../
Занудный Rust становится ненужен. Выходы будут блокироваться во время исплнения.
Ответить | Правка | Наверх | Cообщить модератору

194. "Выпуск языка программирования Rust 1.77"  +1 +/–
Сообщение от Аноним (-), 23-Мрт-24, 17:09 
Рантайм проверки указателей? Где-то мы это уже видели. Заменим дыры на сегфолты. Многообещающе.
Ответить | Правка | Наверх | Cообщить модератору

126. "Выпуск языка программирования Rust 1.77"  +/–
Сообщение от Аноним (126), 22-Мрт-24, 21:22 
все проблемы программирования сводятся к тому что кодер забыл освободить память?
Ответить | Правка | Наверх | Cообщить модератору

128. "Выпуск языка программирования Rust 1.77"  –1 +/–
Сообщение от freecoder (ok), 22-Мрт-24, 21:24 
Не все. Ваш Кэп.
Ответить | Правка | Наверх | Cообщить модератору

152. "Выпуск языка программирования Rust 1.77"  +/–
Сообщение от fumanchez (ok), 23-Мрт-24, 04:34 
проблема в том, чтобы найти где же он забыл ее освободить
Ответить | Правка | К родителю #126 | Наверх | Cообщить модератору

156. "Выпуск языка программирования Rust 1.77"  +/–
Сообщение от Аноним (156), 23-Мрт-24, 05:37 
Не только. Часть из них бы просто не возникала если бы авторы дыряшки в свое время додумались до простой вещи: когда ты пишешь в коде что-то вроде int *x; то эта штука автоматом инициализировалась бы NULL и финты ушами в стиле "объявил указатель, забыл присвоить ему конкретный адрес и теперь через него читаю или пишу по рандомному адресу ибо фиг знает что в нем" не проходили бы.
Ответить | Правка | К родителю #126 | Наверх | Cообщить модератору

157. "Выпуск языка программирования Rust 1.77"  +/–
Сообщение от qwe (??), 23-Мрт-24, 07:19 
Это хорошо, пока указатель валяется на стеке, где память уже выделена. В ином случае инициализация указателя NULL-ом спровоцирует выделение памяти аллокатором и оптимизация с отложенным выделением памяти едет лесом.
Ответить | Правка | Наверх | Cообщить модератору

158. "Выпуск языка программирования Rust 1.77"  +/–
Сообщение от Аноним (156), 23-Мрт-24, 07:30 
Оптимизация сегфолтом после записи в рандомное место адресного пространства процесса сильно лучше? Особенно с учетом того, что это место может быть разным при каждом запуске.
Ответить | Правка | Наверх | Cообщить модератору

192. "Выпуск языка программирования Rust 1.77"  –1 +/–
Сообщение от qwe (??), 23-Мрт-24, 17:01 
Сильно лучше - это культура написания кода и покрытие его тестами. Да и предупреждения компилятора не стоит игнорировать.
Ответить | Правка | Наверх | Cообщить модератору

203. "Выпуск языка программирования Rust 1.77"  +1 +/–
Сообщение от Аноним (156), 23-Мрт-24, 20:34 
Сильно лучше - это не предупреждения компилятора, а отказ компилировать кривой код. Rust так умеет в ряде случаев, дыряшка нет.
Ответить | Правка | Наверх | Cообщить модератору

205. "Выпуск языка программирования Rust 1.77"  +/–
Сообщение от Аноним (184), 23-Мрт-24, 20:48 
> Сильно лучше - это не предупреждения компилятора, а отказ компилировать кривой код.
> Rust так умеет в ряде случаев, дыряшка нет.

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

Вот пример, CVE-2021-26952 (Use of Uninitialized Resource) на расте. Тот самый UB дыряшки но в растишке. Заводи "вывсёврёти", жду. Почему отказался компилировать код? Он же "кривой"!

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

229. "Выпуск языка программирования Rust 1.77"  +/–
Сообщение от Аноним (-), 25-Мрт-24, 16:10 
> Заводи "вывсёврёти", жду.

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

> Почему отказался компилировать код? Он же "кривой"!

Потому что автор написал unsafe чем прямо сказал компилятору "я знаю что делаю"

Вот фикс этой уязвимости: github.com/andrewhickman/ms3d/commit/599313b
И как только этот код переписали на тот, который проверяется компилятором, то все стало хорошо.

Если бы (да! если бы!) ты читал какие гарантии дает раст, то это примера просто не возникло бы!
Но растохейтеры не в состоянии даже открыть расбук и прочитать пару первый глав.
Печально...

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

238. "Выпуск языка программирования Rust 1.77"  +/–
Сообщение от Аноним (184), 26-Мрт-24, 05:43 
>> Заводи "вывсёврёти", жду.
> Никто не врет. Ну... кроме того, что ты совсем чуть-чуть не понимаешь
> что происходит.
> Но мы будем к тебе снисходительны, поэтому все объясним.

лол, сколько апломба, а потом взял и обделался. смотри далее.

>> Почему отказался компилировать код? Он же "кривой"!
> Потому что автор написал unsafe чем прямо сказал компилятору "я знаю что
> делаю"

а почему? может не было до какой-то версии этих методов? :)

> Вот фикс этой уязвимости: github.com/andrewhickman/ms3d/commit/599313b
> И как только этот код переписали на тот, который проверяется компилятором, то
> все стало хорошо.

лол, а в resize вызовы extend_with и truncate, которые опять с unsafe. Да что ж такое-то?
Ждём пока и их проверят? Или тут уж точно гарантии? В std раста нет CVE, правда ведь?
Ну никогда ж такого не было. :-D

> Если бы (да! если бы!) ты читал какие гарантии дает раст, то
> это примера просто не возникло бы!

Если бы ты понимал о чем пишешь, то не писал бы.

> Но растохейтеры не в состоянии даже открыть расбук и прочитать пару первый
> глав.
> Печально...

лол. показал как завернули unsafe в unsafe, а гонора будто мамкины менделеевы. какие ж вы убогие. :-D

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

209. "Выпуск языка программирования Rust 1.77"  –2 +/–
Сообщение от qwe (??), 24-Мрт-24, 00:14 
Открой для себя опцию -wError и все предупреждения компилятора волшебным образом станут ошибками. С другой стороны, если у тебя дыры в голове, то тебе и раст вряд ли поможет.
Ответить | Правка | К родителю #203 | Наверх | Cообщить модератору

224. "Выпуск языка программирования Rust 1.77"  +/–
Сообщение от n00by (ok), 25-Мрт-24, 12:08 
> Это хорошо, пока указатель валяется на стеке, где память уже выделена. В
> ином случае инициализация указателя NULL-ом спровоцирует выделение памяти аллокатором
> и оптимизация с отложенным выделением памяти едет лесом.

Это заблуждение. В каком "ином случае"? Если указатель в регистре, нечего аллоцировать. Если он на куче - то память под него уже выделена.

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

237. "Выпуск языка программирования Rust 1.77"  +/–
Сообщение от qwe (??), 26-Мрт-24, 04:40 
Аллокатор памяти может быть любой, возможно и самописный. Например в результате системного вызова аллокатор не будет выделять вынимать память из пула свободных блоков, лишь зарезервирует виртуальное адресное пространство, а память будет реально выделена лишь по требованию (попытка чтения или записи по адресу блока). Такое поведение может быть удобно при обработке больших массивов данных с произвольным доступом. Массив указателей может использоваться в каком-нибудь дереве. В случае принудительной инициализации указателей значением NULL в резервированном адресном пространстве, ядро выделит всю запрашиваемую память разом, даже если та память вообще не будет использована.
Ответить | Правка | Наверх | Cообщить модератору

243. "Выпуск языка программирования Rust 1.77"  +/–
Сообщение от n00by (ok), 26-Мрт-24, 10:24 
Начиная с какого-то размера блоков malloc() и calloc() примерно так и работают в Linux, страницы резервируются в адресном пространстве процесса, но коммитятся ядром при попытке доступа. При этом ядро обнуляет их содержимое. Если там хранится указатель, он будет обнулён, то есть как раз "эта штука автоматом инициализировалась бы NULL".
Ответить | Правка | Наверх | Cообщить модератору

251. "Выпуск языка программирования Rust 1.77"  +/–
Сообщение от qwe (??), 26-Мрт-24, 17:35 
Осталось объяснить компилятору когда нужно явное обнуление указателя в коде, а когда оно не требуется, мало того - вредно. В любом случае за подобные инициативы придется расплачиваться производительностью. Кто не умеет или не хочет управлять памятью, могут использовать раст или другой язык с автоматическим подсчетом ссылок. Там плату уже взяли.
Ответить | Правка | Наверх | Cообщить модератору

159. "Выпуск языка программирования Rust 1.77"  +2 +/–
Сообщение от Аноним (156), 23-Мрт-24, 07:36 
Представляешь, ее можно несколько раз освободить. Дыряшка легко позволяет бахнуть на указатель сколько угодно free() хоть подряд, хоть по очереди даже если после первого освобождения новое значение указателю не присваивали.
Ответить | Правка | К родителю #126 | Наверх | Cообщить модератору

212. "Выпуск языка программирования Rust 1.77"  +/–
Сообщение от Аноним (113), 24-Мрт-24, 04:53 
Почти. В оригинале было так: There are only two hard things in Computer Science: cache invalidation and naming things. Потом ещё много шуток придумали, типа «… and off-by-one errors» и подобного. Но суть не меняется: эффективное управление памятью — весьма и весьма сложная штука.
Ответить | Правка | К родителю #126 | Наверх | Cообщить модератору

165. "Выпуск языка программирования Rust 1.77"  +2 +/–
Сообщение от Аноним123 (?), 23-Мрт-24, 10:03 
>const HELLO: &core::ffi::CStr = c"Hello, world!";

На сколько же это неудобно

Почему бы не:
auto HELLO = c"Hello, world!";

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

168. Скрыто модератором  –1 +/–
Сообщение от Аноним (-), 23-Мрт-24, 11:11 
Ответить | Правка | Наверх | Cообщить модератору

177. "Выпуск языка программирования Rust 1.77"  +1 +/–
Сообщение от Аноним (-), 23-Мрт-24, 15:12 
Потому что const требует обязательного указания типа. Логику этого я не совсем понимаю, но думаю что есть причины.

Но ты можешь написать:

    let hello = c"Hello, world!";

Судя по описанию фичи это должно сработать. Но это будет не константа, а immutable переменная. Константу компилятор может заменять значением, как ему хочется, всякие там constexpr считать из неё, а вот immutable переменная -- это всё же переменная, хоть она и неизменная.

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

195. "Выпуск языка программирования Rust 1.77"  +/–
Сообщение от Аноним (-), 23-Мрт-24, 17:31 
А чем отличается немутабельная переменная let a, от константы - const? Ведь и ту, и другую сущность нельзя изменять.
Ответить | Правка | Наверх | Cообщить модератору

196. "Выпуск языка программирования Rust 1.77"  +1 +/–
Сообщение от Аноним (184), 23-Мрт-24, 18:16 
> А чем отличается немутабельная переменная let a, от константы - const? Ведь
> и ту, и другую сущность нельзя изменять.

простите, а вы точно цппшник? как _не_растоман спрашиваю.

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

226. "Выпуск языка программирования Rust 1.77"  +/–
Сообщение от n00by (ok), 25-Мрт-24, 12:18 
>> А чем отличается немутабельная переменная let a, от константы - const? Ведь
>> и ту, и другую сущность нельзя изменять.
> простите, а вы точно цппшник? как _не_растоман спрашиваю.

Так он и спрашивает, чем отличаются. Немутабельная переменная в "цпп" это что? const и extern linkage? Оно не нужно здесь.

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

{
  const char hello[] = {"Hello, world!"};
}

?

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

232. "Выпуск языка программирования Rust 1.77"  +/–
Сообщение от Аноним (-), 25-Мрт-24, 17:11 
> Так он и спрашивает, чем отличаются.

Когда я упоминал выше разницу между immutable variable и constant я, кажется, всё сказал, не? Я думал он перебирает с троллингом, прикидываясь настолько тупым, каких не бывает. Но если это не троллинг, я могу объяснить разницу в терминах C/C++.

Сравни:

    const int my_constant = 5;

и

    enum {
        my_constant = 5;
    };

Первое (в терминах раста)  -- это иммутабельная переменная, второе -- это константа. Второе -- это имя для специального значения, которое существует только на этапе компиляции и нигде больше. Первое же -- это имя, с которым линкеру придётся разбираться, а может оно ещё и в таблице символов конечного исполняемого файла окажется.

> Или вместо указателя на секцию данных получится аллокация всего массива на стеке

Никто не знает. Если это константа, то это всё на усмотрение компилятора, который будет смотреть как эта константа используется, и принимать решение. Может ты из этого массива используешь только третий байт, так зачем вообще в такой ситуации тратить место под массив, почему бы не подставить непосредственно в код значение третьего байта?

> аллокация всего массива на стеке
> {
>   const char hello[] = {"Hello, world!"};
> }

Сишное мышление детектед. Кто сказал, что здесь описаны какие-либо выделения? Например, если этот hello не используется, компилятор может выкинуть его полностью в процессе оптимизаций.

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

245. "Выпуск языка программирования Rust 1.77"  +/–
Сообщение от n00by (ok), 26-Мрт-24, 11:46 
>> Так он и спрашивает, чем отличаются.
> Когда я упоминал выше разницу между immutable variable и constant я, кажется,
> всё сказал, не?

Скорее, я не достаточно подробно написал, что такое external linkage и не упомянул про storage duration.

> Я думал он перебирает с троллингом, прикидываясь настолько
> тупым, каких не бывает. Но если это не троллинг, я могу
> объяснить разницу в терминах C/C++.
> Сравни:
>     const int my_constant = 5;
> и
>     enum {
>         my_constant = 5;
>     };

Если речь именно о плюсах, а не Си, то нет существенной в данном контексте (особенно, когда нет static и область видимости не очевидна) разницы. И то и то не занимает места в секции данных, будет подставлено непосредственным операндом в машинную инструкцию. Соответственно этому стандарт плюсов и позволяет использовать первое вместо второго (распространённая практика определять 8-ми разрядные константы как const uint8_t, пока enum мог быть только типа int).

> Первое (в терминах раста)  -- это иммутабельная переменная, второе -- это
> константа. Второе -- это имя для специального значения, которое существует только
> на этапе компиляции и нигде больше. Первое же -- это имя,
> с которым линкеру придётся разбираться, а может оно ещё и в
> таблице символов конечного исполняемого файла окажется.

Это в случае переменных со связыванием. Отсюда при отсутствии static и возникает вопрос, а не определяется ли константа вот так:

void f()
{
  const int my_constant = 5;
}

>> Или вместо указателя на секцию данных получится аллокация всего массива на стеке
> Никто не знает. Если это константа, то это всё на усмотрение компилятора,
> который будет смотреть как эта константа используется, и принимать решение. Может
> ты из этого массива используешь только третий байт, так зачем вообще
> в такой ситуации тратить место под массив, почему бы не подставить
> непосредственно в код значение третьего байта?

Насколько понимаю, поэтому и возник вопрос, поскольку компилятор плюсов не будет тратить место под константу, если его специально не попросить.

>> аллокация всего массива на стеке
>> {
>>   const char hello[] = {"Hello, world!"};
>> }
> Сишное мышление детектед.

В Си ничего нет про аллокацию на стеке. Там это называется automatic storage duration, и всякий сишник знает, что стека может вообще не быть.

> Кто сказал, что здесь описаны какие-либо выделения? Например,
> если этот hello не используется, компилятор может выкинуть его полностью в
> процессе оптимизаций.

Ну как кто? Вон выше было "первое же -- это имя, с которым линкеру придётся разбираться". Вот это static storage duration, оно же выделение на этапе трансляции, если на рабоче-крестьянском языке.

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

249. "Выпуск языка программирования Rust 1.77"  +/–
Сообщение от Аноним (-), 26-Мрт-24, 14:41 
> Если речь именно о плюсах, а не Си, то нет существенной в данном контексте (особенно, когда нет static и область видимости не очевидна) разницы. И то и то не занимает места в секции данных, будет подставлено непосредственным операндом в машинную инструкцию.

Не совсем. const int my_constant может быть операндом операции взятия адреса, и все такие операции должны возвращать одинаковый адрес. В случае же с enum { my_constant = 5}, каждое взятие адреса &my_constant может возвращать свой собственный адрес. Технически правда, я думаю они всё равно все будут одинаковыми, но это не гарантия компилятора, это способ имплементации компилятора.

> Это в случае переменных со связыванием. Отсюда при отсутствии static и возникает вопрос, а не определяется ли константа вот так

Тут компилятор тоже должен предоставить константе валидный адрес, другое дело, что если оптимизатор достаточно умён, и видя что время жизни ограничено лексическим скоупом, он может подметить ситуацию, когда адрес не используется. Такие штуки становятся сложнее, если константная переменная доступна для юнита (топ-левел декларация static const int), потому что то в чём компиль реально силён, и ещё сложнее, если она не ограничена юнитом (там только LTO может помочь, теоретически, а практически я не знаю, помогает ли он).

> В Си ничего нет про аллокацию на стеке. Там это называется automatic storage duration, и всякий сишник знает, что стека может вообще не быть.

Сишное мышление проявляется не в использовании слова "стек", а в озабоченности стораджем в ущерб всему остальному. C не проводит чётко разницы между, например, переменной, сторейжем ассоциированным с ней, и значением сохранённым в этом сторейже. Лол, из-за этого, я когда столкнулся с растом впервые, недели две бился головой о клавиатуру, не мог понять логики. Сторейж переменной может меняться по ходу дела, компилятор не даёт гарантий на этот счёт, значение в строейже может меняться, или сторейж может уходить от одной переменной к другой (например когда ты делаешь move: let my_big_value = ...; foo(my_big_value); функция foo будет работать с тем же самым куском сторейжа, который был ассоциирован с my_big_value, но переменная в ней будет другая).

В расте const декларация -- это имя для _значения_, let декларация -- это имя для переменной, которая может хранить значение, а может и не хранить. let делает _переменную_ неизменной, но нет гарантий что в сторейж никто не будет писать. В том примере выше, когда мы my_big_value отправляем в функцию, она может начать менять это значение. А вот константа... ты не можешь у неё отнять сторейж, ты не можешь изменить значение хранящееся в нём. Ты не можешь "затенить" константу другой декларацией, чтобы создать лексическую изменяемость:

const int x = 5;
{
    const int x = 6;
    cout << "лол я изменил значение константы x: " << x << endl;
}
cout << "фак ю, она осталась прежней: " << x << endl;

Вот в расте такое не прокатит. С let декларацией ты можешь так поступать, создавая новый бинд взамен старого, с const'ом так уже не выйдет.

> Ну как кто? Вон выше было "первое же -- это имя, с которым линкеру придётся разбираться".

В примере имя lexically scoped в функции. Оно не появляется в таблице имён линкера, все такие имена разрешаются компилятором.

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

252. "Выпуск языка программирования Rust 1.77"  +/–
Сообщение от n00by (ok), 26-Мрт-24, 20:20 
>> Если речь именно о плюсах, а не Си, то нет существенной в данном контексте (особенно, когда нет static и область видимости не очевидна) разницы. И то и то не занимает места в секции данных, будет подставлено непосредственным операндом в машинную инструкцию.
> Не совсем. const int my_constant может быть операндом операции взятия адреса, и
> все такие операции должны возвращать одинаковый адрес.

Я не просто так пишу про static. Наверное, ещё и область видимости стоило бы добавить. Если вернуть адрес автоматической переменной из функции, это UB, но как бы можно, да.

Исходный вопрос, как я понял, сугубо практический. Вроде "я так всегда делал, адрес не брал, и оно в коде ведёт себя как enum".

> В случае же с
> enum { my_constant = 5}, каждое взятие адреса &my_constant может возвращать
> свой собственный адрес. Технически правда, я думаю они всё равно все
> будут одинаковыми, но это не гарантия компилятора, это способ имплементации компилятора.

Вы изначально всё верно писали, но тут принялись мне объяснять лишнее и не туда зашли. Это не lvalue. Если передать my_constant параметром в функцию, то адрес у аргумента получить можно, но это окажется неявно созданная копия.

>> Это в случае переменных со связыванием. Отсюда при отсутствии static и возникает вопрос, а не определяется ли константа вот так
> Тут компилятор тоже должен предоставить константе валидный адрес, другое дело, что если
> оптимизатор достаточно умён, и видя что время жизни ограничено лексическим скоупом,
> он может подметить ситуацию, когда адрес не используется. Такие штуки становятся
> сложнее, если константная переменная доступна для юнита (топ-левел декларация static const
> int), потому что то в чём компиль реально силён, и ещё
> сложнее, если она не ограничена юнитом (там только LTO может помочь,
> теоретически, а практически я не знаю, помогает ли он).

Должен - это когда адрес требуется. Если видимость единицей трансляции не ограничена, то это внешнее связывание, но extern не написано же.

>> В Си ничего нет про аллокацию на стеке. Там это называется automatic storage duration, и всякий сишник знает, что стека может вообще не быть.
> Сишное мышление проявляется не в использовании слова "стек", а в озабоченности стораджем
> в ущерб всему остальному. C не проводит чётко разницы между, например,
> переменной, сторейжем ассоциированным с ней, и значением сохранённым в этом сторейже.

Местом хранения озадачиваются только когда оно статичное (что бы инициализировать один раз при вызове функции, что бы экспортировать, или что бы было локально для потока). В остальных случаях оно автоматическое - то есть на выбор транслятора и не важно где. И Си это не плюсы. В Плюсах есть ссылки, у них нет стоража.

> Лол, из-за этого, я когда столкнулся с растом впервые, недели две
> бился головой о клавиатуру, не мог понять логики. Сторейж переменной может
> меняться по ходу дела, компилятор не даёт гарантий на этот счёт,
> значение в строейже может меняться, или сторейж может уходить от одной
> переменной к другой (например когда ты делаешь move: let my_big_value =
> ...; foo(my_big_value); функция foo будет работать с тем же самым куском
> сторейжа, который был ассоциирован с my_big_value, но переменная в ней будет
> другая).

Логика Rust довольно простая. Автор посмотрел на OCaml и его осенила гениальная мысль - почему бы в Си++ не сделать всё const по умолчанию, ведь это разом решит множество проблем (в частности избавит от всяких фокусов вроде возврата ссылки на локальную статическую переменную, что бы скрыть связывание). Но позже почему-то ушёл из проекта.

>[оверквотинг удален]
> my_big_value отправляем в функцию, она может начать менять это значение. А
> вот константа... ты не можешь у неё отнять сторейж, ты не
> можешь изменить значение хранящееся в нём. Ты не можешь "затенить" константу
> другой декларацией, чтобы создать лексическую изменяемость:
> const int x = 5;
> {
>     const int x = 6;
>     cout << "лол я изменил значение константы x: " << x << endl;
> }
> cout << "фак ю, она осталась прежней: " << x << endl;

#include <iostream>

const struct { mutable int x; } X = { 5 };

int main() {
  X.x = 6;
  std::cout << "я действительно изменил значение константы X: " << X.x << std::endl;
}
// не та область видимости
// std::cout << "лол я изменил значение константы x: " << x << std::endl;

Оно в принципе будет работать и с extern const int x, если определить ссылку на константу через const_cast, но придётся менять защиту страницы памяти константной секции ELF-а, что бы не упало при попытке записи. Что бы не заморачиваться, приходится прибегать к фокусам:

struct { const int x; int y; } X = { 5 };

int main() {
  int& xx = const_cast<int&>(X.x);
  xx = 6;
  std::cout << "я действительно изменил значение константы x: " << X.x << std::endl;
}

> Вот в расте такое не прокатит. С let декларацией ты можешь так
> поступать, создавая новый бинд взамен старого, с const'ом так уже не
> выйдет.

Так в том примере две разные переменные с одним именем.

>> Ну как кто? Вон выше было "первое же -- это имя, с которым линкеру придётся разбираться".
> В примере имя lexically scoped в функции. Оно не появляется в таблице
> имён линкера, все такие имена разрешаются компилятором.

Значит нет неявного static, то есть переменная не имеет связывания, не хранится в секции данных. Пока кто-то не пытается взять её адрес, она крякает как enum.

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

257. "Выпуск языка программирования Rust 1.77"  +/–
Сообщение от Аноним (-), 27-Мрт-24, 11:30 
> Исходный вопрос, как я понял, сугубо практический. Вроде "я так всегда делал, адрес не брал, и оно в коде ведёт себя как enum".

Ну, как бы это сказать. Мне приходилось брать адрес от литерала, например, ты можешь попробовать сделать:

    foo(&5);

Я не знаю как там C или C++ с этим обходится, rust легко создаст 5 в памяти, и передаст в функцию её адрес. Вот с константой примерно то же самое.

> Если передать my_constant параметром в функцию, то адрес у аргумента получить можно, но это окажется неявно созданная копия.

Try it. Я забавы ради попробовал в rust'е, он мне даёт два одинаковых адреса для &5u32 и &MY_CONSTANT, который был объявлен как const MY_CONSTANT: u32 = 5;

C/C++ может быть будет создавать копию, потому что ему надо гарантировать неизменность MY_CONSTANT, но если он даст адрес туда... Хотя &5 наверное будет ведь const int*, да? Он не позволит ничего менять, и тогда вроде нет нужды создавать копию. Хз, короче, раст полагается на то, что если есть *const u32, то это реально const, что он не позволит программисту поменять значение, а если программист окажется настойчивым и изобретательным и поменяет, то он ССЗБ.

> Если видимость единицей трансляции не ограничена, то это внешнее связывание, но extern не написано же.

Может мне память изменяет... Насколько я помню идею за extern, то она говорит компилятору, что ему следует верить, что переменная будет определена где-то в другом месте, а здесь только декларация. А если не указано слово static, то имя экспортируется по-дефолту, и компилятор ничего не может предполагать о том, будет ли нужен адрес этой переменной или нет. Так? Меня память не подводит?

> Логика Rust довольно простая. Автор посмотрел на OCaml и его осенила гениальная мысль - почему бы в Си++ не сделать всё const по умолчанию, ведь это разом решит множество проблем (в частности избавит от всяких фокусов вроде возврата ссылки на локальную статическую переменную, что бы скрыть связывание). Но позже почему-то ушёл из проекта.

Неее... Это сильное переупрощение, и я бы даже сказал, что просто неверно. У него не было идеи делать свой C++ с блекджеком и шлюхами, раст начал конвергировать к C++ позже, когда понабежало всяких других разработчиков, и те начали соревноваться с C++ в плане скорости генерируемых программ. Вот тут можно почитать, что он задумывал, и как его идеи расходились с идеями других: https://graydon2.dreamwidth.org/307291.html Может быть это даже ответ на вопрос, почему он ушёл из проекта, или по-крайней мере часть ответа.

> Оно в принципе будет работать и с extern const int x, если определить ссылку на константу через const_cast, но придётся менять защиту страницы памяти константной секции ELF-а, что бы не упало при попытке записи.

Йее, я вижу начало доходить потихоньку? Значение переменной, даже константной это значение переменной, её можно поменять, пускай для этого и придётся прибегать ко всяким трюкам, иногда системно-зависимым. Но попробуй в рантайме поменять значение из enum'а.

> Так в том примере две разные переменные с одним именем.

Да, это т.н. shadowing, одна переменная затеняет другую. Но константу не удастся затенить, раст будет плевать тебе в лицо и обвинять в безрукости при попытке такого.

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

259. "Выпуск языка программирования Rust 1.77"  +1 +/–
Сообщение от n00by (ok), 27-Мрт-24, 18:32 
>> Исходный вопрос, как я понял, сугубо практический. Вроде "я так всегда делал, адрес не брал, и оно в коде ведёт себя как enum".
> Ну, как бы это сказать. Мне приходилось брать адрес от литерала, например,
> ты можешь попробовать сделать:
>     foo(&5);
> Я не знаю как там C или C++ с этим обходится, rust
> легко создаст 5 в памяти, и передаст в функцию её адрес.
> Вот с константой примерно то же самое.

В таком виде с типом int не сработает, адрес можно брать у lvalue, но не у rvalue.

Потому приходится городить неявное создание объекта (экземпляра типа):

#include <iostream>

const int& wrap(const int& i) { return i; }

int main() {
  // ошибка: операнд унарной операции «&» должен быть lvalue-выражением
  // std::cout << "адрес копии: " << &5 << std::endl;
  std::cout << "адрес копии: " << &wrap(5) << std::endl;
  std::cout << "адрес: " << &"&wrap(5)" << std::endl;
}

С "литералом" срабатывает, поскольку это массив char-ов. Он со времён Си где-то должен быть размещён, значит это объект и адрес у него есть. Такая и многие другие странности происходят из обратной совместимости с Си.

>> Если передать my_constant параметром в функцию, то адрес у аргумента получить можно, но это окажется неявно созданная копия.
> Try it. Я забавы ради попробовал в rust'е, он мне даёт два
> одинаковых адреса для &5u32 и &MY_CONSTANT, который был объявлен как const
> MY_CONSTANT: u32 = 5;

const int& wrap(const int& i) { return i; }

int main()
{
  {
    std::cout << "адрес копии: " << &wrap(5) << std::endl;
  }
  {
    std::cout << "адрес другой копии: " << &wrap(6) << std::endl;
  }
}

$ g++ vol2.cpp -o vol2 && ./vol2
адрес копии: 0x7fff60eb50a4
адрес другой копии: 0x7fff60eb50a4

Здесь одинаковые адреса объясняются очень просто - время жизни первого объекта закончилось и используется тот же адрес в стеке для второго. Но это так случайно совпало.

Если вместо int-ов написать два одинаковых литерала (это очевидно разные объекты), то можно получить для них одинаковый адрес в секции данных - линкер объединит константные строки при оптимизации.

> C/C++ может быть будет создавать копию, потому что ему надо гарантировать неизменность
> MY_CONSTANT, но если он даст адрес туда... Хотя &5 наверное будет
> ведь const int*, да? Он не позволит ничего менять, и тогда
> вроде нет нужды создавать копию. Хз, короче, раст полагается на то,
> что если есть *const u32, то это реально const, что он
> не позволит программисту поменять значение, а если программист окажется настойчивым и
> изобретательным и поменяет, то он ССЗБ.

В примере выше const int*. Вернуть можно и не константу (через const_cast), но без const у аргумента функции ссылка не свяжется с 5. "Копия" тут в том смысле, что rvalue и lvalue исторически получились из выражения копирования значения (справа) в объект (слева) при инициализации.

int lvalue = 5; // rvalue

В случае 5 оно хранится как операнд машинной инструкции, и его адрес получить можно не на всяком процессоре.

Вот эта императивность и определяет многое в языке. Rust в основе функциональный, это почему-то тщательно скрывают, но лично для меня многое объясняет. let lvalue = 5 оказывается чистой функцией, а не объектом в памяти, который по семантике надо сохранить, после чего оптимизировать.

>> Если видимость единицей трансляции не ограничена, то это внешнее связывание, но extern не написано же.
> Может мне память изменяет... Насколько я помню идею за extern, то она
> говорит компилятору, что ему следует верить, что переменная будет определена где-то
> в другом месте, а здесь только декларация. А если не указано
> слово static, то имя экспортируется по-дефолту, и компилятор ничего не может
> предполагать о том, будет ли нужен адрес этой переменной или нет.
> Так? Меня память не подводит?

Это в Си так (но и определения можно делать с extern, не только объявления). В Си++ по умолчанию для констант внутреннее связывание, если определены в неймспейсах. При этом вообще всё очень желательно писать в неймспейсах. Если меня память не подводит.

>> Логика Rust довольно простая. Автор посмотрел на OCaml и его осенила гениальная мысль - почему бы в Си++ не сделать всё const по умолчанию, ведь это разом решит множество проблем (в частности избавит от всяких фокусов вроде возврата ссылки на локальную статическую переменную, что бы скрыть связывание). Но позже почему-то ушёл из проекта.
> Неее... Это сильное переупрощение, и я бы даже сказал, что просто неверно.
> У него не было идеи делать свой C++ с блекджеком и
> шлюхами, раст начал конвергировать к C++ позже, когда понабежало всяких других
> разработчиков, и те начали соревноваться с C++ в плане скорости генерируемых
> программ. Вот тут можно почитать, что он задумывал, и как его
> идеи расходились с идеями других: https://graydon2.dreamwidth.org/307291.html Может
> быть это даже ответ на вопрос, почему он ушёл из проекта,
> или по-крайней мере часть ответа.

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

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

>> Оно в принципе будет работать и с extern const int x, если определить ссылку на константу через const_cast, но придётся менять защиту страницы памяти константной секции ELF-а, что бы не упало при попытке записи.
> Йее, я вижу начало доходить потихоньку? Значение переменной, даже константной это значение
> переменной, её можно поменять, пускай для этого и придётся прибегать ко
> всяким трюкам, иногда системно-зависимым. Но попробуй в рантайме поменять значение из
> enum'а.

Потому что enum это значение (rvalue), а "константная переменная" (пусть простит меня учительница русского) - объект (lvalue), хранящий значение. Это наследие Си, а в плюсах очень старались убрать объекты из секции данных, потому изменили связывание для констант. Сейчас разрешили enum-ы с отличными от int типами членов, а как поступали раньше, когда нужна константа с sizeof == 1? Определять её как const uint8_t. Это могли прописать в правилах кодирования. :)

>> Так в том примере две разные переменные с одним именем.
> Да, это т.н. shadowing, одна переменная затеняет другую. Но константу не удастся
> затенить, раст будет плевать тебе в лицо и обвинять в безрукости
> при попытке такого.

Вот это существенное отличие.

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

250. "Выпуск языка программирования Rust 1.77"  +/–
Сообщение от Аноним (-), 26-Мрт-24, 14:47 
> Если речь именно о плюсах, а не Си, то нет существенной в данном контексте (особенно, когда нет static и область видимости не очевидна) разницы. И то и то не занимает места в секции данных, будет подставлено непосредственным операндом в машинную инструкцию.

Не совсем. const int my_constant может быть операндом операции взятия адреса, и все такие операции должны возвращать одинаковый адрес. В случае же с enum { my_constant = 5}, каждое взятие адреса &my_constant может возвращать свой собственный адрес. Технически правда, я думаю они всё равно все будут одинаковыми, но это не гарантия компилятора, это способ имплементации компилятора.

> Это в случае переменных со связыванием. Отсюда при отсутствии static и возникает вопрос, а не определяется ли константа вот так

Тут компилятор тоже должен предоставить константе валидный адрес, другое дело, что если оптимизатор достаточно умён, и видя что время жизни ограничено лексическим скоупом, он может подметить ситуацию, когда адрес не используется. Такие штуки становятся сложнее, если константная переменная доступна для юнита (топ-левел декларация static const int), потому что то в чём компиль реально силён, и ещё сложнее, если она не ограничена юнитом (там только LTO может помочь, теоретически, а практически я не знаю, помогает ли он).

> В Си ничего нет про аллокацию на стеке. Там это называется automatic storage duration, и всякий сишник знает, что стека может вообще не быть.

Сишное мышление проявляется не в использовании слова "стек", а в озабоченности стораджем в ущерб всему остальному. C не проводит чётко разницы между, например, переменной, сторейжем ассоциированным с ней, и значением сохранённым в этом сторейже. Лол, из-за этого, я когда столкнулся с растом впервые, недели две бился головой о клавиатуру, не мог понять логики. Сторейж переменной может меняться по ходу дела, компилятор не даёт гарантий на этот счёт, значение в строейже может меняться, или сторейж может уходить от одной переменной к другой (например когда ты делаешь move: let my_big_value = ...; foo(my_big_value); функция foo будет работать с тем же самым куском сторейжа, который был ассоциирован с my_big_value, но переменная в ней будет другая).

В расте const декларация -- это имя для _значения_, let декларация -- это имя для переменной, которая может хранить значение, а может и не хранить. let делает _переменную_ неизменной, но нет гарантий что в сторейж никто не будет писать. В том примере выше, когда мы my_big_value отправляем в функцию, она может начать менять это значение. А вот константа... ты не можешь у неё отнять сторейж, ты не можешь изменить значение хранящееся в нём. Ты не можешь "затенить" константу другой декларацией, чтобы создать лексическую изменяемость:

const int x = 5;
{
    const int x = 6;
    cout << "лол я изменил значение константы x: " << x << endl;
}
cout << "фак ю, она осталась прежней: " << x << endl;

Вот в расте такое не прокатит. С let декларацией ты можешь так поступать, создавая новый бинд взамен старого, с const'ом так уже не выйдет.

> Ну как кто? Вон выше было "первое же -- это имя, с которым линкеру придётся разбираться".

В примере имя lexically scoped в функции. Оно не появляется в таблице имён линкера, все такие имена разрешаются компилятором.

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

213. "Выпуск языка программирования Rust 1.77"  +2 +/–
Сообщение от Аноним (113), 24-Мрт-24, 05:04 
Если коротко, то у них разная семантика и жизненный цикл.
Ответить | Правка | К родителю #195 | Наверх | Cообщить модератору

216. "Выпуск языка программирования Rust 1.77"  +/–
Сообщение от Facemaker (?), 24-Мрт-24, 12:24 
>const требует обязательного указания типа. Логику этого я не совсем понимаю, но думаю что есть причины

Одно из неявных правил, которого придерживаются разработчики языка: "выведение типа — локально". Константы (как и функции) могут быть объявлены на уровне модуля.

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

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

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




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

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