Jump to content
  • Advertisement
Sign in to follow this  
LonelyStar

Unity predefining a class in the namespace of class

This topic is 4074 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hello Dear community I want to define a class in the namespace of another class, like this:
class A
{
public:
  class B
  {
  ...
  };
  B Something;
  ...
};
But I want to define A and B in sperate files. Since A uses B for a member-variable (like "Something" in the example), B must be defined befor A. So I tried: A.h:
include <B.h>

class A
{
public:
   B Something;
   ...
};
B.h:
class A;

class A::B
{
   ...
}
Does not work, I get "qualified name does not name a class" at the definition of B. How is it done correctly? Thansk! Nathan

Share this post


Link to post
Share on other sites
Advertisement
You can't. C++ does not allow you to declare a single member of a class, you have to declare them all simultaneously. However, you don't have to make B a subclass of A: a typedef is enough.


// B.hpp

class B
{
};

// A.hpp
#include "B.hpp"

class A
{
public:
typedef ::B B;
A::B Something;
};


Share this post


Link to post
Share on other sites
Quote:
Original post by ToohrVyk
You can't. C++ does not allow you to declare a single member of a class, you have to declare them all simultaneously. However, you don't have to make B a subclass of A: a typedef is enough.

*** Source Snippet Removed ***


But what would the benifits of that be?

Class scope definitions of other classes are generally used to reduce the scope and give meaning to the second class, whereas the code you suggest not only leaves class B in the global namespace, but actually gives you multiple ways of defining the same object (since you have to include b.hpp to use a.hpp).

If class B is a generic class that would be used by only a select few classes, then the inclusion and scope of B should be altered, rather than adding additional ways of referencing it.

Spree

Share this post


Link to post
Share on other sites
Quote:
Original post by SpreeTree
But what would the benifits of that be?


Being able to move the definition of B to its own file and out of A.

Quote:
Class scope definitions of other classes are generally used to reduce the scope and give meaning to the second class, whereas the code you suggest not only leaves class B in the global namespace, but actually gives you multiple ways of defining the same object (since you have to include b.hpp to use a.hpp).


_Vector_const_iterator is a template class in the std:: namespace, but nobody ever uses it. In fact, few people even suspect its existence, and it isn't guaranteed to exist on all compilers or libraries either. Most people use std::vector<T>::const_iterator instead, even if it's just a typedef for std::_Vector_const_iterator<T>.

The fact that a class is in the global namespace (or any namespace, for that matter) doesn't mean that it's public—besides, naming it _private_impl_A::_B (with the appropriate name and namespace) is extremely easy to do, and conveys the "don't touch this class" message pretty clearly to programmers. Users should not be aware of the existence of _private_impl_A::_B and the "B.hpp" header.

Ultimately, it is the documentation of the signature of the module, and not the header files, that should be used by the programmers.

Share this post


Link to post
Share on other sites
Quote:
Original post by ToohrVyk
Quote:
Original post by SpreeTree
But what would the benifits of that be?


Being able to move the definition of B to its own file and out of A.


I meant besides that ;)

Quote:
Original post by ToohrVyk
The fact that a class is in the global namespace (or any namespace, for that matter) doesn't mean that it's public—besides, naming it _private_impl_A::_B (with the appropriate name and namespace) is extremely easy to do, and conveys the "don't touch this class" message pretty clearly to programmers. Users should not be aware of the existence of _private_impl_A::_B and the "B.hpp" header.

Ultimately, it is the documentation of the signature of the module, and not the header files, that should be used by the programmers.


I understand your reasoning behind that (and the private impl namespace is a good idea), but unfortunatly to a lot of people the fact that it is global would directly lead them to think it was public.

With the advent of Visual Assist and (to a lesser extent) itellisense showing you everything and more within your current space, people would know of it's existence whether you wanted them to or not.

I have also worked with lot of professional libraries that have little or no documentation (of course you could question the term professional in that case) which is why I try to go to great lengths to show the use and scope of a class directly from the source, rather than only relying on the documentation :)

This is a useful tool in the big box of programmer tools (and there are plenty of ways around limiting the use of B within the space of program), I just thought I would mention a problem some people would have with your solution.

Spree

Share this post


Link to post
Share on other sites
Thanks for your replies.
I want B to be declared in A because it is only used as a member of A and should not be visible from the outside.
On the other hand its big enough to make the class decleration of A look complicated.
For that reason ToohrVyks Idea seems not so good here.

What would you do in this case?
Nathan

Share this post


Link to post
Share on other sites
You also have the possibility of:


// A.hpp
class A
{
// ...
public:

#define A_INCLUDING_B
# include "_B.hpp"
#undef A_INCLUDING_B

B Something;
};

// _B.hpp
#ifndef A_INCLUDING_B
# error This header file should not be included
#endif

class B
{
// ...
};

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!