Hello.

When programming in C++ I often (always) use some method of data encapsulation.

This used to mean defining a class, declaring variables and helper functions private and supplying a public interface of member functions:

class A
{
    public:
        int PublicFunction() { return _privateVariable; }
    
    private:
        int _privateVariable;
};

Any user of this class can create an instance of the class and use its public members.

Should implementation specific details happen to change, the public interface of the class can stay the same. This is all fine.

Howeverm, the more I code, the more I find myself in situations where there only needs to (or only should) ever be one instance of a class.

There are many solutions to this, such as the singleton pattern, classes with static member functions etc.

But somehow these designpatterns have always felt wrong to me. It feels like trying to fit the problem to the solution, where the solution always is some form of a class, be it a singleton or whatever.

namespace // private, not accessable from outside this source file
{
    int privateVariable = 54;
 
    int PrivateHelperFunction()
    {
        // can change this to whatever i want without breaking the public interface
        return 123;
    }
}
 
namespace PublicInterface
{
    bool PerformSomeAction()
    {
        // Can access "private" varaibles and functions from here:
        return PrivateHelperFunction() == privateVariable;
    }
}

• bad (or incorrect) use of namespaces
• cannot seperate implementation over many source code files (would you even want to do this?)
• could it make code less reusable maybe?

Thanks guys!

However, the 'there can only be one' and thus the singleton/global-state is a code smell. Why dictate that the library has to have a single global state and restrain it like that if you don't have to?

namespace // private helper methods and variables (constants etc)
{
    int DrawHelper(const RenderAPI::Renderer& renderer)
    {
        return renderer.GetSomething();
    }
}
 
namespace RenderAPI // public renderer API
{
    class Renderer
    {
        public:
            int GetSomthing() { return _something; }
 
        private:
            int _something;
    };

    Draw(const Renderer& renderer)
    {
        DrawHelper(renderer);
    }
};

Hi, thanks for your input.

Yes, ofcourse the anonymous namespace would be in the source file, and the example was only to show what I mean.

I do understand your reasoning though and I agree that if I am going to use classes or structs, the need for anonymous namespaces more or less goes away.

Global (mutable) data is generally a bad idea, even if inside an anonymous namespace. This is because your functions then are depending on something that the user can't see, and which may change their behavior in unexpected ways - not to mention that the whole scheme breaks down entirely when threads are involved.

True, but the functions themselves are stateless. Free functions is not the same thing as global state. Sometimes it makes a lot of sense to have free functions that are associated with a class but do not belong to it. For instance, you could use free functions to promote encapsulation by doing what AlanSmithee suggested where free functions would be the public interface and the actual class would be a hidden implementation detail, similar to how C's FILE structure is used.

Anonymous namespaces don't really contribute to that, though. As you say, they're more for fixing naming collisions.

Global (mutable) data is generally a bad idea, even if inside an anonymous namespace. This is because your functions then are depending on something that the user can't see, and which may change their behavior in unexpected ways - not to mention that the whole scheme breaks down entirely when threads are involved.

True, but the functions themselves are stateless. Free functions is not the same thing as global state. Sometimes it makes a lot of sense to have free functions that are associated with a class but do not belong to it. For instance, you could use free functions to promote encapsulation by doing what AlanSmithee suggested where free functions would be the public interface and the actual class would be a hidden implementation detail, similar to how C's FILE structure is used.

Anonymous namespaces don't really contribute to that, though. As you say, they're more for fixing naming collisions.

Hi!

Thanks to everyone for contributing, I have learnt a few things.

Ravyne, you are pretty much spot on with everything you say, except me being against the idea of having free functions as a part of the interface - this is actually what I want to achive - sorry if I was unclear. What I did have a problem with was hiding away things that should not be in the public interface. This was a problem to me, because I was not using any form of formal encapsulation (like a class). I was essentially moving from one extreme (using classes for everything) to another extreme (don't use classes at all). I think that was what was making it "not feel right".

So, gathering what has been said in this thread, this is the current solution I am considering: (psuedo code example)

// Public interface of texture manager
namespace TextureManager
{
    class Instance
    {
        public:
            void ChangeTheStateOfThisInstance()
            {
                 ++_secretVariable;
             }
 

            void ChangeTheStateOfThisInstanceTwo()
            {
                 --_secretVariable;
             }
 

            void ChangeTheStateOfThisInstanceThree()
            {
                 _secretVariable *= _secretVariable;
             }
 
         private:
             int _secretVariable = 0;
    };
 
    void IAmAPartOfTheTextureManagerInterface(Instance textureManager)
    {
        textureManager.ChangeTheStateOfThisInstance();
        textureManager.ChangeTheStateOfThisInstanceTwo();
        textureManager.ChangeTheStateOfThisInstanceThree();
    }
};
 
// Usage
int main()
{
    TextureManager::Instance textureManager;
 
    TextureManager::IAmAPartOfTheTextureManagerInterface(textureManager);
 
    // and/or
 
    textureManager.ChangeTheStateOfThisInstanceTwo();
   
    ...
 
    return 0;
}

This feels good to me, and if I am consistent with how I provide the public interface of different functionality, I think it could work well.

I do however realize that not all will agree with the usage of namespaces or the naming conventions used in the above example.

No need for any anonymous namespace here atleast. Should the need arise, it would be another tool in the toolbox though.

Naming conventions aside, I think this is pretty much what Ravyne is talking about?

Any feedback on this approach?

Thanks again!