tags:

views:

165

answers:

5

Hello,

I have been coding regurlarly in C++ in the past months. I am getting used to it step by step... but there are things that confuse me about formatting.

I know there is a lot of legacy from C that I supousee mixes with C++. This time I have doubts about how to order properly my members and functions within in a class. Also considering their access modifiers.

How is the convention in this? Until know I am doing everything "public" and writing first constructor of class, then destructor, next members and finally functions. It this correct? What happens when introducing "private" and "protected" access modifiers or "virtual" functions?

From the documents I have look in the Internet there is different ways of doing things. But my questions aims to get the knowledge from a community that develops in C++ that I want to blend into. ;-)

Thanks a lot!!!

+3  A: 

You answered your question yourself: "there is different ways of doing things". Google has published C++ Style Guide which you could use as starting point.

Kirill V. Lyadvinsky
Not that it is a good C++ standard guide...
David Rodríguez - dribeas
Agreed, it is controversial sometimes.
Kirill V. Lyadvinsky
all coding style guides are controversial!
Max
@max: To an extent not everybody agrees with all rules in a convention. But the google standard has more silly rules than most and has generated a lot of discussion. One of there reasons is that their rules exist to help maintain backwards compatibility with some legacy C++ code.
Martin York
A: 

The order does not matter.

( The only exception to this is that members are initialized in the order they are mentioned, and destroyed in the reverse order. This will only be of significance if your constructors and destructors have side effects - which is rare and best avoided if possible. )

So you can place things in the order that pleases you.

It is best to keep to a consistent order, so you can find things in a class you wrote months ago.

I like to place everything private at the end, so it is tucked out of sight from the casual inspection.

ravenspoint
It can also matter if a member is used in the initialization of another member (which should also be avoided)
David Rodríguez - dribeas
All variables should be private so they should be tucked away at the end in the order you want to have them initialized.
Martin York
+10  A: 

My humble opinion, after having read many style guides all over the 'net:

  • Public first, because that is the interface of your class, which people want to see first.
  • From the same reasoning, private goes last.
  • If you have any private functions, place them before private members. (Again, same reasoning. Your members are of the least interest to anyone.)
  • Constructor first in the public section, because people have to call that before they have an object on which to invoke any functions.
  • Destructor right after the constructor, just to have them in one place.
  • Within the public / protected / private sections, find some grouping logical to any users of the library, and write a one-line comment in front of each group. (Doesn't matter that much what's the logic, as long as it's documented.)
  • Don't make any rules more complicated than this, because the more complicated, the easier to get it wrong (or just ignore it as inconvenient).

Remember that members should be initialized in the order they are declared, and destroyed in the reverse order.

DevSolar
+1 : "Don't make any rules more complicated than this, because the more complicated, the easier to get it wrong (or just ignore it as inconvenient)." its always a good advice.
Tom
+1, couldnt agree more
mizipzor
I'd personally add *"for every section with different access mode typedefs first"* so they are not wildly mixed in.
Georg Fritzsche
I personally add the = operator next to the constructors if I have a copy constructor
Cthutu
I agree in general. But readability must be the first rule. If following the rules makes it harder to understand then break the rule. Ability to unerstand the code (interface) must take precedence over any guidlines (remember they are guidlines not absolutes).
Martin York
@ gf: I tend to discourage the use of typedef's, especially in header files and **especially** in class scope, hence I didn't mention them. Typedef's are nice when they make otherwise hardly readable syntax easier to handle (function pointers or deeply nested containers spring to mind), but most of the time they simply hide information and add yet another step to the lookup process. ("What the heck is a TupleList?")
DevSolar
@ Martin York: Of course a style guide aims at readability. Once you have used a couple of them and earned some experience, you get a pretty good "gut feeling" on what is readable and what isn't. But a poster *asking* for good style apparently doesn't *have* that "gut feeling" yet, so "just make it readable" doesn't help. -- Quoting my Martial Arts instructor: "First, learn to follow the style. Then, build experience. Then find your own style. Skipping step one and two will just give you confidence without skill, which is dangerous at best."
DevSolar
yeah, right! put all functions before data members, and if inline, make reader wondering "what the hell is the type of foo?"
chester89
+1  A: 

I'd suggest if you are learning, you consider making everything private to begin with, and then revising this as needed. That way, you will have to think about each thing when its needed outside the class and may spot a better way to structure your classes as a result.

Let us recommend a book called Code Complete, just search Amazon or your favourite online book store.

John
+1  A: 
Until know I am doing everything "public"

Don't. When you create a class it is like creating your own type, just like int, char, etc.

You have to strive to present an interface ( the public part of your C++ class ) that is easy to use and encapsulate the implementation ( the private part of your class ). If your class does not have any private members then you are not encapsulating anything and is considered bad design.

Read this series of articles on object oriented design principles. You may have a hard time reading it but read it multiple times till you feel you have got a hang of the concepts.

ardsrk