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

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

Страницы: 15 6 7 8 9 10 Следующая »
#105
1:22, 1 мар. 2021

kkolyan
> ты случайно не работаешь преподом в универе?

я могу ответить и "да", и "нет".
и оба ответа будут правильными.


#106
9:25, 1 мар. 2021

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

#107
11:09, 1 мар. 2021

Kartonagnick
> синглетон жеж.
По большому счёту, немногим более, чем стыдливый эвфемизм для обычной глобальной переменной.
Основная претензия к глобальным переменным с точки зрения орхетектуры - то, что они в одном-единственном экземпляре без вариантов, и если вдруг захочется усовершенствовать кусок программы с глобальными переменными так, чтобы могло одновременно существовать несколько контекстов этого куска, то станет трудно. Сингельтон, очевидно, в этом плане от глобальной переменной ничем не отличается.

> - immunity for static initialization order fiasco
> - thread-safe-initialization
В зависимости от наличии в языке подходящего сахера и конвенций, может поддерживаться и для обычных глоб. переменных. В яблосвифте, например, есть lazy-переменные, и глобальные являются таковыми по умолчанию.

#108
(Правка: 14:04) 12:56, 1 мар. 2021

> этот паттерн для того и изобрели,
> что бы получить гарантии того,
> что у класса не может быть более одного экземпляра.

Это, кстати, заблуждение. Да, определение паттерна в книге так и описано. Но определение != предназначение.

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

Единственность в памяти процесса, конечно, в некоторых случаях нужна, но это особые кейсы вроде интеграции с ОС, а в обычном коде это не потребуется никогда (какой смысл?).

К сожалению, в крестах у меня экспертизы маловато (хотя судя по коментам крестовиков, в крестах такое тоже есть), но в Java на данный момент самая популярная реинкарнация паттерна - singleton scope в Spring, который имеет то же самое назначение что GoF-овский синглтон, но при этом лишен его минусов.

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

#109
14:21, 1 мар. 2021

Sbtrn. Devil
> Основная претензия к глобальным переменным с точки зрения орхетектуры - то, что
> они в одном-единственном экземпляре без вариантов, и если вдруг захочется
> усовершенствовать кусок программы с глобальными переменными так, чтобы могло
> одновременно существовать несколько контекстов этого куска, то станет трудно.

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

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

+ что именно пишут в деццких книжках?

реальная же архитектурная проблема:
глобальная переменная - это анти-паттерн для мульти-тред.
эта проблема не имеет элегантных решений.

+ пример


Sbtrn. Devil
> В зависимости от наличии в языке подходящего сахера и конвенций, может
> поддерживаться и для обычных глоб. переменных

а если не поддерживается?
на с++ синглетон Маейрса  - и есть тот самый сахер.

его часто используют не потому, что нужен синглетон,
а потому, что нужен сахар.

#110
14:36, 1 мар. 2021

kkolyan
> Это, кстати, заблуждение. Да, определение паттерна в книге так и описано. Но
> определение != предназначение.

нет, это ты сейчас заблудился.
что за манера: коверкать и искажать изначальный смысл?

kkolyan
> Разработчику, применяющему синглтон к классу A по большому счету важно лишь
> чтобы все компоненты системы имели ссылку на один и тот же инстанс класса A.

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

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

kkolyan
> singleton scope в Spring, который имеет то же самое назначение что GoF-овский
> синглтон, но при этом лишен его минусов.

о каких таких минусах ты вещаешь?

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

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

#111
14:40, 1 мар. 2021

Kartonagnick
> нет, это ты сейчас заблудился.
> твой гипотетический разработчик - идиот,

ладно, сорян. я сливаюсь. такой уровень аргументации я не потяну.

#112
(Правка: 15:44) 15:43, 1 мар. 2021

Из всего этого глобального срача на восемь страниц для себя точно вынес самое важное - глобальные переменные нежелательны если планируется многопоточность. Остальное смахивает на вкусовщину.

#113
16:14, 1 мар. 2021

Sbtrn. Devil
> Основная претензия к глобальным переменным с точки зрения орхетектуры

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

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

#114
16:21, 1 мар. 2021

rcsim
нахождение глобальной переменной в каком-то неймспейсе делает ее менее глобальной? глобальность переменных - это же о жизненном цикле.

#115
16:32, 1 мар. 2021

kkolyan
> глобальность переменных - это же о жизненном цикле.

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

#116
16:38, 1 мар. 2021

rcsim
верно, разница лишь в масштабах.

#117
17:42, 1 мар. 2021

Kartonagnick
> вообще не вижу никаких проблем.
> например, раньше у тебя было только одно окно.
> теперь у тебя менеджер окон, который по дефолту даёт тебе тоже самое окно
Если обработка этого окна была реализована наподобие:

HWND mainHWND; // глобальный

void paintMainWindow(RECT rc)
{
 GC = GetWindowGC(mainHWND, rc);
 ...
}
то просто менеджером тут не отделаешься.

> а если не поддерживается?
Тогда, конечно, всё плохо и трудно.

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

rcsim
> И все эти "претензии" можно экстраполировать и на переменные внутри класса,
> внутри неймспейса.
Инстансов класса может быть произвольное количество, а глобальной переменной (относится также и к статическим) - только один. В этом-то и трудность.

#118
18:55, 1 мар. 2021

Sbtrn. Devil
> а глобальной переменной (относится также и к статическим) - только один. В этом-то и трудность.

А причём тут инстансы?

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

#119
(Правка: 19:18) 19:09, 1 мар. 2021

rcsim
> В каждом конкретном экземпляре конкретная переменная класса только одна, а методов, которые её к примеру могут модифицировать - может быть много. И если у тебя один метод не согласуется с действиями другого в работе над этой переменной, то будет всё ровно так-же, как и с глобальными переменными, только в рамках этого инстанцированного объекта.

N - объем кода, имеющего доступ к глобальной переменной.
Q - объем кода, имеющего доступ к переменной инстанса.

N пропорционально размеру проекта, а Q - нет. На маленьких проектах, пока N не сильно больше Q - пофигу, но чем проект больше, тем больше соотношение N и Q и тем больше выигрыш от избегания глобальных переменных.

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

Страницы: 15 6 7 8 9 10 Следующая »
ПрограммированиеФорумОбщее