LINUX.ORG.RU

Выпуск языка программирования Rust 1.47

 ,


2

8

Опубликован релиз 1.47 языка системного программирования Rust, основанного проектом Mozilla. Язык сфокусирован на безопасной работе с памятью, обеспечивает автоматическое управление памятью и предоставляет средства для достижения высокого параллелизма выполнения заданий, при этом обходясь без использования сборщика мусора и runtime (runtime сводится к базовой инициализации и сопровождению стандартной библиотеки).

Автоматическое управление памятью в Rust избавляет разработчика от ошибок при манипулировании указателями и защищает от проблем, возникающих из-за низкоуровневой работы с памятью, таких как обращение к области памяти после её освобождения, разыменование нулевых указателей, выход за границы буфера и т.п. Для распространения библиотек, обеспечения сборки и управления зависимостями проектом развивается пакетный менеджер Cargo. Для размещения библиотек поддерживается репозиторий crates.io.

Основные новшества:

  • Реализована поддержка типажей для массивов произвольного размера. Ранее, из-за невозможности определить generic-функции для всех целых значений, стандартная библиотека предоставляла встроенную поддержку типажей только для массивов, размер которых не превышал 32 элемента (типажи для каждого размера были определены статически). Благодаря созданию функциональности константных дженериков («const generics») появилась возможность определения generic-функций для любых размеров массива, но они пока не включены в состав стабильных возможностей языка, хотя реализованы в компиляторе и теперь задействованы в стандартной библиотеке для типажей массивов любого размера. Например, следующая конструкция в Rust 1.47 приведёт к выводу содержимого массива, хотя раньше привела бы к ошибке:
    fn main() {
        let xs = [0; 34];
        println!("{:?}", xs);
    }
  • Обеспечен вывод более коротких трассировок (backtrace), выводимых при внештатных ситуациях. Из трассировки исключены элементы, не представляющие интереса в большинстве ситуаций, но захламляющие вывод и отвлекающие внимание от первичных причин проблемы. Для возвращения полной трассировки можно использовать переменную окружения «RUST_BACKTRACE=full». Например, для кода
    fn main() {
        panic!();
    }

раньше выводилась трассировка в 23 этапа, а теперь она будет сведена к 3 этапам, позволяющим сразу уловить суть:

thread 'main' panicked at 'explicit panic', src/main.rs:2:5
    stack backtrace:
       0: std::panicking::begin_panic
                 at /rustc/d...d75a/library/std/src/panicking.rs:497
       1: playground::main
                 at ./src/main.rs:2
       2: core::ops::function::FnOnce::call_once
                 at /rustc/d...d75a/library/core/src/ops/function.rs:227
  • Компилятор rustc обновлён до сборки с использованием LLVM 11 (Rust использует LLVM в качестве бэкенда для генерации кода). При этом сохранена возможность сборки со старыми LLVM, вплоть до версии 8, но по умолчанию (в rust-lang/llvm-project) теперь используется LLVM 11. Релиз LLVM 11 ожидается в ближайшие дни.
  • На платформе Windows в компиляторе rustc обеспечена поддержка включения проверок целостности потока выполнения (Control Flow Guard), активируемых при помощи флага «-C control-flow-guard». На других платформах данный флаг пока игнорируется.
  • В разряд стабильных переведена новая порция API, в том числе стабилизированы Ident::new_raw, Range::is_empty, RangeInclusive::is_empty, Result::as_deref, Result::as_deref_mut, Vec::leak, pointer::offset_from, f32::TAU и f64::TAU.
  • Признак «const», определяющий возможность использования в любом контексте вместо констант, применён в методах:
    • new для всех целых, отличных от нуля;
    • checked_add, checked_sub, checked_mul,checked_neg, checked_shl, checked_shr, saturating_add, saturating_sub и saturating_mul для всех целых;
    • is_ascii_alphabetic, is_ascii_uppercase, is_ascii_lowercase, is_ascii_alphanumeric, is_ascii_digit, is_ascii_hexdigit, is_ascii_punctuation, is_ascii_graphic, is_ascii_whitespace и is_ascii_control для типов char и u8.
  • Для FreeBSD задействован инструментарий из FreeBSD 11.4 (FreeBSD 10 не поддерживает LLVM 11).

Взято с opennet.ru

>>> Подробности

★★

Проверено: Shaman007 ()
Последнее исправление: CYB3R (всего исправлений: 2)

Ответ на: комментарий от VIT

Для Fortran и С существует просто дохренища разнообразных инструментов проверки качества кода. Cмело вычёркивайте. Ассемблер - вообще не язык, а семейство языков. Банальные x86 и arm вроде бы тоже чекерами не обделены.

«Язык, где «+» функция а не сумма - ложный, и хрен кто меня переубедит»

почему ascii символ ‘a’ имеет право быть функцией, а ascii символ ‘+’ - уже нет?

в чём вообще важность идеологической разницы между оператором и функцией, если и то и другое внутри компилятора всё равно в функцию превращается?

next_time ★★★★★
()
Ответ на: комментарий от VIT

кстати, в С и Фортран, + для беззнаковых чисел тоже не арифметическая сумма, а сложение по модулю pow(2, sizeof(operand)*8 -1)

а для знаковых чисел, так и вовсе - никакое не сложение, так как в математике не понятия UB

next_time ★★★★★
()
Ответ на: комментарий от next_time

Во, просто класс! Наконец то на LOR появилась техническая дискуссия вместо обсуждения какой телефон покупать.

Для Fortran и С существует просто дохренища разнообразных инструментов проверки качества кода. Cмело вычёркивайте.

Для Fortran - кое что да, вот для C, таки нет и тому маcса причин. Указатели, например. Для Fortran много попыток было, но не срослось. COMMON блок и EQUIVALENCE - те ещё штуки.

почему ascii символ ‘a’ имеет право быть функцией, а ascii символ ‘+’ - уже нет

Потому что когда я был маленький, мне в школе сказали a = b + c означает a есть сумма двух величин, b и c. И всё, копец. И кандидатская эту проблему не решит - для меня «+» - сумма!

в чём вообще важность идеологической разницы между оператором и функцией, если и то и другое внутри компилятора всё равно в функцию превращается?

В том, что я, как математик, разницу между функцией и оператором вижу. Хотя, как программист, и понимаю, о чём Вы.

VIT
()
Ответ на: комментарий от VIT

вот для C, таки нет

cppcheck же, как минимум

Указатели, например.

именно ради них такие штуки и делают

a = b + c означает a есть сумма двух величин, b и c

Величин, но не обязательно чисел. Величины могут быть векторными, могут быть матрицами, или комплексными числами.

В том, что я, как математик, разницу между функцией и оператором вижу.

А Пеано, например, не видел и определил не только ‘+’, но даже все натуральные числа как функции

next_time ★★★★★
()
Ответ на: комментарий от next_time

Ну хорошо, похоже мы тут математик на математика столкнулись. Будем за вектора спорить, или сразу к Пеано перейдём?

Ладно - дружба! ??

VIT
()
Ответ на: комментарий от VIT

А почему это + не должен быть функцией? Потому что 40 лет назад не допёрли что так можно было? Или для какой-то там мнимой очивидности?

anonymous-angler ★☆
()
Ответ на: комментарий от next_time

в мейнстримных языках, типа джава и питон … всегда есть неявное наследование от какого-нибудь общего класса Object

Это пример класса, который специально сделан для наследования. Можно такое сказать про std::array?

почему к java нет претензий в той же ситуации

Потому что у java приоритеты другие. У C++ - скорость и минимальное использование памяти. У java - возможность работы команды «индусов». Я не говорю, что C++ использовать не надо. Я спрашиваю в чём смысл из C++ делать java.

вот вы сами же и ответили, зачем использовать С++, а не java: в ней нет (вроде, до сих пор) перегрузки операторов

В C# есть.

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

а практически приходится либо использовать возможности, не входящие в стандарт C++, либо использовать такое: https://wiki.sei.cmu.edu/confluence/display/c/INT32-C.+Ensure+that+operations+on+signed+integers+do+not+result+in+overflow Доступа к флажку из стандартного C++ нет, насколько я знаю.

буду благодарен, если вы продемонстрируете, как без таковой обёртки (даже если она прошита в ЯП) можно обойтись в указанном случае

Я бы и сам был бы благодарен.

вы вообще о чём? можете на примере объяснить

Я о том, что вектор при создании нового элемента с помощью push_back не использует конструктор, а копирует элемент. То есть у Вас вначале будет создан умный указатель внутри push_back, затем он скопируется в вектор, а затем уничтожится исходный экземпляр умного указателя.

К счастью, есть альтернатива в виде emplace_back, о которой сообщил RazrFalcon.

Но вообще моя идея была в том, что вектор уже сам использует кучу, сам следит за очисткой памяти. Но безопасно умно указать на эти элементы не получится, если мы не поломаем поведение вектора - расположение элементов последовательно в памяти. В данном случае мы не сможем передать std::vector::data в какую-нибудь сишную функцию, предназначенную для работы с массивом структур.

Kogrom
()
Ответ на: комментарий от Kogrom

класса, который специально сделан для наследования. Можно такое сказать про std::array?

разумеется: в ООП все классы (кроме sealed) специально сделаны для наследования

У java - возможность работы команды «индусов»

где угодно, только не в java, т.к. это самый высокооплачиваемый ЯП

У C++ - скорость и минимальное использование памяти

это про ассемблер, а С++ - про кроссплатформенность, ООП и отсутствие ненужных накладных издержек

Доступа к флажку из стандартного C++ нет, насколько я знаю.

тут есть интересный момент: так-то этот флажок не на всех архитектурах присутствует. как ведёт себя джава-машина в такой ситуации? выходит, по факту в джава есть UB?

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

ну да, поэтому хранить shared_ptr в векторе редко когда вообще нужно

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

зато можно сделать наоборот: хранить в векторе указатели на другие элементы - обычно этого и достаточно

next_time ★★★★★
()
Ответ на: комментарий от Kogrom

Доступа к флажку из стандартного C++ нет, насколько я знаю.

а, лол, сейчс проверил: java вообще никак не проверяет integer overflow - никакого исключения, ничего, ни на какой архитектуре

public class Main
{
	public static void main(String[] args) {
	    int a = 2000*1000*1000;
	    int b = a;
System.out.println("Hello World");
		System.out.println(a + b);
	}
}

output:

Hello World                                                                                                                                                                                                                                                                   
-294967296

Так что, тут с плюсами разницы и нет. В C# примерно также.

next_time ★★★★★
()
Последнее исправление: next_time (всего исправлений: 1)
Ответ на: комментарий от Kogrom

Потому что у java приоритеты другие. У C++ - скорость и минимальное использование памяти. У java - возможность работы команды «индусов»

кстати, так тем более, в такой формулировке, претензии к С++ нужно забыть, а обратить их в сторону java (и других мейнстримных языков)

next_time ★★★★★
()
Ответ на: комментарий от next_time

разумеется: в ООП все классы (кроме sealed) специально сделаны для наследования

Авторы умных книжек (например, Саттер) пишут про срезку, нарушение инкапсуляции и излишнюю связанность кода при наследовании конкретных классов. Но это дело каждого, конечно. Я предпочитаю такие классы не наследовать.

На другие два сообщения отвечу тут же. Протестировал Ваш пример с Java в C#. В режиме Debug получил OverflowException. В Release вывелось отрицательное число, да.

Как ведёт себя джава-машина на разных архитектурах я не знаю, так как джава меня не интересует. Но подозреваю, что так же как C#.

претензии к С++ нужно забыть, а обратить их в сторону java

У меня нет претензий ни к C++, ни к java. Я говорю о том, что если везде в C++ использовать умные указатели и at(), то мало смысла в использовании C++. Конечно, могут быть исключения, например, если проект уже много лет пишется на C++ или так проще использовать какую-то библиотеку. Ну или религиозные предпочтения.

Kogrom
()
Ответ на: комментарий от fsb4000

Внезапно в С++ также

Это не в C++. Это использование флагов компиляции g++, о которых в стандарте не говорится. Для других компиляторов тоже аналоги есть. Вот что я писал тут Выпуск языка программирования Rust 1.47 (комментарий):

а практически приходится либо использовать возможности, не входящие в стандарт C++, либо…

Вот это опровергайте.

Kogrom
()
Ответ на: комментарий от Kogrom

то мало смысла в использовании C++

так альтернатив нет

более-менее мейнстримных языков не так много: питон, джаваскрипт, джава, С#, С и С++

питон и джаваскрипт - это боль, почему, объяснять, думаю, не нужно

С - тоже боль

джава вас не интересует,

C# слишком сложный

в итоге, кроме как на плюсах, писать особо и не на чем

next_time ★★★★★
()
Ответ на: комментарий от Kogrom

Это использование флагов компиляции g++, о которых в стандарте не говорится.

в вашем примере тоже использование флагов компилятора о которых в стандарте C# не говорится

next_time ★★★★★
()
Ответ на: комментарий от next_time

C# слишком сложный

Не сложнее C++.

питон … - это боль

Это субъективно. Мне питон версии 2 нравился за простоту и лаконичность. Сейчас из него какого-то мутанта делают, да.

Кроме того, всякие алгоритмы из STL лучше понимаешь, когда в питоне поработаешь с генерацией и обработкой списков. Из-за меньшей писанины лучше видно что делаешь. Хотя сейчас и C++ изменился в лучшую сторону по лаконичности.

Kogrom
()
Ответ на: комментарий от next_time

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

int a = 2000 * 1000 * 1000;
int b = a;
try
{
    Console.Write("a + b = {0}", checked(a + b));
}
catch(OverflowException)
{
    Console.Write("OverflowException");
}

http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-334.pdf страница 165.

Kogrom
()
Ответ на: комментарий от WitcherGeralt

Ты не шаришь как и анонимы со своими «ОС в браузере». Демонстрация полной некомпетентности, при том что на всяких википедиях давно расписаны понятие «системный программист». @X512 объяснял. Раньше любой дурак-программист знал что это значит. И не было бы этих споров.

baist ★★
()
Ответ на: комментарий от baist

Опять никакой конкретики. Ты просто клоун и позер.

Шас бы мне дворник, или кто ты там, рассказывал, что я знаю, а чего нет.

WitcherGeralt ★★
()
Ответ на: комментарий от Kogrom

«In an unchecked context, the result is truncated by discarding any high-order bits that do not fit in the destination type»

В этом отрывке нет «standard debug mode». И вообще какого-либо описания (честно поискал по всему документу) понятия «checked context». И не нашёл. Т.е., компилятор вполне имеет право этот самый «checked context» вообще нереализовывать.

next_time ★★★★★
()
Последнее исправление: next_time (всего исправлений: 1)
Ответ на: комментарий от Kogrom

Не сложнее C++.

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

сам язык синтаксически тоже помойка. С++, конечно, тоже не GO… но вот это вот обилие сахара и разного синтаксиса, которое есть в шарпе угнетает… не знаю более убогого языка в этом отношении

Мне питон версии 2 нравился за простоту и лаконичность.

мне питон не понравился по двум причинам

  1. динамическая типизация - писать что-то сложнее калькулятора - боль

  2. забагованный pip - в итоге, когда мне требовалось что-то притянуть из него - оказывалось, что оно а) не работало б) советы из stackoverflow как это починить были протухшими, из-за перехода питон 2 -> питон 3

next_time ★★★★★
()
Ответ на: комментарий от next_time

Про математику комментировать не буду, там уже на второй круг пошли.

Соглашусь, что в C# помойка вместо библиотеки. Зато она может почти всё и собрана в одном месте.

Что касается pip, то я подозреваю, что языковые менеджеры пакетов являются тупиковым путём. Раньше было проще. В Windows библиотеки ставились отдельным установщиком, а в Linux через консоль или какой-нибудь Synaptic и никаких проблем не возникало. А сейчас развели вакханалию.

Kogrom
()
Ответ на: комментарий от fsb4000

Ну хорошо, они констекспр доводят до ума. Но это не меняет того, о чем я говорил: констекспр «подязык» замкнут на себе, а дополнительные статические проверки - следствие кастрированности, а не основное предназначение. А основное предназначение - генерация кода в компайл-тайм. Я не спорю, что это может полезно. Например, можно плюсовый код генерить из некоего фреймворка, конфиг для которого создается на этапе проектирования, что позволяет оптимизировать производительность средствами комилятора. А доп. статические проверки идут как приятный бонус.

P.S. И вот так до сих пор делать нельзя:

constexpr std::array<int, 1> arr{ rand() };
seiken ★★★★★
()
Ответ на: комментарий от next_time

тогда тем более не в счёт

С чего бы?

«Если что-то выглядит как утка, плавает как утка и крякает как утка, это, вероятно, и есть утка.»

Код работает, значит перегрузка операторов есть:

public class Point {
  public final int x, y;
  public Point(int x, int y) {this.x = x; this.y = y;}
  
  public Point plus(Point that) {
    return new Point(x + that.x, y + that.y);
  }
}

var a = new Point(1, 2);
var b = new Point(3, 4);

var sum = a + b; // Point(4, 6)
Operation 	Method
a + b 	        a.plus(b)
a - b 	        a.minus(b)
a * b 	        a.times(b)
a / b 	        a.div(b)
a % b 	        a.rem(b)

Negation
Operation 	Method
-a 	        a.unaryMinus()

Я хоть и не пишу на Java, но теперь это точно не отсталый язык, и более менее равен современным модным языкам с сахарком:

https://github.com/manifold-systems/manifold/tree/master/manifold-deps-parent/manifold-ext

fsb4000 ★★★★★
()
Ответ на: комментарий от fsb4000

Нет, если при смене IDE код перестаёт работать, значит, код не работает.

next_time ★★★★★
()
Ответ на: комментарий от next_time

а то так можно про Qt вспомнить и сказать, что в плюсах самая крутая очередь сообщений

Qt не расширял язык ни на сколько. Он лишь тормозит развитие С++. Всё что было в Qt повторили в CopperSpice на чистом С++17 без moc.

fsb4000 ★★★★★
()
Ответ на: комментарий от next_time
#include <QObject>
 
class Counter : public QObject
{
    CS_OBJECT(Counter)
 
    public:
       Counter() { m_value = 0; }
       int value() const { return m_value; }
 
       CS_SIGNAL_1(Public, void valueChanged(int newValue))
       CS_SIGNAL_2(valueChanged, newValue)
 
       CS_SLOT_1(Public, void setValue(int value))
       CS_SLOT_2(setValue)
 
    private:
       int m_value;
};
void Counter::setValue(int value)
{
    if (value != m_value) {
        m_value = value;
        emit valueChanged(value);
    }
}
Counter a, b;
QObject::connect(&a, SIGNAL(valueChanged(int)), &b, SLOT(setValue(int)));
 
a.setValue(12);     // a.value() == 12, b.value() == 12
b.setValue(48);     // a.value() == 12, b.value() == 48
The C++ preprocessor changes or removes the signals, slots, and emit keywords so that the compiler is presented with standard C++

https://www.copperspice.com/docs/cs_api/signals-slots-c.html

fsb4000 ★★★★★
()
Ответ на: комментарий от fsb4000

Это типа, они там свой xorshift ГПСЧ на констекспр запилили. Не, ну круто, но это не сильно надежнее рецепта от васяна на стековерфлоу. С другой стороны, в rust ведь тоже не понятно кто нестандартные библиотеки пишет…

seiken ★★★★★
()
Ответ на: комментарий от next_time

разумеется: в ООП все классы (кроме sealed) специально сделаны для наследования

В ООП - да, в С++ - нет (не обязательно). Наследоваться от стандартных контейнеров как раз считается плохой практикой: у них функции не виртуальные. И все дополнительные проверки идут лесом когда ты свой safe_array передаёшь в функцию, которая ожидает std::array.

DarkEld3r ★★★★★
()
Ответ на: комментарий от fsb4000

В Qt уже давно никто не использует SIGNAL/SLOT макросы. Теперь можно передавать указатели на функции и лямбды.

RazrFalcon ★★★★★
()
Ответ на: комментарий от fsb4000

Он лишь тормозит развитие С++.

Как и любой фреймворк.

Всё что было в Qt повторили в CopperSpice на чистом С++17 без moc.

https://github.com/woboq/verdigris

PS: автор verdigris теперь пилит свой GUI на Rust =) ЧТД

RazrFalcon ★★★★★
()
Последнее исправление: RazrFalcon (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.