Почему operator<=>() не генерирует operator==()?

во что они превратили мой старый добрый цепепе-98, сволочи!

что этот оператор хоть делает? :)

что этот оператор хоть делает? :)

Я вот как раз и не …ээээ… понимаю. Что он должен делать – по идее – так это генерить все операторы сравнения одним махом.

operator== автоматически определяется, только если operator<=> определён как default.

https://godbolt.org/z/jq6zo8Kjv

Советую прикупить книжку https://leanpub.com/cpp20, в которой всё это написано.

Во всяких строка и других стд контейнерах решено делать == отдельно, ибо <=> дорогой, во всяких алгоритмах с миллиоными циклами может быть ощутимо.

Спасибо. ) Вполне в духе C++ дурацкое (в смысле ни хрена не интутивное) решение.

Не вижу как это коррелирует с тем фактом, что default-реализация его таки объявляет. LTO по идее должен вывезти, если программист сам понимает что делает. А если не понимает, то и отдельное объявление == ему не поможет.

Напиши Issue в https://github.com/cpp-ru/ideas/issues со своим предложением.

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

что этот оператор хоть делает?

В основном - бесит олдфагов.

а может ты анонимус ещё больший олдфаг, кто знает

Аналог strcmp

Не вижу как это коррелирует с тем фактом, что default-реализация его таки объявляет.

Видимо имеется ввиду, что default <=> генерит не «дефолтный <=> с выведением из него всех остальных» а «дефолтные все», могущие и не иметь общего <=>.

Ты вступил в олдфажную секту Айрон_Баг?

вообще-то оператор == более базовый, чем <=>.

равенство(идентичность в той или иной форме) определено вообще на любом множестве. а <=> определен только на упорядоченном множестве. то есть оператор <=> «слабее», чем ==.

видимо потому определение <=> не определяет ==, а из == выводится !=

С производительностью вопросы тоже есть - нельзя написать одинаково эффективно все операторы сравнения, нам всегда надо будет сравнивать две строки (для примера) лексикографически тогда как в случае operator== можно обойтись сравнением их size()’ов. Например имеем: «hello» == «hello world» зачем здесь проходить все символы в цикле с целью узнать кто же там первее, если можно быстро сравнить размеры? Очевидный оверхед.

*сильнее/строже а не слабее. Потому что <=> задает более узкую категорию.

А разве это плохо?

Ну вообще-то в C++ изменения обычно обратно совместимы. Т.е. за исключением очень редких случаев код, написанный для C++98 должен работать и в сборке с C++20.

С другой стороны, я могу понять попаболь при виде кода, где используются фичи новых стандартов, если чел ни ухом ни рылом об этих новых стандартах не слышал. И даже статьи Райнера Гримма не осилил прочитать.

И даже статьи Райнера Гримма не осилил прочитать. training/coaching

Эко инфоцыган развелось.

Блин ну и зачем это нужно, все одним махом генерить? Если людям лень писать самим - для них есть Java,C#, на худой конец Rust или Питон - там вообще малословно.

Если людям лень писать самим

Если не лень писать самим, то можешь добавить поддержку старых стандартов, больше строчек богу строчек :)

пример:

#if _HAS_CXX20
    _NODISCARD constexpr strong_ordering operator<=>(const _Array_const_iterator& _Right) const noexcept {
        return _Ptr <=> _Right._Ptr;
    }
#else // ^^^ _HAS_CXX20 ^^^ / vvv !_HAS_CXX20 vvv
    _NODISCARD _CONSTEXPR17 bool operator!=(const _Array_const_iterator& _Right) const noexcept {
        return !(*this == _Right);
    }

    _NODISCARD _CONSTEXPR17 bool operator<(const _Array_const_iterator& _Right) const noexcept {
        return _Ptr < _Right._Ptr;
    }

    _NODISCARD _CONSTEXPR17 bool operator>(const _Array_const_iterator& _Right) const noexcept {
        return _Right < *this;
    }

    _NODISCARD _CONSTEXPR17 bool operator<=(const _Array_const_iterator& _Right) const noexcept {
        return !(_Right < *this);
    }

    _NODISCARD _CONSTEXPR17 bool operator>=(const _Array_const_iterator& _Right) const noexcept {
        return !(*this < _Right);
    }
#endif // !_HAS_CXX20

https://github.com/microsoft/STL/blob/b11945b73fc1139d3cf1115907717813930cedbf/stl/inc/array#L115-L139

нельзя написать одинаково эффективно все операторы сравнения, нам всегда надо будет сравнивать две строки (для примера) лексикографически тогда как в случае operator== можно обойтись сравнением их size()’ов

Вот так понятней, сенькс. Хотя собственно решение не генерить == всё равно под вопросом: если программист может написать более оптимальный ==, дык пусть рядышком с <=> и напишет, а компилятор в этом случае не будет генерить == из <=>. (Полагаю, так и сейчас: кастомное имеет более высокий приоритет чем сгенерированное из <=>.) А в подклассах <=> тогда должен подцепить этот кастомный «оверлоад».

А там размер кешируется?

Контейнеры хранят свой размер, зачем тут какие-то доп телодвижения.

ну не будь инфоцыганом, будь инфоевреем. Какие проблемы?

а компилятор в этом случае не будет генерить == из <=>

при auto operator<=>(const X& x) const = default; компилятор генерирует две фунции,

operator <=> и operator ==

и для == не используется <=>, а != определена как !(a==b).

https://godbolt.org/z/57EzGqoda

даже если оператора == нет, то всё равно не будет выводиться через <=>, а будет ошибка: https://godbolt.org/z/xefEhE6b8

Мама, роди меня обратно.

Срамота. Кресты напоминают стареющую лядь, которая нафигачивает в себя все больше и больше силикона и каждый новый драфт как еще одна неудачная пластика, лол.

Потому что разработкой стандарта занимаются компании типа microsoft, которые ничего не понимают ни в проектировании ни в языках программирования ни в написании программ. Они пихают в язык костыли для своих сиюминутных задач, потом через пять лет их забывают и пихают новые.

А действительно важные предложения лежат десяток лет без стандартизации.

Они пихают в язык костыли

Кстати о птичках: по уму <=> следовало бы реализовать макросом (настоящим, AST-шным), без утяжеления собственно языка. Помнится, не успели в скалу впилить макросы, тут же сообщили что некоторые части компилятора переписываются и упрощаются с их помощью.

Вот впилили бы в C++ полноценное метапрограммирование (вместо нынешней constexpr-по#@#ни), и тонны костылей ушли бы в библиотеки: хочешь юзай, хочешь нет, хошь альтернативу напиши.

Мне кажется, что ты не понял, что <=> не генерит набор операторов на все случаи сравнения, он лишь берёт на себя их функию и дёргается вместо них. Можешь не пользоваться и писать 4 оператора вместо одного.

Вот впилили бы в C++ полноценное метапрограммировани

Ничего, что нет единого, эталонного компилятора? Тебе никто не мешает закостылить свой плагин и привязаться гвоздями к шлангу, например.

вместо нынешней constexpr-по#@#ни

А это чем тебе не угодило? Как AST макросы могут заменить constexpr? Например, хочу распарсить текст в компайлтайме, на что мне нужно натянуть AST макросы?

Т.е. за исключением очень редких случаев код, написанный для C++98 должен работать и в сборке с C++20.

На практике часто либо девелоперы об этом подумали и вкинули макросов, которые позволят ему работать, либо 98-й код написан в слишком пермиссивной манере :)

Мне кажется, что ты не понял, что <=> не генерит набор операторов на все случаи сравнения, он лишь берёт на себя их функию и дёргается вместо них.

Сенькс.

Ничего, что нет единого, эталонного компилятора?

Зато есть единый эталонный стандарт. Могли бы в него впилить. Или там всё настолько плохо, что даже на уровне структур AST договориться невозможно?

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

Это я в курсе.

Например, хочу распарсить текст в компайлтайме, на что мне нужно натянуть AST макросы?

AST-макросы – это код, выполняемый в компайл-тайм. Полноценный код. Произвольный. Хочешь распарсить текст – берёшь и парсишь. На нормальном языке, а не костыльном подмножестве.

https://gcc-python-plugin.readthedocs.io/en/latest/working-with-c.html#spell-checking-string-constants-within-source-code

надо просто ниже задефолтить нужные операторы

Вот впилили бы в C++ полноценное метапрограммирование (вместо нынешней constexpr-по#@#ни), и тонны костылей ушли бы в библиотеки: хочешь юзай, хочешь нет, хошь альтернативу напиши.

так они и делают отход от костылей, — к примеру вместо всяких SFINAE штучек теперь можно использовать человеческие concepts.

Вот впилили бы в C++ полноценное метапрограммирование, и тонны костылей ушли бы в библиотеки

так они и делают отход от костылей, — к примеру вместо всяких SFINAE штучек теперь можно использовать человеческие concepts

concepts – безусловно человеческие, но к метапрограммированию относятся примерно никак, т.к. являются частью языка, а не средством трансформации кода программы.

А точнее, concepts – это инструмент статической типизации, а не МП.

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