Should I use a class of functions or a namespace of functions?

Question

Say I want some functions to deal with some file, and I was considering 2 options.

1) Create a class like SavedDataHandler that a user could use like this....

// Note that SavedDataHandler has no members. It just has functions that operate on a
// resource ( the file)
SavedDataHandler gameSave;
gameSave.SaveData( arg1, arg2 ); // to save data
gameSave.DeleteSave(); // Delete the save
...

2) Create a namespace of functions

namespace SavedDataHandler {
  SaveData( ... ) { ... }
  DeleteSave( ... ) { ... }
  ...
}

that a user would call like

SavedDataHandler::SaveData( arg1, arg 2 );
SavedDataHandler::DeleteSave();

What would be preferred?

P.S. I thought about this when I was thinking about Scott Meyer's recommendation to prefer non-member non-friend functions to member functions. I've run into decisions where I have a function (usually some private member function to help the class do stuff), that could easily be made into a non-member since it doesn't operate on class privates.

However, the function is only used by that one class. Of course, the program might evolve to a point where another class may need it, but I find it hard to find a place for these non-member functions. It's easy when you have a lot of functions with a general purpose, but I find single non-member functions hard to organize into a specific place, and find that leaving it as a member keeps things clean. Any tips regarding this issue?

Answer 1

I tend to the following simplified pattern:

• if its only used by one class and likely to stay that way, put it in the implementation file in an anonymous namespace.
• if it is of use for more then one class and doesn't need access to a class' internal state, put it in a namespace.
• if it needs access to the class internal state, make it a member function of course.

But opinions differ and in the end probably the guide-lines of your employer are the final ones.

Edit:

... Of course its not that simple, but as you mentioned Scott Meyers already covered the details.

As for the organizational problem:
If you put helper functions in anonymous namespaces, they are already mostly decoupled from the class - if you then later decide to reuse them, it shouldn't be too hard to pull them out in a common namespace.
At this point you should also have a better view on the organization that fits, which can sometimes be hard in advance.

Answer 2

My subjective answer is: use a namespace over a class containing static methods.

My rationale for this is that simply by looking at the declaration you would know the purpose of this block of code.

If it's a class, then there's nothing stopping it from having instance methods. If it's a namespace, then you know that all of the functions are free-standing.

These concepts hit home with me when learning C#. In C# you cannot have free standing functions. However, you can have static classes:

internal static class SavedDataHandler
{
    // Because this is a static class, the compiler will not let you create an instance method

    internal static void ThisIsAStaticFunction() // This is fine
    {
    }

    internal void ThisIsAnInstanceFunction() // Compiler error!
    {
    }
}

As C++ doesn't have the concept of static classes, namespaces would be the way to go.