Ты ходишь в кучу не за всем вектором, там непрерывный кусок памяти. Полезнее для кешей и оптимизации, если память есть, только инвалидация портится.

Списки нужны, если "ой кто-то держит указатель на ноду, может её внезапно удалить из середины"

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

Или я сильно упрощённо смотрю на вещи? (Никогда не приходилось лазить внутрь MMU)

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

у тебя есть строгий критерий, когда вектор будет переаллоцирован, а делает он это только тогда когда size() == capacity(), а list это делает при каждом добавлении. как результат, куча фрагментов в хипе без какой-либо надежды попасть в кеш одновременно

Или я сильно упрощённо смотрю на вещи? (Никогда не приходилось лазить внутрь MMU)

а причем здесь MMU

а причем здесь MMU

оно позволяет тусовать память почти как угодно

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

оно позволяет тусовать память почти как угодно

эээ, нет

это к делу не относится вообще никак

к тому же P-tagged обычно только L1 кэш, остальные через MMU мапятся все равно, разницы для них никакой

вот прям вообще-вообще никогда, даже если постоянно добавлять/удалять в середину?

Лучше тогда деку бзать

итого, vector и подобные выигрывают потому что условно непрерывные и процу проще кешировать эту ботву. Прочие варианты сливают из-за хреновой кешируемости

Дека норм (она изнутри — это набор кусков какой-то длины, так можно с обоих концов кушать и наслаждаться)

Лучше тогда деку бзать

дэка вообще отличная штука

наверное один из лучших стандартных контейнеров

+ проблемы с aliasing reasoning у оптимизаора из-за кучи указателей

это когда "память" пересекается? или наоборот не пересекается? ну всмысле эвристики этого процесса?

итого, vector и подобные выигрывают потому что условно непрерывные и процу проще кешировать эту ботву. Прочие варианты сливают из-за хреновой кешируемости

Не только проц: коду приходится на обращение к каждому элемнту подряд делать больше операций

итого, vector и подобные выигрывают потому что условно непрерывные и процу проще кешировать эту ботву. Прочие варианты сливают из-за хреновой кешируемости

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

Не только проц: коду приходится на обращение к каждому элемнту подряд делать больше операций

это мелочи по сравнению с хождением по куче

в общем, чем плюсы хороши - ты можешь выбрать то, что тебе нужно под твои задачи, а не пользоваться общим чем-то, что плохо везде

вроде на русише где-то валялось (если я не путаю)

ага, поэтому я не пользуюсь никакими контейнерами

безконтрольно ходят в кучу

Ну у листа вон можно вставлять в середину без инвалидации указателей/итераторов

и удаление, более того, когда у тебя есть вероятность частых реллокаций вектора, то тоже лучше лист.

вроде на русише где-то валялось (если я не путаю)

по-моему ещё не успели перевести, даже нормальных электронных версий на английском толком нет - только вот эта дичь на 2600 "страниц"

Что за чат с книгами?

это я создал как костыль, пока мы бота книжного не допишем: https://t.me/joinchat/AAAAAE1yUq2Kh6WdPCtjMA

по-моему ещё не успели перевести, даже нормальных электронных версий на английском толком нет - только вот эта дичь на 2600 "страниц"

а, видимо, тут первое издание только на русише валяется

имхо логично, какой на выходе ты тип хочешь получить — не ясно же

ну мб, какой-н. типа std::common_type<T1, T2>::type (вроде не ошибся с этой хренью)

это я создал как костыль, пока мы бота книжного не допишем: https://t.me/joinchat/AAAAAE1yUq2Kh6WdPCtjMA

ему бы кстати не помешали нормальные названия) а не 1kh_yuz_k_kh_yuz_t_parallel_noe_.pdf

Как тип, который вмещает в себя int и double

в шаблонах такое приведение не работает же, емнип. У тебя сигнатура четкая: Т max(Т, Т)

ну мб, какой-н. типа std::common_type<T1, T2>::type (вроде не ошибся с этой хренью)

Да не очень очевидно

Там неочевидный <

в шаблонах такое приведение не работает же, емнип. У тебя сигнатура четкая: Т max(Т, Т)

Вот и давайте сделаем T1, T2 и вернем auto.

Вот и давайте сделаем T1, T2 и вернем auto.

T1<T2?

бгг

T1<T2?

Например, да

Тут уже были дискуссии насчёт обощенного оператора сравнения для контейнеров например

И вроде это дикая дрисьня

Явное лучше неявного в данном случае точно

а можно легкий оффтоп: сколько сейчас примерно медианная зарплата с++ сениора в Москве?

это очень депендс, кмк

Короче лучше ваще никогда не определять порядок разных типов

Явное лучше неявного в данном случае точно

во всех случаях.

А макс задаёт порядок

ага, поэтому я не пользуюсь никакими контейнерами

разумно, лучше навелосипедить

лолшто?

ему бы кстати не помешали нормальные названия) а не 1kh_yuz_k_kh_yuz_t_parallel_noe_.pdf

это я вчера с тврпикса скачал; долго рыскал в инете, только там нашел

Разумно только в одном случае - когда твой контейнер узко заточен и оптимизирован под твой тип данных

а можно легкий оффтоп: сколько сейчас примерно медианная зарплата с++ сениора в Москве?

думаю, в жобс-фладе можно обсудить: https://t.me/joinchat/BYlFbEPe5gMPVQm3OwKjaA

Короче лучше ваще никогда не определять порядок разных типов

Ты уже второй раз пишешь "лучше". Это субъективная оценка. Приведи пример, когда это что-то ломает.

Разумно только в одном случае - когда твой контейнер узко заточен и оптимизирован под твой тип данных

You must be new here....

Ты уже второй раз пишешь "лучше". Это субъективная оценка. Приведи пример, когда это что-то ломает.

Приведи пример когда это обосновано

Приведи пример когда это обосновано

Я хочу узнать что больше 2.5 или 3.

Я хочу узнать что больше 2.5 или 3.

Это частный случай, возьми пользовательские типы пж

Абстрактные

You must be new here....

да.

Я хочу узнать что больше 2.5 или 3.

ну так и узнай: 2.5 и 3.0

Я говорю что порядок разных типов не имеет смысла

Я хочу узнать что больше 2.5 или 3.

а я хочу узнать что больше 2.5 + 2.1i или 2.5(1)

да.

учись велосипедить тогда, иначе не выживешь

а я хочу узнать что больше 2.5 + 2.1i или 2.5(1)

Здесь операция не определена математически, для моего случая определена.

Здесь операция не определена математически, для моего случая определена.

Она не определена например в поле целых чисел, потомучто второй аргумент не входит в него

Запись 3<5.0 я бы тоже запретил на самом деле

Ладно, я не увидел аргументов. Думаю, что дискутировать дальше нет смысла.

Аргумент - страдает банально читаемость и предсказуемость результата

В каком случае ? Можно кусочек кода ?

a::operator<(b) b::operator<(a) Могут быть определены ваще по разному семантически

Что вернёт Макс?

а про чо вы тут спорите?

Хотя это противоречивость порядка

Хз ваще как аргументировать то что порядок в общем случае неопределен

а про чо вы тут спорите?

Про недостатки вот такой функции: template<typename T1, typename T2> auto max(T1 first, T2 second);

Про недостатки вот такой функции: template<typename T1, typename T2> auto max(T1 first, T2 second);

ну да, так себе функция

Её обмазать нужно коньтрактами, ИМХО.

Её обмазать нужно коньтрактами, ИМХО.

ага, как раз собирался сказать

Ее можно определить ну там для арифметических типов

Ее можно определить ну там для арифметических типов

А ещё для всевозможных строк

Для всевозможных нельзя как раз