Зачем нужны глобальные объекты в с ++?
Я знаю, что C ++ также позволяет создавать глобальные объекты класса и структуры.
#include <iostream>
using std::cout;
class Test
{
public:
void fun()
{
cout<<"a= "<<a;
}
private:
int a=9;
};
Test t; // global object
int main()
{
t.fun();
return 0;
}
когда & где я должен использовать глобальные объекты? Есть ли конкретное использование глобальных объектов? Пожалуйста, помогите мне.
Решение
Краткий ответ: Нет нужды.
Длинный ответ заключается в том, что иногда это может быть удобный. К сожалению, удобство субъективно, и то, что один считает удобным, может оказаться слишком мягким.
У глобальных объектов есть проблемы (среди которых мутные потоки данных в коде и синхронизация доступа), но иногда может оказаться удобным, тем не менее, использовать один, потому что он что-то делает Полегче. Это действительно может быть проще, или это может доказать бремя обслуживания, но это может сказать только будущее …
… Если вы можете избежать глобальных объектов, в целом вам лучше. На практике, однако, вы редко будете сталкиваться с проблемами до программирования в масштабе; для примеров игрушек и студенческих проектов редко возникает проблема, поэтому начинающие не понимают, почему более опытные разработчики избегают их, как чумы.
Другие решения
В сложном проекте вы не должны. Вы всегда должны находиться в пространстве имен, если планируете использовать свою сборку в других проектах.
Примером чего-то такого высокого охвата может быть перегрузка оператора или определяемый вами интерфейс, который будет использоваться много раз.
Хорошая практика … организовать ваш проект, чтобы использовать описательные и интуитивно понятные пространства имен.
Глобальный действительно полезен только в простом проекте, который просто не использует пространства имен.
Вопрос неправильный: есть ли need за if wile а также do, поскольку мы можем сделать все с помощью всего for ?
Технический ответ «нет, в этом нет необходимости: тот факт, что мы можем обойтись без этого, доказывает это«Но немного больше прагматизма показывает нам, что сокращение каждого потока управления в единую ключевую работу усложняет отслеживание и отслеживание кода. Так что это технически возможно, но не всегда удобно».
Сейчас: мы можем обойтись без глобальных объектов?
Первый не ответ «да, с одиночками». Но синглтон — это статический объект, полученный с помощью функции. Они не тот концептуально отличается, если не за недостаток дизайна (известный как «статический порядок инициализации фиаско«) из-за того, что C ++ не указывает глобальный порядок объектов инициализации, по существу, чтобы позволить нескольким модулям перевода сосуществовать в одном и том же связанном исполняемом файле. Singleton позволяет обойти эту проблему, но по сути является обходным решением, позволяющим существовать глобальным» вещам «.
Существование этого недостатка (и техники синглтона) заставляет многих «учителей» рисовать некоторые «моральные» убеждения, такие как «никогда не используйте глобальные объекты, иначе пламя ада сожжет ваши задницы». Но что скоро сделаю std::cout << "hello world" и сразу же потерять ВСЕ свое доверие.
Дело в том, что без «глобальных переменных» все является «локальной областью» и в C ++ нет «динамической области»: если funcA звонки funcB, funcB Не могу видеть funcA локальные, следовательно, единственный способ получить доступ к вещам через области видимости — передача параметров ссылки или указателей.
В контексте, который в основном является «функциональным», отсутствие «динамических областей» компенсируется «захватами ламбы», а все остальное будет использоваться в качестве параметра.
В контексте, который в основном является «процедурным», необходимость «состояния», которое сохраняется в границах и может быть изменено при входе и выходе, больше подходит для глобальных объектов. И это причина cout в том, что. Он представляет собой ресурс, который существует до и после программы, состояние которой меняется в зависимости от различных вызовов. Если нет глобального способа доступа coutдолжно быть инициализировано в main, переданный в качестве ссылочного параметра к любому вызову функции: даже к тому, у которого нет вывода, чтобы дать, так как они могут называть себя чем-то еще, что имеет вывод, чтобы дать.
Фактически вы можете думать о глобальном объекте как о «неявных параметрах, передаваемых каждой функции».
Вы можете деформироваться в глобальных функциях, но если сами функции могут быть объектами, а сами объекты могут быть функциональными, почему говорить, что глобальные объекты плохие, а глобальные функции могут быть правильными?
Фактически единственная причина, по сути, оказывается статический порядок инициализации фиаско
Я бы сказал, что глобальные переменные необходимы для обратной совместимости с c. Это точно, и это единственная веская причина, которую я вижу. Поскольку классы и структуры по сути одинаковы, вероятно, не имеет смысла запрещать только один.
Я не знаю каких-либо шаблонов или вариантов использования, которые бы общеприняты в качестве хорошей практики, которые могли бы использовать глобальные объекты. Обычно глобальные объекты рано или поздно приводят к беспорядку, если с ними не взаимодействуют должным образом. Они скрывают поток данных и связи. Это очень легко споткнуться.
Тем не менее, я видел некоторые библиотеки, выставляющие некоторые объекты как глобальные. Обычно вещи, которые содержат некоторые статические данные. Но есть и другие случаи, например, в стандартной библиотеке std::cout и семья.
Я не буду судить, хорошо это или плохо. Это слишком субъективно ИМО. Возможно, вы могли бы использовать синглтоны, но можно утверждать, что вы можете работать с глобальным объектом по контракту и т. Д. И т. Д.