Class Q's

If a particular class''s functionality only makes sense within the context of the main class in that cpp file, feel free not to break it out into a different file. However, if you''re doing this, you should probably consider making it an inner class; that will simplify code, since your tiny classes will have access to private data, and you can declare the inner class private, which will more robustly enforce the class''s intended scope.

If you are declaring a class that isn''t definitionally a private helper for another class, then it''s probably best to break it out into its own file; it''ll keep your file sizes down (good for not being overwhelmed by code) and it could possibly make things easier down the line.

Anon-
It's not so much hiding it from other people (I'm not writing librarys) it's just a protection thing. By declaring stuff outside the class in the source file as static it is local to that source file only. So struct defentitions are only visible to that source file. With the method of declaring all functions/vars in the class all the struct definitions also have to be in the header file, and therefore the other code sections that include that header file will have the struct defentitions as well.

sneftel-
I'm not putting parts of a class into a seperate source file, I'm just theorizing about where things are declared and there scope..

I know it's not a big deal and that I am just being anal about a moot point as both styles are easy to read (I'm very consistent by the way) and offer the same functionality. I guess I'm just looking for outside opinion on what style I should continue to use....

-Nate

Edited by - Zimans on January 4, 2002 8:38:12 PM

That''s really bad coding style You should delare all the data and functions (well the ones that relate to the class) that the class uses as part of the class but delclare them as private. That way only the class will be able to access them.

e.g.

class Example { public: int PublicMethod() { PrivateMethod(); return i; } private: int i; void PrivateMethod() {} }

Only PublicMethod() can be accessed from outside of the class.

The following code will not compile because PrivateMethod() has private access:

Example ex();
ex.PrivateMethod();

- Kaijin

After thinking about it more I guess the main thing i''m really shifty about is struct defenitions in the header.. Lemme make an example:

Way I''ve been doing it.
Class.h
class
{
public:
member1
member2
};

class.c
struct dir_typ
{
member1
member2
member3
...
};

static dir_typ *Directory;

class code...

Here the directory is accessible by the class, but the rest of the code does not see the dir_typ struct defention, otherwise it has to lool like this

class.h
struct dir_typ
{
member1
member2
member3
...
};

class
{
public:
member1
member2
private:
dir_typ *Directory
any other helper funcs
};

class.c
class code....

where any subsystem see''s the dir_typ struct defintion..

again I''m being anal about a moot point...

-Nate

Oh I see. In that case you can put the struct definition inside of the class definition like this:

class.h ======= class { public: member1 member2 private: struct dir_typ { member1 member2 member3 ... }; dir_typ *Directory; any other helper funcs };

At least I think so, my inner class/struct knowledge is a little rusty in C++. You can do it in Java and I''m pretty sure you can do it in C++ too.

- Kaijin

Putting the struct in the private section of the class does work. I just tried it. This seems like a nice compromise for my anal nature, but when classes start to become large, there may be alot of structs declared in the private section.. That would make the class defenitions become rather large.. I dunno.

Thx for the tip.

-Nate

Yeah, that''s true I suppose but some classes are naturally big by their nature.

- Kaijin