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

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 cou开发者_C百科ld 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?

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.

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.

It would make sense to have the save method of the class containing the game data directly, passing helper objects that represent the media that the data is being saved to, and have the delete method be on the media class itself.

If I must answer the question itself, then it would be: It doesn't matter. One could say that the difference between a namespace of functions and a class with static functions in this case is just syntactic.

However, It looks like you're trying to model a "SavedGame" object. Is there any reason why these functions should have a different handler with no state?

It looks like this question stems from some unhealthy design in other parts of the program. I would look at the design of these arg1 and arg2 things that you are passing to the handler, they are probably where the abstraction is missing.