"Right" use of namespaces

[lionheart]

Hi,
I am currently trying to group my classes using namespaces. But since
these groups are not really independend I end up to have a lot of
forward declarations.

My first approache was to enclose all class definitions and forward
declarations in the corresponding headers directly. Which turned out to
make it difficult to read the header, and created a lot of overhead.

Therefore at the moment I am using a headerfile dedicated to forward
delcarations which are enclosed in the correct namespace. Is this a
common strategie? What are the up- and downsides from your perspective?
What are the alternatives?

In the headerfiles I am not using the "using-directive" to import
classnames in the namespace, because I don't want to make them
accessible through a second namespace. Same reason we I don't create a
"shortcut-namespace" (e.g. namespace abc = ada::basic::cobol). But
since I am using the namespace hierachie directly, first there is a lot
of overhead in writting and second if I change the namespaces I have to
change it in every single file. Is there an alterative? If the
using-directive would make the namespace/class imported visible from
outside it would be my perfect choice.

In the .cpp files I take advantage of the the using-directive a lot.
Since all .cpp-files are closed entities it should be fine to do so,
right?

Thanks for your help,
Thomas Kowalski

[Daniel T.]

In article <11**********************@b28g2000cwb.googlegroups .com>,
"lionheart" <th***@gmx.dewrote:

Hi,
I am currently trying to group my classes using namespaces. But since
these groups are not really independend I end up to have a lot of
forward declarations.

My first approache was to enclose all class definitions and forward
declarations in the corresponding headers directly. Which turned out to
make it difficult to read the header, and created a lot of overhead.

Therefore at the moment I am using a headerfile dedicated to forward
delcarations which are enclosed in the correct namespace. Is this a
common strategie? What are the up- and downsides from your perspective?
What are the alternatives?

In the headerfiles I am not using the "using-directive" to import
classnames in the namespace, because I don't want to make them
accessible through a second namespace. Same reason we I don't create a
"shortcut-namespace" (e.g. namespace abc = ada::basic::cobol). But
since I am using the namespace hierachie directly, first there is a lot
of overhead in writting and second if I change the namespaces I have to
change it in every single file. Is there an alterative? If the
using-directive would make the namespace/class imported visible from
outside it would be my perfect choice.

In the .cpp files I take advantage of the the using-directive a lot.
Since all .cpp-files are closed entities it should be fine to do so,
right?

Yes. However I think what you are doing with namespaces is inappropriate
to begin with.

The namespace mechanism exists to avoid name collisions when different
libraries are used in the same program. They also come in handy when
multiple people are working in the same program to avoid name
collisions. An individual working alone simply shouldn't have the kinds
of problems that namespaces are meant to solve. All IMHO of course.

[lionheart]

An individual working alone simply shouldn't have the kinds

of problems that namespaces are meant to solve. All IMHO of course.

Well, since c++ don't have packages I think namespaces is what comes
most close to it. Therefore I use it to clarify the concepts of my
software by grouping classes. I think more then 8-12 classes at the
same level of hierarchie are too troublesome to understand.

Thanks for your answer,
Thomas Kowalski

[Gavin Deane]

Daniel T. wrote:

In article <11**********************@b28g2000cwb.googlegroups .com>,
Yes. However I think what you are doing with namespaces is inappropriate
to begin with.

The namespace mechanism exists to avoid name collisions when different
libraries are used in the same program. They also come in handy when
multiple people are working in the same program to avoid name
collisions. An individual working alone simply shouldn't have the kinds
of problems that namespaces are meant to solve. All IMHO of course.

I agree, except that an individual might have the kind of problems
namespaces are meant to solve if they are both the application
developer and the library author. I keep all of the general tools and
utilities I create in their own namespace. Then I know I can reuse them
as a useful library without the future fear of name clashes. More often
than not it, ends up being perfectly safe to include the whole
namespace with a using directive, but the option of namespace
protection is there for the time I need it.

Gavin Deane

[Daniel T.]

In article <11*********************@i3g2000cwc.googlegroups.c om>,
"lionheart" <th***@gmx.dewrote:

An individual working alone simply shouldn't have the kinds
of problems that namespaces are meant to solve. All IMHO of course.

Well, since c++ don't have packages I think namespaces is what comes
most close to it. Therefore I use it to clarify the concepts of my
software by grouping classes. I think more then 8-12 classes at the
same level of hierarchie are too troublesome to understand.

Maybe I'm showing my old school roots, but I use the header and source
files for that sort of thing.