Going to all the effort of making a singleton object using the usual pattern isn't addressing the second part of your question - the ability to make more if needed. The singleton "pattern" is very restrictive and isn't anything more than a global variable by another name.

// myclass.h

class MyClass {
public:
    MyClass();
    void foo();
    // ...
};

extern MyClass g_MyClassInstance;

// myclass.cpp

MyClass g_MyClassInstance;

MyClass::MyClass()
{
    // ...
}

Now, in any other module just include myclass.h and use g_MyClassInstance as usual. If you need to make more, there is a constructor ready for you to call.

It is just a static object. It is treated like any other global variable.

It will not be tied to any stack frames and will be created when the anything in the file is loaded for the first time.

Generally, people will not recommend relying on globals from a design perspective. It depends though, they can be reasonable.

If you are doing any sort of threading they can be an issue. You also want to minimize different parts of your application knowing that things are global variables, it leads to a lot of spaghetti code.

If the variable is not referenced outside of the file, or for cross-cutting concerns, then sometimes it can be a good thing.

The best advice is to avoid it when you can, don't over design it when you can't.

You probably really do not want to do this, but if you must - in the file that contains main:

#include "A.h"
A a;

int main() {
 ...
}

and then in the files that need to access the global:

#include "A.h" 
extern A a;

You will need to put the declaration of A in the A.h header file in order for this to work.

Using an extern variable is one option.

Another option is to have a function that returns a reference.

logging.h:

LogCenter& getGlobalLogCenter();

logging.cpp:

LogCenter& getGlobalLogCenter()
{
   static LogCenter lc;
   return lc;
}

Yes, you can declare a global variable of any type, class or not.

No, you can't then "call" the constructor again inside a function to initialize it. You can however use the copy assignment operator to do it:

Foo foo;

int main()
{
    foo = Foo(1, 3);
}

Or you can have a "setter" function that is used to set or reinitialize the object.

By the way, and depending on the data in the class, you might want to read about the rule of three.

The global constructors run right after the initializations performed by the C runtime startup code, and right before main() gets called.

In a nutshell, the C runtime initialization code:

• does some low-level initializations (e.g., setup the memory)
• calls the global constructors
• calls main(), which in turn
  • calls init() to do the Arduino-specific initializations
  • calls setup()
  • repeatedly calls loop()

The fine details are probably platform-specific. For AVR-based boards, they are documented in the avr-libc manual.

Your doubt is correct, don't use global variables.

(Note: For this post, I mean variable in its true meaning, i.e. objects that may change.)

I can't say for sure which technique is the correct one without seeing your code, but normally you want to pass the variable as a parameter to whichever entity needs it:

void foo(Input input)
{
    input.doSomething();
}

int main()
{
    Input input;
    input.doSomething();

    foo(input);
}

Or, restrict it to a class as a member variable.

Update: Class examples

You can do it one or both of these ways:

class Person {
    std::string name_;
public:
    explicit Person(std::string const& name) : name_(name) {}
    void set_name(std::string const& name) { name_ = name; }
}

void foo()
{
    Person p("Bob Loblaw");

    p.set_name("Slartibartfast");
}

There are two key downsides to using global variables:

1. They can be changed everywhere.

You generally want to enlist the compiler's aid in finding bugs and errors for you. If you allow yourself to modify a variable from all over your code, it is very hard for your compiler and yourself to track down an error. Consider the following scenario:

Input input; // global

void foo()
{
    Input inputt;
    input = someThingWeird;
}

This code will compile. If you're really unlucky, it will even work for a while. If you don't have a global, the code won't compile and the bug will be easy to find.

2. They increase coupling (and reduce testability).

By reading from a global variable, your entity (i.e. function, class, whatever) depends on that global variable. If some day you want to use something else, you'll have to do a lot of refactoring. What's more important, if you change an aspect of the global variable, you will need to update all parts of the code that uses it. This is a great opportunity for suble bugs to infiltrate your code and make your life miserable. A typical example is that you modify one part of your code, and a completely different part will break.

Using globals also makes your code hard to unit test, because it depends on the global variable.

One solution would be to use a Singleton for your global class. You can see for example this answer.

The problem here is that you are defining on class per compilation units (ie per .cpp file you compile) which means that would have effectively a different instance of your class in each of your cpp files.

You should also think about using the Singleton Design Pattern as it is rarely a good design to adopt when building an application. You can see this to understand more about its use cases!