# namespaces and forward declarations

## Recommended Posts

Hi, I have a little question concerning namespaces and forward declaration. See the following example :
// in foo.h :
namespace Foo
{
class FooClass {};
}

// in bar.h :
namespace Bar
{
class BarClass
{
Foo::FooClass * m_pFoo;
};
}


What should I add in bar.h to make this compile ? If I don't use namespaces, I simply add class FooClass; before the declaration of BarClass, but with namespace, if I add class Foo::FooClass; I have a compile error telling me that namespace Foo is not know / defined (don't remember exactly) And if I add : using namespace Foo; class FooClass; There is an ambiguity : the compiler doesn't know which namespace FooClass belong ... The only solution I've found is to include foo.h in bar.h, but I would like to avoid that. Thx in advance for any help !

##### Share on other sites

namespace Foo{    class FooClass;}

at the top of bar.h

##### Share on other sites
Ok, thanks, that was simple :)

I just thought of another thing :

// in foo.h :namespace Foo{    class FooClass    {        struct FooStruct {};    };}// in bar.h :namespace Bar{    class BarClass    {        Foo::FooClass::FooStruct * m_pFoo;    };}

Is it possible to do that without including foo.h in bar.h ?

##### Share on other sites
Quote:
 Original post by paicOk, thanks, that was simple :)I just thought of another thing :*** Source Snippet Removed ***Is it possible to do that without including foo.h in bar.h ?

Forward declaration means the in order to use a type, you need to declare it somewhere before that line.

If foo.h has been seen somewhere before, then yes, you can do that.

If not, then you need to declare Foo again in bar.h.

iostreams and some other libraries provide xyz_fwd.h for this very reason. Rather than including everything, they provide you with forward declaration of types.

##### Share on other sites
Quote:
 Original post by paicIs it possible to do that without including foo.h in bar.h ?

No. You would have to have the class declaration in scope to see any nested classes. That means nested classes cannot be forward declared.

On the other hand, the need to do so probably implies you have your design wrong.

--smw

##### Share on other sites
Quote:
 Original post by BregmaOn the other hand, the need to do so probably implies you have your design wrong.

When you say something like that, it would be greatly appreciated to tell why :) I'm probably a lot less good than you, and I don't really see any reason (other than the impossibility to use forward declaration) not to use nested structs / enums / classes :s

Edit: And thx for the answer :)

##### Share on other sites
Quote:
 Original post by paicWhen you say something like that, it would be greatly appreciated to tell why :) I'm probably a lot less good than you, and I don't really see any reason (other than the impossibility to use forward declaration) not to use nested structs / enums / classes :s

Why are you doing this? Are you trying to reduce compilation times? Do you have mutual dependencies? Or why?

##### Share on other sites
Well, I'm not doing this for any particular reason.
I have a IResource interface class. And I have an enum inside this class. Something like :
class IResource{public:    enum Type    {        Texture = 0,        VertexBuffer,        // etc.    };};

Then I can use resource types with something like "IResource::Texture"
I find it simple to use, and "user friendly".

Another example is events. I have a few systems with events, and instead of having a big event handler, I have few event handlers, each with their own kind of event. I used nested structures to stores those events. The only reason to that is : I don't have to bother finding a good name for the structures. Since they are nested, they are all called Event :)

I'm not very experienced, so maybe their are big disadvantage to using nested class / struct / enum but I don't know them (except for the forward declaration problem)

##### Share on other sites
Quote:
Original post by paic
Quote:
 Original post by BregmaOn the other hand, the need to do so probably implies you have your design wrong.
When you say something like that, it would be greatly appreciated to tell why

Nesting one class inside another means that it is internal to that class. That's why the enclosing class definition has to be in scope to see the declaration of the nested class (note, the definition of the nested class does not have to be in scope, just its declaration).

As with any other time the internals of a class become a part of its public interface, you risk increased coupling and reduced maintainability of your code. Using a nested class as a part of the interface to the class is not technically wrong. It's just like using any other member of the class. There are the same advantages and disadvantages. The particular problem you seem to be running into here is that you seem to be wanting to use the internals of one class as a part of the public interface of another, unrelated class. Here be dragons.

It's one of those things about C++. If you find you have difficulty expressing what you want to do, it's a good indication that maybe it's what you want to do that's wrong, not the language. I find when that happens to me, if I back up and rethink what I want to do, there's almost always a better way that's easy to implement in C++.

## Create an account

Register a new account

• ### Forum Statistics

• Total Topics
627734
• Total Posts
2978846

• 10
• 10
• 21
• 14
• 12