Здравствуйте, _smit, Вы писали:

_>"равно" появилось именно после тестов.

Ну ок. Да, <= в lower_bound можно оставить. Просто нужно обязательно помнить, что этот предикат задаёт лишь разбиение, но не strict weak ordering. То есть, если его подставить в очень похожие алгоритмы вроде std::equal_range, или std::binary_search, или как параметр std::map/set, то это приведёт к UB. Из-за таких потенциальных, но довольно вероятных проблем я бы поостерёгся так писать.

_>Например если фрагмент нулевой длины, то at(0) укажет на нулевой номер фрагмента,
Хм... А зачем тебе вообще нужно хранить фрагменты нулевой длины в этом алгоритме?
Кажется, куда лучше будет просто отфильтровать их заранее. Если же у тебя с пустыми фрагментами связана какая-то дополнительная информация, которую нельзя потерять, то всё равно стоит подумать как бы передать в конкретно эту структуру данных лишь срез исходного массива.
Но, если есть желание, то такую фигню можно обойти через upper_bound — 1, либо, что чуть лучше, изменив компаратор на такой, который ещё и вернёт true при попытке сравнения с фрагментом нулевой длины даже при совпадении начала (разумеется, не сломав при этом требования упорядоченности). Ну либо, да, оставить как есть.

_>то же самое будет, если фрагмент имеет длину n, на запрос at(n) вернется не следующий, а текущий номер фрагмента.
Что?
Например, если у тебя файл состоит из трёх фрагментов длиной соответственно n, m и k. То в массиве m_index_list будет три элемента: {0, n, m + n}. Разумеется, lower_bound от n вернёт итератор на средний элемент массива, то есть как раз на фрагмент длиной m, который и содержит в себе все байты с индексами от n до n + m — 1 включительно. Всё как надо.