Видимо вы имеете ввиду, что ваш unsafe используется во внешнем публичном API.
Да, я рассматриваю именно такой случай в цитируемом контексте.
Но вопрос: зачем так делать?
Такое нужно только для низкоуровневых системных функций, которые небезопасны по призванию.
Вы сами ответили на свой вопрос. Вы считаете, что на Rust нельзя писать низкоуровневые системные функции? Или вы считаете, что написание низкоуровневых системных функций на Rust не является валидным юзкейсом для обсуждения?
Более того, unsafe нужен не только для "низкоуровневых системных" функций, а для всего, что может выходить за рамки Safe Rust по тем или иным причинам, например, производительности ради -- и это вполне может быть достаточно высокоуровневая логика.
Судя по всему вы просто не понимаете, как используется unsafe в Rust
Пожалуйста, отвечайте по делу. Я понимаю, как используется unsafe в Rust, и я регулярно пишу код на Rust. В своем комментарии я рассмотрел оба варианта применения unsafe в данном контексте, в ответ я получил... несостоятельную критику и переход на личности, мягко говоря.
Статья заангажирована в пользу Rust, что неоднократно отмечается в комментариях. В ней недостаточно конкретики, чтобы утверждать, что устранение пиков связано именно с GC, а не с применением новых алгоритмов и структур данных -- а именно такие оптимизации (пусть и вскользь) упоминаются в ней.
При этом сборщик мусора в Go значительно более примитивен, чем сборщики мусора из коллекции OpenJDK.
а null-ы являются помехой корректности.
Согласен.
Впрочем, могу привести и другие примеры -- D и Nim, другие языки со сборщиками мусора, при этом не страдающие от null'ов.
>либо вообще все обернуть в unsafe -- но в чем тогда смысл unsafe?
Вы отвечаете:
>>но в чем тогда смысл unsafe?
>Смысл в том, что ваша небезопасная реализация с указателями будет изолирована внутри вашего модуля и наружу будет торчать только safe-интерфейс.
Нет. Если все обернуть в unsafe, то наружу будет торчать модификатор unsafe. С тем же успехом можно на С/С++ писать функции, вставляя слово unsafe в название.
Если же вы имеете в виду обертку наподобие
fn foo() {
unsafe { ... }
}
то такая обертка бессмысленна, так как не выделяет действительно небезопасных мест, наоборот, усложняя исследование функции на предмет ошибок при работе с unsafe-операциями.
>Только не забывать, что в случае кольцевых ссылок модет случиться легальная утечка памяти, и за этим надо следить отдельно.
К сожалению, "легальность" утечки памяти ничем не улучшает ситуацию и не облегчает задачу тем, кто будет заниматься отладкой и профилированием программы с целью исправления утечки.
>Ну то есть задача не решается в лоб хранением ссылок, только и всего.
Задача решается либо через умные указатели, привносящие оверхэд, либо через обычные, вынуждающие либо покрывать unsafe каждое разыменование, либо вообще все обернуть в unsafe -- но в чем тогда смысл unsafe?
>Точнее, хранить ссылки можно, если используется куча.
Не совсем так. Хранить ссылки можно, если владение всеми элементами принадлежит кому-то еще, и время их жизни гарантированно превышает время существования списков, где они хранятся. Это сильное требование.
> Когда мне после апгрейда с gcc 6 на gcc 9 потребовалось 2-4 недели вычищать gcc'измы, которые новым компилятором не воспринимались, меня это устраивало
>Когда же поведение кода меняется по-тихому, и это невозможно выяснить на вашей рабочей машине, то это печально.
Так это вас устраивает, или нет? Я спрашиваю, потому что с gcc 6 до gcc 9 было внесено достаточно изменений, молча меняющих поведение кода. Процитирую, например, изменение, внесенное в gcc 8:
>The value of the C++11 alignof operator has been corrected to match C _Alignof (minimum alignment) rather than GNU __alignof__ (preferred alignment); on ia32 targets this means that alignof(double) is now 4 rather than 8. Code that wants the preferred alignment should use __alignof__ instead.
Обе эти цитаты описывают ситуацию, в которой поведение кода меняется по-тихому, просто в одном случае вы зависите от этого поведения, и поэтому это вас больно ударило, а в другом -- нет, и вы этого даже не заметили.
Очевидно, речь про "релиз" (публикацию, если вам угодно -- в интернете "release" используется вполне успешно) С++20. Комментарий набирал в спешке, поэтому несколько раскрою.
Каждый новый стандарт изменяет язык, убирая некоторые его элементы и меняя поведение некоторых остающихся. Каждое такое изменение делает потенциально невозможным перенос кодовой базы на новый стандарт.
С++20 это "мажорный" релиз, в который вошло значительное число как принципиально новых (для языка) фич, так и изменений существующих [1]. Сравните, например, со списком изменений С++17 [2]. В каком-то смысле С++20 можно сравнить с С++11 по масштабу вносимых изменений.
В С++20 было предложено сломать ABI [3] [4]. Хотя комитет отклонил это предложение, у него (предложения) было много сторонников [5] [6]. Это, на мой взгляд, свидетельствует о натуре С++20 -- эта версия стандарта виделась как возможность разом реализовать накопившуюся потребность в изменениях. Реализовать до конца не получилось, но опять же, сравните масштабы С++17 и С++20.
Изменение, сломавшее кодовую базу @0xd34df00d, является побочным эффектом унификации фигурных и круглых скобок в конструкторах. Я регулярно использую try_emplace и emplace_back, и невозможность конструировать объекты так, как я конструировал бы их "руками" сильно раздражала.
И хотя я погорячился с "явно задекларировали", мысль вполне ясна -- С++20 просто обязан был сломать кодовую базу, и странно ожидать обратного.
> я должен его каждый раз пересоздавать
Формально — да. На практике все несколько иначе и зависит от реализации.
А еще для последовательных вычислений и не-функционально-чистых операций используют монады.
Но вообще говоря, если вы испытываете нужду в изменении глобального состояния, при этом используя функциональный стиль, то вы уже делаете все в корне неверно.
Да, я рассматриваю именно такой случай в цитируемом контексте.
Вы сами ответили на свой вопрос. Вы считаете, что на Rust нельзя писать низкоуровневые системные функции? Или вы считаете, что написание низкоуровневых системных функций на Rust не является валидным юзкейсом для обсуждения?
Более того, unsafe нужен не только для "низкоуровневых системных" функций, а для всего, что может выходить за рамки Safe Rust по тем или иным причинам, например, производительности ради -- и это вполне может быть достаточно высокоуровневая логика.
Пожалуйста, отвечайте по делу. Я понимаю, как используется unsafe в Rust, и я регулярно пишу код на Rust. В своем комментарии я рассмотрел оба варианта применения unsafe в данном контексте, в ответ я получил... несостоятельную критику и переход на личности, мягко говоря.
Статья заангажирована в пользу Rust, что неоднократно отмечается в комментариях. В ней недостаточно конкретики, чтобы утверждать, что устранение пиков связано именно с GC, а не с применением новых алгоритмов и структур данных -- а именно такие оптимизации (пусть и вскользь) упоминаются в ней.
При этом сборщик мусора в Go значительно более примитивен, чем сборщики мусора из коллекции OpenJDK.
Согласен.
Впрочем, могу привести и другие примеры -- D и Nim, другие языки со сборщиками мусора, при этом не страдающие от null'ов.
Я пишу:
>либо вообще все обернуть в unsafe -- но в чем тогда смысл unsafe?
Вы отвечаете:
>>но в чем тогда смысл unsafe?
>Смысл в том, что ваша небезопасная реализация с указателями будет изолирована внутри вашего модуля и наружу будет торчать только safe-интерфейс.
Нет. Если все обернуть в unsafe, то наружу будет торчать модификатор
unsafe. С тем же успехом можно на С/С++ писать функции, вставляя слово unsafe в название.Если же вы имеете в виду обертку наподобие
то такая обертка бессмысленна, так как не выделяет действительно небезопасных мест, наоборот, усложняя исследование функции на предмет ошибок при работе с unsafe-операциями.
>Только не забывать, что в случае кольцевых ссылок модет случиться легальная утечка памяти, и за этим надо следить отдельно.
К сожалению, "легальность" утечки памяти ничем не улучшает ситуацию и не облегчает задачу тем, кто будет заниматься отладкой и профилированием программы с целью исправления утечки.
>Ну то есть задача не решается в лоб хранением ссылок, только и всего.
Задача решается либо через умные указатели, привносящие оверхэд, либо через обычные, вынуждающие либо покрывать unsafe каждое разыменование, либо вообще все обернуть в unsafe -- но в чем тогда смысл unsafe?
>Точнее, хранить ссылки можно, если используется куча.
Не совсем так. Хранить ссылки можно, если владение всеми элементами принадлежит кому-то еще, и время их жизни гарантированно превышает время существования списков, где они хранятся. Это сильное требование.
Да. Что-то не так? Go показал, что сборщик мусора и null'ы не являются помехой производительности.
> Когда мне после апгрейда с gcc 6 на gcc 9 потребовалось 2-4 недели вычищать gcc'измы, которые новым компилятором не воспринимались, меня это устраивало
>Когда же поведение кода меняется по-тихому, и это невозможно выяснить на вашей рабочей машине, то это печально.
Так это вас устраивает, или нет? Я спрашиваю, потому что с gcc 6 до gcc 9 было внесено достаточно изменений, молча меняющих поведение кода. Процитирую, например, изменение, внесенное в gcc 8:
>The value of the C++11
alignofoperator has been corrected to match C_Alignof(minimum alignment) rather than GNU__alignof__(preferred alignment); on ia32 targets this means thatalignof(double)is now 4 rather than 8. Code that wants the preferred alignment should use__alignof__instead.Обе эти цитаты описывают ситуацию, в которой поведение кода меняется по-тихому, просто в одном случае вы зависите от этого поведения, и поэтому это вас больно ударило, а в другом -- нет, и вы этого даже не заметили.
Очевидно, речь про "релиз" (публикацию, если вам угодно -- в интернете "release" используется вполне успешно) С++20. Комментарий набирал в спешке, поэтому несколько раскрою.
Каждый новый стандарт изменяет язык, убирая некоторые его элементы и меняя поведение некоторых остающихся. Каждое такое изменение делает потенциально невозможным перенос кодовой базы на новый стандарт.
С++20 это "мажорный" релиз, в который вошло значительное число как принципиально новых (для языка) фич, так и изменений существующих [1]. Сравните, например, со списком изменений С++17 [2]. В каком-то смысле С++20 можно сравнить с С++11 по масштабу вносимых изменений.
В С++20 было предложено сломать ABI [3] [4]. Хотя комитет отклонил это предложение, у него (предложения) было много сторонников [5] [6]. Это, на мой взгляд, свидетельствует о натуре С++20 -- эта версия стандарта виделась как возможность разом реализовать накопившуюся потребность в изменениях. Реализовать до конца не получилось, но опять же, сравните масштабы С++17 и С++20.
Изменение, сломавшее кодовую базу @0xd34df00d, является побочным эффектом унификации фигурных и круглых скобок в конструкторах. Я регулярно использую try_emplace и emplace_back, и невозможность конструировать объекты так, как я конструировал бы их "руками" сильно раздражала.
И хотя я погорячился с "явно задекларировали", мысль вполне ясна -- С++20 просто обязан был сломать кодовую базу, и странно ожидать обратного.
[1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2131r0.html
[2] https://isocpp.org/files/papers/p0636r0.html
[3] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2028r0.pdf
[4] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p1863r1.pdf
[5] https://cor3ntin.github.io/posts/abi/
[6] https://www.youtube.com/watch?v=By7b19YIv8Q
>> ломающую имеющийся код
А что вы хотели от релиза, в котором явно задекларировали решение сломать много и разом? Могли бы и еще больше сломать, жаль, не сломали.
Неужели кто-то обещал вам безболезненную миграцию? Решение о миграции принимали вы сами, решать возможные проблемы должны были быть готовы.
Формально — да. На практике все несколько иначе и зависит от реализации.
А еще для последовательных вычислений и не-функционально-чистых операций используют монады.
Но вообще говоря, если вы испытываете нужду в изменении глобального состояния, при этом используя функциональный стиль, то вы уже делаете все в корне неверно.