CD
А если одинаковые, то как за константу доступ получить?
Поделить на размер блока
Size: a a a
2020 July 22
🎄T
Поделить на размер блока
Так тебе нужно между блоками переходить
m
А если одинаковые, то как за константу доступ получить?
Там массив массивов. Результат деления - индекс в первом массиве, остаток - индекс во втором.
🎄T
Или блоки в одной памяти лежат?
CD
Так тебе нужно между блоками переходить
Нет, у меня vector<unique_ptr<array<T, N>>>
🎄T
Нет, у меня vector<unique_ptr<array<T, N>>>
Понятно, у меня в голове это в виде листа почему-то представлялось
CD
Подскажите контейнер, у которого можно по индексу элемент брать и вставлять в середину быстро(относительно вектора с реалокацией) (кроме дека)
flat_set. deque таким не является, у него вставка как у вектора
CD
Логарифм на обеих операциях, если я понимаю, что это. Константы докручиваются на конкретных задачах только
A
Линейная, потому что размеры блоков посередине не могут быть разные
Хм. Глупость какая-то (я про контейнер, а не про ваше объяснение). Я был лучшего мнения о deque.
CD
Хм. Глупость какая-то (я про контейнер, а не про ваше объяснение). Я был лучшего мнения о deque.
Его задачей является не вставка в середину, а реализация вектора при отказе от ContiniousContainer
CD
Но вы можете попробовать реализовать то же самое с нефиксированными блоками и сказать, зачем это нужно :)
AT
Его задачей является не вставка в середину, а реализация вектора при отказе от ContiniousContainer
*contiguous
IZ
Вот я тоже хотел сказать, что в плане вставки set может быть быстрее. Или ещё попробовать deque.
Они одинаковые по быстроте.
В теории.
В теории.
IZ
AF
Подскажите контейнер, у которого можно по индексу элемент брать и вставлять в середину быстро(относительно вектора с реалокацией) (кроме дека)
rope?
D
https://en.cppreference.com/w/cpp/concepts/same_as
А почему надо писать
Зачем в хелпер надо писать
При этом в
Значит это сделано из-за чего-то, связанного с концептами.
Из-за чего? И как бы это могло поломаться, если бы мы сделали только так?
А почему надо писать
namespace detail {
template< class T, class U >
concept SameHelper = std::is_same_v<T, U>;
}
template< class T, class U >
concept same_as = detail::SameHelper<T, U> && detail::SameHelper<U, T>;Зачем в хелпер надо писать
detail::SameHelper<T, U> && detail::SameHelper<U, T>?При этом в
std::is_same гарантируется эта коммутативность std::is_same<T, U>::value == std::is_same<U, T>::valueЗначит это сделано из-за чего-то, связанного с концептами.
Из-за чего? И как бы это могло поломаться, если бы мы сделали только так?
template< class T, class U >
concept same_as = detail::SameHelper<T, U>;
AF
https://en.cppreference.com/w/cpp/concepts/same_as
А почему надо писать
Зачем в хелпер надо писать
При этом в
Значит это сделано из-за чего-то, связанного с концептами.
Из-за чего? И как бы это могло поломаться, если бы мы сделали только так?
А почему надо писать
namespace detail {
template< class T, class U >
concept SameHelper = std::is_same_v<T, U>;
}
template< class T, class U >
concept same_as = detail::SameHelper<T, U> && detail::SameHelper<U, T>;Зачем в хелпер надо писать
detail::SameHelper<T, U> && detail::SameHelper<U, T>?При этом в
std::is_same гарантируется эта коммутативность std::is_same<T, U>::value == std::is_same<U, T>::valueЗначит это сделано из-за чего-то, связанного с концептами.
Из-за чего? И как бы это могло поломаться, если бы мы сделали только так?
template< class T, class U >
concept same_as = detail::SameHelper<T, U>;
Ну с первого взгляда видно что если кто-то напишет концепт на is_same в другую сторону то это будет ортогональный концепт
D
Ну с первого взгляда видно что если кто-то напишет концепт на is_same в другую сторону то это будет ортогональный концепт
Я не очень понял что ты имеешь в виду
AF
Я не очень понял что ты имеешь в виду
Концепты ранжируются по специфичности и в оверлоад резолюшне выбирается наиболее специфичный
D
Концепты ранжируются по специфичности и в оверлоад резолюшне выбирается наиболее специфичный
Я не очень понимаю как это связано