Войти
ПрограммированиеФорумОбщее

Типизированные int'ы (7 стр)

Страницы: 14 5 6 7 8 9 Следующая »
#90
22:43, 15 июля 2019
+ типа шутка
#91
1:21, 16 июля 2019
Ranma
лол, доставил коммент
>Why in one thread?
#92
5:59, 16 июля 2019

NyakNyakProduction
> Объём срача вокруг реализации этого уже намекает, что проблема есть.
Ну, я для себя проблему уже решил :)

Olaf85
> Есть ф-ция CreateWidget, в которую передаются 5 юинтов - координаты x, y, ширина, высота, флаги. Это что, по вашей философии 5 типов создать чтоб не перепутали?
Кстати, вот чудный пример сабжа. Rect vs rect:
1. left, top, width, height
2. left, top, right, bottom
неужели никто не наступал хоть немного на путаницу в двух последних параметрах? :)

Ranma
> HelloWorld небось по такому же образу и подобию пишете?
Ну, да, как говорится, "без фанатизма!" :D
Но, знаете, я давно как-то проходил собеседование в одну распределённую контору, они пишут какой-то навороченный он-лайновый офис. Мне дали простое тестовое задание: написать класс для работы бухгалтерии с сотрудниками, или чё-то типа того, там получалось пару классов надо было сделать. Потом мы стали с интервьюером разбирать код, и он стал задавать вопросы, почему так, почему так?... На мои ответы он задавал ещё более уточняющие вопросы. В общем, смысл был такой: надо не просто написать (конечный) код, а вложить в него нужный потенциал для дальнейшего развития. Иными словами, когда вы пишите "hello, world!", вы не пишите же его только ради вывода этой строчки, вы что-то в голове планируете делать с этим дальше, и вы должны заложить в код соответствующий потенциал. Не обязательно его писать прям сейчас, но код должен быть написан так, чтобы его можно было быстро начать развивать в нужном направлении. И автор должен уметь и понимать это, что нужно, а что нет. Собственно, ребятам нужен был самостоятельный разработчик, который сможет разумно развивать свою часть кода, поэтому были такие вопросы и такой подход, они хотели увидеть, как я работаю стратегически. С тех пор я отношусь к любому коду не как к статическому набору инструкций и описаний, а как к текущему состоянию кода, стараюсь видеть, как он будет развиваться далее. Вот тот пример про яву, конечно, "с фанатизмом" и забавный, но для меня он смешной с другой стороны, так сказать :)

#93
8:05, 16 июля 2019

https://habr.com/ru/company/piter/blog/460149/

#94
(Правка: 8:30) 8:16, 16 июля 2019

StepEver
> неужели никто не наступал хоть немного на путаницу в двух последних параметрах?
> :)
Сколько человеко-рублей вы потратили на эту путаницу? У вас проблема, которая обнаруживается при первом запуске программы. А уж код этот вы пишете 1% времени от любого полезного кода.

Завтра приходит геймдизайнер Вадим и говорит, что теперь помимо астероида корабль может атаковать рубероид. Через неделю кокс и деньги в стартапе кончаются, и СТО решает, что теперь наша игра должна распространять мальварь, чтобы хоть что-то заработать. Теперь корабль может атаковать сокеты.

Что дальше? Шаблонизированная функция? Switch по какому-нибудь typeof(attacked_id)? Как вы будете ограничивать, что пойдёт в шаблон? Опять наследование, виртуализация? Потом придумаете литералы для каждого типа, чтобы по сети передавать, будете строкой все числа слать?

#95
8:53, 16 июля 2019

NyakNyakProduction
> Сколько человеко-рублей вы потратили на эту путаницу?
Да фиг знает, просто я её помню, что пару-тройку раз задавался вопросом, глядя в код. И, думаю, пару раз даже ошибался. Потому что ректы каждый формирует по своему усмотрению.

NyakNyakProduction
> Что дальше? Шаблонизированная функция? Switch по какому-нибудь typeof(attacked_id)? Как вы будете ограничивать, что пойдёт в шаблон? Опять наследование, виртуализация? Потом придумаете литералы для каждого типа, чтобы по сети передавать, будете строкой все числа слать?
Это драматизация и нагнетание чувств! :D
Как я уже сказал, я проблему (для себя) решил (небольшой код пару страниц назад, потратил семь минут, чтобы придумать и проверить), больше пока проблем нет.

Но, раз уж мы затронули тему, у меня была такая реализация, "с интами": в функции передавались ноды (кто на Юнити работал, тот поймёт), а внутри, в зависимости от ситуации, с этих нод брались компоненты "астероид", "рубероид", "сокет" и так далее. Если компонент получен, работаем с ним. Если нет - нет. Вроде и удобно было, но часто возникают такие ситуации, которые надо обрабатывать кодом: для начала надо снять компонент(ы) с ноды, а потом: есть ли компонент? а один ли он? а если не один, то что? И так далее. Гораздо удобнее передать ссылку на сильно типизированную коллекцию, чем потом сидеть с хрустальным шаром над нодой. Ну это чисто моё мнение. Плюсы хороши тем, что на каждую проблему существует несколько достаточно идеальных решений, на любой вкус. А абсолютного идеального решения в этой вселенной не существует.

#96
(Правка: 9:05) 9:04, 16 июля 2019

Suslik
> для них при этом автоматически будут все операторы как для базовых интов,
> только между ними не будет неявных кастов. аргумент в угловых скобках здесь —
> не шаблонный аргумент, а что-то вроде тега, то есть если у двух разных типов
> тег одинаковый, то они совместимы. это как размерность, то есть legs и level —
> это что-то вроде единиц измерения.
Я задавал выше вопрос, с примерами кода. Хорошо, неявные касты между "размерными" типами будут запрещены. А как быть с кастами между размерными и безразмерными? И что получать в результате вызова функций? У нас будет такое:

set_character_level(static_cast<int<level>>(static_cast<int>(old_level) + 3));
Или какое?

> в любом случае код использования таких функций никак не должен отличаться от
> кода с одинаковыми интами повсюду.
Вот как этого добиться в реальном коде, а не в "хотелось бы, чтобы можно было"? Повторю вопрос - как объяснить компилятору, что sqrt(float<sqare>) должен вернуть float<length>?

#97
9:09, 16 июля 2019

Went
> Повторю вопрос - как объяснить компилятору, что sqrt(float) должен вернуть float<length>?
Я бы перегрузил функцию
CMeters sqrt(CMeters2 sqrMeters);

#98
9:15, 16 июля 2019

StepEver
> Гораздо удобнее передать ссылку на сильно типизированную коллекцию, чем потом
> сидеть с хрустальным шаром над нодой.

Об этом и речь, выбросите типизированные инты в мусорку. У вас будет коллекция по которой уже понятно, какой там id, дальнейшая типизация бесполезна. Никакая типизация не защитит вас от попадания туда непонятного объекта. Дело всегда будет в ошибке в логике заполнения. Но когда у вас трансформация по коллекции, то и факап у вас будет заметный.

#99
(Правка: 9:30) 9:28, 16 июля 2019

NyakNyakProduction
> Об этом и речь, выбросите типизированные инты в мусорку.
Ну уж нет, я придумал чудное решение, надо его будет применить :D

NyakNyakProduction
> У вас будет коллекция по которой уже понятно, какой там id, дальнейшая типизация бесполезна. Никакая типизация не защитит вас от попадания туда непонятного объекта. Дело всегда будет в ошибке в логике заполнения. Но когда у вас трансформация по коллекции, то и факап у вас будет заметный.
Это всё так, но изначально проблема про не торчащие/входящие коллекции, а механизмы воздействия/доступа к ним. Когда передаём в функцию 2 индекса, для двух разных коллекций, где объект одной, к примеру, что-то делает с объектом другой. Легко на входе перепутать индексы. Не, я согласен, любую проблему можно решить архитектурно (2 функции, с хорошими именами, возвращают отдельно два объекта, которые потом), но иногда было бы удобнее и быстрее сделать именно так, одна функция и два типизированных индекса, просто чтобы избежать ошибки перемены мест.
Ну или ещё пример, у меня ПДУ от телевизора с двумя одинаковыми кнопками для переключения каналов и для регулировки звука. Расположены симметрично. Я их иногда путаю :D
upd: решением для ПДУ было бы: развернуть одну кнопку на 90 градусов, сделав её "сильно типизированной" для пальца. Т.е. на ощупь я могу понять, кнопка давится вверх-вниз, или вправо-влево.

#100
9:37, 16 июля 2019

User-defined literals кто-нибудь уже предлагал?

#101
9:58, 16 июля 2019

В Аде такое из коробки есть.

#102
10:04, 16 июля 2019

MrShoor
> В Delphi можно написать так:
>
> type
> TMyNewSuperType = type of Integer;
А вектор с индексами именно этого типа можно?

#103
(Правка: 10:11) 10:09, 16 июля 2019

StepEver
> Я бы перегрузил функцию
> CMeters sqrt(CMeters2 sqrMeters);
И сколько функций тебе придется перегрузить? В реальной игре сотни параметров, над которыми проводятся тысячи разных операций. Если говорить про С++, то там еще и куча шаблонной магии со специализациями. И теперь вместо специализации по реальному типу, начнем писать еще и специализации по размерностям, потому что мерности будут постоянно где-то теряться, нужно будет постоянно что-то дописывать, потом дописывать перегрузки станет лень и начнутся касты и анти-касты наподобие тех, что я выше привел.

Опять же, если говорить про С++, то, наверное, стоит копать куда-то в сторону атрибутов, которые ввели в новых версиях (псевдокод):

class Character
{
  [[metric = level]] int level() const;
  void set_level([[metric = level]] int);

  [[metric = legs]] int legs() const;
};

Character c1, c2;
c1.set_level(c2.level() + 1); // ОК. Компилятор как-то распространит атрибут metric на результат сложения и решит, что все нормально.
с2.set_legs(c1.level()); // Warning. Метрики не совпадают.
Если плясать вокруг этого, то можно пойти дальше, и разрешить делать так
class Character
{
  using Level = [[metric = level]] int;
  using Legs = [[metric = legs]] int;

  Level level() const;
  void set_level(Level);

  Legs legs() const;
};
Плюс такого подхода, что компилятор может вообще забить на эти атрибуты и код продолжит работать. Или программист, который не боится раз в три года ошибиться метриками, просто подавит неприятный ворнинг.

#104
10:47, 16 июля 2019

Went
> И сколько функций тебе придется перегрузить?
В данном примере - одну.

> В реальной игре сотни параметров, над которыми проводятся тысячи разных операций.
Да, и там всё равно придётся писать int-ы в параметрах, так может иногда потратить пару минуть и добавить классы для индексов, чтобы не путаться в этих тысячах int-ов? Я не знаю, надо смотреть на конкретную игру. В любом случае, можно сделать просто, если хочется. Но можно и не делать, если не хочется.

>Если говорить про С++, то там еще и куча шаблонной магии со специализациями. И теперь вместо специализации по реальному типу, начнем писать еще и специализации по размерностям, потому что мерности будут постоянно где-то теряться, нужно будет постоянно что-то дописывать, потом дописывать перегрузки станет лень и начнутся касты и анти-касты наподобие тех, что я выше привел.
Драматизм и сгущение красок, как мне кажется :)
Во-первых, специализации для типизированных int-ов не понадобятся, так как они работают по тем же правилам, что и обычные.
Во-вторых, шаблоны, наоборот, разгружают нас от этого. Они позволяют отгородиться от прямой зависимости между классами.

+ оффтоп

Ну и ещё раз напоминаю: типизированные int-ы, это просто ещё одна возможность, а не обязательность.

Страницы: 14 5 6 7 8 9 Следующая »
ПрограммированиеФорумОбщее