AT
А почему он не будет работать с Bidirectional?
Будет, но неоптимально
Size: a a a
2020 March 08
AT
Хотя, если версия для forward/bidirectional использует advance и он диспатчится не по категории, а по наличию оператора operator + (difference_type), то проблемы нет
NP
Будет, но неоптимально
Да, кажется тут в дизайне STL допущен косяк - фактически попытка ввести свою категорию итераторов бессмысленна, поскольку перегрузить алгоритмы STL для нее нельзя
FS
Да, кажется тут в дизайне STL допущен косяк - фактически попытка ввести свою категорию итераторов бессмысленна, поскольку перегрузить алгоритмы STL для нее нельзя
ну простите, что есть — то есть. boost::iterator_facade в помощь.
AP
Да, кажется тут в дизайне STL допущен косяк - фактически попытка ввести свою категорию итераторов бессмысленна, поскольку перегрузить алгоритмы STL для нее нельзя
Посмотрите как там с этим дело в ranges обстоит
Но кажется что проблема только стала глубже, сову придётся натягивать на больший глобус
Но кажется что проблема только стала глубже, сову придётся натягивать на больший глобус
FS
В стандартной библиотеке проблем столько, что целого мира мало их обсуждать.
AT
Эта - фундаментальная)
FS
Если вы так считаете — донесите это до комитета.
FS
Я не троллю, если что.
NP
Если вы так считаете — донесите это до комитета.
Думается мне, что у этой проблемы решения придумать не получится, поскольку даже если и разрешить перегружать алгоритмы STL для итераторов, то неясно как это делать портабельно - в каких то реализациях может использоваться перегрузка функций по тэгу итератора, в каких то enable_if опять же по тегу
AT
Если вы так считаете — донесите это до комитета.
Это практически невозможно. Слишком много трудозатрат. Только как непосредственные служебные обязанности.
FS
Думается мне, что у этой проблемы решения придумать не получится, поскольку даже если и разрешить перегружать алгоритмы STL для итераторов, то неясно как это делать портабельно - в каких то реализациях может использоваться перегрузка функций по тэгу итератора, в каких то enable_if опять же по тегу
По поводу перегрузки ниблоиды же есть.
FS
Это практически невозможно. Слишком много трудозатрат. Только как непосредственные служебные обязанности.
Скажем так: дорогу осилит идущий. Если вам это действительно надо — донесёте.
AT
Думается мне, что у этой проблемы решения придумать не получится, поскольку даже если и разрешить перегружать алгоритмы STL для итераторов, то неясно как это делать портабельно - в каких то реализациях может использоваться перегрузка функций по тэгу итератора, в каких то enable_if опять же по тегу
Можно добавить катигорию ModularIterator между (Legacy) Bidirectionalterator и RandomAccessIterator, которая будет отличаться от последней отсутствием требования ordering relation
NP
По поводу перегрузки ниблоиды же есть.
Как они тут могут помочь? Речь же не о том как вызвать функцию которая объявлена неизвестно где, а о том, как такую функцию перегрузить правильно, не глядя на реальную имплементацию
AT
Скажем так: дорогу осилит идущий. Если вам это действительно надо — донесёте.
"Действительно надо"? Я не в мире победившего коммунизма живу, чтобы "для души" чем-то всерьёз можно было бы заниматься на постоянной основе
FS
Как они тут могут помочь? Речь же не о том как вызвать функцию которая объявлена неизвестно где, а о том, как такую функцию перегрузить правильно, не глядя на реальную имплементацию
ниблоиды как раз об этом
DS
При чём здесь буст? Есть иерархия категорий в стандартной библиотеке. Я хочу заюзать свой адаптер контейнера - кольцевой буффер - в алгоритмах. Мне надо ему категорию задать, иначе нельзя. Какую? Это вопрос.
А контроля заполненности буфера нет? Почему итераторы не сравнимы?
AT
А контроля заполненности буфера нет? Почему итераторы не сравнимы?
Потому что "по модулю")
FS
"Действительно надо"? Я не в мире победившего коммунизма живу, чтобы "для души" чем-то всерьёз можно было бы заниматься на постоянной основе
причём тут коммунизм? я просто намекаю на то, что если кого-то что-то не устраивает, то этот кто-то может запилить пропозал. Вот и всё.