I have some functions that can be grouped together, but don't belong to some object / entity and therefore can't be treated as methods.
So, basically in this situation I would create a new namespace and put the definitions in a header
file, the implementation in cpp
file. Also (if needed) I would create an anonymous namespace in that cpp
file and put all additional functions that don't have to be exposed / included to my namespace's interface there.
See the code below (probably not the best example and could be done better with another program architecture, but I just can't think of a better sample...)
Sample code (header
)
namespace algorithm {
void HandleCollision(Object* object1, Object* object2);
}
Sample code (cpp
)
#include "header"
// Anonymous namespace that wraps
// routines that are used inside 'algorithm' methods
// but don't have to be exposed
namespace {
void RefractObject(Object* object1) {
// Do something with that object
// (...)
}
}
namespace algorithm {
void HandleCollision(Object* object1, Object* object2) {
if (...) RefractObject(object1);
}
}
So far so good. I guess this is a good way to manage my code, but I don't know what should I do if I have some template-based functions and want to do basically the same.
If I'm using templates, I have to put all my code in the header
file. Ok, but how should I conceal some implementation details then?
I want to hide RefractObject
function from my interface, but I can't simply remove its declaration (just because I have all my code in a header
file)...
The only approach I came up with was something like:
Sample code (header
)
namespace algorithm {
// Is still exposed as a part of interface!
namespace impl {
template <typename T>
void RefractObject(T* object1) {
// Do something with that object
// (...)
}
}
template <typename T, typename Y>
void HandleCollision(T* object1, Y* object2) {
开发者_如何学Python impl::RefractObject(object1);
// Another stuff
}
}
Any ideas how to make this better in terms of code designing?
That's a pretty common solution. Boost does it, and I do it as well, but with the detail
namespace instead. Just make it a rule: "don't look inside detail
!"
File-wise, I recommend giving details their own file, and tucking it away in a detail folder. That is, my code would be akin to:
// v
#include "detail/RefractObject.hpp"
namespace algorithm {
template <typename T, typename Y>
void HandleCollision(T* object1, Y* object2) {
detail::RefractObject(object1);
// Another stuff
}
}
This is just good code practice in general (keep things split up and re-usable) and keeps the header file cleaner of implementation details.
Build a "static class"- instead of the namespace, declare a class with the same name. Make the constructor, destructor, copy, and assignment operators private, then make every one of your stand-alone functions a static member function.
A template Example:
template<class T>
class StringOperator
{
friend SomeOtherLibraryClass; // Let it use "Hidden()"
private:
StringOperator() {}
~StringOperator() {}
StringOperator(const StringOperator&);
StringOperator& operator=(const StringOperator&);
static bool Hidden(const T& input) {
// Hidden routine end-users shouldn't see...
}
public:
static void YourFunction(T& parameter) {
// Some public code....
}
static T AnotherRoutine(const T* ptr) {
// Some public code...
}
};
Here are some advantages vs. a namespace:
1) You can template the entire class, ensuring that you have a version of every function for every type- you could even specialize to add/remove functions based on type.
2) You have a private area where you can hide the declarations for the non-public objects and methods you need
3) Through the "friend" mechanism, you can let other objects like "SomeOtherLibraryClass"
use your functions without exposing them to end users.
End users can access the functions with "StringOperator::FunctionName()", or you could template the functions instead to provide "StringOperator::FunctionName()". The latter is the same pattern they'd use to access functions in a namespace.
You can't hide your source from the user unless you're going to compile it first, which is impossible with templates. So I suggest, in a sense, that you don't bother.
Also gotta ask why Refract can't be a member method.
i thought about the same thing for a while. in the end, i decided to use classes so that the code is more portable, reusable and general.
- classes allows one to do all sorts of meta-programming like traits, tag dispatching and policies.
- classes already have public, private and protected.
the only two reasons why you would use namespace:
- to resolve naming conflicts
std::for_each
vsboost::for_each
- to reduce visual noise. for example
using namespace boost::filesystem
, would let you just call its function without::
.
even for these two cases, you can either inherit the class that has the methods or rename by initiating (my_own_filesystem_methods fs;
and us it as fs.mkdir()
. plus, .
is shorter than ::
.
there are other benefits of namespaces like std::cout << "hi" << endl;
but it's not very important.
精彩评论