atom0s
commented
11 months ago C++ hasn't really developed anything to deal with this kind of thing specifically. Instead, its feature set has allowed for more 'unique' ways of dealing with it. Using extern is still fine and proper in C++, but it is an inherited keyword from C. The way C++ treats things, in regards to extern, is also different and extern has grown to mean more things in C++ as well. The differences can be checked out on the docs here:
externin C - https://en.cppreference.com/w/c/language/storage_durationexternin C++ - https://en.cppreference.com/w/cpp/language/storage_duration
However, it does offer a few ways of dealing with the problem in a different manner. One of those ways is the use of namespaces while still using extern. It allows things to be defined more specifically and helps avoid name collisions, but still requires the same setup, just with more wordage.
Another solution is to use singletons. (I can already feel the hate towards saying that word haha..) The singleton pattern in C++ has gotten a ton of hate in the past due to the way things had to be implemented. It came with its own set of problems such as thread safety, potential memory leaks (when the singleton object still required a pointer), etc. However, in more modern revisions of the C++ standard, these problems became a thing of the past, but the hate still lived on.
C++11 added to the standard that functions can now define local static variables that will have static storage duration and be guaranteed to only initialize once. This also guaranteed initialization thread safety. (See ref here: https://en.cppreference.com/w/cpp/language/storage_duration#Static_local_variables)
This also changed the way the singleton object could be defined:
- The class/object no longer needed a self-allocation, or allocation/pointer at all.
- The class/object no longer had to keep a public destructor.
- The class/object no longer had to manage its own memory at the time of destruction.
The new method of defining a singleton class is known as the Meyers implementation, named after Scott Meyers. That defines an object like this:
class SomeObject
{
// Deleted Copy and Assignment Operators
SomeObject(SomeObject const&) = delete;
SomeObject(SomeObject&&) = delete;
SomeObject& operator=(SomeObject const&) = delete;
SomeObject& operator=(SomeObject&&) = delete;
// Private Constructor and Destructor
SomeObject(void);
~SomeObject(void);
public:
static SomeObject& instance(void)
{
static SomeObject obj;
return obj;
}
};This singleton object can then be further well-defined by being contained within namespace(s).
As mentioned above, with this kind of setup we are gaining some positives such as:
- This approach does not allocate memory for the object, it is instead defined at compiletime where it'll live in the programs memory space.
- This approach does not have any public constructor/destructor as creation outside of the singleton use is not allowed/expected.
- This approach does not require any self-management of cleaning up the singletons memory. (This is handled automatically.)
- This approach automatically gives us thread-safe initialization of the object and guarantees a single instance. (When using C++11 or newer.)
- This approach does not require
externat all, simply include the header file the object is defined in and callSomeObject::instance()to obtain the instance and use it.
These are benefits over the extern usage as it:
- Does not guarantee any kind of initialization or initialization order.
- Does not have thread-safe initialization by itself. (Requires manual locking mechanism.)
- Does not have any kind of naming collision prevention. (You can easily extern two of the same named object and cause problems/shadowing.)
- Pollutes the global namespace with each needed object/variable being extern'd. A singleton can encapsulate lots of data into a single object.
Sadly, singletons still get a lot of hate for whatever reason. Used properly and when needed, they are a great design pattern that has been much better enhanced by the various changes to the C++ standard over the years.
Other means of implementing a singleton exist as well, such as using the even more modern std::call_once, but that then adds back other downsides depending on how it's used.
zach2good
I affirm:
Describe the feature
https://learn.microsoft.com/en-us/cpp/cpp/extern-cpp?view=msvc-170
We have a lot of globals that are accessed from different compilation units, being declared by
externin the secondary units. This feels very 'C', and I presume there's a more 'C++'/standards compliant way to achieve this. I don't know what that would be though...