Developing.ru

Как видите, все операторы сравнения в том случае, если один операнд NoPosition, ведут себя одинаково.

А перед RightBottom - это если NoPosition<RightButton равно true, а RightButton<NoPosition равно false.

Кроме того, NoPosition стоит после RightBottom и после себя, но и он уже до Left и до себя. А ведь Left предшествует RightBottom.

Romeo писал(а): а так же на лицо его очивидная транзитивность в нашем конкретном случае (в отличие от примера с картами),

Какое такое отличие от собственного варианта?

Romeo писал(а):Не думай, что я тебя поучаю или пытаюсь доказать, что моё мнение является единственным правильным. Если честно, я уже вышел из того возраста, когда я должен что-то кому-то доказывать. Я просто сторонник простого кода, и я пока не вижу зачем нам этот код усложнять. Если тебе твой оператор нравится больше, то Бог с ним, оставляй его.

В данном случае принцип наименьшего удивления не действует, а от девизов "Если на клетке с верблюдом написано "Жираф", не верьте, это слон" и "Бороться, искать, найти и перепрятать" придётся не шарахаться, так как ключевая особенность проекта заключается даже не в троичной логике, а в смешении троичной логики с двоичной, причём, прямо в интерфейсе. "Пользователь" должен офигеть на столько, чтоб уже не удивляться чему угодно вплоть до использования иероглифов в программном тексте, форматированного программного текста и семантического наполнения не только у символов, но и оформления, и окончательно увериться в том, что проект писан по-еврейски. Плюс смотрите соседнюю тему. Я ведь начинающий то начинающий, но не вообще в программировании и область такова, что весь этот интерфейсный бедлам действительно должен распространиться на код, как минимум для единобезобразия.

А зачем там что то третье?

Для того, чтобы указать на несравнимость объектов. Пока мы возвращаем true и false, мы декларируем порядок по неубыванию ВСЕХ элементов enum'а и с этим просто невозможно спорить.

Вот смотри: есть некие объекты, некоторые из них распределены слева на право, а один над ними и растянут на всю ось. Сравниваем любой из объектов с верхним. И что получаем? Он левее? Нет. Значит false, уже достаточно.

Зачем ты упорно пытаешь всё усложнить и сделать код неочевидным? Если один из объектов лежит над всеми и просто несравним с другими, то он не имеет право быть в этом enum'е в принципе. Он должен быть в другом enum'e. И оператора сравнения между первым и вторым enum'ом быть не должно. Только после этого всё станет на свои места и код станет интуитивным. Пойми, оператор "меньше" гарантирует сравнимость ВСЕХ элементов типа и возвращение false никак не "уже достаточно". Возвращение false сообщает вызывающей стороне, во-первых, о том, что объкты только что БЫЛИ СРАВНЕНЫ (и этого факта уже никак не отменить) и лишь во-вторых о том, что первый объект "не меньше" второго.

Как видите, все операторы сравнения в том случае, если один операнд NoPosition, ведут себя одинаково.

Приведённые операторы являются нарушением основ матлогики в принципе и являются конфликтующими. Применение их всех в проекты приведёт к лоческому коллапсу всех станрартных алгоритмов.

Если не меньше, то false, всё.

Верно false, но в стандартной логике "не меньше" обозначет "больше либо равно", а не "не сравнимо".

И RightBottom<NoPosition даёт false, и NoPosition<RightBottom тоже даёт false

Если (A "не меньше" B) и (B "не меньше" A) => (A == B). Советую подучить матлогику.

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

Абсолютно неверно. Любой стандартный алгоритм сортировки, например std::sort, использует для сортировки лишь один оператор "меньше", а не все вместе операторы. В случае возвращения false для обоих инверсных вызовов, оператор сортировки, основываясь на вышепреведёных выкладках, поймёт, что значения РАВНЫ и поставит их не в "слабопредсказуемых местах", а в вполне определённых. Он сохранит порядок этих элементов в результирующем массиве таким же, каким он был в исходном. Советую прочесть стандарт C++ или хотя бы просто проверить свою фантазию перед тем, как выкладывать её на форум

область такова, что весь этот интерфейсный бедлам действительно должен распространиться на код, как минимум для единобезобразия

Вот это самый сильный ляп из всех, хотя, на первый взгляд, может оказаться, что вышепреведённые ляпы куда ужаснее. Прости за строгость, но это действительно так. Если хочешь стать хорошим программистом, то прислушайся к моему совету. НИКОГДА и НИ ПРИ КАКИХ ОБСТОЯТЕЛЬСТВАХ не говори, что бардак в коде чем-то оправдан. Каким бы не был "неожиданным" пользовательсий интерфейс, код должен быть идеально взвешен, логичен, не избыточен и т.д. Перенося "бедлам" в код ты рискуешь быть убитым человеком, который будет после тебя в этом коде рабираться, а так же просто ставишь крест на дальшейшем суппорте и на дальнейших энхансментах. Просто большой жирный крест. Твой продукт выкинут или перепишут. А если перепишут конкуренты, то это будет ещё и дважды обидно.

Romeo писал(а):Зачем ты упорно пытаешь всё усложнить и сделать код неочевидным? Если один из объектов лежит над всеми и просто несравним с другими, то он не имеет право быть в этом enum'е в принципе. Он должен быть в другом enum'e. И оператора сравнения между первым и вторым enum'ом быть не должно.

Если бы всё было так просто. А с чем сравнивать цикл for по енаму? И как это не сравним объект, расположенный не в отдельном пространстве, а выше?

Romeo писал(а):Верно false, но в стандартной логике "не меньше" обозначет "больше либо равно", а не "не сравнимо".

Пасквилянт детектед. Кто сказал, что "не равно" - синоним "меньше, или больше"? А nan во флоате меньше ноля или больше? Но он ведь тоже не равен нолю.

Romeo писал(а):любой алгоритм сортировки массива, часть элементов которого равны NoPosition выставит их в слабопредсказуемые места в пределах результирующего массива, зависящие и от конкретного оператора сравнения (<, <=, >=, или >)
Абсолютно неверно. Любой стандартный алгоритм сортировки, например std::sort, использует для сортировки лишь один оператор "меньше", а не все вместе операторы.

Стандартно? А теперь? А ведь это тот же пузырёк, только циклы переставлены. И заметь: не все сразу, а один, но во второй версии другой.

Проект будет переписан в любом случае. В комбинированной двоично-троичной логике, а не в двоичной.

Пасквилянт детектед

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

Кто сказал, что "не равно" - синоним "меньше, или больше"

Знаешь, что такое дискретная математика? А что такое булевая логика? Синтаксис, операторы языка (в том числе оператор "меньше"), а так же все библиотечные функции C++ работают именно на булевой, а не троичной логике. Так что не надо меня спрашивать кто это сказал. Сказал это до меня Страуструп, знаешь такого?

Стандартно? А теперь? А ведь это тот же пузырёк, только циклы переставлены. И заметь: не все сразу, а один, но во второй версии другой.

Если ты будешь писать вручную сортировку, то ты можешь использовать любые операторы сравнения. Но заметь, ты всё равно будешь использовать один из них, а не все сразу. Это во-первых. А во-вторых, спешу открыть тайну - под СТАНДАРТНЫМИ алгоритмами я подразумевал не старндартный подход изобретения велосипеда, а стандартные функции из STL. Все они используют оператор "меньше" для сортировки.