глобальная переменная

синглтон

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

Опять-таки скажу, что особой разности не вижу. Объект синглтона естественно один, но никто не мешает натыкать разных классов-синглтонов, как и не мешает натыкать глобальных переменных. Так что остаюсь при своем мнении - главное не как обозвать глобальный объект и во что его обернуть, а как его организовать и как с ним работать. Суть глобального объекта и объекта синглтона одинакова. Последний, согласен, более защищен от неправильных действий, но все равно сам объект остается глобальным, а то что скрыт за вызовом метода - также можно скрыть и обычный объект, если не объявлять его extern, а доступаться через некий глобальный интерфейс. К тому же предел паранойи должен быть - я понимаю защиту от дураков-пользователей, но защиту от дураков- программистов собственной команды нужно организовывать методом увольнения оных. ИМХО.

У меня глобальный объект настройки вынесен в отдельный модуль, который линкуется к каждому проекту в виде библиотеки. Из проекта требуется вызвать метод Init для его инициализации, а дальше через интерфейсные методы получать/сохранять необходимую информацию. Я пока не увидел никаких особых проблем - если объект хорошо документирован и есть инструкция, то никакой опасности нет.

Ну а с дури и болт сломать можно.
ИМХО.

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



если этот глобальный объект хранит конфигурацию приложения, то это нормально, так как конфигурация приложения редко меняется

если говорить о примере ТСа, то там применение глобальных переменных совершенно оправдано, т.к. прога маленькая
кроме того оно неплохо преобразуется в такой код:


Это сообщение отредактировал(а) GoldFinch - 14.4.2009, 08:37

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

сразу скажу что больших проетков не писал, но мнение по этому поводу есть !

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

а как же функции из STL?

а что STL ? я использую STL но причом тут глоб.перемен ?

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


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


Для интереса написал программулинку, которая посчитала сколько строк у меня сейчас в рабочем проекте. Получилось 96000 с пустыми строками и 84000 без учета оных. Как я и говорил не сильно большой проект, тем не менее и в крупных проектах использовали глобальные объекты без всякого вреда для проекта и психики команды.

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

zim22, и много их там, функций STL? 20?

мдя.. открой да посмотри, и не позорься.

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

60 штук   

zim22, ~100

нет. извольте, но я настою на своём.

Страуструп. Язык программирования С++. Специальное издание. Глава 18.