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

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

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

kkolyan
> Недостаток у подхода один - это позволяет меньше думать и при прочих равных
> можно быстрее отупеть.
это ты про очередной слой абстракции?


#121
21:53, 1 мар. 2021

u960u960
> это ты про очередной слой абстракции?

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

#122
1:54, 2 мар. 2021

kkolyan
> N пропорционально размеру проекта, а Q - нет

Это откуда такое утверждение? Ты так пишешь? Т.е. даешь доступ к переменным для всех?

#123
(Правка: 2:20) 2:01, 2 мар. 2021

rcsim
ну а как ты ограничишь доступ? допустим ты сделал глобальную переменную видимой только из этого compilation unit. как ее дальше-то юзать? при помощи глобальной функции или статического метода я полагаю? доступного из любой точки программы. как еще?

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

#124
4:22, 2 мар. 2021

kkolyan
> как ее дальше-то юзать?
Дальше её юзать внутри любой функции в этом юните компиляции. Например, так:

// SomeClass.cpp
static const int SOME_AMOUNT = 1;
void SomeClass::DoSomeChanges() { _someField += SOME_AMOUNT; }
Не понимаю, в чём проблема. Юнит компиляции - это своего рода отдельная область видимости. Вполне адекватная замена fileprivate из новых языков.
#125
(Правка: 5:14) 4:41, 2 мар. 2021

pahaa
ну да, так и понял. мой второй абзац как раз про это.

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

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

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

#126
10:48, 2 мар. 2021

kkolyan
> ну а как ты ограничишь доступ?

Как его ограничивать (*технически: неймспейсы, синглтоны, приватные статики классов) - это второй вопрос.
А главный, это то что нет никакого принципиального отличия (#113), и _любые_ переменные должны иметь обоснование.

* p.s. Можно кстати и так:

// file.hpp
class A { private: inline static Type data = initial_value; /*дальше можно добавить друзей или пуб. метод доступа*/}

#127
14:07, 2 мар. 2021

У меня в проектах в коде очень много объектов, которые являются единственными экземплярами своего класса. Но синглтоны я не использую именно чтобы обозначать зависимости и побочные эффекты явно. Единственное исключение, это, обычно, логгер.

Kartonagnick
> простое API не означает, что детали внутреннего устройства тоже будут простыми.
В твоём варианте если в "простом" API будут внутри обращения к глоабальным переменным, оно перестанет быть простым и будет давать чудеснейшие возможности для прострела ноги.

#128
14:39, 2 мар. 2021

Panzerschrek[CN]
> В твоём варианте если в "простом" API будут внутри обращения к глоабальным
> переменным, оно перестанет быть простым и будет давать чудеснейшие возможности
> для прострела ноги.
соглы, лучше тогда их сложить их в такое понятие как контекст и тащить с собой этот контекст если уж совсем не хочется архитектуру городить, если что, проще будет многопоточность завести к этому всему.

#129
15:23, 2 мар. 2021

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

#130
15:48, 2 мар. 2021

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

#131
15:55, 2 мар. 2021

kkolyan
> почему бы ее тоже в инстанс не положить
отличий много
если её положить в экземпляр, или даже если сделать просто статическим членом класса, то её нужно тащить в заголовок
в случае со свободной static-переменной, её класс может быть объявлен тут же в цпп-файле, и ни переменная, ни сам класс не будут больше видны вообще нигде
кроме того, в этой же единице трансляции могут быть ещё другие классы, которые хотят использовать эту переменную
тогда будут сразу 2 проблемы:
1. к какому из этих классов она принадлежит?
2. какой у неё уровень доступа? если приватный, то надо дружить классы, а в данном случае это явно лишнее

#132
(Правка: 18:21) 18:03, 2 мар. 2021

rcsim
окей, я понял. у тебя просто нет времени на беседу в этом ключе. твое право.

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

аргумент) ненужной писанины меньше - это хорошо.

pahaa
> могут быть ещё другие классы, которые хотят использовать эту переменную

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

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

#133
(Правка: 21:44) 21:40, 2 мар. 2021

kkolyan
> пофигачив месяцок на крестах понял главную проблему крестов
Главная проблема крестов, что их главную проблему "понимают", "пофигачив месяцок".

Я, вот, уже 20 лет фул-тайм фигачу на С++ и никак не могу ее понять. Она вроде бы есть, что-то постоянно мешает, то спину ломит, то хвост отваливается, но описать ее не получается даже у себя в голове.
#134
(Правка: 22:18) 22:12, 2 мар. 2021

kkolyan
> все дело в том, что в крестах для этого нужно делать ощутимо больше манипуляций
> с клавиатурой по сравнению с этими всякими джавами.
Пользуйся фреймворком и будет тебе счастье. В крайнем случае пили свой. Без фреймворка C++ (в большинстве головах) не существует. Большинство "профессиональных" мнений растет из std, mvs, qt и тд. Поэтому чистым C++ ни кто не пользуется (очень зря) и понятия не имеют как он работает.

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