LINUX.ORG.RU

Rust 1.11

 


1

5

Команда разработчиков Rust рада представить релиз Rust 1.11. Rust — это системный язык программирования, при разработке которого внимание сосредоточено на безопасности, скорости и параллелизме.

Как обычно, вы можете установить Rust 1.11 с соответствующей страницы на официальном сайте, а также посмотреть примечания к выпуску на GitHub.

Основные изменения

  • Большая часть изменений касалась пока ещё нестабильных внутренностей компилятора. Началась работа над инкрементальной компиляцей и переходом на MIR. В этом выпуске были заложены основы для этих возможностей.
  • В выпуске 1.10 был введён новый формат контейнеров cdylib, который используется при компиляции кода на Rust для встраивания в другие языки. До этого момента поддержка cdylib была реализована только в компиляторе, теперь эта возможность стала доступна и в Cargo.
  • В стандартной библиотеке изменилась функция хэширования по умолчанию с SipHash 2-4 на SipHash 1-3.

Стабилизации библиотеки

  • В BinaryHeap, BTreeMap, и BTreeSet добавлен метод append.
  • В BTreeMap и BTreeSet добавлен метод split_off.
  • Методы to_degrees и to_radians ранее были реализованы для f32 и f64 в libstd, теперь они также доступны в libcore.
  • В Iterator добавлены два новых метода: sum и product.
  • Cell и RefCell получили метод get_mut.
  • assert_eq!, как и assert!, теперь принимает пользовательское сообщение об ошибке.
  • Главный поток теперь называется “main” вместо “<main>”.

Cargo

  • Добавлена поддержка цвета для Windows-консолей, и вы можете теперь конфигурировать цвета для stderr так же, как и для stdout.
  • Скрипты сборки теперь могут выдавать предупреждения.
  • Как было упомянуто выше, добавлена поддержка cdylib-контейнеров.
  • Cargo теперь предотвращает публикацию контейнеров при наличии изменённых файлов или файлов, которые не являются частью рабочего дерева.

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

★★★★★

Проверено: Shaman007 ()
Последнее исправление: Kilte (всего исправлений: 9)
Ответ на: комментарий от tailgunner

Windows. И что?

да ничего. Очень хочется узнать - как ты умудрился не поперхнуться на словах «широта использования» в контексте COM

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

Windows. И что?

btw, ты не можешь не знать, что даже в рамках windows COM - это интерфейс для _части_ компонентов системы, а не для всех, старый ты провокатор

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

Т.е «универсальная» - это «может быть использована из любого языка»? Так любая объектная система может быть использована из любого языка, вопрос в толщине прокладок.

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

ты не можешь не знать, что даже в рамках windows COM - это интерфейс для _части_ компонентов системы

И эта часть составляет... 86% часто используемых компонентов? 99%?

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

Так любая объектная система может быть использована из любого языка, вопрос в толщине прокладок.

если ограничить «использование» до «инстанциировать и дёрнуть метод» - то да :)

[народ бунтует, говорит - хвостострел-то ненастоящий]

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

И эта часть составляет... 86% часто используемых компонентов? 99%?

хм. Ну что за виляние. 86% «часто используемых» компонентов одной платформы - это херня, а не универсальность.

у java в таком случае тоже универсальный abi, свекла

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

если ограничить «использование» до «инстанциировать и дёрнуть метод» - то да :)

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

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

Ну что за виляние. 86% «часто используемых» компонентов одной платформы - это херня, а не универсальность.

Ну вот, начался серьезный разговор. А сколько вам надо до признания «универсальности»? 99%? 99.8%? Вот мне хватило бы и 51% ):

у java в таком случае тоже универсальный abi, свекла

Если рассматривать платформу Java - да, естественно. И к этому ABI подстраиваются всяческие Scala.

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

А какие ты еще видишь варианты использования?

создать свой класс

Любое расширение можно делать уже родными средствами, что будет и логичней, и удобней и прямей.

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

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

Ну вот, начался серьезный разговор. А сколько вам надо до признания «универсальности»? 99%? 99.8%? Вот мне хватило бы и 51% ):

а вам? (с) Тебе мало того, что gobject используется не только в гноме, а в куче подсистем, из которых gui - только часть? И при этом не ограничивается одной платформой

Если рассматривать платформу Java - да, естественно. И к этому ABI подстраиваются всяческие Scala.

java platform универсальна в рамках java platform.

молодец, ты сделал мой день

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

создать свой класс

struct MyWidget : public Gtk::Widget {
 bool on_draw(const Cairo::RefPtr<Cairo::Context>& cr) override {
     ....
 }
}

Свой класс? Свой. Расширить его можно? Можно. Что еще надо?

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

Так и не надо. Вон в PyQt прекрасно все расширяется.

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

А сколько вам надо до признания «универсальности»? 99%? 99.8%? Вот мне хватило бы и 51% ):

а вам? (с)

Я же написал - 51%.

Тебе мало того, что gobject используется не только в гноме, а в куче подсистем, из которых gui - только часть?

Мало. Но, наверное, если бы ты назвал GObject «универсальной объектной моделью библиотек, которые разрабатываются в основном Redhat», я бы не спорил.

java platform универсальна в рамках java platform.

Альцгеймер не щадит никого, понимаю. Java ABI универсален в пределах java Platform, которая давно уже многоязычная.

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

86% часто используемых компонентов? 99%?

После выкидывания всяких директшоу c активиксами — даже не 50, я думаю.

Так любая объектная система может быть использована из любого языка

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

Для этого нужна интроспекция. Не уверен, что такое можно нагородить малой кровью на тех же плюсах, даже с RTTI, никто же не нагородил подобного для Qt, все руками пилят. Да и мс запилили COM.

А писать руками обертки для всех методов — это немного не то.

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

Java ABI универсален в пределах java Platform

Ты уверен? Не очень пока разбираюсь в джаве, но скалисты спецом запиливали calling convention или что-то вроде того как в жаве, чтоб была совместимость и всякие акки можно было использовать из жавы. Жвм — она же просто стэковая виртуальная машина, там можно, наверное, своего нагородить, и не будет ничего универсального.

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

Свой класс? Свой. Расширить его можно? Можно. Что еще надо?

это к чему вообще?

Так и не надо. Вон в PyQt прекрасно все расширяется.

в Qt используются костылища вроде qmetaobject, которые делают из цепепешного QObject жалкую пародию божественного сишного gobject :)

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

плюсисты обвиняют (любой другой язык) в том что там плохая система управления зависимостями.

программистам, пишущим на С++ вообще пофигу на «системы управления зависимостями». хотя бы потому, что в С++ такого ненужно нет, ибо оно там ненужно.

если люди тянут в ЯП свой пакетный менеджер - ну пусть тянут. может им так удобнее.

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

Я же написал - 51%

ну так твоего COM в той же жабе - 0%

на gnu/linux - тоже примерно столько же.

а ты говоришь, что универсальный. Ай-яй-яй

Но, наверное, если бы ты назвал GObject «универсальной объектной моделью библиотек, которые разрабатываются в основном Redhat»,

если учитывать, что glib object system - это экспорт _объектной модели_ через C ABI - то твои заявления о неуниверсальности этого самого ABI выглядят странно.

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

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

ну так твоего COM в той же жабе - 0%

Жаба - отдельная платформа.

а ты говоришь, что универсальный. Ай-яй-яй

Универсальность в пределах платформы. Я думал, это понятно без явной декларации.

универсальна ли сама объектная модель?

По-моему, ты путаешь «спроектирована, чтобы быть универсальной» и «стала универсальной».

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

это к чему вообще?

К тому, что если ты хочешь создавать свои классы, то тебе совершенно нет надобности в чем-либо вроде GObject. Тебе нужен только _родной_ для используемого языка базовый класс. А поверх чего он будет построен - абсолютно параллельно.

в Qt используются костылища вроде qmetaobject, которые делают из цепепешного QObject жалкую пародию божественного сишного gobject :)

Есть маленький ньюанс - QMetaObject не умеет в динамику, а значит он никак не может быть использован для создания классов в PyQt.

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

86% часто используемых компонентов? 99%?

После выкидывания всяких директшоу c активиксами — даже не 50, я думаю.

Честно говоря, не слежу за вендой уже 15 лет. Когда-то COM был там универсальной объектной моделью, если перестал - видно, что-то пришло ему на смену.

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

Я и не говорю о малой крови. Обертка может быть толстой и кровавой. Но меня лично интересует сравнение оберток поверх GObject и поверх Си-интерфейса аналогичной функциональности. Если где-то такое есть.

даже с RTTI

А через RTTI и не надо. В DWARF есть вся нужная информация.

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

К тому, что если ты хочешь создавать свои классы, то тебе совершенно нет надобности в чем-либо вроде GObject.

если ты хочешь, чтобы твои классы «созданные снаружи» - были видны «объектной системе» именно как твои классы, а не как ProxyForSomethingObject - то надобность есть.

Есть маленький ньюанс - QMetaObject не умеет в динамику, а значит он никак не может быть использован для создания классов в PyQt.

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

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

Жаба - отдельная платформа.

да? а виндовс - нет?

Универсальность в пределах платформы. Я думал, это понятно без явной декларации.

опять виляние. Твой com - якобы универсален в рамках windows (на самом деле нет). При этом gobject работает и windows в том числе. Но - он не универсален по твоему. Почему? Непонятно.

По-моему, ты путаешь «спроектирована, чтобы быть универсальной» и «стала универсальной».

ты уже на стадии добавления уточнений к термину. Ремиссия?

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

если ты хочешь, чтобы твои классы «созданные снаружи» - были видны «объектной системе» именно как твои классы, а не как ProxyForSomethingObject - то надобность есть.

Для этого - да, но сколько ты знаешь случаев, когда библиотека не на С экспортировала бы классы через GObject и ей бы пользовались из других языков?

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

НЯП, для питона репы и pip живут в каких-то непересекающихся реальностях. вроде они как бы одним и тем же питоном рулят, а получается, что для работы надо удалять пакеты из репы и ставить через pip.

но это фишка питона, видимо им там удобнее.

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

но это проблема линковщика и ни репы ни какой-то встроенный менеджер её не решат.

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

Для этого - да, но сколько ты знаешь случаев, когда библиотека не на С экспортировала бы классы через GObject и ей бы пользовались из других языков?

да в общем-то примерно так работает accessibility гнома/юнити, если мне склероз не изменяет, и какая-то прога для ползания по объектам/виджетам запущенного приложения - то ли с целью автоматизации/скриптования то ли ещё чего.

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

да в общем-то примерно так работает accessibility гнома/юнити, если мне склероз не изменяет, и какая-то прога для ползания по объектам/виджетам запущенного приложения - то ли с целью автоматизации/скриптования то ли ещё чего.

Для этих задач тоже нет никакой надобности использовать GObject для создания своих новых классов.

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

еще не нужно вайнить про то, что C++ чем-то не устраивает, когда можно просто писать на таких замечательных ЯП как лисп или жава.

хотя мне кажется, это невыполнимая просьба.

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

Для этих задач тоже нет никакой надобности использовать GObject для создания своих новых классов.

есть. Ну или любое другое нечто с поддержкой интроспекции - хоть тот же qt с костылями для цепепе

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

Они не умеют в скорость и в экономию ресурсов

ты так пишешь, как будто c++ умеет в скорость и экономию.

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

Всё в руках твоих

всем остальным запретили писать программы? Алилуйя, слава росатому. Где заказы?

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

Когда следующий раз попытаешься начать, не используй словосочетание «универсальная объектная модель» и вообще читай, что тебе пишут в ответ. А то ты споришь с голосами в голове.

Господа, я с вас шизею, как вы о словах спорите… Предполагает ли словосочетание «универсальная объектная модель» замену родной объектной модели языка программирования или использование изначально в качестве основной? Да нет. Если в магазине есть универсальные кухонные комбайны, это не значит что в том же магазине не продаются мясорубки или миксеры. Но GObject это действительно объектная модель, которую можно использовать в любом языке программирования (кроме basic-256 и focal, разве-что). И спроектирована она, да, явно универсальней, чем MS COM. Так что сравнение некорректно. Как и с прибитым гвоздями к плюсам Qt. Так что по отношению к языку эта модель универсальна. Используется ли она за пределами Gtk? Нет. Удобнее ли неё встроенные объектные модели популярных языков? Ну да, странно было бы, если бы швейцарский нож оказался удобней отдельно взятых финки и пассатижей там, где нужны именно последние. Заслуживает ли она интереса? Каждый выбирает по себе — но если хочется программировать не на плюсах, за Gtk некоторая фора.

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

Жаба - отдельная платформа.

да?

Да.

а виндовс - нет?

Тоже да. И Линукс - тоже.

Твой com - якобы универсален в рамках windows (на самом деле нет).

На самом деле да.

При этом gobject работает и windows в том числе. Но - он не универсален по твоему. Почему? Непонятно.

См. выше о процентах.

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

Короче, весь спор из-за плохого C ABI. Срочно нужно пинать Леонарда, чтобы внедрил в ядро новый, с классами и интроспекцией

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

Не понимаю о чем ты, лично я о том, что единственная причина использовать С++ это скорость и экономия в купе с подходящей задачей. С++ в сравнении с Джавой и Лиспом быстрый и экономичный язык.

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

есть. Ну или любое другое нечто с поддержкой интроспекции - хоть тот же qt с костылями для цепепе

Нет, нету. Т.к. тут очевидно такой код рассчитан только на уже известные и выписанные классы/методы, и не может обладать телепатическими познаниями о совершенно неизвестных классах, и тем более не сможет принимать решения - что с ними делать. А потому и расширять уже известные классы (чтоб с ними мог работать такой код) можно как угодно, ни на что это не повлияет.

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

Короче, весь спор из-за плохого C ABI. Срочно нужно пинать Леонарда, чтобы внедрил в ядро новый, с классами и интроспекцией

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

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

А либреофис и гимп разве не на gtkmm? Чем не популярность gtk?

libreoffice на своем тулките, и может и в gtk, и в qt, и в win32 и т.д. А поводу GIMP - да, смешная шутка.

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

На самом деле да.

нет

См. выше о процентах.


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

с этим сложно согласиться

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

Паркуа бы и не па

В какую редакцию писать, чтобы внедрили?

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

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

что?

корневое окно, дай мне список дочерних вьюшек. Окай, теперь ищем вьюшку с такими-то свойствами. Окей. Пользователь - смотри, тут есть такие методы - что дёрнуть?

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

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

В чем комический смысл шутки?

В том, что GTK это и есть (был) GIMP Toolkit. И если ты не нашел ничего кроме него, что показать популярность GTK... Ну и к слову - GIMP малоизвестен за рамками Linux (а в Linux, понятно, дизайнеров кот наплакал). Да и кроме того малоюзабелен. Например, в macOS это глючное и тормозное нечто, чем даже при желании невозможно пользоваться.

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

Не понимаю о чем ты, лично я о том, что единственная причина использовать С++ это скорость и экономия в купе с подходящей задачей. С++ в сравнении с Джавой и Лиспом быстрый и экономичный язык.

конечно. Только писать на нём долго и муторно - мешают сапоги из танковой брони и свинцовые трусы (на всякий случай)

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

Ну и к слову - GIMP малоизвестен за рамками Linux (а в Linux, понятно, дизайнеров кот наплакал).

Не факт. Хотя для профессионального дизайна Photoshop — «межкорпоративный» стандарт, среди любителей видел не так мало пользователей виндового Гимпа.

be_nt_all ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.