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

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

Страницы: 13 4 5 610 Следующая »
#45
16:23, 18 янв. 2021

jaguard
> какие ты метрики в принципе знаешь?

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


#46
(Правка: 18:01) 17:59, 18 янв. 2021

Zab
Инициализация статических переменных нулем является обязательной согласно (§6.7.8/10).

10 If an object that has automatic storage duration is not initialized explicitly, its value is indeterminate. If an object that has static storage duration is not initialized explicitly, then:
— if it has pointer type, it is initialized to a null pointer;
— if it has arithmetic type, it is initialized to (positive or unsigned) zero;
— if it is an aggregate, every member is initialized (recursively) according to these rules;
— if it is a union, the first named member is initialized (recursively) according to these rules.

Иное поведение компилятора или ОС - является ошибкой.

#47
(Правка: 18:06) 18:05, 18 янв. 2021

forwhile
Например инициализация статических переменных объявленых внутри функций, является thread safe. На основе этого построены Синглтоны Маерса.

#48
(Правка: 18:40) 18:39, 18 янв. 2021

xDimka
Это с какой версии языка? В 98й тоже было? И как бедные компиляторы это обеспечивали? Не все же глобальные данные имеют свой образ на файле, которые не инициализированы - могут не иметь. Активный код какой-то для инициализации выполнять? Зачем?

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

#49
18:56, 18 янв. 2021

xDimka
Zab
Учите матчасть. Вы запутались в терминологии.

#50
(Правка: 19:35) 19:34, 18 янв. 2021

Zab
Компиляторы генерируют специальный код который исполняется до исполнения функции main. В этом коде и находится инициализация всей статики. Ответственность вызова этих функций и вызова main лежит на run time library с которой вы линкуетесь при компиляции, грубо говоря на операционной системе. Мои слова вы можете проверить просто запустив отладчик.

Современный game development использует с++14 и выше, так давайте не будем тратить время на обсуждение того что никому не интересно.

#51
19:38, 18 янв. 2021

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

#52
19:44, 18 янв. 2021
xDimka
> Одолжите мне ваш хрустальный шар, чтобы я мог заглянуть в ваши мысли и понять,
> что вы имеете ввиду.

у него хреновый хрустальный шар, я бы даже сказал хреновОй

#53
19:48, 18 янв. 2021

gudleifr
> Все непрограммисты думают, что проблемы многопоточных приложений отличаются от
> проблем однопоточных.
Отличаются. Весьма существенно. Но идиот - не ты, конечно же.

+ Показать
#54
20:09, 18 янв. 2021

xDimka
> что вы имеете ввиду.
Только то, что Вы, не имея понимания предмета, наугад дергаете из гугла факты.

beejah
> Отличаются. Весьма существенно.
Я и говорю: у непрограммистов - отличаются.

#55
4:23, 19 янв. 2021

Zab
> В 98й тоже было?
Да. §3.6.2 и §8.5.
http://www.lirmm.fr/~ducour/Doc-objets/ISO+IEC+14882-1998.pdf

#56
6:45, 19 янв. 2021

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

Но классы не могут быть в независимом вакууме. Хоть как делай, а тот же рендер ну никак не сделать не зная hwnd окна.. Ладно, его передать один раз.... Но тот же рендер никак не может обойтись без знания событий ресайза, активности/неактивности окна и т.д.

Передавать нужные объекты ссылками... Это делает код зависимым даже там, где это не нужно - возникают этакие посредники которые откуда-то берут ссылку и куда-то ее кидают, хотя им самим она не нужна.
Ну и это криво, уродливо и нечитаемо, когда у функции десятки ссылок и только пара ее аргументов... В результате возникают какие-нибудь враперы которые собирают эти ссылки в себя и передаются аргументами - тоже криво

#57
(Правка: 7:22) 6:49, 19 янв. 2021

kipar
> А так у глобальных основная проблема в том что если их менять из разных мест
ммм? Делаешь ему только публичные гетеры, а сетеры в приват френдишь (тоже криво, зато нельзя изменить в глобальном пространстве - только читать)

Suslik
> за глобальные переменные никто не отвечает, их никто не контролирует, они
> никому не принадлежат
Они сами за себя отвечают, они сами себя контролируют, и они принадлежат глобальному пространству)))

Suslik
> может влиять вообще кто угодно когда угодно из какого угодно треда
Не может, если их закрыть и дать доступ к изменению только разрешенным классам (или вообще никому).

>и нарушают инкапсуляцию
А как? ну одно дело, когда глобальный какой-нибудь size2 WindowSize - это да, зло так делать.
А когда глобальный Логгер - кто его будет менять, если у него есть только публичный Print метод? (да, принт меняет состояние - но в любом случае это будет происходить там где он нужен, хоть глобальный лог, хоть ссылка на лог)
На уровне объектов никто особо не меняет эти объекты (я вообще в последнее время все настраивающие методы делаю приватными чтобы никто не имел к ним доступа)

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

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

#58
(Правка: 7:33) 7:26, 19 янв. 2021

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

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

> А когда глобальный Логгер - кто его будет менять, если у него есть только
> публичный Print метод?
дай-ка подумать.. кто угодно? что если я хочу перенаправить логгер для одной подсистемы в фаел, а лог другой подсистемы направить, например, в консоль? что если я хочу лог от каждого потока писать в свой файл?

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

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

#59
8:07, 19 янв. 2021

Как тут все сложно.
А если создать один большой класс и разместить в нем все переменные и методы, а все остальные классы использовать как голый набор свойств? Это плохо или хорошо?

class God
{
// все переменные и методы...
};

int main()
{
auto g = std::make_unique<God>();

u->BigBang();
}

Страницы: 13 4 5 610 Следующая »
ПрограммированиеФорумОбщее