А DNS даёт пиратским сайтам 100% трафика. Давайте обяжем все DNS подключиться к роскомпозору и фильтровать. По решению задней пятки какого-нибудь Васисуалия Кукуевича.
В Rust их в очень многих случаях можно избежать. В многопоточке они используются для целей шаринга состояния. Обычно это одна копия на задачу, что, как правило, почти незаметно. А вот в Swift, насколько я понимаю, любое ссылочное значение это Arc<_>.
Я нашёл для себя неплохое правило. Все макросы именовать начиная с $. Частью идентификатора он быть не может, зато препроцессоры "большой тройки" воспринимают его как нормальный допустимый символ. Заодно убирает проблему конфликтов имён и для аргументов макросов.
К сожалению, X-macro не всегда можно адекватно заменить на шаблонный код. Классическое применение — функция-маппер вариантов перечисления в строку и обратно. А ещё перечисление может "внутри" мапиться на что-нибудь нетривиальное. Справедливости ради, это действительно один из немногих случаев, когда макросы реально полезны.
Где-то можно почитать о том, как предполагается использовать модули, со всеми их партишенами и другой эзотерикой? Неясно даже, единицу чего представляет модуль.
SPARK это, судя по описанию, очень круто. Но там ради безопасности срезали массу всего, в т.ч. исключения, динамическую память, указатели. Что, увы, ограничивает нишу применимости.
1) Есть альтернативы, например, в виде флага, который ставится в 1 по ошибке, и который можно проверять (точно так же, как по стандарту IEEE754 это затребовано task-local для плавучки). Можно придумать переопределение режима и флага для своего куска кода, не обязательно в TLS, годится любая указанная переменная.
Можно, кто же спорит. Но жёстко контроллируемую математику не ввели. Видимо, посчитали чрезмерной в контексте языка.
2) Вообще, позиция отрицания «anything can throw» это перегиб даже больший, чем предыдущее активное введение структурных исключений во все новые языки. И паника, которая по умолчанию что-то печатает, по такому событию — тоже.
Можно было бы подумать в эту сторону, но не отвергать исключения совсем.
Панику стоит рассматривать не как исключение "что-то пошло не так", а аналог сигнала "что-то КОНКРЕТНО пошло не так".
Результатом был бы жуткий срач.
Про срач — если, как у современных компиляторов, код веток «что-то пошло не так» выносится отдельно, то, да, это будет обширнее, чем если бы проверка не делалась, но отнюдь не «ужас-ужас».
Неточно выразился. Под "срач" здесь и дальше понимаются возмущённые крики определённой аудитории "Оверхед!!!". С учётом что Rust позиционируется как более безопасная и в чём-то простая замена C/C++, это было бы смертельно.
Ну вот пока подход «для тех, кому нужна», а не по умолчанию… как говорил один мой знакомый, security бывает двух уровней — high и «няхай». Впрочем, кто хочет смягчить защиту и уверен в этом — пусть язык даст ставить атрибут на кусок кода.
Справедливости ради, большинство нынешних уязвимостей вызвано скорее ошибками доступа к памяти/ресурсам, а не арифметики как таковой. Мне бы тоже было интересно посмотреть на проверяемую компилятором арифметику.
По поводу устойчивости к ошибкам человека надо читать 1ю часть. Простой и понятный и при этом однозначный синтаксис тут в помощь.
Грамматика насколько мне известно как минимум однозначная. По крайней мере, дичи вроде C/С++ most vexing rule или counter-clockwise rule нет в природе. Примеры контекстно-зависимых элементов.
Простота и понятность — в целом вещи субъективные. Для знакомых с Си-подобными языками читать и понимать труда не составляет.
Перерасход памяти для строк зависит от реализации. Пусть строка s1 содержит 1024 символа. Сколько будет задействовано памяти (и какой — стек, хип?) после операций s1[14] = 'x'? s1 += 'x'?
Строки реализованы в виде владеющего типа String и невладеющего типа-диапазона &str. Первый выделяет память в куче, второй — ссылается на уже выделенную строку или её часть. Строковые литералы выделяются в data section и рассматриваются как &'static str.
А DNS даёт пиратским сайтам 100% трафика. Давайте обяжем все DNS подключиться к роскомпозору и фильтровать. По решению задней пятки какого-нибудь Васисуалия Кукуевича.
А чем не подходит схема с явным конструктором, принимающим хранилище-источник, и методом serialize, принимающим хранилище-приёмник?
Естественно приведёт. Но вопрос в том, какая именно функция возвращает
&str. И нельзя ли эту строку "выковырять" из объекта. И надо ли вообще.В Rust их в очень многих случаях можно избежать. В многопоточке они используются для целей шаринга состояния. Обычно это одна копия на задачу, что, как правило, почти незаметно. А вот в Swift, насколько я понимаю, любое ссылочное значение это
Arc<_>.На выходе нативный код. В теории не медленней С/С++. На практике зависит от алгоритмов и оптимизатора.
В предыдущих статьях по этой теме упоминался Spin-transfer torque как решение проблемы.
Я нашёл для себя неплохое правило. Все макросы именовать начиная с $. Частью идентификатора он быть не может, зато препроцессоры "большой тройки" воспринимают его как нормальный допустимый символ. Заодно убирает проблему конфликтов имён и для аргументов макросов.
К сожалению, X-macro не всегда можно адекватно заменить на шаблонный код. Классическое применение — функция-маппер вариантов перечисления в строку и обратно. А ещё перечисление может "внутри" мапиться на что-нибудь нетривиальное. Справедливости ради, это действительно один из немногих случаев, когда макросы реально полезны.
Т.е. он не будет уметь zero allocation из коробки?
Вот это поворот… Интересно, когда получим "any textual string is a valud program in C++".
Увы, все вкусняшки мира не спасут от тонн легаси. Так что всё равно попробуйте.
Не могу не согласиться. И это вдвойне грустно.
Где-то можно почитать о том, как предполагается использовать модули, со всеми их партишенами и другой эзотерикой? Неясно даже, единицу чего представляет модуль.
Наконец-то! Впрочем, с появлением std::format этот архаизм можно выкинуть на помойку — что ещё лучше.
std::locale в частности и iostreams вообще надо бы по хорошему закопать нафиг и больше не трогать.
У Rust есть вариант сделать атрибут
#[async]вместо полноценного кейворда и, как результат, получить кейвордawait!в виде контекстного макроса.Кстати, почему действительно не использовать атрибуты?
Скажите это Autodesk, Dassault Systemes, PTC, Siemens. Посмеёмся вместе.
SPARK это, судя по описанию, очень круто. Но там ради безопасности срезали массу всего, в т.ч. исключения, динамическую память, указатели. Что, увы, ограничивает нишу применимости.
Можно, кто же спорит. Но жёстко контроллируемую математику не ввели. Видимо, посчитали чрезмерной в контексте языка.
Панику стоит рассматривать не как исключение "что-то пошло не так", а аналог сигнала "что-то КОНКРЕТНО пошло не так".
Неточно выразился. Под "срач" здесь и дальше понимаются возмущённые крики определённой аудитории "Оверхед!!!". С учётом что Rust позиционируется как более безопасная и в чём-то простая замена C/C++, это было бы смертельно.
Справедливости ради, большинство нынешних уязвимостей вызвано скорее ошибками доступа к памяти/ресурсам, а не арифметики как таковой. Мне бы тоже было интересно посмотреть на проверяемую компилятором арифметику.
Грамматика насколько мне известно как минимум однозначная. По крайней мере, дичи вроде C/С++ most vexing rule или counter-clockwise rule нет в природе. Примеры контекстно-зависимых элементов.
Простота и понятность — в целом вещи субъективные. Для знакомых с Си-подобными языками читать и понимать труда не составляет.
Строки реализованы в виде владеющего типа String и невладеющего типа-диапазона &str. Первый выделяет память в куче, второй — ссылается на уже выделенную строку или её часть. Строковые литералы выделяются в data section и рассматриваются как
&'static str.Пакеты с кастомными строками
В целом довольно сильная ориентация на ФП:
Если у Вас есть более конкретные требования к поддержке ФП в языке, напишите пожалуйста.
Я себе не совсем представляю, как язык может это гарантировать в отрыве от ОС.