В чем нуждаются глобальные объекты в C++?

Question

Я знаю, что 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; 
} 

Когда &, где я должен использовать глобальные объекты? Существует ли какое-либо конкретное использование глобальных объектов? Пожалуйста, помогите мне.

Answer 1

Короткий ответ не нужно.

---

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

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

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

Answer 2

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

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

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

Global действительно полезен только в простом проекте, который просто не использует пространства имен.

Answer 3

Я бы сказал, что глобальные переменные необходимы для обратной совместимости с c. Это точно, и это единственная трудная причина, по которой я вижу. Поскольку классы и структуры по существу одинаковы, вероятно, не было смысла запрещать только один.

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

Тем не менее, я видел некоторые библиотеки, отображающие некоторые объекты в виде глобальных символов. Обычно вещи, содержащие некоторые статические данные. Но есть и другие случаи, например, стандартная библиотека std::cout и семья.

Я не буду судить, хорошо это или плохо. Это слишком субъективная ИМО. Вы могли бы, вероятно, использовать одиночек, но можно утверждать, что вы можете работать на глобальный объект по договору и т.д. и т.п.

Answer 4

Вопрос: это неправильно расположенный там need для ifwile и do, так как мы можем сделать все с только for?

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

В настоящее время: можем ли мы обходиться без глобальных объектов?

Первый отказ от ответа «да, с одноточием». Но singleton - это статический объект, полученный через функцию. Они не являются , что концептуально отличается, если не для дефекта дизайна (известный как «static initialization order fiasco») из-за того, что C++ не указывает глобальный порядок объектов инициализации, по существу, чтобы позволить нескольким единицам перевода сосуществовать в одном связанном исполняемом файле. Синглтон позволяет обойти эту проблему, но по существу является обходным решением, позволяющим создавать глобальные «вещи».

Существование этого недостатка (и техника одиночной моды) - это ват, что позволяет многим «учителям» нарисовать «моральное» учение как «никогда не использовать глобальные объекты, или пламя ада сожжет ваши задницы». Но это скоро произойдет std::cout << "hello world" и сразу потеряет ВСЕ их авторитет.

Дела в том, что без «глобал» все «сфера местные» и нет «динамического размаха» в C++: если funcA вызовов funcB, funcB не могут видеть funcA местных жителей, следовательно, единственным способа получить доступ к вещам по прицелам является передача параметров ссылки или указателей.

В контексте, которые в основном являются «функциональными», недостающие «динамические области» компенсируются «захватами lamba», и все остальное будет проходить как параграф.

В контексте, который в основном является «процедурным», потребность в «состоянии», которая выживает в областях и может быть изменена при входе и выходе, более подходит для глобальных объектов. И вот в этом причина cout. Он представляет собой ресурс, который ранее существовал и существовал в программе, состояние которой развивается по различным вызовам. Если нет глобального способа доступа к cout, он должен быть инициализирован в main, передан как ссылочный параметр для любого вызова функции: даже тот, у которого нет вывода, чтобы дать, поскольку они могут называть себя чем-то другим, у которого есть вывод, чтобы дать ,

Фактически вы можете думать глобальному объекту, как «неявные параметры, переданные каждой функции».

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

Фактическая единственная причина, по сути, оказывается, чтобы быть static initialization order fiasco