Перегрузка в C++. Часть II. Перегрузка операторов

[Daddy_Cool]

Спасибо за статью! От объёма мной непознанного просто перехватывает дыхание. Увы, я-то пишу по сути на С, с редким использованием ++совских плюшек.
Можно пару вопросов?
Если в C++17 можно перегружать ^, значит ли это, что я смогу каким-то образом заменить pow(x,y) на x^y — в стиле Бейсика?
Практически невозможно научить хорошо программировать студентов, которые раньше изучали BASIC: как потенциальные программисты они умственно искалечены, без надежды на восстановление. Эдсгер В. Дейкстра
Это видимо обо мне.
Насколько поддерживается С++ 17 в VS2017-19?

[a-tk]

Если в C++17 можно перегружать ^, значит ли это, что я смогу каким-то образом заменить pow(x,y) на x^y — в стиле Бейсика?

Если как минимум один из типов не встроенный — да.

Более того, можно извратнуться и для пользовательских типов сделать перегрузку вида x**y для возведения в степень — можете взять в качестве домашнего задания.

[Daddy_Cool]

Если как минимум один из типов не встроенный — да.

Упс. Т.е. если я хочу x^y, то надо делать тип «показатель степени» совпадающий например с double?

x**y — кстати да — для использования формул из фортрановских текстов как раз.

[a-tk]

Упс. Т.е. если я хочу x^y, то надо делать тип «показатель степени» совпадающий например с double?

Не совпадающий, а оборачивающий, и всё равно не получится, поскольку компилятор не будет искать перегрузку, где как минимум один из аргументов требует implicit-конструирование чего-либо. Зато можно с помощью пользовательских литералов это сделать.
Вот например: godbolt.org/z/qfDzcV

[a-tk]

Насколько поддерживается С++ 17 в VS2017-19?

MSVS очень неплохо кстати поддерживает современные стандарты.
docs.microsoft.com/en-us/cpp/overview/visual-cpp-language-conformance?view=vs-2019

[dm_frox]

MSVS 2017 очень хорошо, я в свое время делал довольно много проверок. Надо только включить соответствующую опцию компилятора (по умолчанию она выключена). Ну в MSVS 2019 надо уже обсуждать поддержку C++20.

[dm_frox]

Этот вариант обсуждался в одной из книг списка литературы. Он признан неудачным по причине приоритета оператора. У возведения в степень традиционно высокий приоритет, выше чем у умножения, а у ^ довольно низкий, и поэтому надо будет ставить скобки там, где их никто не привык ставить. Надо будет писать 2*(x^2) вместо привычного 2*x^2. Но и, соответственно, куча трудно обнаруживаемых ошибок.

[Daddy_Cool]

Ох, т.е. нет в жизни счастья?
С одной стороны находится вот такое:
www.cyberforum.ru/cpp-beginners/thread1108743.html
по заданию в лабораторной, нужно написать программу которая будет вычислять значение математического выражения с заданным приоритетом операций(приоритет каждой операции задаётся пользователем),
С другой — softwareengineering.stackexchange.com/questions/161049/can-i-change-operator-precedence-and-associativity-in-c
-How do I change the operator precedence in C++?
-NO: you cannot change precedence because the language specification doesn't allow it. Full stop.
Может надо в С++23 предложить возможность изменения приоритета операций?

[MooNDeaR]

Может надо в С++23 предложить возможность изменения приоритета операций?

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

[a-tk]

Это из другой плоскости задача: как сделать своё, если не нравится чужое.

[dm_frox]

MSVS 2017 очень хорошо, я в свое время делал довольно много проверок. Надо только включить соответствующую опцию компилятора (по умолчанию она выключена). Ну в MSVS 2019 надо уже обсуждать поддержку C++20.

[dm_frox]

Конечно так правильнее. Но C-строки носят скорее иллюстративный характер, а не практический и мне хотелось продемонстрировать hash_combine, которую можно использовать гораздо шире.

[oktonion]

Перегружать зависимые операторы для класса не обязательно, можно использовать операторы из std::rel_ops непосредственно, для этого надо воспользоваться using-директивой.

И если такое навалите в заголовочном файле вашего класса, то неожиданно для всех пользовательских типов появятся операторы сравнения, которые ещё и компилироваться не будут при вызове и, соответственно, отсутствии реализаций операторов '<' и '=='?

[dm_frox]

Конечно получится плохо. Вообще using-директива в заголовочном файле относится к запрещенным приемам. Описанная возможность носит скорее абстрактный характер, служит для лучшего понимания архитектуры стандартной библиотеки и каких-то экспериментов. Лично я вообще никогда не использую using-директиву (правда, никогда не говори никогда). Так, что надо не поленится и ручками определить все операторы.

[a-tk]

operator== к слову тоже может определяться через operator<
medium.com/@shiansu/strict-weak-ordering-and-the-c-stl-f7dcfa4d4e07

[dm_frox]

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