Подобный STL диапазон, Что могло пойти не так, как надо, если бы я сделал это?
Я пишу (как осуществление самообразования) простой Подобный STL диапазон. Это - Неизменный произвольный доступ "контейнер". Мой диапазон, сохраняет только его элемент запуска, число элементов и размер шага (различие между двумя последовательными элементами):
struct range
{
...
private:
value_type m_first_element, m_element_count, m_step;
};
Поскольку мой диапазон не содержит элементы, он вычисляет желаемый элемент с помощью следующего:
// In the standards, the operator[]
// should return a const reference.
// Because Range doesn't store its elements
// internally, we return a copy of the value.
value_type operator[](size_type index)
{
return m_first_element + m_step*index;
}
Как Вы видите, я не возвращаю a const reference поскольку в стандартах говорится. Теперь, могу я принимать это a const reference и копия элемента является тем же с точки зрения использования невидоизменяющихся алгоритмов в стандартной библиотеке?
Любой совет о предмете значительно ценится.
@Steve Jessop: Положительная сторона, что Вы упомянули итераторы.
На самом деле я использовал sgi в качестве своей ссылки. В конце той страницы это говорит:
Принимающие X и Y являются итераторами от того же диапазона:
Идентификационные данные инвариантов
x == y if and only if &*x == &*y
Так, это сводится к тому же исходному вопросу, который я задал на самом деле :)
4 ответа
Стандартные алгоритмы на самом деле не используют оператор[], они все определены в терминах итераторов, если только я не забыл что-то значительное. Планируется ли переопределить стандартные алгоритмы поверх оператора оператора[] для ваших "диапазонов", а не итераторов?
Там, где не мутирующие алгоритмы используют итераторы, все они определены в терминах *it, которые могут быть назначены на то, на что они должны быть назначены, или иным образом действительны для какой-нибудь определенной операции или вызова функции. Я думаю, что все или большинство таких операторов подходят по значению.
Единственное, о чем я могу думать, это то, что вы не можете передать значение, в котором ожидается неконстантная ссылка. Есть ли какие-нибудь не мутирующие алгоритмы, требующие неконстантной ссылки? Наверное, нет, при условии, что каких-либо параметров functor и т.д. в них достаточно const.
Извините, я не могу определенно сказать, что не бывает странных углов, которые идут не так, но для меня это звучит в принципе нормально. Даже если есть какие-то нигглы, вы можете исправить их с очень небольшими различиями в требованиях между вашими версиями алгоритмов и стандартными.
Правка: вторая вещь, которая может пойти не так, это принятие указателей/ссылок и их слишком долгое хранение. Насколько я помню, стандартные алгоритмы не сохраняют указатели или ссылки на элементы - причина в том, что именно контейнеры гарантируют валидность указателей на элементы, типы итераторов говорят только тогда, когда итератор остаётся действительным (например, копия входного итератора не обязательно остаётся действительной при инкременте оригинала, в то время как для многопроходных алгоритмов прямые итераторы могут быть скопированы таким образом). Так как алгоритмы не видят контейнеров, а только итераторы, у них нет причин полагать, что элементы являются постоянными.
Хочешь, чтобы твой ассортимент можно было использовать в алгоритмах STL? Не лучше ли использовать первый и последний элементы? (Учитывая тот факт, что end() часто требуется/используется, Вам придется предварительно вычислить его для производительности). Или Вы рассчитываете на сопрягаемые элементы (что является моим вторым пунктом)?
Предметы в контейнерах STL будут скопированы все время скопированы все время; Подумайте, когда вектор должен быть перераспределен, например. Итак, ваш пример в порядке, за исключением того, что он работает только со случайными итераторами. Но я подозреваю, что последний, вероятно, по дизайну. :-P
Так как вы кладете «контейнер» в «цитатах», вы можете делать все, что вы хотите.
Type Type (итераторы, различные функции элементов на контейнерах ..) Возвратные ссылки, потому что ссылки - это Lvalues, и определенные конструкции (т. Е. MyVec [I] = ownless) могут компилировать. Подумайте о операторе [] на STD :: Map. Для Const ссылки, это не значение, чтобы избежать копии, я полагаю.
Это правило нарушено все время, хотя, когда удобно. Также распространено, чтобы классы итератора хранят текущее значение в переменную элемента чисто для возврата ссылки или ссылки Const (да, эта ссылка будет недействительна, если итератор расширен).
Если вы заинтересованы в таком родах, вы должны проверить библиотеку итераторной библиотеки.