- Больше рекурсий богу рекурсий Обязательно используйте внутри рекурсии транзакцию, Аноним (3), 14:08 , 22-Мрт-24 (3) –3
- Половину этого списка поддерживают другие языки , Аноним (4), 14:08 , 22-Мрт-24 (4) +1
- Только не по умолчанию да ЛОЛ, КО (?), 14:13 , 22-Мрт-24 (7) +5
- Это база даже для C и Python , Аноним (4), 14:20 , 22-Мрт-24 (9) +3
- а где почитать про обязательную инициализацию и с , Аноним (36), 15:09 , 22-Мрт-24 (36) –2
- Вот тут почитай -Wall -Wextra -Wpedantic -Werror -Wuninitialized -Werror, Аноним (49), 16:10 , 22-Мрт-24 (49) +10 [^]
- C вообще замечательная штука из него посредством комбинирования флагов компил, Аноним (180), 15:34 , 23-Мрт-24 (180) –1
C++ вообще замечательная штука: из него посредством комбинирования флагов компилятора получается штук сто разных диалектов.
- тока на опеннете можно почитать про разные языки лиспы, и диалекты с на основе, Аноним (184), 15:43 , 23-Мрт-24 (184) +2
> C++ вообще замечательная штука: из него посредством комбинирования флагов компилятора > получается штук сто разных диалектов.тока на опеннете можно почитать про разные языки лиспы, и диалекты с++ на основе флагов компилятора. За то и любим, ценим. Надеюсь кто-то, перед смертью проекта (желаю долгих лет жизни), сделает архив здешнего паноптикума. Потроллить гуманоидов в 2999 году.
- Почитал Связь с обязательно и на уровне языка не нашёл Ещё варианты есть И, Карлос Сношайтилис (ok), 15:02 , 08-Апр-24 (264)
Почитал. Связь с "обязательно" и "на уровне языка" не нашёл. Ещё варианты есть? Или перестанешь глупо шутковать?
- https gcc gnu org onlinedocs gcc Warning-Options html, Аноним (53), 16:14 , 22-Мрт-24 (53) +1
- 129318 , Аноним (36), 14:08 , 22-Мрт-24 (5)
- Зато безопасно , Аноним (-), 16:12 , 22-Мрт-24 (51) +2
- Классическая Tier-3 поддержка от Мозиллы Предполагается что с доводкой до ума д, Kuromi (ok), 17:06 , 22-Мрт-24 (65)
- https doc rust-lang org nightly rustc target-tier-policy htmlДля Tier 1 2 у те, laindono (ok), 18:31 , 22-Мрт-24 (81)
- Логично подтасовывать карты Ставить в один ряд какой-нибудь ресдох и BSD Или H, Аноним (184), 20:00 , 22-Мрт-24 (106) +4
- чем тайр 3 отличчается от не поддерживается вообще - и там и там е6итесь со , Аноним (176), 15:06 , 23-Мрт-24 (176)
чем тайр 3 отличчается от "не поддерживается вообще"? - и там и там "е6итесь со своими проблемами сами"
- Тем, что если оно вообще не поддерживается, то этого кода нет в мейнстриме , laindono (ok), 15:21 , 23-Мрт-24 (178) –1
Тем, что если оно вообще не поддерживается, то этого кода нет в мейнстриме.
- кода ресдоха или хайку и прочий Tier 3 тоже нет в апстриме раста Всё что там ес, Аноним (184), 16:11 , 23-Мрт-24 (188)
> Тем, что если оно вообще не поддерживается, то этого кода нет в > мейнстриме.кода ресдоха или хайку и прочий Tier 3 тоже нет в апстриме раста. Всё что там есть - затычки. Которые даже не гарантируют сборку.
- Тут есть документация Выше ссылку же кинул Вот что говорится о третьем тире Ti, laindono (ok), 16:42 , 23-Мрт-24 (190)
Тут есть документация. Выше ссылку же кинул. Вот что говорится о третьем тире: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.
- Скрыто модератором, Аноним (184), 16:46 , 23-Мрт-24 (191) [---]
даже не читал что ты скинул, лол, просто глянул затычки в коде. в общем, как всегда. звездишь много, а по факту имеем что имеет. тобишь ничего.
- Годный язык , 111 (??), 14:12 , 22-Мрт-24 (6)
- Не понимаю какой вектор развития языка Вот взять лисп - он уже как 50 лет гото, Вы забыли заполнить поле Name (?), 14:41 , 22-Мрт-24 (18) +2
- Лисп уже 50 готов к использованию, а никто его не использует, Аноним (27), 14:56 , 22-Мрт-24 (27) +10 [^]
- Можно еще взять лиспмашину и запустить лисп на ней Но для этого придется грабить, Аноним (-), 15:00 , 22-Мрт-24 (30) +6 [^]
- Лисп стабилен Этих лиспов как собак нерезаных, каждый так и норовит свой собст, Аноним (-), 15:48 , 22-Мрт-24 (42) +2
- Ну, если под лиспами понимать любые языки, использующие s-выражения в качестве с, Аноним (63), 16:58 , 22-Мрт-24 (63) +2
- Есть какие-то другие идеи common lisp, scheme, elisp, racket, clojure -- это на, Аноним (-), 15:04 , 23-Мрт-24 (174)
> если под лиспами понимать любые языки, использующие s-выражения в качестве синтаксисаЕсть какие-то другие идеи? common lisp, scheme, elisp, racket, clojure -- это навскидку из сколь-нибудь популярных, и все они называют себя лиспами. У тебя есть какое-то определение которое не включает в список лиспов любые языки, использующие s-выражение в качестве синтаксиса?
- Стабилен У комона и схемы есть стандарт А раз есть стандарт, то есть и разные , Вы забыли заполнить поле Name (?), 20:01 , 22-Мрт-24 (107) +1
- Стандарт ANSI X3 226-1994 Common Lisp был принят 8 декабря 1994 года и с тех п, Аноним (113), 20:22 , 22-Мрт-24 (113) +1
- Как же меня трясет когда я читаю слово типаж ухх , cheburnator9000 (ok), 14:46 , 22-Мрт-24 (19) +3
- А кортеж , Аноним (24), 14:48 , 22-Мрт-24 (24) +2
- Trait ещё можно перевести, как черта , Пряник (?), 16:08 , 22-Мрт-24 (47)
- Мне, как представителю театральной интелигенции слово типаж очень нравится , Аноним (-), 17:18 , 22-Мрт-24 (67) +2
- Предлагаю в Rust добавить ключевое слово Freier, Аноним (76), 17:50 , 22-Мрт-24 (76) +1
- Тарболы для модулей еще не завезли Почему нельзя загрузить модули как в Python,, Аноним (28), 14:59 , 22-Мрт-24 (28)
- Прошу знающих объяснить, как на Rust писать GUI вариантов десятки Многие выгля, Amurzet (ok), 15:05 , 22-Мрт-24 (34) +1
- Я использую egui https www egui rs , Аноним (40), 15:46 , 22-Мрт-24 (40)
- Шрифты мыльные в браузере в их демках, Вы забыли заполнить поле Name (?), 21:59 , 22-Мрт-24 (138)
- В том и дело, конечно egui всплывает первым после изучения Но оно какое-то визу, Amurzet (ok), 05:16 , 23-Мрт-24 (155)
- Шрифты мыльные - капризы, такие капризы, Neon (??), 15:05 , 23-Мрт-24 (175) –1
Шрифты мыльные - капризы, такие капризы
- Ой, про либу на ржавом сказали правду, обиделся Поплачь, снежинка , Вы забыли заполнить поле Name (?), 15:34 , 23-Мрт-24 (181) +1
> Шрифты мыльные - капризы, такие капризы Ой, про либу на ржавом сказали правду, обиделся? Поплачь, снежинка.
- Ну давай я тебе в системе шрифты замылю, посмотрим как ты запоешь Сомневаюсь, ч, Вы забыли заполнить поле Name (?), 21:27 , 23-Мрт-24 (207) +1
> Шрифты мыльные - капризы, такие капризы Ну давай я тебе в системе шрифты замылю, посмотрим как ты запоешь. Сомневаюсь, что ты как фанбой и защитничег раста используешь его в каждодневных задачах. У самого небось DE на сишечке.
- Никак Чисто гипотетически я могу предположить, что должны быть в природе качест, Аноним (-), 15:57 , 22-Мрт-24 (45) +5
- С такими вопросами вам лучше сначала без GUI Вы не осилите слоты и сигналы в Qt, Пряник (?), 16:11 , 22-Мрт-24 (50) –3
- Из приличного gtk-rs, Slint Ещё Tauri если GUI на webview устраивает , Андрей (??), 18:42 , 23-Мрт-24 (198) +1
Из приличного: gtk-rs, Slint. Ещё Tauri если GUI на webview устраивает.
- Народ, какие преимущества будут, если ядро Windows, переведут на Rust И какие пр, Nicho (ok), 15:53 , 22-Мрт-24 (43)
- На время перевода появятся тысячи рабочих мест для разработчиков А так как в ядр, ptr (ok), 15:41 , 23-Мрт-24 (183) +1
> какие преимущества будут, если ядро Windows, переведут на Rust?На время перевода появятся тысячи рабочих мест для разработчиков. А так как в ядре в любом случае значительная часть кода будет unsafe, то еще несколько лет будут вычищать там привнесенные при переписывании баги, в том числе и при работе с памятью. Если без шуток, то следует понимать, что при наличии в API повсеместно вызовов, содержащих в параметрах <указатель на буфер> и <размер буфера>, обеспечивать контроль за переполнением буферов со стороны ядра при ошибках в userspace, несколько проблематично. И эта проблема решаема только созданием нового API ядра, несовместимого с текущим. Но это чуть ли не новая операционная система получится. Так что сначала нужно разработать и стандартизировать некий POSIX-memory-safe API, и лишь затем внедрять его в существующие сейчас операционные системы. А так как переход на это API может занять десятилетия, то, вспоминая Ходжу Насреддина, за эти годы обязательно умрет (устареет) или эмир (rust), или ишак (новое API), или сам Ходжа (мы).
- может быть можно сделать какие-то байнды, в которых это будет заворачиваться в о, fidoman (ok), 18:17 , 23-Мрт-24 (197)
> <указатель на буфер> и <размер буфера>может быть можно сделать какие-то байнды, в которых это будет заворачиваться в один тип, примерно как массив с размером, и проверку компилятором получим автоматически.
- Компилятор ядра ничего не знает о приложении Так же как и компилятор приложения, ptr (ok), 19:27 , 23-Мрт-24 (200)
Компилятор ядра ничего не знает о приложении. Так же как и компилятор приложения ничего не знает о ядре. Один из возможных подходов - это выделение буферов только средствами ядра, а в API указывать не указатель на буфер, а уникальный в системе идентификатор буфера, ранее выделенного ядром, размер и адрес которого ядру заведомо известен. Права доступа приложения к такому буферу тоже должны контролироваться ядром.
- Ответом на это будет повсеместное использование арен Даже когда приложения поль, Аноним (-), 16:37 , 25-Мрт-24 (231)
> Один из возможных подходов - это выделение буферов только средствами ядраОтветом на это будет повсеместное использование арен. Даже когда приложения пользуются юзерспейсной кучей, им не хватает производительности и они расчехляют арены. А уж если любой malloc будет сисколлом, то в юзерспейсе не останется ничего кроме арен.
- Никаких, проблема виндов не в языке, а в организации разработки Если бы они оси, BeLord (ok), 14:55 , 24-Мрт-24 (218)
Никаких, проблема виндов не в языке, а в организации разработки. Если бы они осилили модульность и оптимизации под железо это была бы совершенно другая операционная система, но их модели бизнеса это не надо, поэтому имеем глючный комбайн живущий своей жизнью.
- Кто-то из России делал анализ языков, какие-либо тесты реальные может опубликова, Аноним (44), 15:55 , 22-Мрт-24 (44) +3
- Зато с икспердным мнением Отсылки к синтаксису -- это палево крайней степени,, Аноним (-), 16:17 , 22-Мрт-24 (56) +1
- Если хочешь быть лояльным, надо избегать разговоров о синтаксисе , Аноним (76), 17:34 , 22-Мрт-24 (71) +6 [^]
- Простой веб-сервер rustextern crate iron macro_use extern crate mime use ir, Аноним (118), 20:42 , 22-Мрт-24 (118) –3
- А как тебе проблема с карго Ну типа такого https www reddit com r rust comme, Аноним (119), 20:51 , 22-Мрт-24 (119)
- 1 Можно использовать local path скачав нужные крейты откуда тебе угодно заране, Аноним (122), 21:28 , 22-Мрт-24 (129) +2
- Это трёхлетней давности пост Уже давно cargo поддерживает пользовательские репо, freecoder (ok), 21:30 , 22-Мрт-24 (130) +1
- Это чья-то проблема, которая недостаточно описана для того, чтобы начинать думат, Аноним (-), 15:39 , 23-Мрт-24 (182) +3
> А как тебе проблема с карго? Ну типа такого: https://www.reddit.com/r/rust/comments/pct3mz/adopting_rust_.../Это чья-то проблема, которая недостаточно описана для того, чтобы начинать думать о том, что с ней делать. > Вот отключат тебе крейты, что будешь делать? Сейчас элементарно вопрос доверия к американским технологиям, позволяющим себе санкции я лично себе задаю. Ответ на этот вопрос очень простой: пользоваться пока получится пользоваться. Отказываться от технологий и переходить на доисторические технологии до того, как в этом возникла необходимость -- ну это так себе идея. Проблема в том, что не-американских технологий не существует в принципе. C -- это американская разработка. gcc и clang -- это американские разработки. linux -- это американская разработка. glibc, musl и иже с ними -- это американские разработки. Компьютер, с которого ты тут комменты пишешь -- это американская разработка. Техпроцесс, по которым твой процессор напечатан -- это американская разработка. Даже ASML, казалось бы, нидерландская компания, но она работала с трансфером технологий из США, и поэтому она будет делать то, что ей из США говорят. Чисто теоретически, существуют ещё китайские технологии, но на них полагаться ещё опаснее. Если тебе crates.io прикроют, ты врубишь vpn и продолжишь им пользоваться. А если Китай тебе обрубит... ну успехов искать китайский vpn. Пока технологии не обрубили -- это ситуация "или шах помрёт, или ишак помрёт". Вот скончается завтра человек, занимающий пост президента, и что будет? Сдадут dumbass и будут торговаться по Крыму, в поисках компромисса, между снятием максимума санкций и минимизацией унижения, так? И все твои опасения перестанут быть актуальными. Но если ты прямо сейчас начал предпринимать дорогостоящие шаги по подготовке к тому, что не случиться, то кому от этого хуже будет?
- Самый производительный веб фреймворк Dragon написан на C , cheburnator9000 (ok), 05:52 , 24-Мрт-24 (214)
Самый производительный веб фреймворк Dragon написан на C++.
- Вопрос к знатокам - на расте можно писать веб-сервисы Есть что то зрелое для эт, Аноним (61), 16:53 , 22-Мрт-24 (61)
- Только их и можно - кроме как плеваться в консоль и tcp-порт Раст ни на что не с, Аноним (64), 17:04 , 22-Мрт-24 (64) –2
- Попробуй https actix rs или https rocket rs Есть ещё https github com tok, laindono (ok), 17:37 , 22-Мрт-24 (72) +2
- можно даже на asm-еasm и C, которые оборачиваешь в расте и везде пишешь, что нап, Аноним (-), 19:10 , 22-Мрт-24 (92)
- И actix-web, и axum работают хорошо Если нужен gRPC помимо HTTP, то лучше строи, freecoder (ok), 19:25 , 22-Мрт-24 (97) +1
- https ibb co ZYfJDwMКогда вижу такой синтаксис, моя рука тянется к нагану, EP45DS3L (?), 17:26 , 22-Мрт-24 (68) +6 [^]
- А как же илитность С таким синтаксисом, да на тайловом ВМ под вяланд как покаже, Аноним (78), 18:24 , 22-Мрт-24 (78) +1
- А какие претензии именно _к_синтаксису_ в данном фрагменте , freecoder (ok), 19:22 , 22-Мрт-24 (96) +2
- Не самый плохой пример, кстати Или вот code pub fn read P AsRef Path path , Аноним (184), 19:41 , 22-Мрт-24 (98) –2
- Зачем писать бессмысленные нагромождения синтаксиса Можно и лаконичнее code pu, freecoder (ok), 21:18 , 22-Мрт-24 (125) +2
- Не бессмысленное, а чтоб показать влияние семантики Можно хоть в однострочник вс, Аноним (184), 21:45 , 22-Мрт-24 (131) –1
- Как определить какие возможные ошибки может вернуть данная функция Для этого на, Вы забыли заполнить поле Name (?), 13:12 , 24-Мрт-24 (217) –1
> Зачем писать бессмысленные нагромождения синтаксиса? Можно и лаконичнее. > 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 никак не обрабатываются? Считается нормной просто запаниковать и упасть?
- Посмотреть на возвращаемое значение и увидеть там не Result, а io Result хлопн, Аноним (-), 12:12 , 25-Мрт-24 (225)
> Как определить какие возможные ошибки может вернуть данная функция?Посмотреть на возвращаемое значение и увидеть там не Result, а io::Result; хлопнуть себя ладонью по лбу и сказать "аааа, это ж та обёртка над Result, которая Result<T, io::Error>". Если это неочевидно, но интересно, то я бы рекомендовал не вопросы по форумам задавать, а пойти и почитать Rust Book. > Почему ошибки аллокации в Vew::new никак не обрабатываются? Считается нормной просто запаниковать и упасть? Да.
- А если бы там кроме io Error были бы другие, например от сторонней либы, что то, Вы забыли заполнить поле Name (?), 13:25 , 25-Мрт-24 (227)
>> Как определить какие возможные ошибки может вернуть данная функция? > Посмотреть на возвращаемое значение и увидеть там не Result, а io::Result; хлопнуть > себя ладонью по лбу и сказать "аааа, это ж та обёртка > над Result, которая Result<T, io::Error>".А если бы там кроме io::Error были бы другие, например от сторонней либы, что тогда писать? >> Почему ошибки аллокации в Vew::new никак не обрабатываются? Считается нормной просто запаниковать и упасть? > Да. Кек. Нормально для системного языка.
- То есть, если функция генерирует ошибки разного типа, и их все хочется возвращат, Аноним (-), 18:45 , 25-Мрт-24 (233)
> А если бы там кроме io::Error были бы другие, например от сторонней либы, что тогда писать?То есть, если функция генерирует ошибки разного типа, и их все хочется возвращать? Есть разные подходы. Либо ты садишься и создаёшь свой тип ошибок, который включает все, либо берёшь anyhow и оставляешь эту задачу ему. anyhow конструирует типы ошибок в динамике, то есть ты получаешь vtables, аллокации памяти из кучи и все прочие неотъемлимые ООП гнусности. > Нормально для системного языка. Да. Бывают исключения, но это де факто статистическая норма.
- Ну кажется нормальная задача Вот функция работает с io разбирает какой-то фор, Вы забыли заполнить поле Name (?), 22:47 , 25-Мрт-24 (235)
>> А если бы там кроме io::Error были бы другие, например от сторонней либы, что тогда писать? > То есть, если функция генерирует ошибки разного типа, и их все хочется > возвращать?Ну кажется нормальная задача. Вот функция работает с io + разбирает какой-то формат и там могут быть свои ошибки. > Есть разные подходы. Либо ты садишься и создаёшь свой тип ошибок, который > включает все, либо берёшь anyhow и оставляешь эту задачу ему. anyhow > конструирует типы ошибок в динамике, то есть ты получаешь vtables, аллокации > памяти из кучи и все прочие неотъемлимые ООП гнусности. В zig как я понял можно просто написать ?T в возваращаемом типе и все возможные ошибки функции будут выведены в compile time. Странно, что в расте для этого нужны какие-то приседния.
- https lkml org lkml 2021 4 14 1099, Вы забыли заполнить поле Name (?), 22:49 , 25-Мрт-24 (236) +1
- Так-то Rust не является специализированным языком для системного программировани, freecoder (ok), 10:25 , 27-Мрт-24 (255)
> Кек. Нормально для системного языка.Так-то Rust не является специализированным языком для системного программирования, скорее это язык общего назначения, допускающий применение в системном программировании. Проблема с паниками при аллокации - со временем решается в языке. В случае с `Vec`, если вам нужно обработать ошибку аллокации, используйте метод `try_reserve`.
- Просто прими факт что ты неосилятор Или это уже старческая деменция Или просто у, Вы забыли (-), 19:50 , 22-Мрт-24 (99)
- Ты впервые pattern matching увидел что ли Я тебя разочарую, но в других языках , Вы забыли заполнить поле Name (?), 20:24 , 22-Мрт-24 (115) +5
- Тише Тише Не пугаю любителей дыряшки такими сложными терминами Они застряли где, Аноним (-), 23:22 , 22-Мрт-24 (147) –3
- В середине 80х, а тем более 90х уже были ocaml, erlang, так что ты ерунду сказал, Вы забыли заполнить поле Name (?), 10:00 , 23-Мрт-24 (164) +3
- В середине 80-х в СНГ только Turbo C был ворованный впрочем, все писали на паск, Аноним (180), 15:49 , 23-Мрт-24 (185)
В середине 80-х в СНГ только Turbo C был ворованный (впрочем, все писали на паскале), а в 90-х начали появляться нормальные книжки по C++. Ну о чём вы, какой ocaml, какой erlang.
- Рекомендую посмотреть год создания этих языков В них есть pattern matching , Вы забыли заполнить поле Name (?), 19:40 , 23-Мрт-24 (201) +1
> Ну о чём вы, какой ocaml, какой erlang.Рекомендую посмотреть год создания этих языков. В них есть pattern matching.
- Рекомендую ещё раз перечитать мой комментарий У наших тогда были паскаль, сишеч, Аноним (204), 20:42 , 23-Мрт-24 (204)
Рекомендую ещё раз перечитать мой комментарий. У наших тогда были паскаль, сишечка и что-то краем уха про smalltalk слышали (но никто не видел). Оттуда и растут ноги обожествления ассемблера и сишечки — больше просто ни черта и не было.
- Ты за всех говоришь Книга Автоматическая обработка данных Язык лисп и его реа, Вы забыли заполнить поле Name (?), 21:20 , 23-Мрт-24 (206) +1
> Рекомендую ещё раз перечитать мой комментарий. У наших тогда были паскаль, сишечка > и что-то краем уха про smalltalk слышали (но никто не видел). > Оттуда и растут ноги обожествления ассемблера и сишечки — больше просто ни черта > и не было.Ты за всех говоришь? Книга "Автоматическая обработка данных: Язык лисп и его реализация / С.С. Лавров, Г.С. Силагадзе" была издана в 78 году. Прочитай также про реализации лиспа для БЭСМ-6
- Паттерн-матчинг в СССР появился в 1966-м году, когда Турчин В Ф создал на осн, n00by (ok), 11:45 , 25-Мрт-24 (221)
"Паттерн-матчинг" в СССР появился в 1966-м году, когда Турчин В.Ф. создал на основа нормальных алгорифмов Маркова язык Рефал.А "в 90-х начали появляться нормальные книжки по C++" это пёрл из разряда "пытались писать ядро Linux на плюсах" или "STL означает стандард либрари". Язык стандартизован в 1998-м, а STL это первые буквы фамилий Степанов и Ли.
- Почему Степнову выделили 2 буквы, а Ли всего одну , Вы забыли заполнить поле Name (?), 13:39 , 25-Мрт-24 (228)
>а STL это первые буквы фамилий Степанов и ЛиПочему Степнову выделили 2 буквы, а Ли всего одну?
- Потому что эксперты не умеют искать тривиальные ответы самостоятельно Я вернулс, n00by (ok), 10:06 , 26-Мрт-24 (239)
>>а STL это первые буквы фамилий Степанов и Ли > Почему Степнову выделили 2 буквы, а Ли всего одну?Потому что эксперты не умеют искать тривиальные ответы самостоятельно. "Я вернулся к разработке обобщенной библиотеки в 1992, когда Билл Ворли, бывший заведующим моей лаборатории, запустил проект по алгоритмам со мной в качестве руководителя. ... В 1992 г., когда проект был сформирован, в нём было 8 человек. Постепенно группа уменьшалась, и в итоге включала двоих — меня и Менг Ли."
- И как это отвечает на вопрос , Вы забыли заполнить поле Name (?), 10:11 , 26-Мрт-24 (241)
>>>а STL это первые буквы фамилий Степанов и Ли >> Почему Степнову выделили 2 буквы, а Ли всего одну? > Потому что эксперты не умеют искать тривиальные ответы самостоятельно. > "Я вернулся к разработке обобщенной библиотеки в 1992, когда Билл Ворли, бывший > заведующим моей лаборатории, запустил проект по алгоритмам со мной в качестве > руководителя. > ... > В 1992 г., когда проект был сформирован, в нём было 8 человек. > Постепенно группа уменьшалась, и в итоге включала двоих — меня и > Менг Ли." И как это отвечает на вопрос?
- gt оверквотинг удален Это объясняет, почему эксперт спроецировал свой опыт и н, n00by (ok), 10:15 , 26-Мрт-24 (242)
>[оверквотинг удален] >>> Почему Степнову выделили 2 буквы, а Ли всего одну? >> Потому что эксперты не умеют искать тривиальные ответы самостоятельно. >> "Я вернулся к разработке обобщенной библиотеки в 1992, когда Билл Ворли, бывший >> заведующим моей лаборатории, запустил проект по алгоритмам со мной в качестве >> руководителя. >> ... >> В 1992 г., когда проект был сформирован, в нём было 8 человек. >> Постепенно группа уменьшалась, и в итоге включала двоих — меня и >> Менг Ли." > И как это отвечает на вопрос?Это объясняет, почему эксперт спроецировал свой опыт и написал "Степнову выделили", вместо "Степанов так захотел". Проще говоря, вопрос не имеет смысла.
- gt оверквотинг удален Душно стало, надо проветрить , Вы забыли заполнить поле Name (?), 11:12 , 26-Мрт-24 (244) +2
>[оверквотинг удален] >>> "Я вернулся к разработке обобщенной библиотеки в 1992, когда Билл Ворли, бывший >>> заведующим моей лаборатории, запустил проект по алгоритмам со мной в качестве >>> руководителя. >>> ... >>> В 1992 г., когда проект был сформирован, в нём было 8 человек. >>> Постепенно группа уменьшалась, и в итоге включала двоих — меня и >>> Менг Ли." >> И как это отвечает на вопрос? > Это объясняет, почему эксперт спроецировал свой опыт и написал "Степнову выделили", вместо > "Степанов так захотел". Проще говоря, вопрос не имеет смысла.Душно стало, надо проветрить.
- [.... слишком большой тред, остальное см. в режиме смотреть все |+ ] (246)!
- Почему тебя так STL волнует Месяц назад ты зачем-то повторил эту фразу в ответ , Аноним (253), 03:50 , 27-Мрт-24 (253)
Почему тебя так STL волнует? Месяц назад ты зачем-то повторил эту фразу в ответ на рассуждения Страуструпа о стандартной библиотеке в 1988.В принципе под STL имеют в виду то оригинальную библиотеку Степанова, то соответствующую часть стандартной библиотеки, то её целиком (жаловаться в Майкрософт, не сюда, это он так делает). Ну и отдавая дань твоему умению лезть в бутылку, надо на "STL (что значит "Степанов и Ли")" возразить, что это Standard Template Library, ведь именно это написано в названии, а другое не написано и, следовательно, не существует.
- Потому что так себя ведёт воображаемый я в твоём маня-мирке Да Охотно верю, но , n00by (ok), 11:33 , 27-Мрт-24 (258)
> Почему тебя так STL волнует?Потому что так себя ведёт воображаемый я в твоём маня-мирке. > Месяц назад ты зачем-то повторил эту фразу > в ответ на рассуждения Страуструпа о стандартной библиотеке в 1988. Да? Охотно верю, но не помню, хоть убей. Ты помнишь, значит волнует меня. Поздравляю. > В принципе под STL имеют в виду то оригинальную библиотеку Степанова, то > соответствующую часть стандартной библиотеки, то её целиком (жаловаться в Майкрософт, > не сюда, это он так делает). Если здесь пишут, что STL это стандартная библиотека, то в ответ я наверняка напишу, что это заблуждение. Как и про то, что ядро якобы пробовали писать на плюсах (стандартизованных значительно позже). > Ну и отдавая дань твоему умению лезть в бутылку, надо на "STL > (что значит "Степанов и Ли")" возразить, что это Standard Template Library, > ведь именно это написано в названии, а другое не написано и, > следовательно, не существует. В названии чего? HP STL? SGI STL? STLPort? Или страницы в Википедии? В то, что ты видел оригинальные сорцы Степанова и Ли, я не верю. "STL означает Степанов и Ли" - это слова самого Степанова. Он автор и авторитет в данном вопросе.
- Паттерн матчинг растёт из 70х В C перегрузка операторов явно под влиянием тех, Аноним (-), 17:03 , 23-Мрт-24 (193) +2
Паттерн матчинг растёт из 70х. В C++ перегрузка операторов явно под влиянием тех идей, только как обычно в C++ через известное место и с полной потерей исходной задумки.
- Вам в соседнюю новость про COBOL , Аноним (180), 15:49 , 23-Мрт-24 (186)
Вам в соседнюю новость про COBOL.
- Правильно тянется Я не знаю Rust, но в коде всё понятно Не понятно, однако, за, n00by (ok), 11:54 , 25-Мрт-24 (223)
> https://ibb.co/ZYfJDwM > Когда вижу такой синтаксис, моя рука тянется к нагану Правильно тянется. Я не знаю Rust, но в коде всё понятно. Не понятно, однако, зачем же стреляться?
- CHERI-расширения системы команд и компиляторы с поддержкой CHERI решат проблемы , Аноним (76), 19:52 , 22-Мрт-24 (100) –2
- все проблемы программирования сводятся к тому что кодер забыл освободить память , Аноним (126), 21:22 , 22-Мрт-24 (126)
- Не все Ваш Кэп , freecoder (ok), 21:24 , 22-Мрт-24 (128) –1
- проблема в том, чтобы найти где же он забыл ее освободить, fumanchez (ok), 04:34 , 23-Мрт-24 (152)
- Не только Часть из них бы просто не возникала если бы авторы дыряшки в свое вре, Аноним (156), 05:37 , 23-Мрт-24 (156)
- Это хорошо, пока указатель валяется на стеке, где память уже выделена В ином сл, qwe (??), 07:19 , 23-Мрт-24 (157)
- Оптимизация сегфолтом после записи в рандомное место адресного пространства проц, Аноним (156), 07:30 , 23-Мрт-24 (158)
- Сильно лучше - это культура написания кода и покрытие его тестами Да и предупре, qwe (??), 17:01 , 23-Мрт-24 (192) –1
Сильно лучше - это культура написания кода и покрытие его тестами. Да и предупреждения компилятора не стоит игнорировать.
- Сильно лучше - это не предупреждения компилятора, а отказ компилировать кривой к, Аноним (156), 20:34 , 23-Мрт-24 (203) +1
Сильно лучше - это не предупреждения компилятора, а отказ компилировать кривой код. Rust так умеет в ряде случаев, дыряшка нет.
- ты даже не понимаешь о чем тебе говорят, лол всё зависит от задачи коррестность, Аноним (184), 20:48 , 23-Мрт-24 (205)
> Сильно лучше - это не предупреждения компилятора, а отказ компилировать кривой код. > Rust так умеет в ряде случаев, дыряшка нет.ты даже не понимаешь о чем тебе говорят, лол. всё зависит от задачи. коррестность выполнения задачи покрывается анализаторами и тестами. Вот пример, CVE-2021-26952 (Use of Uninitialized Resource) на расте. Тот самый UB дыряшки но в растишке. Заводи "вывсёврёти", жду. Почему отказался компилировать код? Он же "кривой"!
- Никто не врет Ну кроме того, что ты совсем чуть-чуть не понимаешь что происх, Аноним (-), 16:10 , 25-Мрт-24 (229)
> Заводи "вывсёврёти", жду.Никто не врет. Ну... кроме того, что ты совсем чуть-чуть не понимаешь что происходит. Но мы будем к тебе снисходительны, поэтому все объясним. > Почему отказался компилировать код? Он же "кривой"! Потому что автор написал unsafe чем прямо сказал компилятору "я знаю что делаю" Вот фикс этой уязвимости: github.com/andrewhickman/ms3d/commit/599313b И как только этот код переписали на тот, который проверяется компилятором, то все стало хорошо. Если бы (да! если бы!) ты читал какие гарантии дает раст, то это примера просто не возникло бы! Но растохейтеры не в состоянии даже открыть расбук и прочитать пару первый глав. Печально...
- лол, сколько апломба, а потом взял и обделался смотри далее а почему может не , Аноним (184), 05:43 , 26-Мрт-24 (238)
>> Заводи "вывсёврёти", жду. > Никто не врет. Ну... кроме того, что ты совсем чуть-чуть не понимаешь > что происходит. > Но мы будем к тебе снисходительны, поэтому все объясним.лол, сколько апломба, а потом взял и обделался. смотри далее. >> Почему отказался компилировать код? Он же "кривой"! > Потому что автор написал unsafe чем прямо сказал компилятору "я знаю что > делаю" а почему? может не было до какой-то версии этих методов? :) > Вот фикс этой уязвимости: github.com/andrewhickman/ms3d/commit/599313b > И как только этот код переписали на тот, который проверяется компилятором, то > все стало хорошо. лол, а в resize вызовы extend_with и truncate, которые опять с unsafe. Да что ж такое-то? Ждём пока и их проверят? Или тут уж точно гарантии? В std раста нет CVE, правда ведь? Ну никогда ж такого не было. :-D > Если бы (да! если бы!) ты читал какие гарантии дает раст, то > это примера просто не возникло бы! Если бы ты понимал о чем пишешь, то не писал бы. > Но растохейтеры не в состоянии даже открыть расбук и прочитать пару первый > глав. > Печально... лол. показал как завернули unsafe в unsafe, а гонора будто мамкины менделеевы. какие ж вы убогие. :-D
- Открой для себя опцию -wError и все предупреждения компилятора волшебным образом, qwe (??), 00:14 , 24-Мрт-24 (209) –2
Открой для себя опцию -wError и все предупреждения компилятора волшебным образом станут ошибками. С другой стороны, если у тебя дыры в голове, то тебе и раст вряд ли поможет.
- Это заблуждение В каком ином случае Если указатель в регистре, нечего аллоци, n00by (ok), 12:08 , 25-Мрт-24 (224)
> Это хорошо, пока указатель валяется на стеке, где память уже выделена. В > ином случае инициализация указателя NULL-ом спровоцирует выделение памяти аллокатором > и оптимизация с отложенным выделением памяти едет лесом.Это заблуждение. В каком "ином случае"? Если указатель в регистре, нечего аллоцировать. Если он на куче - то память под него уже выделена.
- Аллокатор памяти может быть любой, возможно и самописный Например в результате , qwe (??), 04:40 , 26-Мрт-24 (237)
Аллокатор памяти может быть любой, возможно и самописный. Например в результате системного вызова аллокатор не будет выделять вынимать память из пула свободных блоков, лишь зарезервирует виртуальное адресное пространство, а память будет реально выделена лишь по требованию (попытка чтения или записи по адресу блока). Такое поведение может быть удобно при обработке больших массивов данных с произвольным доступом. Массив указателей может использоваться в каком-нибудь дереве. В случае принудительной инициализации указателей значением NULL в резервированном адресном пространстве, ядро выделит всю запрашиваемую память разом, даже если та память вообще не будет использована.
- Начиная с какого-то размера блоков malloc и calloc примерно так и работают в, n00by (ok), 10:24 , 26-Мрт-24 (243)
Начиная с какого-то размера блоков malloc() и calloc() примерно так и работают в Linux, страницы резервируются в адресном пространстве процесса, но коммитятся ядром при попытке доступа. При этом ядро обнуляет их содержимое. Если там хранится указатель, он будет обнулён, то есть как раз "эта штука автоматом инициализировалась бы NULL".
- Осталось объяснить компилятору когда нужно явное обнуление указателя в коде, а к, qwe (??), 17:35 , 26-Мрт-24 (251)
Осталось объяснить компилятору когда нужно явное обнуление указателя в коде, а когда оно не требуется, мало того - вредно. В любом случае за подобные инициативы придется расплачиваться производительностью. Кто не умеет или не хочет управлять памятью, могут использовать раст или другой язык с автоматическим подсчетом ссылок. Там плату уже взяли.
- Представляешь, ее можно несколько раз освободить Дыряшка легко позволяет бахнут, Аноним (156), 07:36 , 23-Мрт-24 (159) +2
- Почти В оригинале было так There are only two hard things in Computer Science , Аноним (113), 04:53 , 24-Мрт-24 (212)
Почти. В оригинале было так: There are only two hard things in Computer Science: cache invalidation and naming things. Потом ещё много шуток придумали, типа «… and off-by-one errors» и подобного. Но суть не меняется: эффективное управление памятью — весьма и весьма сложная штука.
- На сколько же это неудобноПочему бы не auto HELLO c Hello, world , Аноним123 (?), 10:03 , 23-Мрт-24 (165) +2
- Скрыто модератором, Аноним (-), 11:11 , 23-Мрт-24 (168) –1 [---]
>Почему бы не: >auto HELLO = c"Hello, world!";А так получится небезопасно.
- Потому что const требует обязательного указания типа Логику этого я не совсем п, Аноним (-), 15:12 , 23-Мрт-24 (177) +1
Потому что const требует обязательного указания типа. Логику этого я не совсем понимаю, но думаю что есть причины.Но ты можешь написать: let hello = c"Hello, world!"; Судя по описанию фичи это должно сработать. Но это будет не константа, а immutable переменная. Константу компилятор может заменять значением, как ему хочется, всякие там constexpr считать из неё, а вот immutable переменная -- это всё же переменная, хоть она и неизменная.
- А чем отличается немутабельная переменная let a, от константы - const Ведь и ту, Аноним (-), 17:31 , 23-Мрт-24 (195)
А чем отличается немутабельная переменная let a, от константы - const? Ведь и ту, и другую сущность нельзя изменять.
- простите, а вы точно цппшник как _не_растоман спрашиваю , Аноним (184), 18:16 , 23-Мрт-24 (196) +1
> А чем отличается немутабельная переменная let a, от константы - const? Ведь > и ту, и другую сущность нельзя изменять.простите, а вы точно цппшник? как _не_растоман спрашиваю.
- Так он и спрашивает, чем отличаются Немутабельная переменная в цпп это что c, n00by (ok), 12:18 , 25-Мрт-24 (226)
>> А чем отличается немутабельная переменная let a, от константы - const? Ведь >> и ту, и другую сущность нельзя изменять. > простите, а вы точно цппшник? как _не_растоман спрашиваю.Так он и спрашивает, чем отличаются. Немутабельная переменная в "цпп" это что? const и extern linkage? Оно не нужно здесь. Или вместо указателя на секцию данных получится аллокация всего массива на стеке { const char hello[] = {"Hello, world!"}; } ?
- Когда я упоминал выше разницу между immutable variable и constant я, кажется, вс, Аноним (-), 17:11 , 25-Мрт-24 (232)
> Так он и спрашивает, чем отличаются.Когда я упоминал выше разницу между immutable variable и constant я, кажется, всё сказал, не? Я думал он перебирает с троллингом, прикидываясь настолько тупым, каких не бывает. Но если это не троллинг, я могу объяснить разницу в терминах C/C++. Сравни: const int my_constant = 5; и enum { my_constant = 5; }; Первое (в терминах раста) -- это иммутабельная переменная, второе -- это константа. Второе -- это имя для специального значения, которое существует только на этапе компиляции и нигде больше. Первое же -- это имя, с которым линкеру придётся разбираться, а может оно ещё и в таблице символов конечного исполняемого файла окажется. > Или вместо указателя на секцию данных получится аллокация всего массива на стеке Никто не знает. Если это константа, то это всё на усмотрение компилятора, который будет смотреть как эта константа используется, и принимать решение. Может ты из этого массива используешь только третий байт, так зачем вообще в такой ситуации тратить место под массив, почему бы не подставить непосредственно в код значение третьего байта? > аллокация всего массива на стеке > { > const char hello[] = {"Hello, world!"}; > } Сишное мышление детектед. Кто сказал, что здесь описаны какие-либо выделения? Например, если этот hello не используется, компилятор может выкинуть его полностью в процессе оптимизаций.
- Скорее, я не достаточно подробно написал, что такое external linkage и не упомян, n00by (ok), 11:46 , 26-Мрт-24 (245)
>> Так он и спрашивает, чем отличаются. > Когда я упоминал выше разницу между 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, оно же выделение на этапе трансляции, если на рабоче-крестьянском языке.
- Не совсем const int my_constant может быть операндом операции взятия адреса, и , Аноним (-), 14:41 , 26-Мрт-24 (249)
> Если речь именно о плюсах, а не Си, то нет существенной в данном контексте (особенно, когда нет 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 в функции. Оно не появляется в таблице имён линкера, все такие имена разрешаются компилятором.
- Я не просто так пишу про static Наверное, ещё и область видимости стоило бы доб, n00by (ok), 20:20 , 26-Мрт-24 (252)
>> Если речь именно о плюсах, а не Си, то нет существенной в данном контексте (особенно, когда нет 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.
- Ну, как бы это сказать Мне приходилось брать адрес от литерала, например, ты мо, Аноним (-), 11:30 , 27-Мрт-24 (257)
> Исходный вопрос, как я понял, сугубо практический. Вроде "я так всегда делал, адрес не брал, и оно в коде ведёт себя как 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, одна переменная затеняет другую. Но константу не удастся затенить, раст будет плевать тебе в лицо и обвинять в безрукости при попытке такого.
- В таком виде с типом int не сработает, адрес можно брать у lvalue, но не у rvalu, n00by (ok), 18:32 , 27-Мрт-24 (259) +1
>> Исходный вопрос, как я понял, сугубо практический. Вроде "я так всегда делал, адрес не брал, и оно в коде ведёт себя как 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, одна переменная затеняет другую. Но константу не удастся > затенить, раст будет плевать тебе в лицо и обвинять в безрукости > при попытке такого. Вот это существенное отличие.
- Не совсем const int my_constant может быть операндом операции взятия адреса, и , Аноним (-), 14:47 , 26-Мрт-24 (250)
> Если речь именно о плюсах, а не Си, то нет существенной в данном контексте (особенно, когда нет 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 в функции. Оно не появляется в таблице имён линкера, все такие имена разрешаются компилятором.
- Если коротко, то у них разная семантика и жизненный цикл , Аноним (113), 05:04 , 24-Мрт-24 (213) +2
Если коротко, то у них разная семантика и жизненный цикл.
- Одно из неявных правил, которого придерживаются разработчики языка выведение т, Facemaker (?), 12:24 , 24-Мрт-24 (216)
>const требует обязательного указания типа. Логику этого я не совсем понимаю, но думаю что есть причиныОдно из неявных правил, которого придерживаются разработчики языка: "выведение типа — локально". Константы (как и функции) могут быть объявлены на уровне модуля.
|