m
Точно так же можно туда засандалить is_partial detection. Чтобы const снять с итераторов.
Что-то в этом есть.
Size: a a a
2020 October 20
DS
хм. Спасибо. Надо будет еще раз посмотреть как это работает.
Это очччень полезная штука, например поиск по string_view когда ключ string и т.п. Я их вообще затайпдефил сразу, transparent_map/transparent_set.
DS
Нужен proposal в 23.
DS
Comparator::is_partial как признак non-const для set::iterator.
DS
Кстати, интересно чокак с transparent Equal/Hash?
SS
Кстати, интересно чокак с transparent Equal/Hash?
вроде в 20 появились
ПК
Extract это потенциально перебалансировка. Последующая вставка это logn + опять потенциально перебалансировка. Вообще избыточна эта const'овость итераторов на мой взгляд. Всё равно есть много способов отстрелить ногу :) нетранзитивный компаратор, mutable, сравнение через указатели...
это гораздо сложнее, чем на ровном месте инты поменять в
std::set<int>DS
это гораздо сложнее, чем на ровном месте инты поменять в
std::set<int>Это ровно то же самое, просто за вычетом allocate/deallocate.
ПК
Это ровно то же самое, просто за вычетом allocate/deallocate.
нет, это проще
DS
нет, это проще
Ну условно erase это extract + drop node. Insert это create node/find insert point/insert/rebalance. Убираются только drop/create node.
ПК
Ну условно erase это extract + drop node. Insert это create node/find insert point/insert/rebalance. Убираются только drop/create node.
А, я про неконстантный итератор имел ввиду
DS
А, я про неконстантный итератор имел ввиду
Ну я ж говорю, согласен, пусть будет const, шикарный вариант это протащить условно мутабельность через трейты компаратора.
DS
Нода частично мутабельна если она является ключом лишь частично. В этом случае set почти наверняка будет использовать transparent компаратор (ибо зачем для поиска создавать полную ноду?). Если при этом компаратор заодно разрешит мутабельность ноды, нехай стреляют же, дело личное.
O
Понадобилась реализация
Будет ли корректной следующая замена или я что-то важное упускаю?
is_nothrow_invocable_r для C++11, за основу для реализации взял этот C++20 пример, но столкнулся при реализации с проблемой:struct bar { bar(int) noexcept; };
static_assert(noexcept(std::declval<void(&)(bar) noexcept>()(42)), "");
В C++17 проверка ожидаемо проходит, а в C++14 — нет. Что-то поменялось в стандарте на этот счёт? (Думаю, что это "The noexcept-specification is a part of the function type and may appear as part of any function declarator (since C++17)")Будет ли корректной следующая замена или я что-то важное упускаю?
static_assert(noexcept(static_cast<To>(std::declval<From>())), "");
NV
Статья, имхо, не очень, я в неё очень долго въезжал, в итоге нашёл статью в каком-то блоге на англ и только тогда стало яснее
))) ок, поделитесь тогда, не будет лишним ещё одно мнение узнать
АК
Понадобилась реализация
Будет ли корректной следующая замена или я что-то важное упускаю?
is_nothrow_invocable_r для C++11, за основу для реализации взял этот C++20 пример, но столкнулся при реализации с проблемой:struct bar { bar(int) noexcept; };
static_assert(noexcept(std::declval<void(&)(bar) noexcept>()(42)), "");
В C++17 проверка ожидаемо проходит, а в C++14 — нет. Что-то поменялось в стандарте на этот счёт? (Думаю, что это "The noexcept-specification is a part of the function type and may appear as part of any function declarator (since C++17)")Будет ли корректной следующая замена или я что-то важное упускаю?
static_assert(noexcept(static_cast<To>(std::declval<From>())), "");
До C++17 noexcept не входил в сигнатуру функции. Поэтому по сигнатуре не узнать, является ли функция noexcept
АК
Вот по выражению можно узнать -
noexcept(foo(1, 2, 3)). Так что замена выглядит корректнойO
Вот по выражению можно узнать -
noexcept(foo(1, 2, 3)). Так что замена выглядит корректнойВо всех найденных мной реализация использованы более сложные синтаксические конструкции, чем
static_cast. Полагаю, это как-то связано с формулировкой стандарта:The predicate condition for a template specialization is_convertible<From, To> shall be satisfied if and only if the return expression in the following code would be well-formed, including any implicit conversions to the return type of the function:
To test() {
return declval<From>();
}
Но я, тем не менее не знаю, в чём принципиальное отличие этой функции от static_cast<To>(declval<From>()). На ум приходят какие-то мысли об RVO или поведении деструктора, но, кажется, мне не хватает пониманияDC