Целились в C++, а попали в Аду?

Начнем с того, что никакого оскорбления не имело места быть. Если не согласен, можешь призвать хоть всех модераторов ЛОР, авось вместе углядите (правда, я сомневаюсь в этом). А закончим тем, что заявление будто

главная политика Rust - using of unsafe is highly discouraged. В идеале в user-коде unsafe быть не должно. Разработчики и проталкиватели языка настолько на этом помешаны, что на полном серьёзе предлагают писать списки на массивах.

выглядит как идиоматичный бред «плюсовика» в адрес Раст, далекий от действительности. Но лично мне опровергать этот бред лень, я не разраб и не «проталкиватель», поэтому - ОК, так им и надо, этим лицемерам разрабам и проталкивателям за вранье, лихо ты их на чистую воду вывел 😊.

Про скорость: вот, например, проверенный и уважаемый даже некоторыми сишниками человек, точно не «растоман» пишет https://isocpp.org/blog/2014/06/stroustrup-lists (10 лет назад и кеши с тех пор только выросли), и он же про то что сырые указатели надо прятать в умных указателях и контейнерах - https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#S-resource; ну и если логически подумать то пихать в прикладной алгоритм указатели и прочие goto ( а указатель по сути тот же goto только для данных) такая себе затея cve.org и Дейкстра не дадут соврать, и человекам такое тяжело читать понимать и компиляторы не могут полноценно оптимизировать

А теперь перечтите его первую статью еще раз:

My point is not about lists as such. They have their uses, but this example isn’t one of them. Please don’t confuse the example with what the example is used to illustrate.

My suggestion is:

• don’t store data unnecessarily,
• keep data compact, and
• access memory in a predictable manner.

Он говорит про то, что существуют кейсы, когда vector работает лучше, чем list. И не только из-за cache miss. Он предлагает использовать векторы там, где они будут работать лучше. Выше по треду я привел пример, когда векторы являются самым худшим вариантом из возможных. Потому что

• скорость доступа к конкретному элементу в многопоточной обработке не важна - мы уже имеем указатель на объект в треде - аргумент cache miss тут не канает
• Добавление элемента в вектор (внезапно) может сломать поинтеры на объекты во всех тредах из-за реаллокации. А в случае unmutable vector - здравствуй Java и твоё потребление в 72 ГБ при обработке набора данных в 256 метров, давно не виделись.

Список в таком случае выигрывает целиком и полностью.

Я не спорю, что у списка есть свои недостатки (например если голова не имеет указателя на конец - то вставка в конец будет O(n)). Но кричать что векторы всегда могут заменить списки и списки устарели не стоит, это не так.

Как и пишет труп страуса - есть contiguous данные, есть linked и скидывать всё под одну гребенку нет смысла.

| Какой-то универский препод написал систему опакечивания alire, что-то типа Cargo

вот именно, намного доступнее стала: компилятор, плагин в вскоде 0_0, поддержка stm32 с каких пор интересно

| Просто сделай опрос тут на ЛОР

Ох, концентрация эдиков и айронбагов тут великовата (

Ох, концентрация эдиков и айронбагов

Эти и против Раста, и против Ады, так что ортогонально :)

но в итоге то:

| And, yes, my recomendation is to use std::vector by default. More generally, use a |contiguous representation unless there is a good reason not to. Like C, C++ is designed |to do that by default.

|Выше по треду я привел пример, когда векторы являются самым худшим |вариантом из возможных.

без большего контекста о задаче, похоже что хэшмап лучше всего подойдёт- если часто надо вставлять удалять- самое то, и многопоточности это никак не мешает; и в общем, прямо вот на одномерном векторе никто и не зацикливается, у нас ещё дохрена вариантов: вектор векторов или векдеков или хэшмапов или наоборот, что больше подойдет под задачу. И вот только после тщательных измерений, если каким-то чудом это всё не подойдёт, мы делаем специализированный контейнер возможно и с тщательно проверенными указателями внутри и с безопасными торчащими наружу индексами.

|Список в таком случае выигрывает целиком и полностью.

неа, реально мерять надо

отсутствие альтернативных реализаций компилятора

gccrs доступен. С остальным согласен.

Какой-то универский препод написал систему опакечивания alire, что-то типа Cargo.

Вот именно этот каргокультизм сам отомрет, т.к. в общем и целом ненужно, кроме «быстрого прототипирования». Прибивание языков к «покетманагерам» уже приводит к забавным пока казусам. Напоминающим времена расцвета... RAD-сред с покетами, кроме юзания которых большинство их юзавших не могло ничего, особенно когда покеты содержат не забавные предположения и роняют приложение целиком вместо правильных поправок к неправильно вычисленным индексам, в которые авторы покета не смогли, пытаясь быть слишком универсальными и каждый раз выполнять вычисления значений, которые... не меняются. Например, в некоторых проектах это приводит к необходимости содержать свой репозиторий покетов, с патчами, которые в общем, элементарны, но... авторами покетов даже не имеются в виду «следите за релизами» (и кто им доктор?). Но зачем... если можно просто не юзать глючные покеты, и подключать библиотеки напрямую, как ада могла задолго до этих заигрываний со своими хипстерскими подражателями, делающими вид, что до них ничего не было (особенно радует toml — «зумеры изобрели ini-файлы»). Например в «ответственных применениях»(ТМ), которым ядро линукса, с добавлением в которое носятся как курица с яйцом, само по себе не является. А вот отсутствие стандарта еще долго будет препятствием для. Просто после обработки комитетом, «болельщики» обнаружат, что множество «фич», к которым они привыкли, окажутся за рамками стандарта, как явно опасные, «нестабильные» и «не рекомендуемые в текущей имплементации». А на «стандартном» языке, обложенном ограничениями на фичи, создать что-то путное смогут не только лишь все.

кто знает Раст и кто Аду (но не просто хелло-ворлд, а на уровне всё, что хочу реализовать - реализую, с минимальной гуглёжкой. Ну или посмотри на количество вопросов на SO. Для раста гораздо

проще найти помощь.

Само это неравенство условий забавляет весьма. Для Ады значит «минимальный гуглеж», а для раста — помощь зала и SO.

Адакопец? Хотя она и без Rust’а себя НЕ ОЧЕНЬ хорошо чувствовала. В РФ так вообще вакансий по Аде я с 2015 года не видел.

А давно ты авионику писал по DO178? В применениях ады собственно языка программирования изначально недостаточно, надо «домен специфик» знаниями свободно оперировать, а не только «холодными закусками».

Для Ады значит «минимальный гуглеж», а для раста — помощь зала и SO.

я такого не писал, наоборот, при прочих равных для раста проще получить помощь. Хотя тут тоже не всё так однородно. Так, например, ответы на вопросы о Аде, которые я видел на SO, были от очень узкого круга людей, но абсолютно все по делу и большая часть исчерпывающие. Сильно не уверен, что такие же ответы могут написать все пользователи Раста.

https://isocpp.org/blog/2014/06/stroustrup-lists

Вот с этого поржал конечно. В первом же предложении Страуструп пишет что школьники из Интернета обвинили его в незнании структур данных.

Посыл в том, что вакансии висят, но они про какое-нибудь авиастроение и Ады в тексте может не быть? Берут какого-нибудь физика на завод и заставляют Аду учить, так?

Как без nightly не тянуть его? Пишут что невозможно.

no_std давно в стейбле.

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

Если тебе интересно что-то узнать, а не накидывать на вентилятор, то почитай про редакции. Старый код никто не ломает (кроме крайне редких случаев когда исправляется баг) и постоянно обновлять/переписывать его не надо.