Reputation: 720
In the past, I would write classes like this:
// my_class.h
class MyClass
{
public:
// Signals emitted by MyClass objects.
typedef boost::signal<..> SignalA;
typedef boost::signal<..> SignalB;
enum SomeEnum
{
..
};
enum AnotherEnum
{
..
};
typedef some_type SomeOtherType;
// an exception thrown by MyClass objects
class ExceptionA
{
..
};
MyClass();
// rest of class definition omitted
};
The thing I always hated about this style is that it convoluted the class declaration. So then for a recent project I decided to try something new. I decided to use namespaces in a fashion similar to that of modules in Python (we also use Python a lot where I work):
// my_class.h
namespace my_class
{
// Signals emitted by MyClass objects.
typedef boost::signal<..> SignalA;
typedef boost::signal<..> SignalB;
enum SomeEnum
{
..
};
enum AnotherEnum
{
..
};
typedef some_type SomeOtherType;
// an exception thrown by MyClass objects
class ExceptionA
{
..
};
class MyClass
{
public:
MyClass();
..
};
}
And the result wasn't too bad. The only downside is that you always had to prefix "my_class::" before everything. But that could be alleviated by utilizing "using" statements.
I am about start another project and I was thinking of doing this again. Are there any serious downsides (other than increased verbosity) to adopting this use of namespaces?
Upvotes: 3
Views: 2059
Reputation: 39419
This is exactly how you should do it. One thing to keep in mind is that you want to avoid circular dependencies between namespaces. Furthermore, IMHO it is a good idea for each namespace to correspond to a separate library. That also implies that you should avoid nesting the namespaces too deeply. Maybe one top level namespace for your company to differentiate from third party code, and then another level of namespaces for individual components.
Upvotes: 1
Reputation: 8206
Other than the name my_class, that should be fine. In fact, that is the purpose of namespaces.
Upvotes: 2