IL
ну он дополнительный проход делает, этого вроде как хочется избежать
Size: a a a
2020 July 15
IL
не говоря о том, что требует больше
AT
ranges::set_union(ranges::unique(first), ranges::unique(second))или
ranges::unique(ranges::set_union(first, second))O
inspect proposal? :)
Я искренне надеюсь, что он будет разбит на несколько более вразумительных частей по-меньше, ко второй половине пропозала уже выглядит инопланетно и нечитаемо, я бы предпочёл иметь только библиотечный паттерн-матчинг, чем такой языковой
CD
который из двух?
Оба. Почему в нём повторящиеся элементы разные, а на выходе операции их должны сократить? Вы хотите сделать set_union(unique(arg1), unique(arg2)), но почему это вообще должно записываться одной операцией
AT
ranges::set_union(ranges::unique(first), ranges::unique(second))или
ranges::unique(ranges::set_union(first, second))пока мне рано такое)
AT
Оба. Почему в нём повторящиеся элементы разные, а на выходе операции их должны сократить? Вы хотите сделать set_union(unique(arg1), unique(arg2)), но почему это вообще должно записываться одной операцией
потому что это можно. И это можно сделать за меньшее количество операций и память, чем
merge+unique или set_union+uniqueCD
потому что это можно. И это можно сделать за меньшее количество операций и память, чем
merge+unique или set_union+uniqueа еще меньше памяти займет их не хранить сразу :)
CD
в любом случае, задача должна решаться фильтром на итераторах перед вызовов set_union
CD
таких фильтров до ranges я не знаю
AT
нет, ну серьёзно. Аргумент про что-то там семантическое неверное — несостоятелен совершенно (по крайней мере в любом контексте). Можно сделать оптимальнее — да. Нет оптимального алгоритма в стандартной библиотеке — да.
CD
нет, ну серьёзно. Аргумент про что-то там семантическое неверное — несостоятелен совершенно (по крайней мере в любом контексте). Можно сделать оптимальнее — да. Нет оптимального алгоритма в стандартной библиотеке — да.
почему? с тем же успехом в C++ gc нет
AT
и симуляции реального мира в C++ тоже нет. Увы
CD
и нельзя без промежуточной переменной float как int прочитать
RR
Анатолий, а списки предварительно каким образом упорядочились? С большой вероятностью даже мердж+юник не будет узким местом
RR
Или у вас чисто спортивный интерес?
CD
там небось input iterator вообще на входе
🎄T
в
operator++ инкрементировать нижележащий итератор, пока не найдётся отличный от текущего элемент или endМне почему-то казалось, что это есть в рэнжах
IL
да, писать свой
view::unique не нужно, если под рукой есть уже написанный, это вроде как очевидноCD
но да, компрессить sort+unique намного логичнее, чем set_union+unique+unique