Опубликован релиз языка программирования общего назначения Rust 1.76, основанного проектом Mozilla, но ныне развиваемого под покровительством независимой некоммерческой организации Rust Foundation. Язык сфокусирован на безопасной работе с памятью и предоставляет средства для достижения высокого параллелизма выполнения заданий, при этом обходясь без использования сборщика мусора и runtime (runtime сводится к базовой инициализации и сопровождению стандартной библиотеки)...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=60575
Вообще, впервые слышу, чтобы сборка софта влияла на игры. Это же не венда, в венде компиляция мешает играм. Реально играм мешают только загруженная CUDA, и то не совсем критично.
Совсем больной? Игры утилизируют RAM, CPU не в меньшей степени чем GPU/VRAM. Еще скажи что можно все ядра отключить, скорость залочить на 800мгц и ФПС не должен упасть.
Сборка проекта на Rust утилизирует все ядра по простой банальной причине, количество crate пакетов зависимостей и зависимостей их зависимостей может достигать до ТЫСЯЧИ.
С NodeJS не перепутал?)
Компиляция утилизирует все ядра потому что по-умолчанию задана параллельная сборка на всех ядрах. Это можно настроить и по-другому.
Или ты? Сборка софта в линуксе всегда происходит с пониженным приоритетом и процессор буквально никогда не является узким местом для остального софта. Память тоже не используется так уж активно, современная память в многоканальном режиме весьма производительная. Вот забитый io может быть проблемой и создавать задержки, ionice что-то не работает так хорошо как раньше.
втф я только что прочитал... вспоминаются экспертные мнения из детства о том, как винда активному окну больше cpu выделяет...
Так у меня генту, я бы заметил. А вот почему венда так хреново себя ощущает под минимальной нагрузкой, я не имею понятия, но это факт.
> втф я только что прочитал... вспоминаются экспертные мнения из детства о том,
> как винда активному окну больше cpu выделяет...Система повышает динамический приоритет потока для повышения его отклика следующим образом:
При переносе процесса, использующего NORMAL_PRIORITY_CLASS, на передний планировщик увеличивает класс приоритета процесса, связанного с окном переднего плана, чтобы он был больше или равен классу приоритета любых фоновых процессов. Класс приоритета возвращается к исходному параметру, когда процесс больше не находится на переднем плане.
Когда окно получает входные данные, такие как сообщения таймера, сообщения мыши или ввод с клавиатуры, планировщик повышает приоритет потока, которому принадлежит окно.
https://learn.microsoft.com/ru-ru/windows/win32/procthread/p...
> Или ты? Сборка софта в линуксе всегда происходит с пониженным приоритетом и
> процессор буквально никогда не является узким местом для остального софта. Память
> тоже не используется так уж активно, современная память в многоканальном режиме
> весьма производительная. Вот забитый io может быть проблемой и создавать задержки,
> ionice что-то не работает так хорошо как раньше.В каком мире работа обычного бинарника gcc или clang запускается с пониженным приоритетом? Или у вас Linux ZverCD Edition ну тогда понятно.
В любом, в котором "сборщик" не одноклеточное, потому что это целиком на нём как правило. Но дело в том, что изменение приоритетов процессора у процессов венды далеко не так замечательно работает. И особенно что касается планировщика io.
Ну у него может быть сборка с nice запускается.
PORTAGE_NICENESS откройте для себя.
>скорость залочить на 800мгц и ФПС не должен упасть.Ты не поверишь, залоченность на низкую частоту влияет только на скорость загрузки уровней. По крайней мере если ядер много. А вот для браузеров частота это всё и при 800 МГц некоторые сайты ощутимо лагают.
Версии языка выходят быстрее, чем я пишу один проект.
На самом деле нет, просто добавили фичи и выкатили новую версию.
Которую обязательно нудно собрать, чтобы собрать последующие.
> чем я переписываю один проектпоправил, уж извини
Какая разница, что тебе переписывать, оригинальный проект или свой переписанный?
У Rust фиксированный график выпусков, новая минорная версия языка выходит через каждые 6 недель.
> Реализован третий уровень поддержки для платформ {x86_64,i686}-win7-windows-msvcА сколько воя было что семерку дропают!
Впрочем, это было читать совсем не удивительно читать на опеннете.
интересно еще то, что года 3-4 назад на rust под windows 7 спокойно писалось и работало, а тут поддержка..
Ну так 4 года назад и было EOL семерки - "Windows 7 support ended on January 14, 2020".
Мурзила напр. ее будет тянуть вроде до осени или начала зимы в ESR ветке.Они просто перевели его из Tier1 (или Tier2) в Tier3.
Потому что даже машину для тестирования с семеркой сложно найти (местные ретрограды не в счет).
А ведь там должна быть лицуха, ибо засудят, и ее нужно как-то интегрировать в общую инфру (дырявую семерку, хаха).
Там наверняка виртуалки,хоть хрюньку пихай.
Понимаю что звучит дико, но им виртуалки тоже лицензионные нужны.
1. Не поверю, чтобы ни у кого из членов Rust Foundation не завалялось лицензионных дисков, которых им не жалко задонатить, хоть на хрюшу, хоть на висту, хоть на семёрку. Даже у меня есть, но ведь им не нужно это.
2. Платиновый спонсор вполне мог бы дать с барского плеча.
Так платиновый спонсор уже дропнул поддержку.
Нафига ему продлевать агонию уже мертвого продукта?
Он заинтересован в том чтобы все дружным строем перешли на 11 винду.
А через несколько лет и на 12
> Планировщик оптимизирован для повышения приоритета интерактивных задач на фоне задач, интенсивно нагружающих CPU. Например, в тесте запуска игрового приложения одновременно со сборкой ядра планировщик scx_rustland позволил добиться в игре более высокого FPS, чем при использовании штатного планировщика EEVDF.Вот это да! А если найс игре повысить то внезапно планировщик тоже будет больше процессорного времени выделять. Вот только ядро медленнее собираться будет(как и с scx_rustland), но журнализдов это мало волнует.
> Вот только ядро медленнее собираться будет(как и с scx_rustland), но журнализдов это мало волнуетИменно, потому что всем какбэ по.. на то, сколько собирается ядро.
Оно уже собранное прилетает 99% юзеров с очередным обновлением.
У ментейнеров есть соответствующее железо, а проблемы гентопердоликов никого не интересуют.
Зачем тебе опенсорс, братан, если тебе всё "прилетает"?Ну давайте тогда ядра на суперкомпьютерах собирать. Чтобы открытый или закрытый исходник было без разницы, всё равно не собрать.
Затем опенсорс и нужен! Для разделения труда.
Кто-то пишет код и ментейнит, кто-то собирает, кто-то тестирует и пишет багрепорты.> Ну давайте тогда ядра на суперкомпьютерах собирать. Чтобы открытый или закрытый исходник было без разницы, всё равно не собрать.
Даже если только на суперкомпе, все равно код будет открытый))
А сообщество может скинуться и купить или арендовать суперкомп.
И да, для Раста не нужен суперкомп, просто на девайсе с помойки оно будет собираться часов 12...
Но это же не надо делать каждый день.
>но журнализдов это мало волнует.У вас с порядком приоритетов проблемы. Вам и в игрушку поиграть и emerge -uND --with-bdeps=y @world подавай с одинаковой производительностью без потери ФПС и времени, чудес не бывает, устанавливай второй компьютер для таких желаний.
В венде так всегда было foreground приложение получает больший приоритет любого backgroud и никто до сих пор не жаловался, наоборот только довольны, а в линуксе и этого нет в 2024 году.
Выпускать книжки по расту - это золотая жила. Можно каждую неделю выпускать новую.
Наоборот, народ приучается читать доки и исходники (установка которых строго необходима для внятных сообщений об ошибках).
> Наоборот, народ приучается читать доки и исходникиСмешно. Они man не могут осилить, сразу в инет лезут.
>> Наоборот, народ приучается читать доки и исходники
> Смешно. Они man не могут осилить, сразу в инет лезут.А что, кто-то из бородатых сишников до сих пор читает man-ы вместо стандарта?
>>> Наоборот, народ приучается читать доки и исходники
>> Смешно. Они man не могут осилить, сразу в инет лезут.
> А что, кто-то из бородатых сишников до сих пор читает man-ы вместо
> стандарта?В твоем вопросе вся твоя некомпетентность.
>>>> Наоборот, народ приучается читать доки и исходники
>>> Смешно. Они man не могут осилить, сразу в инет лезут.
>> А что, кто-то из бородатых сишников до сих пор читает man-ы вместо
>> стандарта?
> В твоем вопросе вся твоя некомпетентность.С точки зрения предпочитателя man-ов стандарту, естественно.
Мне тоже он нравится, жаль я не могу PHP заменить на Rust, виртуальный хостер не поддерживает.
https://pbs.twimg.com/media/FqFIs-UWIAAtLnl?format=jpg&name=...Классика. Помню еще с времён жс-а. А ведь симптоматично.
> В документацию добавлена отдельная секция, описывающая совместимость различных типов аргументов и типов возвращаемых значений функций на уровне ABI. По сравнению с прошлыми версиями гарантирована совместимость на уровне ABI типов "char" и "u32", которые имеют идентичный размер и выравнивание.Это вроде не альфа версия. На минуту этот язык пытаются в ядро пропихнуть, а такие вещи не описаны.
Ну-ка напомни размер int'а в си описан? Ой-ой-ой, как же так, а в ядро пропихнули.
Ты не понимаешь это другое!
В СИ "щвободка и пусть система сама разберется, нам лениво это прописывать в стандарте ИСО",
а вот в расте "диктат компилятора и вообще все плохо"!
И вообще ты видел какое у них токсичное сообщество! СИшники всего-то в ядро навыпрограммировали уязвимостей, а эти их травят!
Мне больше интересно почему у этих символ вместо 1 байта 4 байта? И я не понимаю, у них это utf-16 без суррогатных единиц, т.е. несчастный огрызок UCS-2 с которым все уже настрадались? При этом, утф-8 использовать просто нельзя, в нём легко может быть и 1 и 2 и 6 байт.
Строго до 4 по стандарту. больше - уже невалидно.
Хм, действительно, я был практически уверен что мне встречались какие-то 6-байтные последовательности, это даже было законно и по стандарту (прошлому) в теории. Не помню, что это было и для чего. В таком случае, 4 байт действительно хватает для utf-8, остаётся вопрос с переменностью.
https://www.unicode.org/reports/tr26/
Похоже, это именно оно, спасибо за ссылку! Припоминаю, что пришлось использовать utf-32 тогда, потому что нормальный юникод был только в линуксе и в программах с icu (тот же хром) и у всех остальных платформ свои несовместимые представления о юникоде.
> В таком случае, 4 байт действительно хватает для utf-8, остаётся вопрос с переменностью.4 байт не хватит для представления любого символа в utf-8.
utf-8 это способ кодирования unicode символов, где 1 символ минимум 1 байт, а максимум 6 байт
В utf-16 - минимум 2, максимум 4
utf-32 - всегда 4 байта, потому что unicode символ по стандарту не может иметь codepoint больше по размеру чем 4 байта.Строки в Rust utf-8, и там один символ может быть закодирован как 6 байт, что логично, ведь латиница в utf-32 занимала бы в 4 раза больше места чем нужно, а худший случай в 6 байт на codepoint пока не осуществим (Нет таких пока, китайский и прочие языки - максимум 5 байт)
Однако строки в Rust напрямую не индексируются посимвольно, а потому char сделали статичные 4 байта, поэтому char вмещает в себя любой unicode codepoint.
>один символ может быть закодирован как 6 байт, что логично, ведь латиница в utf-32 занимала бы в 4 раза больше места чем нужно, а худший случай в 6 байтОткуда данные про 6 байт на символ? В первый раз слышу! 4 байта на символ, или UTF-32 - это самый большой формат кодирования из всех существующих, и он легко вместит в себя все кодовые позиции последнего вышедшего стандарта Юникод.
Что бы закодировать все возможные четырёхбайтные значения (0x00000000 ... 0xffffffff) в кодировке UTF-8 может потребоваться до 6-ти байт. Однако стандарт ограничил диапазон возможных значений символов Уникрода максимумом U+10FFFF и они умещаются в 4 байта UTF-8.
Однако суть не меняется, codepoint максимум 4 байта, codepoint закодированный в utf-8 максимум 6 байтДаже когда в Unicode решат дропнуть utf-16 (из-за него codepoint range и ограничили, хотя там действительно до столкновения с другими цивилизациями range не кончится) - Rust останется с ним полностью совместим
> Ну-ка напомни размер int'а в си описан? Ой-ой-ой, как же так, а
> в ядро пропихнули.Если тебе нужны гарантии используешь целое с размером из stdint, если нет и ты знаешь, что точно хватит, то просто int. Что не так?
> Ну-ка напомни размер int'а в си описан?а причём тут int, в С char == 1 byte
Это смотря в каком месте ABI. Если при передаче в функцию, то там char занимает 4 байта. Но это если на стеке, а вот если на x86_64 да при регистровой передаче, так целый восьмибайтовый регистр ему нужен.
> а вот если на x86_64 да при регистровой передаче, так целый восьмибайтовый регистр ему нужена регистры тут при чём ? по вашему получается гарантии раста невозможны - на этой архитектуре восьмибайтный регистр u64 или i64
> гарантирована совместимость на уровне ABI типов "char" и "u32", которые имеют идентичный размер и выравнивание
Ты представляешь себе, что такое ABI, Application Binary Interface? Он описывает как значения должны выглядеть в разных ситуациях. Например, когда мы хотим это значение хранить в памяти. Или когда мы хотим хранить массив таких значений в памяти. Или когда мы передаём значение в функцию. ABI позволяет проводить чёткие границы между разными кусками программы, чтобы потом из этих кусков как из кубиков можно было бы собирать более сложные конструкции. Чтобы когда ты из одной функции вызываешь другую, не надо было бы проводить анализ вызываемой функции с тем, чтобы выяснить как туда передать аргументы.Насчёт же невозможности выполнения гарантий раста, у меня встаёт другой вопрос: тебе математику в школе читали? Учили понимать точный смысл слов и свои мысли выражать точными фразами, не допускающими двусмысленностей? Утверждение "имеют идентичный размер и выравнивание" будет истинным и в том случае, когда значение расширяется до 64 бит, чтобы передать через 64 битный регистр, и даже несмотря на то, что при хранении в регистре выравнивания нет как класса. То есть утверждение "char и u32 имеют идентичный размер и выравнивание" будет истинным и для C но с оговоркой "при передаче в функцию".
> Утверждение "имеют идентичный размер и выравнивание" будет истинным и в том случае, когда значение расширяется до 64 бит, чтобы передать через 64 битный регистрно ведь это ты утверждал что char-у _нужно_ 64 бита, а оказывается это просто процессор не имеет подходящих регистров и там без разницы какой языковой тип, так зачем ты всё же приплёл регистры ?
> ты утверждал что char-у _нужно_ 64 бита,И продолжаю утверждать, что char'у нужно 64 бита для передачи через регистры. Все распространённые ABI так делают на 64-битных процах.
> а оказывается это просто процессор не имеет подходящих регистров
Ты типа пытаешься аппелировать к тому, что это единственный способ передавать чары через регистры? Не думаю, что даже если это верно, то это что-то меняет, но ситуация ещё интереснее тем, что это неверно. Я предположу, что ты никогда не писал на ассемблере? Там ведь нет никаких проблем упаковать 8 чаров в один регистр для передачи. Или, скажем, четыре чара и один uint32_t. На x86_64 есть частичные регистры al/ah, которые позволяют без использования сдвигов упаковать два чара в один rax. Но это не делается в ABI.
Кроме того, речь не только о регистрах, но и о стеке, где char использует 32 бита.
> И продолжаю утверждать, что char'у нужно 64 бита для передачи через регистры.
> Там ведь нет никаких проблем упаковать 8 чаров в один регистр для передачи.так ты сам привёл пример что не нужно - но так проще быстрей и унивесальней
> речь не только о регистрах, но и о стеке, где char использует 32 бита
речь только об этом - как данные в памяти размещаются, если любой тип целый регистр занимает нет смысла говорить там о выравнивании, но ты зачем-то приплёл это, хотел сказать этим что на асме писал ? cahr/byte в С вообще не про регистры - это минимальный адресуемый размер данных в памяти.
> так ты сам привёл пример что не нужно - но так проще быстрей и унивесальнейПричины того или иного технического решения не отменяют самого технического решения. Если принято решение использовать под каждый char аж целый 64-х битный регистр, то это решение принято.
>> речь не только о регистрах, но и о стеке, где char использует 32 бита
> речь только об этом - как данные в памяти размещаютсяРегистры и стек -- это тоже память. Регистры -- это самая быстрая память, быстрее даже чем L1, но регистров немного, и поэтому для их адресов придумывают мнемонические имена. В том же x86_32 регистров восемь штук и они в машинном коде кодируются тремя битами адреса. Но восемь это немного, и можно каждому придумать имя. Плюс их нельзя косвенной адресацией достать, только статически прописанным "адресом", поэтому арифметика адресов регистров не имеет большого смысла, и поэтому можно и мнемониками. Но регистры -- это память и притом самая важная.
А уж стек -- это память даже в том смысле этого слова, который прямолинейно ссылается на оперативку. Даже сову на глобус не надо натягивать, чтобы называть стек памятью. И на стеке твои чары занимают 32 бита.
> cahr/byte в С вообще не про регистры - это минимальный адресуемый размер данных в памяти.
Ты сейчас пытаешься соскочить с темы. Чувствуешь что слил, да? Мы не говорим о том, про что там char/byte в C, мы говорим об ABI используемых с C.
> Мы не говорим о том, про что там char/byte в Cя сказал про размер char/byte в С
> мы говорим об ABI используемых с C
это ты соскочил с темы рассказывая что регистры тоже память, кроме тебя же не знает никто бугага
Только надо понимать, что один байт не всегда равен 8 бит.
> Только надо понимать, что один байт не всегда равен 8 бит.так это растовикам надо напомнить - будет ли на таких архитектурах работать раст ? я не уверен
> Только надо понимать, что один байт не всегда равен 8 бит.простите, вот раньше - да, но это было десятки лет назад
а где сейчас оно не равно?
> а где сейчас оно не равно?где угодно
https://software-dl.ti.com/ccs/esd/documents/c2000_byte-acce...
Будто bbcachefs идеальна,а она в этой финской лабе и многи нравится.
>гарантирована совместимость на уровне ABI типов "char" и "u32", которые имеют идентичный размер и выравниваниеОни там с ума посходили, хранить значения от 0 до 256 в 4х байтах? Всё с ними ясно, ффтопку этот раст.
шел 2024 год, писатели на си всё еще не узнали про юникод
Писатели на си используют строго UTF-8. Даже петицию создали https://utf8everywhere.org/ .
Так и в расте в строках используется UTF-8.char это для итерации по декодированным символам.
Извиняюсь тогда. Мало на расте кодил, забыл, что там для строк другой тип. а не как в сишке.
Utf8 - юникод, символ (codepoint) там максимум 4 байта, и Rust тут следует стандартуUtf8 это про кодирование, а не про размер символа, размер символа общий и для utf8, и для utf16, и для utf32 4 байта, а кодируются эти 4 байта в utf8 - 1-6байт, в utf16 - 2-4байта, в utf32 - 4байта
Сколько будет занимать англ. символ в у8 в char в Rust ?
> Сколько будет занимать англ. символ в у8 в char в Rust ?utf8 про кодирование в строку, в строке английский символ занимает 1 байт
char (codepoint) про посимвольную итерацию по строке, char 4 байта независимо от того, что там за символ
UTF-8 переменной длины. При кодировании арабских символов доходит, что-то, до 6 байт.
> UTF-8 переменной длины. При кодировании арабских символов доходит, что-то, до 6 байт.utf-8 переменной, а char фиксрованной и ограничен 4 байтами
Писатели на Си знают что такое битовые поля в структурах. А этот ваш юникод с эмоджи не нужен. Выдумывают каждый код новые пиктограммы чтобы, коммитет продолжали финансировать. Весь ваш юникод еще на версии 2 надо было закрывать.
Наоборот, Юникод нужен, а ты не нужен.
Пусть лучше будет Юникод, чем вот это вот CP866, KOI8-R, CP1251, ISO-8859-15, ДКОИ.
>>хранить значения от 0 до 256сразу видно вы настоящий программист ))
>>>хранить значения от 0 до 256
> сразу видно вы настоящий программист ))Если длина строки известна, то завершающий 0 хранить не обязательно, возможно кодировать им U+0100.
Вот так и случается, благими намереньями потом за границы строк выходят)
И много ты наэкономишь на одном символе на каждую строку?Уже пробовали делать null-terminated, аж целый байт наэкономили...
А ошибки отгребают до сих пор.
Если со строкой делается что-то большее, чем передача аргументом в puts(), то она хранится в графе (дереве). Минимум два указателя - это 16 байт. Если заменить их на индексы массива, то получится экономия в 2 или даже 4 раза. В последнем случае размер окажется ограничен 64К узлами. Что бы это ограничение обойти, можно вместо символа хранить маркер, указывающий, что в следующей ячейке массива хранятся старшие 16 разрядов индексов. Таким образом можно упаковать и до однобайтных индексов, что даст экономию памяти в пределе до 8 раз (без учёта символа). Но настоящих программистов не осталось, потому на Rust двусвязный список unsafe, а браузеры выжирают гигабайты.
Энто те самые "настоящие программисты" которые наделали столько CVE что находят окаменелости 30 летней давности как в хоргʼе?
Ну и слава богу, что они потихоньку вымирают.
А то я насмотрелчя на любителей оптимизировать заранее, а потом бросать свой страшный, глючный и совершенно не поддерживаемый код.
> Энто те самые "настоящие программисты" которые наделали столько CVE что находят окаменелости
> 30 летней давности как в хоргʼе?Это тот самый эксперт, который смысл сообщение вообще не понял, но возразить очень хочет?
> Если со строкой делается что-то большее, чем передача аргументом в puts(), то
> она хранится в графе (дереве). Минимум два указателя - это 16 байт. Если заменить
> их на индексы массива, то получится экономия в 2 или даже 4 раза.У оптимизатора компилера могут быть какие-то свои идеи на этот счет. В _современных_ архитектурах оно могет и адресацию относительно базы, вгружаемой 1 раз на эвон какой код, а вон там указатель сделан как адресация с офсетом от, и если указатель в сыром виде никто не юзает то и хрен с ним вообще.
>> Если со строкой делается что-то большее, чем передача аргументом в puts(), то
>> она хранится в графе (дереве). Минимум два указателя - это 16 байт. Если заменить
>> их на индексы массива, то получится экономия в 2 или даже 4 раза.
> У оптимизатора компилера могут быть какие-то свои идеи на этот счет. В
> _современных_ архитектурах оно могет и адресацию относительно базы, вгружаемой 1 раз
> на эвон какой код, а вон там указатель сделан как адресация
> с офсетом от, и если указатель в сыром виде никто не
> юзает то и хрен с ним вообще.Гипотетически, оптимизатор компилера обладает сознанием и генерирует идеи, а практически пока не видно цитаты стандарта, из которой бы следовало, что можно просто так взять и сохранить в памяти половину указателя.
А можно поподробнее, что это за стандарт хранения строк в дереве? Я конечно могу себе такое представить, но утверждать что это частое явление, мне кажется слишком сильно.
Это не стандарт. Попробуйте выполнить курсовую работу из старого курса CS MIT - реализовать интерпретатор LISP. Словарь в каком виде хранить? Массив строк и искать там прямым перебором?
> Словарь в каком виде хранить? Массив строк и искать там прямым перебором?Зачем массив? Список. Лисп же.
Но если хочется оптимизаций, то хеш-табличка. Если так не хочется хранить указатели на строки, то строки можно писать в массив чаров последовательно, и хранить индексы туда. Этим индексам можно будет половину бит урезать, а если этого мало, то можно как-нибудь ещё извратиться. Но тут момент какой: все эти извращения требуют данных с полей о том, как этот словарь используется. Скажем, если мы нарисуем распределение длин строк, то как оно будет выглядеть? Будет ли там много одно-/двух-/трёх- байтовых строк? Будет ли там много 16+ байтовых строк? Опять же, что важнее -- скорость проверки наличия строки в словаре, скорость чтения её оттуда или скорость добавления новой?
Преждевременная оптимизация -- корень всех проблем, а раз так, то словарь в лиспе надо хранить в виде списка по-крайней мере до тех пор, пока операции над этим списком не начнут заметно тормозить интерпретатор.
>> Словарь в каком виде хранить? Массив строк и искать там прямым перебором?
> Зачем массив? Список. Лисп же.Ну вот, уже появился простейший граф.
> Но если хочется оптимизаций, то хеш-табличка.
Это что, самому надо написать? Или std::map<> сойдёт? Так там под капотом может внезапно оказаться red_afroamerican_tree.
> Преждевременная оптимизация -- корень всех проблем, а раз так, то словарь в
> лиспе надо хранить в виде списка по-крайней мере до тех пор,
> пока операции над этим списком не начнут заметно тормозить интерпретатор.Вопрос не как хранить, а как искать. O(n!) вряд ли сгодится в зачёт будущему магистру.
Соглашусь, что всё-таки способ хранения строк нужно выбирать исходя из требований задачи. Но std::map<> для хранения char-ов не слабый такой оверхэд по памяти получается.
И я не понял, что за алгоритм поиска даёт сложность O(n!) ???
"Словарь" - это такая штука, где хранятся имена функций. Таких имён может быть например 10000. Интерпретатор читает в исходнике имя функции и ищет его в словаре - что бы далее найти её определение. Вот это всё должно не экономить память (преждевременная оптимизация), а работать так, что бы пользователь при запуске программы не уходил пить кофе. Какая там окажется сложность при переборе всех имён в массиве или списке - даже думать не хочу, потому взял с запасом. В std::map<> хранят не символы, а имена, это обычное решение "в лоб" для быстрого поиска, а внутри там не обязательно perfect hash, может быть и дерево.
Да, сорри. Изначально неправильно понял ваш пост, что строки хранятся в дереве. Я то подумал речь идёт о дереве, где каждый узел - это char. А каждая строка имеет свой уникальный путь в этом дереве. Поэтому был так удивлён 🙂
Всё правильно поняли, каждый узел - это char. Если для курсовика годится хранить словарь в мапе, то в реальном мире желательно выводить в сообщении об ошибках подсказку при опечатках в имени функций. Так что вышеотписавшийся преждевременный оптимизатор, нашедший решение в гугле, пролетает с хеш-табличкой. Понадобится префиксное дерево.
Мне кажется это зависит от функции, в которую ты передашь свою мега-строку.
Действительно, зависит. Программисты ведь пишут не функции, а команды типа git clone.
>>Они там с ума посходили, хранить значения от 0 до 256 в 4х байтах?Нет. Для 8ми битных строк есть другие типы.
Но, чайники сделают все по примерам, именно с толстыми строками (по умолчанию).А вот работа со структурами, через одно неприятное место. А если ещё и с битовыми полями, то исходники "write only".
Опять всё переписывать...
rust так хочет в gamedev? или "ну хоть куда-то"
rust и gamedev на данный момент несовместимы т.к. у раста нет флага компилятора -fast-math. Все игры собираются с этим флагом в С++ и это позволяет ускорить математику в играх примерно в 5-10 раз.
> rust и gamedev на данный момент несовместимы т.к. у раста нет флага
> компилятора -fast-math. Все игры собираются с этим флагом в С++ и
> это позволяет ускорить математику в играх примерно в 5-10 раз.А еще, а еще, там классов нормальных нет.
> rust и gamedev на данный момент несовместимы т.к. у раста нет флага компилятора -fast-math.Ну вот fast math в играх и правда полезен - там на корректность математики довольно похрен в общем случае. В самом неудачном - ну будет какой-то глитч под воркэраунд, не смертельно.
А создатели батлфилдов про это в курсе?
Откуда можно скачать исходники?
Исходники чего?
> Исходники чего?Языка программирования Rust 1.76
Ты удивишься, но с https://github.com/rust-lang/rust
> Ты удивишься, но с https://github.com/rust-lang/rustДействительно удивлен. Откуда у вас эта информация -- на их сайте ничего об этом нет нет. Только возможность что-то установить из сети.
Думал без генераторов плохо, а там уже async/await давно есть.
> The sum of the `core::array::iter::IntoIter<i32, 3>` is 6.Ящерки совсем не палятся примерами. Не, человек такую фразу выдать не сможет, люди так не думают в принципе.