Флейм
GameDev.ru / Флейм / Форум / Что даёт такой стиль кода , в чем его плюсы или минусы ? (5 стр)

Что даёт такой стиль кода , в чем его плюсы или минусы ? (5 стр)

Страницы: 14 5 6 7 8 Следующая »
KartonagnickЗабаненwww12 июля 201817:07#60
Ghost2
> Через жопу - это когда нужен вариант. И детектор членов. Универсальный.
ещё через жепю, когда твой член может быть отрицательной длины.

характерная особенность таких черезжёпий: они не в состоянии объяснить,
чем их не устраивает вариант (python смотрит на них, как на говно) ,
или детектор членов. универсальный.
что касается детектора: в с++20+ завезут статическую рефлексию.
черезжопиям не очевидно, зачем она может быть нужна.

Ghost2Постоялецwww12 июля 201819:48#61
Eugene

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

> генерик коллекций типа behavior tree blackboard
ЯННП. У behavior tree blackboard есть какое-нибудь описание для чайников? Чтобы я безоговорочно убедился, что там без вариантов никак?

Правка: 12 июля 2018 19:55

Ghost2Постоялецwww12 июля 201819:55#62
Kartonagnick

> когда твой член может быть отрицательной длины
Чего это ты про члены заговорил? Я там выше вообще то про члены классов говорил.

> характерная особенность таких черезжёпий: они не в состоянии объяснить
Скорее это ты не в состоянии объяснить, зачем все это надо. Люди в космос ракеты запускают,
а в небо - самолеты. На чистом Си. И да, для любого придуманного тобой варианта я смогу
объяснить, почему тут не нужен вариант или детектор. Потому что вся эта ересь нужна только
тогда, когда ты не знаешь, что должно получиться в итоге.

EugeneУчастникwww12 июля 201820:56#63
Ghost2
> Ну то есть для кейса с метаданными варианты не очень то и нужны?
Варианты — нужны. С фиксированным набором типов.

> ЯННП. У behavior tree blackboard есть какое-нибудь описание для чайников? Чтобы
> я безоговорочно убедился, что там без вариантов никак?
behavior tree — паттерн для создания игровой логики, т.е. алгоритмов, протяженных во времени.
Алгоритм — это дерево функциональных узлов.
Чтобы узлы могли обмениваться данными, эти данные лежат в общем контексте. Он же blackboard. Считай, доска, на которой каждый пишет чо надо.
Юзкейс: иметь архитектуру, которая позволяет добавить произвольное число логических узлов, общающихся произвольным образом.

DelfigamerПостоялецwww12 июля 201822:42#64
Kartonagnick
> попробуйте реализовать вариативный тип без union,
Окей.
Там даже есть свинья, но сто пудов никто из вас не догадается.
EugeneУчастникwww12 июля 201822:47#65
Delfigamer
Где выравнивание, билли?
DelfigamerПостоялецwww12 июля 201822:56#66
Eugene
> Где выравнивание, билли?
Дома забыл. :(
Ну вот, а теперь Картонажник прочитает и тоже почувствует себя умным.

Правка: 12 июля 2018 22:57

Ghost2Постоялецwww13 июля 20182:00#67
Eugene

> Варианты — нужны. С фиксированным набором типов.
Я же не про варианты вообще, это все равно что спорить о пользе юниона, а про сложные типы внутри.

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

EugeneУчастникwww13 июля 20183:09#68
Ghost2
> Сам концепт помойки данных мне не сильно понятен я за локальность. Но сильно бы
> игровая логика пострадала, заставь ты узлы обмениваться только примитивными
> типами?
Ну во первых, хотелось бы типобезопасные указатели. А это автоматически type erasure и виртуальности.
Во вторых, не хочется ограничивать пользователей библиотеки фиксированным набором типов, которые они даже изменить не могут без хаков. А все типы сразу не запасешь.
Помойка данных — это тоже архитектура, которая периодически оказывается единственным решением, не причиняющим боль при использовании снаружи.
KartonagnickЗабаненwww13 июля 201811:15#69
Delfigamer
> Окей.
это я и называю: сделать через жёпь.
усложнение на ровном месте.
так делали во времена с++03,
когда юнионы не умели полноценные классы.

соответственно вопрос:
нахира делать сложно, если можно поиметь аналогичный профит просто?

KartonagnickЗабаненwww13 июля 201811:17#70
Delfigamer
> Там даже есть свинья
нет там никакой сфиньи.
KartonagnickЗабаненwww13 июля 201811:18#71
Eugene
> Где выравнивание, билли?
гарантируется new
KartonagnickЗабаненwww13 июля 201811:21#72
Ghost2
> Скорее это ты не в состоянии объяснить, зачем все это надо.
нет смысла что то объяснять дибилам.

если ты не считаешь себя дибилом,
тогда у тебя хватит мозгов самостоятельно выяснить,
зачем комитет хочет завести в кресты статическую рефлексию.
(а если не хватит, значит - дибил)

EugeneУчастникwww13 июля 201811:27#73
Kartonagnick
> гарантируется new
Как new может что-то гарантировать, если мы пишем в char m_data[ sizeof( value_type ) ]?
Как должен отработать new для типов с alignof()=16, если хранилище выровнено по 4 байта (как это обычно бывает).
KartonagnickЗабаненwww13 июля 201811:34#74
Eugene
> Как new может что-то гарантировать
Item* item = new Item();

агрегат будет корректно выровнен.

struct Item
  {
    std::atomic< Item* > m_next;
    char m_data[ sizeof( value_type ) ];
  };


поле m_data будет корректно выровнено.

Страницы: 14 5 6 7 8 Следующая »

/ Форум / Флейм / Программирование

2001—2018 © GameDev.ru — Разработка игр