Тёмная тема
- Suslik
- Модератор
innuendo
нет, потому что синглтон-фабрика нужен, чтобы менеджить зависимые от него сущности. окна вообще ни от кого не зависят и привязывать их к синглтону — говнокод.
Suslik
покажи как работать без указателя с окнами из разных мест кода
точно так же, как с любыми другими RAII ресурсами. например, можешь посмотреть как это сделано в том же sfml, из которого взят тот пример — он для начинающих, разберёшься.
Suslik
там ни одного примера с исходниками больше чем на один .cpp. В примере для винды они создают окна обычным способом использую winapi в самом примере при этом имплементация для неё у них есть.
Suslik
> окна вообще ни от кого не зависят и привязывать их к синглтону — говнокод.
окна не могут разделять общие данные ? ну надо же как бывает
innuendo
Окна отдельно, котлеты отдельно.
nes
петросянишь ?
Suslik
> нет, потому что синглтон-фабрика нужен, чтобы менеджить зависимые от него
> сущности. окна вообще ни от кого не зависят и привязывать их к синглтону —
> говнокод.
окна зависят от системного апи (менеджера окон). (скрытый синглтон)
(но если в кроссплатформу писать, то лучше системное оконное API в синглтон обернуть)
но мне понравился подход innuendo, тем, что он не загадил класс лишними конструкторами.
если бы он так написал:
Window window = new Window();
мне бы тоже норм было.
Люди не умеют в API общего назначения, по-этому бегают и в каждом треде говорят, что WinAPI-говно, DX-говно.
Люди охотно умеют в API конркетного назначения. "вот для моего движка нужен только такой конструтор, и по-этому я его добавлю".
Чем это плохо; когда движок "поменяется", то либо старый конструтор останется и будет тухнуть.
Либо конструктор поменяется, и потянет изменения во многих местах.
Как итог - перманентное движкопереписательство.
Suslik
> потенциальный https://en.wikipedia.org/wiki/Most_vexing_parse
Интересно когда выкинут из языка вообще форвардные декларации функций внутри функций. К C++30 надеюсь созреют, ибо абсолютно бесполезный в современных реалиях лет уже 30 как костыль.
Когда мне еще было годиков 5 оно в языке Си было интересно в силу того, что предельно упрощенному по возможностям парсеру было вполне естественно в контексте функции иметь ввиду какие то внешние функции которые другим функциям в текущем модуле трансляции были неинтересны.
Но это же реально уже такое дремучее и error-prone говно мамонта, что OpenGL даже выглядит выгоднее.
skalogryz
> но мне понравился подход innuendo, тем, что он не загадил
...
innuendo
> ...
принято!
=A=L=X=
> https://en.wikipedia.org/wiki/Most_vexing_parse
то ли дело в паскале.
переменные объявляются в секции "var", а типы в "type"
skalogryz
> то ли дело в паскале.
> переменные объявляются в секции "var", а типы в "type"
Ну было бы странно, если бы в паскале типы объявлялись бы в секции "var", а переменные в секции "type".
=A=L=X=
> Ну было бы странно,
это действительно было бы странно.
но даже, если бы так и было, всё-равно не было бы крестопроблем связанным с двояким восприятием одного и того же.
innuendo
>петросянишь ?
В последнее время Петросян почти стал синонимом для инуенды.
skalogryz
> но даже, если бы так и было, всё-равно не было бы крестопроблем связанным с
> двояким восприятием одного и того же.
Эта проблема в Си не из-за "гибкости синтаксиса", а из-за того, что этот синтаксис уже давно корёжили как тузикову грелку.
В оригинале от Кернигана и Ричи функции и типы параметров в них объявлялись через отрубленную лошадиную голову:
int func1(a, b, c, d ) char a, c; int b, d; { ... };
Такой синтаксис давал даже более чем паскалевскую краткость при декларации параметров одинакового типа, но...
Оно никак не вписывалось в forward declarations.
Вообще никак.
Именно поэтому в итоге горемыки намучавшись с постоянно вылазившими ошибками линковки таки намудрились с явным прописыванием типа КАЖДОГО ГРЁБАННОГО параметра по отдельности.
Только так оно не ломало кости парсеру.
В общем то еще развлекалово.
И MyClass myVar( notAFunc!!! ) типичное гоневно.