А можно небольшую просьбу от человека, знакомого с C, Rust, но плюсы знающего исключительно на уровне "Си с классами"?
В дискуссиях "C++ vs Rust" регулярно используется довод, что в C++ можно делать всё не менее безопасно, чем на Rust, и наверняка хорошо известно, что именно для этого требуется. Скорее всего, и компиляторы / линтеры это должны уметь.
Не могли бы вы (в значении "эксперты по языку C++", не обязательно лично Вы) показать пример конфигурации открытого компилятора и/или открытых линтеров, обеспечивающих адекватную степень безопасности? Чтобы была возможность начать проект на C++, включить их в этой конфигурации и быть уверенным, что они дадут мне по рукам, когда я случайно использую malloc вместо make_unique / напишу код с ошибкой инвалидации итератора / сделаю какую-нибудь ещё глупость, про которую я просто не в курсе. Потому что за себя я уверен, что даже если я прочитаю от корки до корки C++ Core Guidelines, как минимум поначалу такие ошибки всё равно будут.
Вот, например, clang-tidy --checks=cppcoreguidelines-*,modernize-* — это адекватно, избыточно или недостаточно?
А добавьте пожалуйста для Rust опцию -C target-cpu=native для более честного сравнения с C(++). На моём Skylake она снижает время работы приведённого кода с 0.65 секунды до 0.55.
(update: вижу, выше уже предлагали, но поиск по Rust тот комментарий не нашёл ввиду русскоязычного написания)
С прискорбием вынужден не согласиться. Нередко код потребляет много ресурсов не потому, что он простой, а потому, что он одновременно сложный и неоптимальный.
В Firefox есть точно та же проблема, только максимальная "короткая" строка не 12 байт, как в Chrome, а 23 / 11 символов (для Latin1 / двухбайтных — см. раздел inline strings по ссылке). На 24 символах проблема воспроизводится. Кстати, следует учитывать, что выбор режима между Latin1 и двухбайтным выполняется исключительно по тому, в каком режиме была изначальная строка — то есть если там был Юникод за пределами Latin1, то и все подстроки будут оставаться ссылками по лимиту в 11 символов, а не 23.
Что ещё веселее, если внимательно посмотреть на результаты теста в JSPerf на Firefox, то окажется, что "решение" через (' ' + str).slice(1) работает за время, не зависящее от длины подстроки. Дело в том, что в Firefox эта операция выполняется через строку типа Rope и не приводит к "отсоединению" от базовой строки, то есть не выполняет свою задачу. Лишний раз видим, что самые быстрые решения зачастую оказываются менее надёжными.
Длина свободного пробега молекул порядка единиц микрометров — это очень «грубый» вакуум. С точки зрения самого давления сойдёт, но, например, с точки зрения разрядов в высоковольтной электронике при пониженном давлении всё самое интересное начинается не выше единиц паскалей, сколько я помню… и заканчивается ещё на пяток порядков ниже, когда концентрация становится недостаточной для опасных пробоев.
Это и есть каталог, там отдельные файлы для разных смонтированных файловых систем. Защищать от создания файлов не пробовал, т.к. правильнее решить проблему в самом Firefox.
С Firefox на Linux всё не так хорошо, как хотелось бы. С версии 19 (изначальный репорт) он пишет эту информацию в хранилище GIO/GVFS (бинарную базу данных, находящуюся в ~/.local/share/gvfs-metadata). Проверить можно командой gio info $filename.
Что хуже, в приватном режиме он тоже это делает, о чём я оставил bug report.
Вообще говоря, способна. У роверов есть несколько антенн, и сигнал ненаправленной LGA с Земли вполне слышен. Для научных данных она плохо подходит ввиду низкой максимальной скорости, но на сигнал «я тут ещё жив» её бы хватило. Судя по пресс-релизам, пока ровер жив, он должен был ежедневно просыпаться, включать ненадолго этот сигнал и вновь уходить в спячку.
Это ж блин сигнатура функции, она должна говорить про типы параметров, а не требования к производительности определять.
Да, поэтому сигнатуру, которая сразу же ограничивает "а эта функция точно не сможет работать максимально быстро вне зависимости от реализации из-за отсутствия инлайнинга и т. п.", лучше делать явно видимой. Кроме того, dyn Trait не только в сигнатурах может возникать, но и, например, в структурах данных, где подобные ограничения также лучше видеть.
Аргумент с ортогональностью impl Trait тоже неубедителен — в одном случае это кодогенерация, которая делает возможным прежде недоступные вещи, а другое — просто алиас для уже существующей синтаксической конструкции, которую придется деприкейтить и писать тулзы для миграции.
Аргумент с ортогональностью — он скорее не про возможности, а про обучение. У новичков разница между dyn Trait и impl Trait будет, предположительно, вызывать сильно мешьную путаницу, чем между Trait и impl Trait при использовании в местах, где могут быть оба варианта. Rust и так имеет непростую кривую обучения, так что её локальное упрощение имеет смысл даже ценой небольших миграций.
На ExoMars Trace Gas Orbiter почему-то поставили такой же прибор для поиска воды, который стоял и на Mars Odyssey — хотя зона покрытия у него будет примерно та же.
Строго говоря, не такой же, а более продвинутый. В нем используется нейтронный коллиматор, что по предварительным оценкам позволит на порядок улучшить пространственное разрешение.
В servo есть минимум одна большая и сложная абстракция (интеграция с JavaScript-движком mozjs, вариантом SpiderMonkey, который написан на C++), плюс логические ошибки, которые ловят ручные или автоматические assert-ы разных видов, в некоторых случаях недостаточно оптимизированное потребление ресурсов на особо весёлых страницах (например, slither, создающий более 2000 canvas-ов). Иногда ещё драйверы GPU вылетают.
null в Rust есть только на уровне небезопасных абстракций ("сырые" указатели и им подобное). Да, код, работающий с ними напрямую, должен об этом беспокоиться — но это в худшем случае несколько абстракций, предоставляющих внешнему коду безопасный интрефейс, а не весь объём кода приложения.
Пока что не соответствует действительности. Из Firefox потихоньку "выпиливают" фирменную технологию байндингов XBL (но и то ещё на ранних этапах), а XUL пока что остаётся и даже кое-где развивается (например, одной из составляющих в замене XBL станет поддержка Custom Elements в XUL). Другое дело, что с Quantum XUL окончательно становится деталью реализации, поскольку дополнения доступа к нему лишаются.
Вероятно, здесь стоит упомянуть, что передача пароля в аргументе командной строки — вообще не очень хорошая идея, поскольку он будет светиться в /proc/$pid/cmdline
Справедливости ради следует отметить, что внешний скрипт, загружаемый с CDN, может быть безопасен с этой точки зрения в современных версиях Firefox и Chrome/Opera (и других chromium-based), если используется Subresource Integrity (caniuse), поскольку проверяется правильность хэша (sha256 или более сильные). Впрочем, к скриптам метрики это не относится ввиду отсутствия эталонного хэша, который не должен изменяться.
Согласен, не уточнил, но это некритично до тех пор, пока глаз неподвижен во время движения луча. Замените «в изображение зеркала» на «в пределах несфокусированного изображения зеркала». Даже несфокусированное, оно останется почти точкой в масштабах поля зрения. Вот если бы глаз был в этот момент в движении, ситуация могла бы оказаться существенно иной.
Но этот луч в каждую точку линии приходит из одного источника (от зеркала). А зрачок глаза, сфокусированного на зеркале, все лучи, приходящие от него, собирает в одну точку на сетчатке — в изображение зеркала. Он всю эту линию сворачивает практически в точку.
Потому что это было установлено после завершения трёхнедельного цикла измерений, когда устройство было извлечено из камеры. Повторение трёхнедельного цикла измерений — удовольствие непростое и, вполне вероятно, недешёвое.
По завершении было установлено, что провода закоротило, а сама микросхема (после отключения проводов) функционирует. Вопрос того, что случилось с проводами и как этого избежать, остался на дальнейшую работу, я так понимаю.
А можно небольшую просьбу от человека, знакомого с C, Rust, но плюсы знающего исключительно на уровне "Си с классами"?
В дискуссиях "C++ vs Rust" регулярно используется довод, что в C++ можно делать всё не менее безопасно, чем на Rust, и наверняка хорошо известно, что именно для этого требуется. Скорее всего, и компиляторы / линтеры это должны уметь.
Не могли бы вы (в значении "эксперты по языку C++", не обязательно лично Вы) показать пример конфигурации открытого компилятора и/или открытых линтеров, обеспечивающих адекватную степень безопасности? Чтобы была возможность начать проект на C++, включить их в этой конфигурации и быть уверенным, что они дадут мне по рукам, когда я случайно использую
mallocвместоmake_unique/ напишу код с ошибкой инвалидации итератора / сделаю какую-нибудь ещё глупость, про которую я просто не в курсе. Потому что за себя я уверен, что даже если я прочитаю от корки до корки C++ Core Guidelines, как минимум поначалу такие ошибки всё равно будут.Вот, например,
clang-tidy --checks=cppcoreguidelines-*,modernize-*— это адекватно, избыточно или недостаточно?А добавьте пожалуйста для Rust опцию
-C target-cpu=nativeдля более честного сравнения с C(++). На моём Skylake она снижает время работы приведённого кода с 0.65 секунды до 0.55.(update: вижу, выше уже предлагали, но поиск по Rust тот комментарий не нашёл ввиду русскоязычного написания)
В Firefox есть точно та же проблема, только максимальная "короткая" строка не 12 байт, как в Chrome, а 23 / 11 символов (для Latin1 / двухбайтных — см. раздел inline strings по ссылке). На 24 символах проблема воспроизводится. Кстати, следует учитывать, что выбор режима между Latin1 и двухбайтным выполняется исключительно по тому, в каком режиме была изначальная строка — то есть если там был Юникод за пределами Latin1, то и все подстроки будут оставаться ссылками по лимиту в 11 символов, а не 23.
Что ещё веселее, если внимательно посмотреть на результаты теста в JSPerf на Firefox, то окажется, что "решение" через
(' ' + str).slice(1)работает за время, не зависящее от длины подстроки. Дело в том, что в Firefox эта операция выполняется через строку типа Rope и не приводит к "отсоединению" от базовой строки, то есть не выполняет свою задачу. Лишний раз видим, что самые быстрые решения зачастую оказываются менее надёжными.С Firefox на Linux всё не так хорошо, как хотелось бы. С версии 19 (изначальный репорт) он пишет эту информацию в хранилище GIO/GVFS (бинарную базу данных, находящуюся в
~/.local/share/gvfs-metadata). Проверить можно командойgio info $filename.Что хуже, в приватном режиме он тоже это делает, о чём я оставил bug report.
Да, поэтому сигнатуру, которая сразу же ограничивает "а эта функция точно не сможет работать максимально быстро вне зависимости от реализации из-за отсутствия инлайнинга и т. п.", лучше делать явно видимой. Кроме того,
dyn Traitне только в сигнатурах может возникать, но и, например, в структурах данных, где подобные ограничения также лучше видеть.Аргумент с ортогональностью — он скорее не про возможности, а про обучение. У новичков разница между
dyn Traitиimpl Traitбудет, предположительно, вызывать сильно мешьную путаницу, чем междуTraitиimpl Traitпри использовании в местах, где могут быть оба варианта. Rust и так имеет непростую кривую обучения, так что её локальное упрощение имеет смысл даже ценой небольших миграций.Строго говоря, не такой же, а более продвинутый. В нем используется нейтронный коллиматор, что по предварительным оценкам позволит на порядок улучшить пространственное разрешение.
В servo есть минимум одна большая и сложная абстракция (интеграция с JavaScript-движком mozjs, вариантом SpiderMonkey, который написан на C++), плюс логические ошибки, которые ловят ручные или автоматические assert-ы разных видов, в некоторых случаях недостаточно оптимизированное потребление ресурсов на особо весёлых страницах (например, slither, создающий более 2000
canvas-ов). Иногда ещё драйверы GPU вылетают.nullв Rust есть только на уровне небезопасных абстракций ("сырые" указатели и им подобное). Да, код, работающий с ними напрямую, должен об этом беспокоиться — но это в худшем случае несколько абстракций, предоставляющих внешнему коду безопасный интрефейс, а не весь объём кода приложения.Так, например, стек ядра каждого потока — это от 8k, то есть две последовательные страницы памяти, на большей части архитектур.
Пока что не соответствует действительности. Из Firefox потихоньку "выпиливают" фирменную технологию байндингов XBL (но и то ещё на ранних этапах), а XUL пока что остаётся и даже кое-где развивается (например, одной из составляющих в замене XBL станет поддержка Custom Elements в XUL). Другое дело, что с Quantum XUL окончательно становится деталью реализации, поскольку дополнения доступа к нему лишаются.
Вероятно, здесь стоит упомянуть, что передача пароля в аргументе командной строки — вообще не очень хорошая идея, поскольку он будет светиться в
/proc/$pid/cmdlineПо завершении было установлено, что провода закоротило, а сама микросхема (после отключения проводов) функционирует. Вопрос того, что случилось с проводами и как этого избежать, остался на дальнейшую работу, я так понимаю.