Need advice on C ++ pattern
Hello!
I have a working prototype of a game engine and am currently refactoring it. I am asking for your opinion on using the following C ++ coding patterns.
I have implemented some trivial collision detection algorithms and they are implemented like this:
Not shown here - the class constructor is made private and the algorithms look like Algorithm::HandleInnerCollision(...)
class Algorithm {
// Private routines
static bool is_inside(Point& p, Object& object) {
// (...)
}
public:
/**
* Handle collision where the moving object should be always
* located inside the static object
*
* @param MovingObject & mobject
* @param const StaticObject & sobject
* @return void
* @see
*/
static void HandleInnerCollision(MovingObject& mobject, const StaticObject& sobject) {
// (...)
}
So my question is, someone advised me to do this "C ++" so that all functions are wrapped in a namespace , but not in a class , Is there a good way to keep the privatization if I close them in a namespace like it was recommended?
I want to have a simple interface and be able to call functions like Algorithm::HandleInnerCollision(...)
without polluting the namespace with other functions likeis_inside(...)
Of, if you can advise any alternative design pattern for such logics, I'd really appreciate it ...
a source to share
If different functions have something to do with each other, if it more than helps, but does have a common factor, like acting on the same object, then putting them into a class. On the other hand, if a function acts on the same object as the others, but you also want to reuse it for other objects that can be converted to the first object, then retrieve it outside the class:
bool same_size(const shape& a, const shape& b)
{
return a.bounding_x == b.bounding_x && a.bounding_y == b.bounding_y;
}
The above function will work on any two objects that can be converted to or from shape
.
Put functionality you don't want to pass to other translation units (such as helper functions and help objects) in an unnamed namespace. This is the C ++ equivalent for static C functions, and it instructs the compiler to store anything inside an unnamed namespace, closed to that translation unit.
namespace {
bool is_inside(Point& p, Object& object)
{
// ...
}
// ...
}
Place all the functionality you want to share with other translation units in a named namespace. This will instruct the compiler to wrap the code with a common name, so the names do not clash with the names of the external code (library, etc.).
namespace kotti {
void HandleInnerCollision(MovingObject& mobject,
const StaticObject& sobject)
{
// ...
}
// ...
}
a source to share
There are several idiomatic ways to do this. First way: where there are implementation files (cpp files), just use an unnamed namespace in that file for global functions or variables. Unnamed namespaces are not really unnamed, but instead have a unique name in each translation unit that you cannot print. If you are inline in a header file, you cannot do that - the general approach seems to be to use a namespace called detail inside the function namespace. It is not private, but it is common enough for developers to be left alone.
One thing you should note is that the is_inside function in your example is marked as private in the comments, but it is not private. By default, the members of a struct are public - in fact, that's the only difference between structs and classes, so since you don't precede it with a private one, it's public.
a source to share
You can have functions you want in one namespace and then have functions like is_inside()
in another namespace, like this:
namespace othernamespaceHelperFunctions
{
...helper functions...
}
Just use the namespace you want to use, the only one that uses the helper function namespace.
a source to share
Yes, you can use an unnamed namespace:
namespace
{
int private_variable;
}
int f()
{
return private_variable;
}
private_variable will only appear within the current translation unit.
But generally, I don't think this is a good idea. Better to use classes, OOP, components. :) The higher the better. This is the modern C ++ way.
a source to share
Okay, to answer your original question, to "privatize" a function, you either use a static one if you want it to be local to that file, or you can put it in a private header file if you want to use it throughout your entire the code. Ie either have it static bool is_inside(const Point& point, const Object& object);
in your .cc file or put the declaration inside algorithmsPrivate.hh
.
However, you are indeed writing C code here. If you want to do it in C ++, you add a method to the class instead Object
:
class Object {
...
bool contains(const Point& point) const;
}
One good thing about this is that it even lets you make the function virtual.
virtual bool contains(const Point& point) const;
Then, when you implement each Object
, it can have its own implementation of the contains function.
a source to share
I think you should keep it as a static class. This gives you the benefits of public / private, which is what you desire, and I see no disadvantages. I've always considered this to be a bit of a hack to use namespaces the way the other answers suggest. In my opinion, namespaces are for grouping related classes and free functions, and for avoiding name collisions, rather than providing encapsulation.
a source to share