TheMadManiac
asked on
Private classes
hello,
I am creating a class that can translate HTML pages to plain text much like lynx does, however it's output is going to show up on video-tex (context info, you can forget that after this ;-).
The problem I have is that it has a lot of sub-classes, and they are all defined private in the root-class, like this:
class root
{
private:
class _1 {/*stuff*/};
class _2 {/*stuff*/};
class _3 {/*stuff*/};
class _4 {/*stuff*/};
};
Needless to say this becomes really messy. However just defining them outside the root will take away a lot of usable names for classes, and will not be of any use to any programmer (including me), once the root is done.
I am looking for some way to keep the classes private or otherwise hidden outside the root class, but clean up the root class header.
Any ideas are welcomed,
Floris
I am creating a class that can translate HTML pages to plain text much like lynx does, however it's output is going to show up on video-tex (context info, you can forget that after this ;-).
The problem I have is that it has a lot of sub-classes, and they are all defined private in the root-class, like this:
class root
{
private:
class _1 {/*stuff*/};
class _2 {/*stuff*/};
class _3 {/*stuff*/};
class _4 {/*stuff*/};
};
Needless to say this becomes really messy. However just defining them outside the root will take away a lot of usable names for classes, and will not be of any use to any programmer (including me), once the root is done.
I am looking for some way to keep the classes private or otherwise hidden outside the root class, but clean up the root class header.
Any ideas are welcomed,
Floris
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Essientialy that is using the root class as a namespace for sub. If your "library" defines lots of other things that you would also like to prevent from poluting tha global namespace (like constants, typedefs, enums) you might want to consider using a real namespace to "hide" this stuff. (You can use a class to "hide" the typedefs and enums too, but not constants, so I prefer namespaces)
ASKER
Reading about namespace stuff, i come to the simplified conclusion that a namespace is similair to a class with everything public, and no constructor/destructor.
What advantage would using a namespace have over the use of a 'class-namespace' ? Both will be accessable via the :: scope operator, and members of that scope need the scopename:: infront of their declarations (inless directly declared inside that scope-definition-body).
Floris
What advantage would using a namespace have over the use of a 'class-namespace' ? Both will be accessable via the :: scope operator, and members of that scope need the scopename:: infront of their declarations (inless directly declared inside that scope-definition-body).
Floris
There is no direct advantage to using a namespace for these classes, unless you have lots of other classes and functions that you want to place outside the global namespace.
>> namespace is similair to a class with everything
>> public, and no constructor/destructor
That is ver simplified. But they are very similar syntacally and in _some_ ways in which they are used (like in this way). but a class is a type. That is a class used to create objects--data. A namespace is not a type, it can not be used create data. It simply is a "scope" that can be used to group a bunch of names (class names, typdefs, constant names, procedure names etc.) together and to prevent them from confliciting with other names in the program.
>> What advantage would using a namespace
>> have over the use of a 'class-namespace'
It depends. Possibly none. Possibly some, Possibly just depends on you programming style. One advantage is that classes cannot store "global" constants. i.e if you declare a constant in a class, that constant appears in every object of that class, not just one time. if you make the constant static, it appears just one time, but might not be optimized as efficiently as a global constant. Another adjantage to a namespace is that you can use a "using" declaration to bring names from the namespace into the current scope so that you do not have to prefix the names with the namespace name and a "::". you cannot do this with a class--an oversight I believe! Another advantage is that you can reopen a namepace to add members to in in different parts of the program. A class cannot do this. All of its members must be declared in the class declaration and this declaration must be the same each time it occurs.
However, none of these points are advanages if you don't need them.
>> public, and no constructor/destructor
That is ver simplified. But they are very similar syntacally and in _some_ ways in which they are used (like in this way). but a class is a type. That is a class used to create objects--data. A namespace is not a type, it can not be used create data. It simply is a "scope" that can be used to group a bunch of names (class names, typdefs, constant names, procedure names etc.) together and to prevent them from confliciting with other names in the program.
>> What advantage would using a namespace
>> have over the use of a 'class-namespace'
It depends. Possibly none. Possibly some, Possibly just depends on you programming style. One advantage is that classes cannot store "global" constants. i.e if you declare a constant in a class, that constant appears in every object of that class, not just one time. if you make the constant static, it appears just one time, but might not be optimized as efficiently as a global constant. Another adjantage to a namespace is that you can use a "using" declaration to bring names from the namespace into the current scope so that you do not have to prefix the names with the namespace name and a "::". you cannot do this with a class--an oversight I believe! Another advantage is that you can reopen a namepace to add members to in in different parts of the program. A class cannot do this. All of its members must be declared in the class declaration and this declaration must be the same each time it occurs.
However, none of these points are advanages if you don't need them.
You can apply the using to class members, in a limited way:
struct A { static void f(); };
struct B : public A { using B::f; };
struct C
{
using A::g; // illegal, A is not a base of C
};
struct A { static void f(); };
struct B : public A { using B::f; };
struct C
{
using A::g; // illegal, A is not a base of C
};
ASKER
I'll answer the question and make another one for you nietod.
However I would like this 'thread' in one piece, which is also handy for future purchasers.
Nietod:
So if I understand correctly ('file' being a class in the first example, and a namespace in the second), instead of doing:
//file.cpp
#include "file.hpp"
file::function() {}
file::function2() {}
file::function3() {}
I could do:
//file.cpp
#include "file.hpp"
using namespace file;
function() {}
function2() {}
function3() {}
.... or did I really mis the boat on that one? ( I read some.. but I think i need to read it again ;-) If this is true, then this would probably also apply to member functions that access again member-classes (currently I have 3 layers of sub-classes, and class::class::class::Type:
Even though I currently do not see how that would benefit myself as it does not happen all that often... unless I drop everything in a namespace instead of a root-class.. then the root class would become namespace::class, but i can live with that.
KangaRoo:
That seems... erm... usefull.. I guess :-) I did not know it was possible, but I guess it removes the need to re-make the 'f' function, and thus would reduce code-size (if the compiler was not that smart as to remove identical functions).
Floris
However I would like this 'thread' in one piece, which is also handy for future purchasers.
Nietod:
So if I understand correctly ('file' being a class in the first example, and a namespace in the second), instead of doing:
//file.cpp
#include "file.hpp"
file::function() {}
file::function2() {}
file::function3() {}
I could do:
//file.cpp
#include "file.hpp"
using namespace file;
function() {}
function2() {}
function3() {}
.... or did I really mis the boat on that one? ( I read some.. but I think i need to read it again ;-) If this is true, then this would probably also apply to member functions that access again member-classes (currently I have 3 layers of sub-classes, and class::class::class::Type:
Even though I currently do not see how that would benefit myself as it does not happen all that often... unless I drop everything in a namespace instead of a root-class.. then the root class would become namespace::class, but i can live with that.
KangaRoo:
That seems... erm... usefull.. I guess :-) I did not know it was possible, but I guess it removes the need to re-make the 'f' function, and thus would reduce code-size (if the compiler was not that smart as to remove identical functions).
Floris
>> I'll answer the question and make another one for you nietod.
I wasn't "looking for ooints". I really just wanted to give you another option. Kangaroo's answer was correct and the best choice if only 1 soluton was presented. but there are was another good choice.
I wasn't "looking for ooints". I really just wanted to give you another option. Kangaroo's answer was correct and the best choice if only 1 soluton was presented. but there are was another good choice.
ASKER
Never the less I still learned something :-) This is why I ask questions, to learn things that are closely related to the original question. As well as to give me new ideas or alternatives. Even though I might not use them at that point, someday soon I might. You could consider it an unasked question's answer or something.
PS: all sorts of stuff, including namespaces : http://www.ocsltd.com/c++/
PS: all sorts of stuff, including namespaces : http://www.ocsltd.com/c++/