DS
Ну если у тебя зазор в половину диапазона есть, можно так
Ну относительно размерности size type я думаю это достаточно большой зазор.
Size: a a a
2020 March 09
CD
Ну относительно размерности size type я думаю это достаточно большой зазор.
А, можно в кольцевом буфере базу считать, да
ПК
Это ясно, что может. Я ж объяснил про трудозатраты и необходимость на жизнь зарабатывать. Как я объясню траты денег из семейного бюджета на поездки на конференцию где нужно защищать?
На заседание комитета за вас Яндекс поедет и защищать ваш пропозал будет
AT
Кстати с учётом 2 complement переполнения можно ордеринг сделать по знаку разницы, положительная, отрицательная, нулевая.
Если я хочу сделать так:
circular<int> c{3, 1, 2, 4, 5}; std::sort(std::begin(c), std::next(std::begin(c), c.size()));, то std::begin(c) == std::next(std::begin(c), c.size()), т.к. указывают на один и тот же элемент, и, при этом, std::begin(c) < std::next(std::begin(c), c.size()), т.к. в операторе < сравниваются эти хитрые индексы (не по модулю). Strict total ordering не выполняется.AT
Поэтому мне кажется, что нужна категория между BidirectionalIterator и RandomAccessIterator, без требования на сравнимость оператором <
АР
типа для bucket list'ов всяких?
AT
типа для bucket list'ов всяких?
не знаю. Мне надо просто, чтобы работать с отрезком в контейнере фиксированного размера, постоянно сдвигаясь вперёд (без ограничений)
DS
Если я хочу сделать так:
circular<int> c{3, 1, 2, 4, 5}; std::sort(std::begin(c), std::next(std::begin(c), c.size()));, то std::begin(c) == std::next(std::begin(c), c.size()), т.к. указывают на один и тот же элемент, и, при этом, std::begin(c) < std::next(std::begin(c), c.size()), т.к. в операторе < сравниваются эти хитрые индексы (не по модулю). Strict total ordering не выполняется.Я бы делал размер буфера параметром шаблона вообще чтобы оптимизировать индексацию по модулю для степеней двойки например. Здесь begin это index 0, end это 5, не понимаю почему один и тот же элемент.
AT
потому что 5 % 5 == 0
AT
допустим итератор будет хранить итератор контейнера
it и оператор == может быть устроен так template<typename T, typename Container> bool circular<T, Container>::iterator::operator == (iterator other) const { return it == other.it; }DS
потому что 5 % 5 == 0
Если подразумевается что размер буфера 5 и 5 это индекс end, то 5%5 будет выполняться только при разыменовывании end, что в любом контейнере ub.
AT
а в этом не ub)
AT
в этом нет не-dereferenceable и при этом valid итераторов
DS
а в этом не ub)
Это кольцевой буфер без контроля переполнения?
AT
можно рассматривать для простоты кольцевой буффер (адаптер) над контейнером фиксированного размера (не обязательно типа
std::array, но append insert push_fornt/back etc нельзя вызывать у underlying контейнера)AT
ну или считать, что любой resize ведёт к тому, что все итераторы, полученные для кольцевого буффера до resize-а, становятся невалидными
AT
допустим итератор будет хранить итератор контейнера
it и оператор == может быть устроен так template<typename T, typename Container> bool circular<T, Container>::iterator::operator == (iterator other) const { return it == other.it; }здесь it всегда dereferenceable, т.к. все инкременты/декременты — "по модулю"
AT
По такому контейнеру можно проитерироваться полностью не зная его размер?
я думал, что так можно:
auto beg = c.begin(), it = beg; assert(!c.empty()); do { f(it); } while (++it != beg);