couple of questions regarding classes

[Aakanaar]

I had a couple of different questions. First off.. when making a class, a class consists of member functions that provide the interface to the rest of the program. then it also consists of some member functions that are internal, and thus are private. The data members are also private for true encapsulation.

So.. I generally handle my class declaration (where i declare all of the member functions and data members) in the header file, and then define the functions in the cpp file. This has a side effect of displaying for whoever happens to be reading the header file to see what functions they have available to them, all of the functions including the private functions and data members that they need not be concerned with.

However, once I start declaring a class, I don't see anyway to stop after declaring the interface functions then continue the rest of it inside the cpp file. It has to all be declared in one sitting. (unless you inherit, but that provides other problems).

How do you handle that?

Also, I have been in the habbit of putting one class per header file and cpp file combination. (I havn't had much practice before with seperating code into multiple files. prior to devc++, i would have to make the make file to link it all together and I was never good at that.)

It makes sense to me to use a seperate header and cpp file per class. However, lets use the blackjack example since it's a recent topic. If i have a class to represent a card, which is very small:

class card
{
  public:
    int value ();
    string face ();

    void setvalue (int value);
    void setsuit  (int suit);

  private:
    int cValue; // 1 to 13
    int cFace; // 1 to 4
}

Does this really warrent a seperate header and cpp file? or should it be included with the header and cpp file that is defining the deck class, and or the shoe class?

[firedraco]

In reality, it doesn't really matter, however you probably will want to do whatever standard you are following tells you to do for the consistency. (Or when you come back in 2 years to read the code)

[Aakanaar]

ok.. well.. in a sense i guess i'm asking what is the de-facto standard.. when I get past playing with the language, and doing someting constructive or worse yet join a team, i would like to have a leg up and not have problems with the rest of the team because of the standards i develop on when to seperate to another file and when not to.

and for the first question, as long as I am the only one using the files that I create i know it wont be much of a problem. but if i distribute a module along with the header file, i'd like to not advertise anything more than what is required for the object's interface.

[Zaita]

Yes I know it, but, seeing the fact that C++ does not have a "string" type, I prefer to use directly arrays.

Methods. Not member functions.

So.. I generally handle my class declaration (where i declare all of the member functions and data members) in the header file, and then define the functions in the cpp file. This has a side effect of displaying for whoever happens to be reading the header file to see what functions they have available to them, all of the functions including the private functions and data members that they need not be concerned with.

There are technical reasons for doing it this way to. Otherwise you end up with cyclic-dependencies and declarations. IDE's handle it better for code finding etc.

Also, I have been in the habbit of putting one class per header file and cpp file combination. (I havn't had much practice before with seperating code into multiple files. prior to devc++, i would have to make the make file to link it all together and I was never good at that.)

Ideally, Keep the declaration in a single header, and the code in a single cpp file. Not split across files.

It makes sense to me to use a seperate header and cpp file per class. However, lets use the blackjack example since it's a recent topic. If i have a class to represent a card, which is very small:

Ahhh now it gets interesting. Now I am speaking from my POV.

In this situation, my object of card would be a struct, not a class. While handled almost the same by C++, there is a design difference.

Classes are more complete objects that have a much greater purpose, they have methods.

Structs are simple data structures that hide small amounts of information in an organise fashion.

e.g

struct card {
 int Value;
 int Face;
};

That would be sufficient enough. I typically don't encapsulate structs as I treat them like a complex-datatype. Now, because it's a struct (really a new data-type) and not a class with an implementation you can declare this in ur Deck header file.


Note: I do know how Structs/Classes are handled by the compiler and language etc. But this is from a design point of view.

Another note: Using private instead of protected, should only be done when there is NO possibility that member or method will need to be inherited.

[Aakanaar]

yea.. I do know from what i have read on this site as well as others, that classes and structs are the same thing as far as c++ is concerned, with the only exception being that in a class, members default to private, where in structs they default to public.

I too, do the same convention of using structs when I have no member functions (or methods) and use classes otherwise. I treat structs as just a complex data type.

And i was thinking of using a class for the card because, i could use a member fu.. er.. method to call the value (1 to 13) and another to return a string face, where I use the value and suit to construct "Ace of Hearts" or "Three of Spades" etc.

However, this will still be small enough, I suppose I should just declare and define it inside the same file that i use for "Shoe". And then decide if I want to use a seperate file for "Deck".

I know you're about to ask, why am i using both a Shoe and a Deck? I want to similate reality a bit closer and while I could just randomly get cards out of the deck as dealt, I want to shuffle the cards by clearing the shoe an then randomly getting cards out fo the deck and pushing into the shoe. Then I can pop off the front of the shoe for each card delt.

I know it's the hard way, but It would give me more practice in a more complex situation.

Edit: also, The reason i'll keep the value from 1 to 13, instead of 1 to 10 (it is blackjack after all) is the same reason i'm bothering to mess with suits. I'm trying to design the deck and shoe object so that I can re-use them in future card games as well.

[jsmith]

Aakanaar:

I was going to reply by saying "just use the pImpl idiom", but upon review of C++ Coding Standards by Sutter and Alexandrescu (ISBN 0-321-11358-6) they say to use it "judiciously" and "when you know you benefit from the extra level of indirection" [pp 76-78].

Used extensively it will slow program execution due to the extra function calls.

For reference, the pImpl idiom is as follows (pImpl stands for pointer-to-implementation):

class MyClass {
   public:
     // public API here
   private:
     struct MyClassPrivate;
     MyClassPrivate* pImpl;  // Or make this auto_ptr, shared_ptr, scoped_ptr, etc.
};

You will then need to implement a constructor that instantiates MyClassPrivate and possibly a destructor that destroys it (unless you use one of the self-managing pointer classes listed above). Furthermore, all of your public API functions must be implemented in the .cpp file (meaning they cannot be inlined) and all those functions do is call through the pImpl pointer to a similarly-named member function of MyClassPrivate to do the work. The idea is that MyClassPrivate is a type that the user cannot see and your header file must not include the header where MyClassPrivate is declared.

This idiom is generally used to reduce compile times.

Generally, if you've designed the API to your class well (meaning you don't expose the internals and you completely specify the behaviors of all public member functions for all valid and invalid inputs), you shouldn't care that the user can see your internal data members.

[Aakanaar]

ok.. thank you.. the idea of the pImpl is very intriging.. but the explanation of how it shoudln't really matter if the user can see the internal data members is also very helpful.

I appreciate the reply.

[mahlerfive]

It doesn't matter if someone can literally see the private members of your class because in their code they have no way of directly accessing them, the language itself prevents it. So the real point of private members is that the language will literally not allow someone to write code outside of your class to access the private members. Your public methods should be enough for another person to do everything that you intended your class to do, and nothing more.

[mahlerfive]

One last thing: if you have questions about c++ style (like your questions about header files), a good place to look is the Google c++ style guide: http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml

[Aakanaar]

ok, this is odd
I copied that link and got a blank page
So i went to google's main page and searched "Google c++ style guide" and got a link that matched your link and still lead me to a blank page.

This is very odd.

Edit: in fact google gives me several links all eventually leading to this same blank page. I view sorce and after a short header i see <body></body></html>

So litterally nothing..

[mahlerfive]

Weird because I'm seeing it fine..

[Aakanaar]

i wonder if it's my browser.. but that doesn't make sense either.
When i View Source, what i see is this

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=windows-1252"></HEAD>
<BODY></BODY></HTML>

[jmc]

You must have some kind of a stupid browser ;)
This is XML and not HTML so you should not have HTML, HEAD and BODY tags.
I can only recommend Firefox

[Aakanaar]

hey.. I resent t hat.. my browser is not stupid..
it's Intellectually challenged..

IE7
ver: 7.0.5730.13

I used to have firefox around somewhere.. but I think Microsoft Windows automatically removed it in favor of IE.. Just today, I got an error message saying that I'm not allowed to disable MySpace IM from startup.. very wierd.