вот так сразу взять и здоровую идею назвать антипаттерном.
Во-первых, если операция сложения векторов не определена, но валидна для данной области, то это очевидно проблема разработчика, а не подхода. Определяем операцию и всё.
Во-вторых, смотрим на С++ с его "прекрасными" сообщениями об ошибках и делаем выводы для всей идеи. Возьмём другой инструмент и овертипизация уже не будет казаться такой уж овер.
Здравствуйте, vsb, Вы писали:
vsb>Вообще я всегда, когда вижу, как люди увлекаются перекладыванием на систему типов всё большего функционала, вспоминаю, что рядом есть люди, которые пишут на JS и питоне. И пишут вполне себе серьёзные проекты, приносящие пользу и зарабатывающие деньги. И также вспоминаю, что уже лет 30 есть хаскель, который, несмотря на всю его типизированную мощь, так и не нашёл отклика в сердце массового программиста.
Это ты зря. Многие идеи с монадами, типизацией, ленивостью, иммутабельностью и прочей функциональщиной перекочевали в массовые ЯП типа c#/java/typescript и даже js с питонами.
Из хаскеля получился отличный полигон для испытаний.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, T4r4sB, Вы писали:
TB>Против подобных идиотских мыслей я и борюсь. А на два шага вперед посмотреть?
Смотрю на куда больше чем на два.
Никакого signed там быть не должно.
TB>И придется код засирать кастами. И всего этого бы не было если бы изначально был знаковый размер.
И ради этой мелочи ты готов посеять далеко растущую проблему?
Что там насчёт "больше чем на два шага?"
Этот срач уже был, мне не интересно его заново начинать.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, vsb, Вы писали:
vsb>А адреса 2^63 .. 2^64 — 1 пометить как невалидные, чтобы при попытке обращения к ним всё падало (в идеале вообще добавить в процессор специальные операции, которые будут вызывать прерывание сразу после вычисления неправильного адреса).
А ничо что весь kernel живёт в этих адресах?
Рука так и тянется к шотгану...
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, sergii.p, Вы писали:
SP>Во-вторых, смотрим на С++ с его "прекрасными" сообщениями об ошибках
О чём ты вообще?
Или ты кроме микрософтовского компилера ничем другим не пользовался?
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
vsb>>А адреса 2^63 .. 2^64 — 1 пометить как невалидные, чтобы при попытке обращения к ним всё падало (в идеале вообще добавить в процессор специальные операции, которые будут вызывать прерывание сразу после вычисления неправильного адреса).
CC> CC>А ничо что весь kernel живёт в этих адресах? CC>Рука так и тянется к шотгану...
Здравствуйте, T4r4sB, Вы писали:
S>>Т.е. могли бы вы описать как вам бы хотелось работать с подобными значениями?
TB>Как с интами. Ну и валидацию только в самом конце когда ставим фигуру на доску. TB>Опционально валидацаю в сеттере set_coords. Вроде это намного проще чем кастовать на каждый чих.
Т.е., условно такой вариант вас устроил бы (в варианте C++, в Rust-овом синтаксисе могу напутать)?
class Position {
int v_;
public:
Position(int v); // Здесь контроль за корректностью v. Исключение если некорректно.
[[nodiscard]] int value() const noexcept { return v_; }
};
class Offset {
int v_;
public:
Offset(int v); // Здесь контроль за корректностью v. Исключение если некорректно.
[[nodiscard]] int value() const noexcept { return v_; }
};
void MakeMove(Position from, Offset to) { // На вход могут прийти только корректные значения.
...
}
Внутри же MakeMove для проведения вычисления новой позиции нужно будет оперировать "голыми" int-ами, которые получаются из исходных "оберток" посредством методов value().
Здравствуйте, CreatorCray, Вы писали:
CC>Смотрю на куда больше чем на два. CC>Никакого signed там быть не должно.
Да хоть на 10. Я использовал знаковые размеры в других языках — жить стало лишь легче. Доменная ориентированность оказалась ненужным словом, чисто чтоб хипсторам порадоваться
TB>>И придется код засирать кастами. И всего этого бы не было если бы изначально был знаковый размер. CC>И ради этой мелочи ты готов посеять далеко растущую проблему?
Да нет никакой далеко растущей проблемы
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, sergii.p, Вы писали:
SP>>Во-вторых, смотрим на С++ с его "прекрасными" сообщениями об ошибках CC>О чём ты вообще? CC>Или ты кроме микрософтовского компилера ничем другим не пользовался?
То ли дело сообщения об ошибках в гцц , да?
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Здравствуйте, so5team, Вы писали:
S>Т.е., условно такой вариант вас устроил бы (в варианте C++, в Rust-овом синтаксисе могу напутать)?
Ну вроде выглядит здраво. Конечно если MakeMove это единственное место где нужны числовые значения, то тогда наличие методов value становится бессмысленным, и если его убрать то и получилось бы что-то в стиле адептов ddd.
Но когда таких методов становится овердофига и постоянно пишешь новые, то лучше использовать этот самый value
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Здравствуйте, T4r4sB, Вы писали:
TB>Ну вроде выглядит здраво. Конечно если MakeMove это единственное место где нужны числовые значения, то тогда наличие методов value становится бессмысленным, и если его убрать то и получилось бы что-то в стиле адептов ddd.
В C++ (как и в Rust-е, емнип) нет read-only свойств (aka properties). Поэтому если хочется, чтобы типы Position и Offset представляли только корректные значения, то приходится само значение прятать, а доступ к нему делать через getter.
Если же таких гарантий от Position и Offset не нужно, то можно вообще вот так в C++ после C++11:
struct Position { int v_; };
struct Offset{ int v_; };
Собственно, это удобно когда приходится работать с функциями/методами, в которых подряд идет много однотипных аргументов (вроде трех int-ов подряд, или четырех bool-ов подряд).
Но это уже частности. Как бы суть такого подхода, что типы вводятся только для хранения значений, отдельных операторов для манипулирования значениями не делается. Из-за чего со значениями можно работать как хочешь, приводя к нужным рамкам только там, где ожидается финальный результат.
Здравствуйте, T4r4sB, Вы писали:
CC>>А что не так? Лимит в 32 бита конечно неправильно, надо size_t TB>Ой, я опечатался. Короче, там ввели usize, а должно быть isize.
Разве не очевидно, что разница двух usize должна давать isize?
Здравствуйте, B0FEE664, Вы писали:
BFE>Разве не очевидно, что разница двух usize должна давать isize?
Мне очевидно, что разница двух чисел из диапазона [0 .. 2**64-1] должна лежать в диапазоне [1-2**64 .. 2**64-1], но такое в реальности не сделать с приемлемой производительностью. Теория обосралась при встрече с практикой.
Во всех известных мне языках разница двух usize это usize. И всем пофиг что это падает на данных из самого часто используемого на практике диапазона.
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Здравствуйте, no_ise, Вы писали:
_>Для хардкорного доказательства теорем это может быть круто. А для сложения-умножения точек _>в каком-нибудь GDI кажется будет перебором.
А потом к вам прилетает спецтекст, который при открытии в Блокноте вызывает выполнение произвольного кода.
Здравствуйте, T4r4sB, Вы писали:
BFE>>Разве не очевидно, что разница двух usize должна давать isize? TB> Мне очевидно, что разница двух чисел из диапазона [0 .. 2**64-1] должна лежать в диапазоне [1-2**64 .. 2**64-1],
А причём тут числа? TB>но такое в реальности не сделать с приемлемой производительностью.
откуда вы взяли степень 64? зачем 64?
TB>Во всех известных мне языках разница двух usize это usize. И всем пофиг что это падает на данных из самого часто используемого на практике диапазона.
Есть принципиальная разница между порядковым числом и числом выражающим количество. А то, что большинство их всё время путает — ну это проблемы большинства. У меня есть код в котором индекс — это unsigned int по модулю размера массива. И никаких проблем с выходом за пределы массива.
Здравствуйте, T4r4sB, Вы писали:
G>>а потом с подачи товарища Волшина идею "make illegal states unrepresentable"
TB>А как этот долбаный фанатик собирается писать банальную задачу "прибавить к позиции шахматной фигуры смещение и проверить валидность результата"?
Позиция шахматной фигуры — это беззаконное целое по модулю 8.
Здравствуйте, B0FEE664, Вы писали:
TB>> Мне очевидно, что разница двух чисел из диапазона [0 .. 2**64-1] должна лежать в диапазоне [1-2**64 .. 2**64-1], BFE>А причём тут числа?
Действительно, какое же отношение тип имеет к числам.
BFE>откуда вы взяли степень 64? зачем 64?
Интересно, и сколько же битов у usize на большинстве современных компов.
BFE>Есть принципиальная разница между порядковым числом и числом выражающим количество. А то, что большинство их всё время путает — ну это проблемы большинства. У меня есть код в котором индекс — это unsigned int по модулю размера массива. И никаких проблем с выходом за пределы массива.
И как ты в своём коде выполняешь операцию "циклически перейти к предыдущему элементу"?
Здравствуйте, B0FEE664, Вы писали:
BFE>Позиция шахматной фигуры — это беззаконное целое по модулю 8.
Я ж не про шахматы на торе
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Здравствуйте, so5team, Вы писали:
S>Собственно, это удобно когда приходится работать с функциями/методами, в которых подряд идет много однотипных аргументов (вроде трех int-ов подряд, или четырех bool-ов подряд).
Кстати, как это помогает, когда 4 була подряд? Типа позволяет выдать аргументам имена в точке вызова, типа не просто
Здравствуйте, T4r4sB, Вы писали:
TB>>> Мне очевидно, что разница двух чисел из диапазона [0 .. 2**64-1] должна лежать в диапазоне [1-2**64 .. 2**64-1], BFE>>А причём тут числа? TB>Действительно, какое же отношение тип имеет к числам.
Вот правильный вопрос. Ответ — опосредованное.
BFE>>откуда вы взяли степень 64? зачем 64? TB>Интересно, и сколько же битов у usize на большинстве современных компов.
А ещё интересно сколько памяти на большинстве современных компов.
BFE>>Есть принципиальная разница между порядковым числом и числом выражающим количество. А то, что большинство их всё время путает — ну это проблемы большинства. У меня есть код в котором индекс — это unsigned int по модулю размера массива. И никаких проблем с выходом за пределы массива. TB>И как ты в своём коде выполняешь операцию "циклически перейти к предыдущему элементу"?
Как обычно, с помощью итераторов. Для этого индексы вообще не нужны.
Если же в общем случае, то index = (index + offset) % size
BFE>>Позиция шахматной фигуры — это беззаконное целое по модулю 8. TB>Я ж не про шахматы на торе
А вы вообще не про шахматы, потому что в шахматах ход на произвольное значение невозможен.
Здравствуйте, B0FEE664, Вы писали:
TB>Действительно, какое же отношение тип имеет к числам. BFE>Вот правильный вопрос. Ответ — опосредованное.
Правда? А в спецификации прямо сказано, какой диапазон у какого типа на какой платформе.
BFE>А ещё интересно сколько памяти на большинстве современных компов.
А какая разница? Тип usize такой, какой он есть.
BFE>Как обычно, с помощью итераторов. Для этого индексы вообще не нужны.
И как итератор позволяет перейти циклически на 1 элемент назад?
BFE>Если же в общем случае, то index = (index + offset) % size
А для отрицательного оффсета как?
BFE>А вы вообще не про шахматы, потому что в шахматах ход на произвольное значение невозможен.
Очевидно, что я про внутреннюю реализацию шахматного движка, а не про возможность игрока двигать любую фигуру на любое поле.
Сорян, даже полный наркоман, свихнувшийся на Александреску, не сможет записать корректный ход шахматной фигуры, чтобы его корректность выражалась на уровне системы типов.
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
