UPD 04.02.2024 (13:54 MSK) Обновлено введение: добавлено пояснение относительно функции fи в общем более человеческое объяснение как strong_ordering, так и weak_ordering. Удалена бесполезная информация касательно так и не попавших в стандарт strong_equality и weak_equality.
Раздел про слабо упорядоченные типы стал подробнее: появилось детальное объяснение понятия «различимости».
Оригинальный пропозал Consistent comparison (P0515) подразумевает под различимостью то, что хоть a == b может быть true, но какое-то f(a) == f(b) при этом может быть и не true, где f «считывает только заметное для сравнения состояние, доступное с помощью publicconst членов».
Стандарт не навязывает, что такое различимость. Программист сам регулирует это под свои намерения.
Мне кажется, в примере с CaseInsensitiveString можно сказать, что в целом все, что от нее требуется — это case insensitive сравнение. Но концептуально она должна давать нам возможность получить исходный string. Он может нам для чего-то понадобиться. Так что у нас тут weak order, ибо мы можем выдумать удовлетворяющую критериям функцию f, что f(a) != f(b) при a == b: bool f(C a, C b) { return a.str(); == b.str(); }
Является ли адрес в памяти «заметным для сравнения состоянием, доступным с помощью public const членов»? Наверное, только в очень специфических случаях. И программист это явно регулирует.
Про всякие даблы. Допустим, у нас есть класс, представляющий какое-нибудь вещественное число (без всяких NaNов). Программист явно определил, какие объекты считать «равными» (допустим, равные с точностью до целого). И программист явно же определил, какие объекты считать различимыми, ограничивая публичный интерфейс. Он сделал возможность получить исходное число частью публичного интерфейса — тогда 1.2 и 1.5 различимы. А если же не сделал — то есть, пользователи, пользуясь публичным интерфейсом, никак не могут различить 1.2 и 1.5 — неразличимы.
Всё верно, этот конкретный фрагмент — перевод, так как я прямо цитировал пропозал Consistent comparison (P0515). Абзацем ранее было написано: «а какой тип, собственно, должен возвращать наш operator<=>, если мы реализуем его своими руками: std::strong_ordering, std::weak_ordering или std::partial_ordering». Видимо, я был должен уточнить, что под «_ordering» подразумевается «(strong/weak/partial)_ordering». Соглашусь с тем, что информация про удаленные виды экволити оказалась лишней. Моей мотивацией было полностью сохранить оригинальные формулировки, так как я посчитал, что они достаточно интересны и полезны. Но теперь мне действительно кажется, что они лишь вносят неясность. Спасибо, я подкорректирую этот фрагмент статьи.
Ваш ответ несомненно правильный, но очень сжатый. Целью моей статьи был развернутый ответ на вопрос с приведением примеров.
Так ядро «с нуля» и «полностью на собственных решениях». Как то, что решили не пилить поддержку запуска Android приложений, соотносится с открытостью-закрытостью (о которой, кстати, в статье ничего не написано)? Windows тоже линуксовые бинарники нативно не запускает.
Спасибо, очень интересно было почитать документацию к fast_io. Однако это едва-ли можно назвать general purpose решением: прикручивать форматирование собственных классов в эту библиотеку, видится, очень больно (например, вот так реализуется поддержка std::complex).
Краткая запись тоже работает. Чем отличается explicit object parameter от других аргументов — тем, что перед ним стоит this. Больше на него кроме того, что он не может быть variadic pack'ом, ограничений практически не накладывается.
Хм, неужели компилятору все еще недостаточно указания constexpr и такого коротенького тела функции, чтобы он его заинлайнил и понял, что никаких указателей быть не должно? Это что ж получается, C++ обрастает все более и более монструозным синтаксисом во имя производительности, и все зря? Тривиальнейшие конструкции все еще можно оптимизировать? Или все эти конструкции, авторы каждой из которых говорят "смотрите, как стало понятно и лаконично написано" не работают, если всю эту понятность и лаконичность не обмазать десятком move(forward(auto&&))?
Одно дело — оптимизации, которые компилятор может (или не может) выполнить, другое — возможность явно описать то, что ты хочешь.
Стандарт, за редкими исключениями, не говорит о возможных оптимизациях, и они — явно не то, на что следует полагаться разработчику при написании кода.
Слово конструктор (по крайней мере, в моем понимании) подразумевает, что с помощью вашей библиотеки я могу реализовать клиент и сервер для своего протокола.
Метаклассы предлагают программисту контракт: какие поля они добавляют, какую функциональность реализуют. Применяя метакласс к своему классу, программист должен осознавать вносимые им изменения. В приведенных примерах interface Shape не компилируется, потому что статья описывает функциональность, которая только предложена для включения в стандарт, но еще не принята и не реализована. Такие метаклассы как interface вполне могут стать частью стандартной библиотеки.
Если мы оставим шаблонную реализацию битовых операций в namespace std, то using namespace std в пользовательском коде подтянет их в пользовательский неймспейс — загрязнит его реализациями битовых операций для пользовательских enumов.
4 из 5 вопросов — азы, которые подробно рассказываются в каждом учебнике. Интересные у вас собеседования.
В оригинале написано
Это не делает число менее странным, но кроме того там в комментариях есть пояснение:
Да что-то не компилируется..
50?
UPD 04.02.2024 (13:54 MSK)
Обновлено введение: добавлено пояснение относительно функции
fи в общем более человеческое объяснение какstrong_ordering, так иweak_ordering. Удалена бесполезная информация касательно так и не попавших в стандартstrong_equalityиweak_equality.Раздел про слабо упорядоченные типы стал подробнее: появилось детальное объяснение понятия «различимости».
Спасибо @Kelbon и @NeoCodeза ранний фидбек.
Оригинальный пропозал Consistent comparison (P0515) подразумевает под различимостью то, что хоть
a == bможет бытьtrue, но какое-тоf(a) == f(b)при этом может быть и неtrue, гдеf«считывает только заметное для сравнения состояние, доступное с помощьюpublicconstчленов».Стандарт не навязывает, что такое различимость. Программист сам регулирует это под свои намерения.
Мне кажется, в примере с
CaseInsensitiveStringможно сказать, что в целом все, что от нее требуется — это case insensitive сравнение. Но концептуально она должна давать нам возможность получить исходныйstring. Он может нам для чего-то понадобиться. Так что у нас тут weak order, ибо мы можем выдумать удовлетворяющую критериям функциюf, чтоf(a) != f(b)приa == b:bool f(C a, C b) { return a.str(); == b.str(); }
Является ли адрес в памяти «заметным для сравнения состоянием, доступным с помощьюpublic constчленов»? Наверное, только в очень специфических случаях. И программист это явно регулирует.Про всякие даблы. Допустим, у нас есть класс, представляющий какое-нибудь вещественное число (без всяких
NaNов). Программист явно определил, какие объекты считать «равными» (допустим, равные с точностью до целого). И программист явно же определил, какие объекты считать различимыми, ограничивая публичный интерфейс. Он сделал возможность получить исходное число частью публичного интерфейса — тогда 1.2 и 1.5 различимы. А если же не сделал — то есть, пользователи, пользуясь публичным интерфейсом, никак не могут различить 1.2 и 1.5 — неразличимы.Имхо, с инкапсуляцией всё ок.
Всё верно, этот конкретный фрагмент — перевод, так как я прямо цитировал пропозал Consistent comparison (P0515). Абзацем ранее было написано: «а какой тип, собственно, должен возвращать наш
operator<=>, если мы реализуем его своими руками:std::strong_ordering,std::weak_orderingилиstd::partial_ordering».Видимо, я был должен уточнить, что под «
_ordering» подразумевается «(strong/weak/partial)_ordering». Соглашусь с тем, что информация про удаленные виды экволити оказалась лишней. Моей мотивацией было полностью сохранить оригинальные формулировки, так как я посчитал, что они достаточно интересны и полезны. Но теперь мне действительно кажется, что они лишь вносят неясность. Спасибо, я подкорректирую этот фрагмент статьи.Ваш ответ несомненно правильный, но очень сжатый. Целью моей статьи был развернутый ответ на вопрос с приведением примеров.
Еще раз спасибо за фидбек!
Спасибо, вы правы, я опечатался
Спасибо, поправил. Параметра быть там не должно. Это пример из исходного пропозала.
Так ядро «с нуля» и «полностью на собственных решениях». Как то, что решили не пилить поддержку запуска Android приложений, соотносится с открытостью-закрытостью (о которой, кстати, в статье ничего не написано)? Windows тоже линуксовые бинарники нативно не запускает.
Спасибо большое, поправил!
Только при использовании
std::format,std::print, ... разбор форматной строки, если я правильно понял, что вы имеете ввиду, происходит в compile-time (см. std::basic_format_string)Спасибо, очень интересно было почитать документацию к fast_io. Однако это едва-ли можно назвать general purpose решением: прикручивать форматирование собственных классов в эту библиотеку, видится, очень больно (например, вот так реализуется поддержка std::complex).
Краткая запись тоже работает. Чем отличается
explicit object parameterот других аргументов — тем, что перед ним стоитthis. Больше на него кроме того, что он не может бытьvariadic pack'ом, ограничений практически не накладывается.Одно дело — оптимизации, которые компилятор может (или не может) выполнить, другое — возможность явно описать то, что ты хочешь.
Стандарт, за редкими исключениями, не говорит о возможных оптимизациях, и они — явно не то, на что следует полагаться разработчику при написании кода.
Это определенно не конструктор протоколов.
Слово конструктор (по крайней мере, в моем понимании) подразумевает, что с помощью вашей библиотеки я могу реализовать клиент и сервер для своего протокола.
Писать огромное количество кода только ради того, чтобы смочь сложить два и два без лишнего рантайма — это, конечно, прикольно.
Метаклассы предлагают программисту контракт: какие поля они добавляют, какую функциональность реализуют. Применяя метакласс к своему классу, программист должен осознавать вносимые им изменения.
В приведенных примерах
interface Shapeне компилируется, потому что статья описывает функциональность, которая только предложена для включения в стандарт, но еще не принята и не реализована.Такие метаклассы как
interfaceвполне могут стать частью стандартной библиотеки.Если мы оставим шаблонную реализацию битовых операций в
namespace std, то using namespace stdв пользовательском коде подтянет их в пользовательский неймспейс — загрязнит его реализациями битовых операций для пользовательскихenumов.Хочу сам отметить занятную вещь: если в libc++ и libstdc++ для дедубликации кода не сделано ничего, то в Microsoft STL для этого используется макрос.