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) {
impl::RefractObject(object1);
// Another stuff
}
}
Any ideas how to make this better in terms of code designing?
Namespace is a feature added in C++ and is not present in C. A namespace is a declarative region that provides a scope to the identifiers (names of functions, variables or other user-defined data types) inside it. Multiple namespace blocks with the same name are allowed.
Namespaces are used to organize code into logical groups and to prevent name collisions that can occur especially when your code base includes multiple libraries.
In an operating system, an example of namespace is a directory. Each name in a directory uniquely identifies one file or subdirectory. As a rule, names in a namespace cannot have more than one meaning; that is, different meanings cannot share the same name in the same namespace.
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With