История изменений

Где логика?

А она вам нужна? Тогда попробуйте мысленно поставить смайлик в исходном сообщении. Согласен, выглядит как-то так.

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

Структуры же данных должны выбираться по задаче и целевой платформе. Работаете в каком-то baremetal с выключенным кешем по данным или с областью памяти, которая через MMU отмечена как uncached (часто всяким DSP такую отдают), то и запары с промахами нет, а если память ещё и сильно фрагментирована (хотя, обычно, где это критично, использование памяти достаточно детерминировано и её вообще можно сразу порезать), то связный список или дек тут то, что дохтур прописал - распихать ноды (или чанки) по свободным кусочкам памяти. Вернулись на PC, то уже как бы и повнимательнее нужно быть. В любом случае, лично я, сначала буду использовать решения из стандартной библиотеки, не устраивает - популярной сторонней, снова не устраивает - ну тогда может в компании есть какие-то наработки, и опять мимо - что делать, буду писать сам. А ещё - пользоваться профилировщиком и исправлять только те месте, где действительно есть просадки по проивзодительности.

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

Вообще, если в хлебоносном для меня ЦПП мысленно ввести понятия safe/unsafe, львиная доля существующего кода окажется именно во второй секции, ведь даже, казалось бы, ссылки, призванные защититься от ошибок с указателями, внезапно и ненавязчиво могут оказаться висячими. То, с чем в C++ пытаются бороться хорошими практиками, в Rust делают средствами компилятора и явно определяют границы дозволенности. Вот только, что C, что C++ пытаются быть везде и им это, так или иначе, удаётся как раз благодаря некоторым обтекаемым формулировкам в стандарте. Меня бы ввело в замешательство, то, что на платформе, где байт 10 бит имя типа u8 уже не отражает своего содержимого (лет 12 назад с подобной платформой столкнулся).

Плюс сложные вещи, типа OS, будут требовать использования unsafe (да что OS: coreutils, util-linux /хотя тут всё достаточно гладко/), а тут уже спрятаться проблемам будет проще (можно ещё перебрать этот список на предмет использования unsafe, но у меня столько времени нет).

Резюмируя: не в списке дело, а unsafe не так редко нужен, как хотелось бы и писать г-но можно на любом ЯП.

Ну... теперь, надеюсь, логики добавилось :)

Где логика?

А она вам нужна? Тогда попробуйте мысленно поставить смайлик в исходном сообщении. Согласен, выглядит как-то так.

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

Структуры же данных должны выбираться по задаче и целевой платформе. Работаете в каком-то baremetal с выключенным кешем по данным или с областью памяти, которая через MMU отмечена как uncached (часто всяким DSP такую отдают), то и запары с промахами нет, а если память ещё и сильно фрагментирована (хотя, обычно, где это критично, использование памяти достаточно детерминировано и её вообще можно сразу порезать), то связный список или дек тут то, что дохтур прописал - распихать ноды (или чанки) по свободным кусочкам памяти. Вернулись на PC, то уже как бы и повнимательнее нужно быть. В любом случае, лично я, сначала буду использовать решения из стандартной библиотеки, не устраивает - популярной сторонней, снова не устраивает - ну тогда может в компании есть какие-то наработки, и опять мимо - что делать, буду писать сам. А ещё - пользоваться профилировщиком и исправлять только те месте, где действительно есть просадки по проивзодительности.

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

Вообще, если в хлебоносном для меня ЦПП мысленно ввести понятия safe/unsafe, львиная доля существующего кода окажется именно во второй секции, ведь даже, казалось бы, ссылки, призванные защититься от ошибок с указателями, внезапно и ненавязчиво могут оказаться висячими. То, с чем в C++ пытаются бороться хорошими практиками, в Rust делают средствами компилятора и явно определяют границы дозволенности. Вот только, что C, что C++ пытаются быть везде и им это, так или иначе, удаётся как раз благодаря некоторым обтекаемым формулировкам в стандарте. Меня бы ввело в замешательство, то, что на платформе, где байт 10 бит имя типа u8 уже не отражает своего содержимого (лет 12 назад с подобной платформой столкнулся).

Плюс сложные вещи, типа OS, будут требовать использования unsafe (да что OS: coreutils, util-linux /хотя тут всё достаточно гладко/), а тут уже спрятаться проблемам будет проще (можно ещё перебрать этот список на предмет использования unsafe, но у меня столько времени нет).

Резюмируя: не в списке дело, а unsafe не так редко нужен, как хотелось бы и писать г-но можно на любом ЯП.

Ну... теперь, надеюсь, логики добавилось :)