LINUX.ORG.RU

C++ — туда и обратно, или зачем нужен Boost

 , , ,


3

5

Мой предыдущий тред в Development собрал самое большое число ответов аж с сентября, то есть за последние 9 месяцев, и это лишний раз подтверждает упадок этого форума. Полагаю, кто-то должен это изменить, и поэтому мы с тобой, ЛОР, поговорим сегодня про C++.

Начиная с C++26 вместо std::function вводится пачка новых классов: std::copyable_function, std::move_only_function (доступна с C++23) и std::function_ref. Что же не так с оригинальным std::function, ты можешь спросить? А вот что:

#include <functional>
#include <print>

struct call_me {
    int x = 0;
    void operator()() {
        std::print("x was {}\n", x++);
    }
};

int main() {
    const std::function<void()> f = call_me{};
    f();
}

Несмотря на то, что переменная f объявлена константной (люблю оксюмороны!), у неё есть внутреннее состояние и оно меняется при вызовах. Компилятор это без проблем хавает.

Так вот, ковыряясь в том, зачем и кто вообще смог так насрать себе в штаны сам, я наткнулся на статью ребят, которые подводят список подобных косяков комитета C++, когда фичи живут по 10 лет и объявляются устаревшими.

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

  • Известный vector<bool>, живущий издревле в STL и про который все говорят, что его надо избегать. Частично заменяется std::bitset.
  • std::auto_ptr. Бесполезен, ломает контейнеры, выкинут на помойку в C++17.
  • Указание исключений у функции в формате throw(X, Y). Так же выкинуто в C++17.
  • std::iterator объявили устаревшим в C++17, собираются удалить в C++26.
  • std::aligned_storage и std::aligned_union добавлены в C++11, объявлены устаревшими в C++23, скоро удалят.
  • Ключевое слово register удалено в C++17, хотя всё ещё доступно в Си.
  • std::get_temporary_buffer и std::raw_storage_iterator удалены в C++20.
  • Потрясающее по эпичности фиаско с интерфейсом для сборщиков мусора. std::declare_reachable сотоварищи были добавлены в C++11. Выяснилось, что сборщики мусора для C++ писать либо никто не умеет, либо никто не хочет, поэтому в C++23 это всё удалили и сделали вид, что ничего не было.
  • Абсолютное безумие вокруг концептов, модулей и поддержки сети. Предложения одобряли, вновь отклоняли, переделывали, и по итогу теми же модулями до сих пор никто не пользуется.
  • Сопрограммы (coroutines). В том виде, в котором они есть в C++, это просто ужас. Достаточно того, что корутины требуют выделения памяти из кучи во время работы, а значит вообще не подходят для случаях, когда требуется серьёзная производительность. Например, в любом коде, требующим работы в реальном времени и не позволяющем делать системные вызовы.

Просто лютый трешак, который никто подчищать пока не собирается:

  • std::regex – лютый тормоз, рекомендуется не использовать.
  • Мертворождённый std::simd, добавленный в C++26 и уже с ходу не нужный вообще никому, потому что код с std::simd в два-три раза тормознее чем со сторонними библиотеками, просто голыми интринсиками, и даже медленнее чем просто цикл for.
  • std::async. Дескруктор ждёт завершения асинка и поэтому может залочить весь код тебе. Наконец починили в C++26, но эта штука была сломана 15 лет.
  • Отвратительно спроектированный <iostream>. Его наконец можно выкинуть и использовать std::print, но не все про это знают.
  • Абсолютно тормозные контейнеры map, set, unordered_map. Вместо первого можно использовать flat_map из C++23. Контейнеры в стандартной библиотеке Rust (BTreeMap) и другие реализации B-Tree Map их обгоняют по производительности, но тем не менее в C++ выбирают убогий дефолт.

Решения многих из этих проблем существуют в Boost и сделаны там гораздо лучше. Но в то же время возникает важный вопрос: зачем вообще нужен настолько плохо спроектированный язык, где каждое следующее поколение инженеров, работающих над ним, отменяет решения предыдущих, а код под новые стандарты часто нужно переписывать если не с нуля, то очень близко к тому? Даже процесс разработки Rust с его поехавшими клоунами в юбках на этом фоне выглядит адекватным.

В общем, всё печально, ЛОР. Такие дела.



Последнее исправление: CrX (всего исправлений: 3)
Ответ на: комментарий от BruteForce

если честно, до опр. момента, я так же писал, и был уверен что это удобно, пока не начал проверять гипотезы, и в один момент наткнулся на опровержение своего же подхода, и теперь я уверен, что наследование нужно, но до этого я знал, что шаблоны помогают, и по-тихоньку подходил к ним, да я признаюсь и щас до сих пор проверяюсь в шаблонах, но когда я на руках увидел 2 рабочих примера, без наследования с описанием всего что нужно в таком стиле с композицией, плюс до этого я тестил грид на Расте, и парочку деревьев, я чуть понял, что хотел привнести С++, но это далеко не сразу после обучения.

anonymous
()
Ответ на: комментарий от BruteForce

ну новичковый пример самой проблемы вам не понравился, тут проблема состоит в том, сколько раз или действий надо сделать, чтобы достигнуть того-то поведения, пока это вписывается в рамки, что пока незаметно и это ок - ок, но когда проверка гипотезы, это просто куча кода, пускай и через свитч стянутое в 1 класс, ну просто потомучто так удобно, тут начинается момент с читаемостью, и архитектурой, и тут обычно, достаточно просто увидеть вот тоже самое на архитектурной рельсе, и просто сохранить, и понять, что просто на не глубокой наследуемости, можно просто гибче описать модель архитектуры.

anonymous
()
Ответ на: комментарий от anonymous

перечислять парент-чилд, делая вид что не существует этой механики в языке, о дааааааа улыбка.jpg

Кого где перечислять?

напишите УИ

https://doc.qt.io/qt-6/qml-tutorial2.html

https://react.dev/learn/tutorial-tic-tac-toe

https://github.com/ocornut/imgui

https://github.com/immediate-mode-ui/nuklear

Ну и сам я писал, например вот:

раз, QML

два, clay

HTML+CSS также я отнёс бы к композиции; в CSS только часть свойств наследуется, а наследования классов нет вообще.

В общем случае, могу сказать: если вам так нравится я не против, напишите УИ в таком стиле, иметь 7000 миллиардов сущностей с жесткими связями и тонны бойлерплейта, начитавшись учебников по цепепе, о дааааааа улыбка.jpg

BruteForce ★★★★
()
Ответ на: комментарий от anonymous

я знал, что шаблоны помогают, и по-тихоньку подходил к ним, да я признаюсь и щас до сих пор проверяюсь в шаблонах, но когда я на руках увидел 2 рабочих примера

При чём тут шаблоны? Где в твоём коде шаблоны? Шаблоны стоят перпендикулярно к наследованию.

в один момент наткнулся на опровержение своего же подхода, и теперь я уверен, что наследование нужно

Может ты продемонстрируешь его и я вступлю в секту Наследователей?

я тестил грид на Расте

Кто этот дядька? Корпорат или комитетчик?

BruteForce ★★★★
()
Ответ на: комментарий от BruteForce

ну так потомучто это был подход в лоб(самый первый так сказать) - «щас напишу без наследования и будет работать», да чанкменежэр - это не иерархия ограничивающих обьёмов например, а привязка кубов - которые наполнены кубами, к координатам.

anonymous
()
Ответ на: комментарий от anonymous

Ну сравни читаемость и архитектуру твоего примера и моего.

  • У тебя на 27% больше кода: ты в нём допустишь на 27% больше ошибок.

  • У меня одна сущность с одним обработчиком, у тебя 3 сущности и 2 обработчика.

  • Твой код компилится шлангом в 453 строчки асм, мой в 151.

  • Когда окажется, что нужны indestructable игроки ты откуда наследоваться начнёшь?

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

Ну показывай.

BruteForce ★★★★
()
Ответ на: комментарий от BruteForce

так правильно я и показал, базовый елемент это тот елемент от которого наследуемся, вторую глубину можно не делать, оставить 1 наследование, и там от елемента пронаследовать всё что нужно в УИ

Element -> Button Widget

Element::onUpdate();

anonymous
()
Ответ на: комментарий от BruteForce

как оказалось плоское программирование пускай и на свиче это как раз минус, 1 уровень наследования, вот с этим вот уже удобнее, нет БЯМ мне не делала, она мне подсказывала, как запустить например С++ на емскриптен, как сделать атлас ), как сделать статичный рект, чтобы БЯМ сделала, архитектура должна быть успешнее, а это как раз что-то из 90ых, но щас не об этом, а о том на сколько удобно иметь 1 глубину наследования и как удобно запускать в детях Elemnt::update(); и не видеть ту лапшу, какая например у меня вот чуть по-выше, хоть пускай и рабочее.

anonymous
()
Ответ на: комментарий от anonymous

Ну скажи мне, чем твоё не видеть содержимое Elemnt::update()

void Button::update() {
    Elemnt::update();
}

от, например, такого

void Elemnt::update() {
    base_update();
}

отличается???

И вообще, тебе скроллить в текстовом редакторе запретили? PgDown на клаве нет? В чём проблема ВИДЕТЬ общий для всех элементов код без необходимости открывать второй файл?

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

  1. Ты привёл не 1 уровень наследования.

  2. Примеры, где что-то «оказалось» будут?

  3. Что за плоское программирование и чем оно отличается от впуклого?

BruteForce ★★★★
()
Последнее исправление: BruteForce (всего исправлений: 2)
Ответ на: комментарий от BruteForce

там в примере нет шаблона, вы правы. https://godbolt.org/z/4heaWcfjh - вот пример с 1 глубиной уровня наследования. ну кубики рисовать по началу в композиции удобно да еще и на расте с его многопоточкой, но когда дело доходит до нормальной архитектуры УИ, чтобы она была отдельным завершенным модулем, чтобы подключил в проект, настроил слои, накидал визуал, и оно завелось, можно же пойти по пути наименьшего сопротивления, и просто рисовать отдельно в GL при помощи MDI - типо DOD стиль, где нет ни паттерна ни архитектуры, просто рисуем как есть и обыгрываем логику включений, тут как не крути, даже самый новичек-новичков, дойдя до этого вопроса даже без многопоточки просто с 1 статичной ограниченной сценой, задасться вопросом как удобнее обыграть УИ, чтобы а - его легко было врубить б - переиспользование. в - пускай первые итерации по незнанию могут быть на а - без архитектур и без паттернов просто данные б - на бсп или бвх в - тут уже пойдут книжки и конкретика, как сделать удобно с отрисовкой сцены

anonymous
()
Ответ на: комментарий от BruteForce

писать язык, выбор каждого, наверняка есть разные подходы, можно не ударяться в создание своего скриптового языка, а отполировать сначала, самый базовый функционал УИ. Чтобы и текст и кнопочки и скролбары были на месте и было удобное использование, самое главное, чтобы даже можно было легко вставить этот уи, например в текстовый редактор, и там просто пол вопросов после отрисовки текста самого редактора просто отпадает, если завершить базовый УИ

anonymous
()
Ответ на: комментарий от anonymous

https://godbolt.org/z/4heaWcfjh - вот пример с 1 глубиной уровня наследования.

Ну теперь добавь танк, свойство team всем игрокам и undestructable игроков.

чтобы она была отдельным завершенным модулем, чтобы подключил в проект, настроил слои, накидал визуал, и оно завелось,

Ты продолжишь отрицать существование DearImGui?

BruteForce ★★★★
()
Ответ на: комментарий от BruteForce

ладно, я понял. прикол в том, что надо понять как сделать с нуля до демки, попутно изучая, всё что надо, тоесть понять бвх - это ок, но потом надо понять многопоточку, и вот щас у меня момент просто понять УИ, можно и DearImGui поставить, и сразу анриал - это согласен. Можно так же пытаться и WM свой писать, поняв УИ, можно покопаться и с WM в Xephyr, знаю следующий вопрос, завтра не станет иксов, что тогда? будем вейланд изучать точно также…. )

anonymous
()
Ответ на: комментарий от anonymous

Ты вообще читаешь сообщения, на которые отвечаешь?

Вот тут ты привёл два раковых примера. Я тебе на это указал и даже показал один из менее опухолевых вариантов. Ты ответил «азазаз ну напиши без наследования УИ, когда боженька дал Derived:Base», и тогда я привёл в пример готовые и очень популярные проекты, где для создания UI не используется наследование: QML, React, ImGui, Nuklear, каждый из которых гораздо приятнее для разработчика чем какая-нибудь QtWidgets, а также заметил, что HTML/CSS тоже не очень-то напоминают тот кал, что ты принёс в комменты.

И ты соглашаешься, что CSS это скорее композиция, а не наследование.

Я спрашиваю, как ты оцениваешь другие примеры, которые я привёл? Что с clay, который позволяет быстро и просто накидывать лейауты?

А ты мне пишешь про «писать язык». Какой к чёрту язык? Кого писать? Ты о чём вообще?

Ты троллишь меня? Ты отвечаешь как БЯМ: забыл контекст и выдал рандомные слова. Ты БЯМ или тролль, колись!?

Также хочу заметить, что твои чудо-примеры на цепепе и расте не касались UI, а были про сущности с названием Player, у которого были health и name. Это что за виджет такой был?

BruteForce ★★★★
()
Ответ на: комментарий от anonymous

Что понял? Кто понял? Кто такая бвх? Каким потом многопоточку?

Я попросил БЯМ разъяснить мне твой коммент: https://aistudio.google.com/app/prompts?state=%7B%22ids%22:%5B%221cOYGwkvDssJUbAmEUY5MG4QrZgainIMx%22%5D,%22action%22:%22open%22,%22userId%22:%22117161649248296922289%22,%22resourceKeys%22:%7B%7D%7D&usp=sharing

Кажется, БЯМ ещё тупее меня.

BruteForce ★★★★
()
Ответ на: комментарий от BruteForce

пример там о том, как на расте это компоузится, а в С++ наследуется, QML(поэтому я написал про создать язык) - это язык, про реакт я ничего не знаю и яваскрипт.

то что нуклеар и диаримгуй какие-то - окей, не берусь обсуждать, потомучто не знаю. Про clay я просто ничего не знаю.

пример я привёл своего видения в композиции без наследования, а потом увидел с наследованием, но его не привёл. а просто описал, что можно от 1 елемента пронаследоваться.

anonymous
()
Ответ на: комментарий от BruteForce

wiki/Иерархия_Ограничивающих_Обьёмов - это грубо говоря коробки - описываемые 2 квадратами, кубик образно, который является обьемом. в 3д это куб, в 2д, это квадрат, соотв там есть манёвры, но не очень удобно как может оказаться или надо по-больше знать. в противовес этому есть в 3д тематика грид-бейзед подход, это воксельная тематика, она просто интересная.

так вот в воксельной тематике в многопоточку проще зайти(продолжить), чем в мирах где например BVH+-ландшафт, тоесть тут придётся вникать в BVH как продолжать в многопоточку, в OpenWorld, по типо как в воксельном.

причем сдесь УИ, потомучто хочется свой УИ по нормальному как понятно типо, да и где-то читал, пока сам делаешь лучше понимаешь.

anonymous
()
Ответ на: комментарий от anonymous

QML(поэтому я написал про создать язык) - это язык

QML -> язык -> писать -> «писать язык, выбор каждого»

Такая логика? Не пиши ещё один QML! Более того, я даже не призывал тя использовать QML. Я опровергал твоё голословное утверждение, что писать UI без наследования трудно.

про реакт я ничего не знаю

то что нуклеар и диаримгуй какие-то - окей, не берусь обсуждать, потомучто не знаю.

Ты берешься обсуждать Rust и C++ на базе своего незнания, вот тут, ещё больше вот тут и тут (linux.org.ru) (будто бы работа с цепепе связана с наследованием, будето бы в C нет «деструкторов»).

Про clay я просто ничего не знаю.

Страшно, да? При этом Clay это C, Nuklear это C, QML написан на цепепе, DearImGui на цепепе………… И вот ведь дураки какие-то находятся, тащат это всё в свои вонючие проекты, «перечисляют парент-чилд», блин!!!!И не лень им копаться в ужасной архитектуре своего UI без нормального наследования в 1 уровень!?!?

пример я привёл своего видения в композиции без наследования

Твоё видение композиции без наследования — рак. Твоё наследование в этих примерах — тоже рак. Будут здоровые примеры?

BruteForce ★★★★
()
Ответ на: комментарий от BruteForce

а тут тонкий нюанс, что мы понимаем под нормальным наследованием при плате по проходу в стиле наследование+парент-чилд, очевидно, что по кешу проигрыш, просто удобнее в проектировании получается.

нету у меня нормального примера наследования.

anonymous
()
Ответ на: комментарий от anonymous

Ты меня убьёшь сегодня, машина) Миры и ландшафт, кубы…… Спасибо, буду знать, что 2д куб это квадрат с соответствующими манёврами.

потомучто хочется свой УИ по нормальному как понятно типо

Ты с вопросами пришёл или с ответами? Если с вопросами — задавай. если с ответами — отвечай за свои ответы.

Напоминаю, начал ты(этот и два последующих коммента) не с UI, а с наследования, и я отвечал тебе на цепепе-раст рак с сущностями Player.

BruteForce ★★★★
()
Ответ на: комментарий от anonymous

нету у меня нормального примера наследования.

Слив засчитан.

очевидно, что по кешу проигрыш

Кто кому по кешу проигрывает?

удобнее в проектировании получается

Что удобнее в проектировании получается?

Что здесь очевидного, я тоже не понимаю.

BruteForce ★★★★
()
Последнее исправление: BruteForce (всего исправлений: 1)
Ответ на: комментарий от BruteForce

что 2д куб это квадрат с соответствующими манёврами. как попытка можно попробовать сделать уи так и посмотреть что будет, именно в этой части нужны знания(хорошо/плохо/удобно/неудобно) сама суть иерархии для передвижения и расчета коллизий отрабатывает в 3д. на цепепе-раст рак с сущностями Player. ок. Кто кому по кешу проигрывает? DOD быстрее будет. Что удобнее в проектировании получается? OOP c 1 уровнем наследования в УИ для меня лично. чем с композицией всего этого в лапшу ту, там я кидал набросок, который видя, после наследования от елемента, уже не хочется даже тестить на расте.

anonymous
()
Ответ на: комментарий от anonymous

что 2д куб это квадрат с соответствующими манёврами.

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

сама суть иерархии для передвижения и расчета коллизий отрабатывает в 3д.

на цепепе-раст рак с сущностями Player.

ок.

Кто кому по кешу проигрывает?

DOD быстрее будет.

Что удобнее в проектировании получается?

OOP c 1 уровнем наследования в УИ для меня лично. чем с композицией всего этого в лапшу ту, там я кидал набросок, который видя, после наследования от елемента, уже не хочется даже тестить на расте.

anonymous
()
Ответ на: комментарий от BruteForce
— А ты кто такой? Откуда взялся?
— С того берега моря.
— На чём приехал?
— Оседлал хромую блоху, сел и приехал.
— Море что, лужа?
— Может, и лужа, да только ту лужу орёл не перелетел.
— Значит, орёл — птенец?
— Наверное, птенец, но тень от его крыльев город закрывает, в городе ночь настаёт.
— Город, небось, крохотный?
— Через тот город заяц бежал, не перебежал.
— Выходит, заяц маленький?
— Заяц как заяц, из его шкуры тулуп вышел.
— Куда вышел?
— Вышел из того города, где заяц бежал, на который тень от орла упала, и пошёл куда глаза глядят.
— Чьи глаза?
— Глаза того тулупа, который из шкуры зайца вышел, в городе, где ночь настаёт, когда над ним птенец пролетает верхом на хромой блохе.

© «Ух ты, говорящая рыба!»

shdown ★★
()
Последнее исправление: shdown (всего исправлений: 1)
Ответ на: комментарий от BruteForce

там всё можно сделать даже с ООП в модуле, например ui_model.cppm, проблема в том что на етапе проектирования можно сначала оттестить это в инклудах, потом это кинуть в модуль.

class Element{
protected:
 std::string m_name;
 Element* m_parent{ nullptr };
 std::vector<std::unique_ptr<Element>> m_children;
public:
 virtual ~Element() = default;
 Element(const UIElement&) = delete;
 Element& operator=(const Element&) = delete;

 Element(Element&&) noexcept = default;
 Element& operator=(Element&&) noexcept = default;
 virtual void HandleInput(const SDL_Event& event) {
 }
 void AddChild(std::unique_ptr<Element> child) {
   if (child) {
     child->m_parent = this;
     m_children.push_back(std::move(child));
   }
 }
 virtual void Update(float deltaTime) {
    if (!m_visible) return;

     // Обновляем всех детей по цепочке
     for (auto& child : m_children) {
       child->Update(deltaTime);
     }
 }
 virtual void Render(SDL_Renderer* renderer) {
 }
 //get/set итак далее
};
anonymous
()
Ответ на: комментарий от BruteForce

https://godbolt.org/z/P8W99cG1W ну вот реальность 1

https://godbolt.org/z/oq6j77eK1 вот реальность 2

на расте вам не понравилась композиция, там же еще события нужны

https://godbolt.org/z/q4hM1jvsz вот еще пример композиции, всё плохо да?

anonymous
()
Ответ на: комментарий от BruteForce

А ты мне пишешь про «писать язык». Какой к чёрту язык? Кого писать? Ты о чём вообще?

я о том, что есть разметка это скорее всего язык, если это после инициализации динамически добавлять, это же надо команду сделать поидее, потом если человек её будет писать её можно распарсить, получается, мы приходим к синтаксису разметки для execute внутреннего dsl - тоесть подмножество для описания макета, после реализации которой можно отказаться от текстовой разметки, и всё писать по разметке на dsl внутреннем.

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

anonymous
()
Ответ на: комментарий от anonymous

У меня есть просьба и совет:

  1. Не шли людям портянки БЯМ. Если твои собеседники захотят пообщаться с БЯМ, они сделают это в обход тебя. Люди тратят своё время на ответы тебе, отвечать им ответами БЯМ — проявление неуважения. Понравится ли тебе, если я ЧатуГПТ дам свой пароль от ЛОР, он залогинится и будет отвечать на твои сообщения портянками по 100 строчек?

  2. Не используй БЯМ. Загубишь своё будущее! У тебя слишком мало опыта, тебе нечего противопоставить чуши, которую БЯМ тебе льёт вёдрами. Тебе кажется, что у тебя прогресс и всё получается, но это дорога в никуда.

BruteForce ★★★★
()
Ответ на: комментарий от BruteForce

ну покажите здравый подход тогда если мои тесты рак, как вы пишите, и вы поняли что я не знаю, вы тогда обязаны показать кристаллик свой, или не кристаллик, а то что для вас нормик? или это всё только в одном направлении? а как вы опыт получаете? вот мы пришли к тому, а к чему? к тому что у меня не так?) но у вас тогда никак) или кинуть clay и это ок? или хэлп заключается в том, что гоу писать портянки на С/Rust, это опытно ), а в Расте при всём этом боров вам советует, в С++ вы кинули только свитч, а задали вопросов больше, причем не углублялись как я понимаю, потомучто QML с наследованием скорее всего, как и кути…

anonymous
()
Ответ на: комментарий от BruteForce
#include <iostream>
#include <string>

struct GO {
    enum Type {
        NONE,
        PLAYER,
    } type{NONE};
    char name[16]{};
    int32_t health{};
    int32_t score{};
};

void go_update(GO*obj) {
    std::cout << obj->name << " обновлен\n";
    switch (obj->type) {
    case GO::PLAYER: {
        std::cout << "Игрок проверяет ввод...\n";
    } break;
    default:;
    }
}

void go_take_damage(GO*obj, int32_t amount) {
    obj->health -= amount;
    std::cout << obj->name << " получил " << amount << " урона. ХП: " << obj->health << "\n";
}

int main() {
    GO player = {.type = GO::PLAYER, .name = "Герой", .health = 100};
    go_update(&player);
    go_take_damage(&player, 20);
}

тоесть этот пример вам кажется удобнее, если начнём его развивать в чилдрен-парент да?) зачем вам тогда С++? если можно эффективно управление памятью на С написать, и вы выше писали как я понял возмущение что типо в С нету деструктора, дескать как я понял это в укор типо, типо есть деструктор да?

anonymous
()
Ответ на: комментарий от anonymous

суть то в чем, есть архитектура,

есть сцена 3д/2д - как не крути это узел

есть 2д уи,

суть в том, что несмотря на то в С текстовый редактор или в С++ игра, пуск луча будет проходить сначала в точку клика в уи потом сцену, для этого не надо бям запускать

anonymous
()
Ответ на: комментарий от anonymous

Слушай, ты задаёшь вопрос про кристаллик, а сам не заметил, что кристаллик не поворачивается (он симметричный). Здравый подход — это когда ты сначала делаешь git blame на свою карму, а потом уже спрашиваешь, почему у тебя тесты рак.

Насчёт «в одном направлении» — да, опыт вообще штука однонаправленная, как #include в C++ (не может быть цикла). Ты спрашиваешь, как я опыт получаю — а я получаю его точно так же, как Rust получает наследование: через боль, три уровня абстракции и невнятный impl, который никто не может дебажить.

Про «кинуть clay» — окей, это нормально, но готовься, что clay у тебя протечёт прямо в рантайм.

К тому, что у тебя «не так» — в Rust боров тебе советует, потому что боров — это единственный, кто читает твой код внимательно, в отличие от ревьюеров.

Кути вообще вроде по делу, но ты потом три дня разгадываешь, что signal на самом деле emit'ился до того, как ты подписался на slot. Это не баг, это тебе карма за прошлую жизнь.

shdown ★★
()
Ответ на: комментарий от shdown

а может у меня не инклуд, а модуль, а кидаю примеры переработанные в инклуд чтоб читаемее было. clay, я вообще не знаю.

Я лично для себя понял, что можно остаться в понимании уровня Раст без понимания принципов где помогает наследование.

anonymous
()
Ответ на: комментарий от anonymous

Ну так профессионалы на C движки пишут ровно так же, как шаманы бьют в бубен — по наитию, но с строгим соблюдением техники безопасности и дисциплины.

Виртуалка и песочница от движка — это не ограничение, это просто способ движка сказать «я тебе не доверяю, но и без тебя не могу», прямо как borrow checker, только без borrow checker'а, поэтому в C у тебя эта функция размазана по трём файлам и одному bash-скрипту, который генерирует остальное в билд-тайм.

Понимаешь, ты не компилируешь код, ты договариваешься с компилятором, чтобы он не заметил, что у тебя UB в hot path уже третий квартал. ДСЛ тут не при чём вообще — ДСЛ это как QML для тех, кто не любит QML, то есть просто ещё один слой абстракции, который в итоге транспилируется в тот же самый switch, который тебе уже кидали в C++, только теперь он генерируется макросом, а не человеком, что как бы честнее.

А песочница движка — она нужна не для тебя, она нужна чтобы моддеры не уронили весь рантайм одним while(true) { spawn(); }. Профессионалы же живут вне песочницы, у них там memory arena, ручной аллокатор и один программист, который знает, где лежит вся правда о жизни — обычно в файле utils_v2_final_FINAL.c.

Короче: ДСЛ — это не про табу, это про то, что кто-то один раз объяснил компилятору, что такое «уровень», а все остальные теперь просто наследуют его травму.

shdown ★★
()
Ответ на: комментарий от anonymous

Ну смотри, твой GO — это прекрасно, пока у тебя один enum и один switch, но как только ты начнёшь его «развивать в чилдрен-парент», у тебя switch превратится в дерево из двадцати case'ов, и это дерево будет называться «полиморфизм, который мы делаем себе сами, руками, без анестезии». Вот тут-то тебе и понадобится _нормальный_ C++ — не потому что он лучше, а потому что он просто уже придумал название для того, что ты всё равно напишешь: vtable.

Только у тебя это будет vtable, собранная на коленке из указателей на функции внутри структуры, и каждый новый GO::Type — это ещё один if, который кто-то забудет обновить в 2027 году. Насчёт деструктора — это не укор был, это констатация факта, что вода мокрая. В C у тебя нет деструктора, поэтому у тебя есть go_destroy(GO*), которую ты обязан вызвать сам, руками, каждый раз, во всех местах, включая тот один exit-path в error-handling, который ты забудешь через полгода.

RAII — это не «есть деструктор да», это когда тебе не нужно помнить об этом вообще, потому что компилятор помнит за тебя. Эффективное управление памятью на C — да, можно, кто спорит. Только эффективное оно ровно до тех пор, пока проект не вырастет и ты не начнёшь писать свой собственный allocator, свою собственную систему owner-ства, свою собственную reference-counting логику — то есть ты всё равно напишешь C++, только без синтаксического сахара и с большей вероятностью написать use-after-free в пятницу вечером перед релизом. Так что «удобнее» и «то, во что оно превратится через триста GO::Type» — это разные вопросы. C++ тут не потому что нужен, а потому что он экономит тебе изобретение велосипеда, который у тебя и так уже наполовину изобретён в этом самом enum.

shdown ★★
()
Ответ на: комментарий от shdown

в С нет модулей, как бы не было так, когда движок жирок отрастит, при вводе в IDE, процессор выжил, еслиб были модули в С, этоб была уже история не про Раст, а про С.

С++ создавался поначалу именно, что как С с классами, но как я понял, с своего не проф. уровня, пришло понимание тонкости, и понять это было тогда видимо так тонко, что щас некоторое пишется буквально парой строчек, а на С и Расте лапша, и поверив сегодня в Раст, можно еще глубже занырнуть в легаси получается, так и не упростив себе ситуацию наследованием это вообще парадокс нашего времени получается, тоесть боров или наследование получается вопрос. Вопрос риторический.

anonymous
()
Ответ на: комментарий от anonymous

Суть-то суть, но луч этот твой не сам себя запускает — кто-то же должен решить, в кого он летит сначала: в кнопку «Инвентарь» или в дракона за ней. И вот это «кто-то» — это уже не архитектура, это политика, а политику на голом C ты тоже можешь написать, просто она у тебя будет называться не hit-test hierarchy, а «полтора if подряд, потому что UI panel всегда рисуется последней, значит и проверяем её первой, ЕСЛИ не забыли».

Узел — да, сцена это узел, кто спорит, дерево есть дерево что в мерзком 3D, что в 2D. Но луч, прежде чем дойти до точки пересечения, обязан сначала спросить: а точка эта — она в screen space или уже в world space, потому что UI у тебя ортографическая проекция поверх перспективной камеры, и если ты это не developер осознал заранее, то твой raycast будет попадать не в кнопку, а в текстуру неба за ней, и это будет не баг, это будет «фича глубины Z-buffer'а», про которую ты потом полгода будешь писать на форумах.

Никто не просит тебя виртуалить весь UI ради одного клика. Но как только у тебя появится drag-and-drop инвентаря поверх сцены с курсором, который должен ещё и tooltip показывать с задержкой в 300мс — вот тут твой честный C-шный switch на raycast начнёт обрастать состояниями, и это состояние будет называться либо «state machine», либо «то, что раньше называлось state machine, а теперь просто три bool флага, которые взаимно исключают друг друга иногда».

Так что архитектурно ты прав — сначала UI, потом сцена, это стандартный порядок инверсии z-order. А вот реализационно — не важно C это или C++, важно кто у тебя первый в очереди на input event, и вот это уже не про язык, это про то, что ты явно один раз сядешь и напишешь Input Manager, а потом будешь делать вид, что так и было задумано с начала.

shdown ★★
()
Ответ на: комментарий от shdown

насчет луча из скрин спейса есть нюансы, потомучто луч можно пустить из игрока, получая валидные пересечения, луч пускаемый из скрин спейс тоже есть, насчет УИ, могу поспорить, потомучто можно рисовать УИ и сцену, как бы двух-проекционно, ну и да луч можно пустить от игрока или если быть точным, от камеры, потомучто она привязана к игроку, такие дела…

anonymous
()
  • Markdown
Пустая строка (два раза Enter) начинает новый абзац. Знак '>' в начале абзаца выделяет абзац курсивом цитирования.
Внимание: прочитайте описание разметки Markdown.
Используйте Ctrl-Enter для размещения комментария