Сама по себе библиотека проблемой не является: все лишние функции будут выкинуты при LTO. Да и содержимое libcore в основном - это либо широко используемые фичи, либо компиляторная магия. К тому же непонятно, зачем без веской причины отказываться от стандартной библиотеки языка, а потом руками ее куски переимплементировать: https://github.com/torvalds/linux/blob/e8f71f89236ef82d449991bfbc237e3cb6ea584f/include/linux/string.h#L22
Более того, стандартная библиотека Rust монолитна
Все эти претензии относятся к std - платформозависимой части стандартной библиотеки. Никто не предлагает тащить ее в ядро (хотя бы потому, что она не умеет работать в kernel mode), поэтому эти претензии нерелевантны.
Только это не "счетчик ссылок", а флаг. В коде на C точно такой же флаг (возможно, засунутый внутрь объекта) точно также придется поддерживать (чтобы понять в конце функции, надо ли делать очистку или нет). Так что нарушений принципа zero cost пока не видно.
Давно пора сделать стандарт для низкоуровневого байткода, описывающего отрисовку.
Такой байткод в сочетании с WebAssembly позволит писать быстрые веб-приложения на чем-угодно
Теорема Райса говорит, что существуют программы, для которых нельзя доказать интересующее вас свойство. Например, если мы попытаемся доказать что программа на питоне никогда не кидается TypeError, то:
Для каких-то программ мы сможем это сделать.
Но найдутся такие, для которых доказать это мы не сможем.
Сейчас вы уводите разговор в совершенно иную плоскость: мы все-таки про UB говорим а не про стандартизацию.
И да, reference — это то, что (в идеале) должно дорасти до стандарта.
По аналогии, на любом компиляторе c++ который вы сможете найти, ваш пример будет работать аналогично.
И где в документации clang, g++ и msvc написано, что они гарантируют, что чтение неактивного поля это не всегда UB?
Это используется в стандартной библиотеке.
Например тут и во многих других аналогичных местах делается что-то вроде transmute с помощью union.
https://doc.rust-lang.org/nightly/reference/items/unions.html#reading-and-writing-union-fields: Unions have no notion of an "active field". Instead, every union access just interprets the storage at the type of the field used for the access. Reading a union field reads the bits of the union at the field's type. (Конечно, если чтение породит невалидное значение, то поведение не определено).
Код с UB просто не является программой на расте.
Почему? Rustc не отклоняет ее, значит это корректная прогорамма (несмотря на то что ее поведение во всех случаях не определено).
Многообразие синтаксических форм для инициализации
std::vector foo (s.begin(), s.end());
vs
std::vector foo {s.begin(), s.end()};
Более того, НЯП в одной строке создается вектор интов на основе двух итераторов, а в другой вектор итераторов.
Сама по себе библиотека проблемой не является: все лишние функции будут выкинуты при LTO. Да и содержимое libcore в основном - это либо широко используемые фичи, либо компиляторная магия. К тому же непонятно, зачем без веской причины отказываться от стандартной библиотеки языка, а потом руками ее куски переимплементировать: https://github.com/torvalds/linux/blob/e8f71f89236ef82d449991bfbc237e3cb6ea584f/include/linux/string.h#L22
Все эти претензии относятся к std - платформозависимой части стандартной библиотеки. Никто не предлагает тащить ее в ядро (хотя бы потому, что она не умеет работать в kernel mode), поэтому эти претензии нерелевантны.
Только это не "счетчик ссылок", а флаг. В коде на C точно такой же флаг (возможно, засунутый внутрь объекта) точно также придется поддерживать (чтобы понять в конце функции, надо ли делать очистку или нет). Так что нарушений принципа zero cost пока не видно.
Давно пора сделать стандарт для низкоуровневого байткода, описывающего отрисовку.
Такой байткод в сочетании с WebAssembly позволит писать быстрые веб-приложения на чем-угодно
Теорема Райса говорит, что существуют программы, для которых нельзя доказать интересующее вас свойство. Например, если мы попытаемся доказать что программа на питоне никогда не кидается TypeError, то:
Для каких-то программ мы сможем это сделать.
Но найдутся такие, для которых доказать это мы не сможем.
Хабрапарсер съел асимптотику.
Попытка номер 2: O(2^n * N^2), где ^ это возведение в степень.
Она разрешима за конечное время. Например есть довольно простой алгоритм время работы которого O((2*N) (N2)), где это возведение в степень
Но это же пространство имен вроде как.
Чем тогда является это:
?
А где в этом C++ коде используются области видимости?
Можете.
std::cell::Cell, смотрите функции get() и set() ЕМНИП
Силами сообщества уже делается, но кажется довольно сырое: https://github.com/shiftkey/desktop
Сейчас вы уводите разговор в совершенно иную плоскость: мы все-таки про UB говорим а не про стандартизацию.
И да, reference — это то, что (в идеале) должно дорасти до стандарта.
И где в документации clang, g++ и msvc написано, что они гарантируют, что чтение неактивного поля это не всегда UB?
Например тут и во многих других аналогичных местах делается что-то вроде transmute с помощью union.
Кажется, такого очень мало. Мне сходу в голову только одно приходит:
https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=5cadcaefcd6a2ca8f6d631b1f3a4ada2
Например корректность ссылок и невозможность выхода за границы массива.
Ну, проблема в том что вроде как в течение 3-4 месяцев AST borrowck должны полностью выпилить, и какой-то код все-таки сломается.
Ну например:
auto x = baz();
vs
decltype(auto) x = baz();
Многообразие синтаксических форм для инициализации
std::vector foo (s.begin(), s.end());
vs
std::vector foo {s.begin(), s.end()};
Более того, НЯП в одной строке создается вектор интов на основе двух итераторов, а в другой вектор итераторов.
Но далеко не убегает, потому что ноги прострелены.
Можно зашифровать им сервера террористов.
Нейронные сети плохо справляются с придумыванием алгоритмов кмк
Конечно)):