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

Глобальные переменные в С++ (7 стр)

Страницы: 1 2 3 4 5 6 7
#90
(Правка: 21:45) 21:43, 19 янв. 2021

Zegalur
> злоупотребление
Эти злоупотребления - лишь следствие детсадовской болезни: "писать впрок", "писать по правилам".


#91
(Правка: 6:31) 6:12, 20 янв. 2021

Went
> Вы предлагаете сделать окно глобальной сущностью? Ну вообще, огонь. Потом
> потребуется сделать многооконное приложение
А немного подумать? Ты же программист, а не перепечатыватель статей.

Делаешь один менеджер окон - глобальная сущность. Этот менеджер создает любое количество окон и управляет ими

Это наиболее правильное решение, хотя бы потому что на виндах у тебя в 99% случаев одна глобальная функция WndProc(). И ей не место в окне. Ей место в менеджере, который по ее действиям раскидывает события по окнам.

#92
6:31, 20 янв. 2021

harbinger
> Народ кто понимает что глобальные переменные зло
Не факт что понимают, начитаются статей и повторяют как попугаи.

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

Это все хорошо, но есть такая вещь - как интерфейсы библиотеки.

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

Если же оно глобальное (типа менеджера раздающего сущности), то при рефакторинге ты сразу убираешь эту связь в реализации, не трогая интерфейс.

#93
8:44, 20 янв. 2021

war_zes
спасибо за интересный кейс.

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

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

#94
9:29, 20 янв. 2021

war_zes
> Делаешь один менеджер окон - глобальная сущность. Этот менеджер создает любое
> количество окон и управляет ими
То ли ты меня не понимаешь, то ли я тебя.
Если твой менеджер - это, фактически, stateless сущность, которая хранит в себе лишь "мостик" между HWND и MyWindowClass*, чтобы перенаправлять сообщения между статической WndProc и функцией-членом virtual MyWindowClass::ProcessMessage, то здесь все довольно чисто. Единственная глобальная переменная тут - std::map<HWND, MyWindowClass*> s_window_handles, и это необходимая прокладка в силу С-шности WinAPI. А остальные функции этого менеджера - создать окно, удалить окно и т.п., это просто обертки, в них нет собственного состояния и это нормально. В этом случае твое предложение никак не противоречит моему утверждению о вреде глобальных сущностей.
А я прочитал твое сообщение как если бы ты предлагал сделать глобальную переменную HWND s_window_handle, описывающую единственное и неповторимое игровое окно (ведь обычно-то в игре оно одно...)

#95
(Правка: 9:52) 9:45, 20 янв. 2021

war_zes
> Went
> А немного подумать? Ты же программист, а не перепечатыватель статей.
он задуплившийся сеньор, который фигачит по бест практиксам, ему некогда думать.

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

#96
(Правка: 9:53) 9:49, 20 янв. 2021

kkolyan
> Зачем юзеру запрещать создавать несколько инстансов этого менеджера в рантайме?
Потому что это бессмысленно? Плюс это снижает понимание кода для программиста - можно просто не заметить момент, когда используется другой менеджер - очень тяжело такое читать

Но опять же, конечно можно, если того требует задача, просто сверху написать более вышестоящего менеджера, который будет раздавать менеджеров помладше :)

Ведь все равно как-то придется разруливать взаимодействие между ними... Хотя опять же моя идея в основном на том, что между разными сущностями есть внешний посредник, в каких-то задачах/архитектурах это конечно неприменимо, поэтому мой подход может там не подойди... Ну серебряной пули нет, для этого мы и ищем решения

Плюс я тут намешал сингтоны и глобальные... Имхо, синглтон не всегда является глобальным. Ведь это паттерн, а не идиома. Поэтому если менеджер создается где-то внутри главной функции (типа main) и далее передается ниже по ссылкам, то это синглтон, хотя и создается он локально в терминах языка. Такие синглтоны могут быть и во множественном числе - это вроде называется контекстами (но активен только один контект, их надо переключать)

Ну а когда глобальный объект, без всякого управления и контроля или вообще POD-тип - изменяй кто хочет - то и я против такого

#97
10:28, 20 янв. 2021

war_zes
> Потому что это бессмысленно? Плюс это снижает понимание кода для программиста - можно просто не заметить момент, когда используется другой менеджер - очень тяжело такое читать
в том варианте, который мне видится удачным, они не персекаются. разные миры, просто в рамках одного процесса ОС. но в какой-то точке, где они дирижируются - это просто несколько однотипных объектов.

war_zes
> Плюс я тут намешал сингтоны и глобальные... Имхо, синглтон не всегда является глобальным. Ведь это паттерн, а не идиома. Поэтому если менеджер создается где-то внутри главной функции (типа main) и далее передается ниже по ссылкам, то это синглтон, хотя и создается он локально в терминах языка. Такие синглтоны могут быть и во множественном числе - это вроде называется контекстами (но активен только один контект, их надо переключать)
это да, интерпретации синглтона разнятся) в своем сообщении я имел ввиду именно глобально уникальный объект. но так, согласен с интерпретацией где синглтон единственен в неком контексте, которых в рамках процесса может быть несколько. и кстати, в терминах некоторых популярных фреймворков, контексты (и соответственно синглтоны в их же терминологии) могут быть активные и одновременно - каждый обслуживается своим пулом потоков, например. либо пул потоков один, прсото граф зависимостей в каждом контексте свой.

war_zes
> Ну серебряной пули нет, для этого мы и ищем решения
+100500.

#98
11:48, 20 янв. 2021

war_zes
> Если ты передаешь ссылками что-то куда-то, а оно там уже не нужно после рефакторинга...
Именно. Сначала уйдем из программирования в крестопроблемы, а затем будем жаловаться на код, который вынужден, зараза, что-то делать.

Страницы: 1 2 3 4 5 6 7
ПрограммированиеФорумОбщее