Siemargl

Если у вас 100к шаред пойнтеров, возможно проблема в дизайне, а не в мейк_шаред. Особенно, если данные иммутабельные. ТС это тоже относится

Ну да, очень странна радость пользователя от Acer Spin 2 in 1 Chromebook, у которого N4000, 4Gb RAM и 32Gb диска. Какие контейнеры с такими ограничениями?

glibc все используют, а других биндингов нет.

Хотя я бы скорее придрался к -ffast-math

Теорию ИИ я не знаю, по коду — применяется корневая функция (9 вариантов) к треугольнику матрицы.

Не столько переменные, но ссылки. Обходится как подсказали выше. Но неудобство кардинальное, особенно при отладке — лишний раз println написать и то запрет — уже попользовано.

Собственно, по мне писать на Расте — это как плавать со связанными руками. Неудивителен рост на Тиобе — без гугла ни строки. (

По-моему тоже, такое разрешительство идет поперек всей идеологии Раста.

Впрочем, легко поправимое и без ломающих последствий.

Осталась только полная невозможность создания хоть каких-то разделяемых библиотек со стабильным высокоуровневым API.

Кроме extern C еще изобрели CORBA и DCOM. Все благополучно издохли.
Жениться вам барин надо (с)

tia portal бесплатен для s7-1200

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

let sum_kg = kg + kg

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

У Раста оказывается есть собственный линтер. Да еще и 350 линтов.
Я удивлен.
Но данное ишью касается лишь терминологии, а вот 1300е — как раз предупреждениям и было отвергнуто.

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

т.е кроме unsafe, еще ищем в коде unwrap? =)
что еще?

Да, это хороший ответ. И я наверное слишком ограниченно подошел к Option/Result как только к обработке ошибок.
Но эта двойственность же и опасна — если что то можно не делать, люди и будут не делать.

Языков с NPE много. Большинство дадут вменяемый стектрейс. Но ниже есть лучший ответ.

Отлично. Теперь возвращаемся к началу ветки

Вы это сейчас серьёзно говорите? Про язык с нуллабельными указателями без проверки времён жизни?

И чем же Option безопаснее нуллабельного указателя??? Паникой вместо GPF/segfault?

Где то это уже было… -Werror

Не надо полумер, советуйте сразу писать без ошибок!

Option.unwrap варнинга, кстати, не генерирует.

Например, сделать все переменные TLS по умолчанию (D), или таки встроить примитивы синхронизации в язык (C#, Active Oberon, Ada). Хотя второе наверное не сильно отличается от подхода Раста — когда они в библиотеке.

А с Option в любом случае придётся что-то сделать, прежде чем получить само значение

Напоминаю про недавний пример, где игнорирование Result приводит к ошибке.
Аналогично берем и пишем Option.unwrap()

Запрет это не решение.

Тем, что бесконечные unwrap без проверок — это вопрос дисциплины кода, а нуллабельные указатели — элемент языка?

Проверка на нуль это тоже дисциплина кода.

Rust шарить неизменяемую ссылку на статический объект между потоками

Это в общем то и всё, что он может. Это могут все. Смешно.

Я зря надеялся на большее (

В Rust компилятор защищает от большинства проблем многопоточности

Это бред. Раст просто запрещает разделение ресурсов. Это не решает проблем многопоточности.

Конечно, ваша девственность защищена на 100% поясом, только использовать вы не можете НИЧЕГО.

Только насколько выразительным и безопасным он будет?

Оберон тут образцом.

Оптимизировать его можно до идеала. Безопасным — не хуже Раста, выразительность конечно на уровне дат разработки — 2013 макс.

А теперь возьмем Safe C. Время компиляции — на уровне С (Раст тормоз, если кто не в курсе), за счет толстых указателей — безопасность памяти вполне (в Расте это заимствовано в виде &str — слайсов, не в обиде за идею).

Нет, я немного жив =)

Возможно, моя информация устарела — я не настолько слежу за компиляторами, но мне кажется, что не каждая оптимизация требует отдельного полного прохода.

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

Нет. Из 7-9 проходов компиляции С++, оптимизации посвящены максимум 2.

Любой язык с простой семантикой может быть одновременно быстрым и в компиляции и в исполнении.

А что, техлид потоковый торрент не освоил? =)

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

Ну а в остальном, кажется стало даже понятнее! :troll:

Но в данном примере явно нехватает лайфтамов, это которые `

Можно, я отвечу, как адвокат дьявола?

Я бы дождался решения от Микрософт.

Следующим поколением С лучше считать Safe C и Checked C.

Да какие претензии к языку? Просто наблюдение.

А вот комментарии к Pin, которых я вдоволь начитался вчера, доставляют

• Notice that this guarantee does *not* mean that memory does not leak!
• The following implementations aren't derived in order to avoid soundness issues..
• this method is safe because..(много повторений)
• This constructor is unsafe because we cannot guarantee that...
• This function is unsafe. You must guarantee...(несколько шт)
• we just need to take care not to allow such impls to land in std

Но главное, что работает :troll:

Ну так DerefMut реализуют все примитивы.

Это совершенно не верно. Как минимум можно использовать безопасные примитивы синхронизации. Также и без них можно шарить между потоками объект по статической ссылке.

Можно пример?

не нужно. а программисты по дефолту ленивые

Видно в документации? Нет.
Я то в исходниках потом нашел.

Для x64 наоборот — в основном SSE.

Даже с моим минимальным опытом, я бы сказал, что весьма неоднозначно.

CISC по определению имеет больше инструкций чем RISC (reduced instruction set computer)

А в 64-бит версиях?

Я встречал мнения, что 32бит покинуты (abandoned), т.е не развиваются.

Я читал доку, а там не всё.

Кстати, на моей [длинной] памяти это первый язык, нарушающий правило — хороший код — самодокументированный.

В Расте комментарии документирования превышают код втрое

Я был неправ, но и Вы тоже. Просто у Pin есть разные специализации трейтов для &T и для &mut T.
Из документации этого не видно — но по факу Pin(&T) не умеет в as_mut().
В итоге, читая доку, я был обманут.

Итоговый результат в этом треде — Раст предотвращает гонку данных между потоками. Но цена этого — вы не можете использовать общие данные между потоками в safe Rust. Никак!

Заметил (давно), что i387 инструкции больше не используются. Это учтено?

Хотя их и было немного, но могли попасть в дебаг версии.

Ну и было бы неплохо добавить в статистику число тиков на инструкцию как ИТОГО… Архитектуры то разные.