Как стать автором
Обновить

Комментарии 35

НЛО прилетело и опубликовало эту надпись здесь
Большой минус в плане удобства — проблемы с приоритетами таких операторов на макросах.
Насколько я понимаю, можно просто вместо оператора умножения брать за основу любой другой бинарный оператор, приоритет которого нужно унаследовать.
читая подобные статьи становишься фанатом C++…
хотя, кому я вру, не становишься, а болезнь еще сильнее начинает прогрессировать
Подброшу в тему полезную ссылку из недавнего — изящную реализацию any_of без злых макросов, но с шаблонной магией
Да вы правы, спасибо, поправил.
имхо, фо фан это круто и все такое, но увидеть подобный код в продакшене я бы не хотел …
Круто! Я бы не стал делать макрос, а оставил бы вариант *in*:
if (auto res = "true" *in* some_map)

Для этого придётся сделать глобальную переменную in, зато она уже нормально включается в namespace. Понятно, что сама она состояние хранить не сможет, нужно на первом умножении создавать временное значение и хранить ключ там.

Да, именно так, только вместо *|, используется — так.

Т.е. это не обобщенное решение, а надо писать перегрузку для каждого существующего контейнера?
Да, но в ссылке на github можно найти готовую реализацию для некоторых контейнеров (unordered_map, unordered_set, map, set, vector, string)
Почему бы не использовать std::optional или boost::optional
он имеет каст к bool. преследует как раз safe bool idiome и нужен как раз для таких случаев

godbolt.org/g/Bz35nQ
Конечно можно, в статье это просто пример, возвращать можно в принципе что угодно. Спасибо за совет.
В данной статье in используется не для итерации по контейнеру.

Хм… Странный подход. Сейчас, вроде, в C++ наметился тренд в сторону функциональной нотации. То есть не key in map, а contains(map, key) например. Но это ладно, это мелочи. В предложенном методе нарушается подход Single Responsibility. Это как если бы в std::stack был метод pop_and_get (например), или pop не только бы извлекал элемент со стека, но и возвращал бы его. Но такого метода нет (можно у Саттера почитать, почему) — и это правильно. Так же и тут: зачем в одном операторе совмещать две разных ответственности? Оператору in оставить возвращаемое значение bool. А то, что хочется, реализуется чуть проще:


template<typename M, typename K>
std::optional<typename M::const_iterator> from(const M& m, K&& key)
{
    auto p = m.find(key);
    if (p != m.end())
         return p;

    return std::optional<typename M::const_iterator>();
}

//...

if (auto res = from(some_map, "cat"))
{
     std::cout << res->second << std::endl;
}

Можно даже optional на значение возвращать, чтобы не только map'ы, но и списки с векторами поддержать.

Отсутствие возвращаемого значения у метода pop имеет число техническую причину, и ничего общего с SRP эта причина не имеет.

Не всё так просто. Сейчас эту техническую составляющую можно убрать — pop может возвращать std::optional. Но такая операция даёт разработчику (by design!) меньше гарантий, чем пара top/pop. Возникает, например, интересный вопрос: что делать, если во время создания копии объекта для возврата из pop возникло исключение? Что делать, если это случилось на этапе создания возвращаемого значения? Гарантировать, что pop всегда будет делаться через move нельзя — для объектов в стеке эта операция может быть попросту не определена. Полагаться на RVO/copy elision тоже не всегда можно.
В примере с in такая реализация сужает контракт. Работая с итераторами (казалось бы, удобно!) быстро утыкаешься в то, что для ассоциативных контейнеров и сиквенсов они разные. А стоит переключиться на значения — см. выше.

Вот это все вами перечисленное и есть та самая «техническая составляющая».
Хм. Интересная интерпретация. :) Я думал, что «техническая причина» — это невозможность (техническая) в языке вернуть заведомо невалидное значение независимо от его типа. В С++ такой возможности действительно нет. А то, что я перечислил — это исключительно вопросы контракта. Можно реализовать так, а можно иначе. Принципиальных технический препятствий в языке для любого из вариантов нет.
Гарантировать, что pop всегда будет делаться через move нельзя — для объектов в стеке эта операция может быть попросту не определена.

Ну, можно было бы сделать заenable_ifленный pop по условию наличия move и его noexcept'ности.

Ну, можно и оператор индексирования для списка написать. Тут ведь вопрос — нужно ли. :)
А ещё нет list::operator[], что тоже объяснено, почему. Вот только их всё равно иногда надо использовать и то, что можно было бы с приятной либой написать в мало строчек, приходится писать в 3 раза большее количество.
Спасибо, прострелил себе ногу.
Занятный пример так называемого «академического» кода — да, так можно, но нет, так не нужно.

Спасибо, но я подожду С++20, там будет bool map::contains(key) https://en.cppreference.com/w/cpp/container/map/contains, с поддержкой transparent comparator.


В Boost с версии 1.67 есть нечто подобное, без дополнительных макросов: https://www.boost.org/doc/libs/1_68_0/libs/hof/doc/html/include/boost/hof/infix.html

Спасибо, но я подожду С++20, там будет bool map::contains(key)

Метод std::map::count есть уже сейчас. Возвращает не bool, а int(0/1), но этого достаточно для любого практического применения. Впрочем, автора интересовало не только наличие элемента по ключу в контейнере, но и возможность (если он там есть) его редактировать без повторного поиска.

с поддержкой transparent comparator.

В перегрузке с transparent comparator собака зарыта. Например:
std::map<QString,Value> foo;
// ...
return foo.contains("bar");

Операторы сравнения QString и const char * определены так, что сначала из const char * создается QString, а потом сравниваются два QString'а. Итого N*log(N) лишних аллокаций, деаллокаций и преобразований кодировок в сравнении с:
return foo.contains(QString("bar"));
Кто ж мешает в кучу Qt и STL?
в данном случае QString оказался попросту первым пришедшим мне на ум классом с подобными свойствами. Однако, почему бы и не смешивать? Например, до недавних пор контейнеры Qt не умели работать с noncopyable объектами, а аналогов emplace(...) у них до сих пор нет. Стандартные алгоритмы — тоже STL.
Спасибо за интересную статью! Почерпнул идеи для создания произвольных оператров в C++.
Оператор годный, только есть одна проблема (как и с примерами в секции PS). Этот опрератор очень удобно читать и писать. Если писать я его еще могу как то сам, то читать мне как и большинству других разработчиков приходится преимущественно чужой код.

Вот и проблема, как убедить своих колег в том, что это натация стоит использования? Увидев такой код на ревью, меня первым делом спросят, где тесты? Нет тестов — значит оно точно работает (не)всегда так как я этого не ожидаю.

Где тесты? Где границы применимости т.е. при каких условиях такая натация это UB? Какие есть ограничения на контейнеры, на value_type, как я могу это использовать не по назначению (скорее всего случайно), и как запретить это на уровне компилятора?

Когда то я тоже увлекался подобными вещами, очень полезно и развивает, а потом в какой то момент я сказал себе, хватит заниматься борьбой с ветренными мельницами (с++). Никто и никогда в здравом уме не даст мне это использовать в продакшене. А самое главное это должно быть на уровне языка, а не библиотеки (даже если это и можно с эмулировать в виде библиотеки) потому, что ни одна утилита (статический анализотр, в том числе встроенные в компилятор ворнинги) про это счастье ничего не знает и не узнает. Значит только внимательное код ревью спасет меня и моих колег от проблем, но у меня и так полно мест за которыми мне нужно очень внимательно следить, я не хочу загружать в свой мозг еще и вот это все.

Еще раз, мне это очень нравиться как концепция и на уровне языка я всеми конечностями за такое, но это поделка на коленке почти наверняка не пригодна к применению в продакшене. Продакшен код нужно читать как очень плохой, несогласованный, полный багов, спагети код, который при малейшей возможности всегда проявляет UB. А еще мои (да и не только мои) колеги очень упрямые и даже если покрыть все 3х этажными тестами на все случаи жизни и предвидеть будующие измениния с++ (ну хотя бы лет на 5-6), то даже в этом случае у меня почти нет шансов убедить хотя бы парочку, что это того стоит.

К сожалению практической пользы в лучшем случае 0 (а для многих вообще отрицательная), но читать было приятно, пишите есчо, есть вероятность, что другие поделки будут полезней.
Простите промахнулся ответом. (ответ ниже)

Консерватизм свойственен людям, тут ничего не поделаешь. Можно попробовать с каких-то более предсказуемых конструкций. Не сразу втаскивать оператор "in", а начать с чего-то меньшего. Но это, конечно, зависит от коллег, есть люди которые считают, что все что не предусмотрено языком — лишнее и не имеет право на существование.


P.S.
Мне больше повезло с коллегами сейчас. Для одной из задач, я использовал что-то типа именованных аргументов функции и перегруженный operator | для объединения операций. Если интересно, то можно посмотреть на github.

adjachenko
Вот и проблема, как убедить своих колег в том, что это натация стоит использования?

Ну моя задача состояла в том чтобы, поделится с сообществом своими идеями. Убедить ваших коллег использовать это или нет, уже не моя забота. Я к идеям своих подчинённых, отношусь например без предубеждений.
Где границы применимости т.е. при каких условиях такая натация это UB?

Это всего лишь перегруженный оператор * UB у него такие же как и у любого другого перегруженного оператора *.
Какие есть ограничения на контейнеры, на value_type, как я могу это использовать не по назначению (скорее всего случайно), и как запретить это на уровне компилятора?

Это зависит уже от перегруженного оператора in, в принципе его перегрузить можно для чего угодно, я не вижу каких-то особенных препятствий.
Когда то я тоже увлекался подобными вещами, очень полезно и развивает, а потом в какой то момент я сказал себе, хватит заниматься борьбой с ветренными мельницами (с++). Никто и никогда в здравом уме не даст мне это использовать в продакшене.

Я бы не назвал, это борьбой с ветряными мельницами, я например делаю это для собственного развлечения в основном. Ну а если вам не разрешают использовать это в продакшене, то почему бы не использовать это в своём пэте, раз вам понравилось.
. А самое главное это должно быть на уровне языка, а не библиотеки

Я встречал довольно много библиотек которые активно используют макросы, за частую даже опасные.
К сожалению практической пользы в лучшем случае 0 (а для многих вообще отрицательная)

Сочувствую вам, сам когда-то работал в компании которая на С++11 то не хотела переходить, не то что там использовать подобные фичи.
но читать было приятно, пишите есчо

Спасибо, как раз намечается интересная статья.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.