Can there be two public section in a class? If yes then why ? And in which circumstances we do so?

Question

There is something bugging me about classes. For example

class A
{
public:
  A()
  {
  .....
  .....
  }

  void cleanup()
  {
  ....
  ....
  ....
  }

public:
  UINT a;
  ULONG b;
};

In the above example there are two public section. In the first section I am defining a constructor and a method and in the second section I am declaring data members. Is the above class i.e. A correct. Can we do that? If yes then why is that needed and in what circumstances should we use it? Since we can do the entire thing in one section then why are there two sections?

Clairvoyant

Your class has only one public section (plus an unnecessary additional public specifier in the middle of it). – Shiller

Answer 1

Access qualifiers simply apply to the code that follows until the next qualifier. There is no restriction on the number or order of such qualifiers.

It is generally not necessary to repeat the same access qualifier in a class, and doing so is likely to confuse the reader. They also may have an effect on the layout of a class, since data members following the same qualifier must be laid out in the order they are declared, but there is no such restriction between qualifiers.

Dijon

+1 The unspecified layout of members within different access specifier labels is an important detail. – Leaves

I'm intrigued. gcc complains when in the initializer list two attributes are initialized in reverse order from the way they are declared, is this affected ? – Exscind

It complains because the attributes are initialized in the order they appear in the class declaration (though I'm not clear how this works across access qualifiers). It can be misleading if the initializer list has them in a different order. – Dijon

If you have something private which depends on something public, and something public which depends on something private, then it makes sense to have repeat sections. This can happen when you have lots of typedefs and enums – Frogmouth

Answer 2

As Marcelo says, you can use the public, private and protected qualifiers as many times as you wish. "When" is entirely personal. Some people like this:

class AClass
{
public:
   // all the public stuff
protected:
   // all the protected stuff
private:
   // all the private stuff
};

but personally (and this really is just a personal preference) I like to do this:

class AClass
{
   // constructors and destructors
public:
   // public cons/dest
protected:
   // protected cons/dest
private:
   // private cons/dest

   // accessors
public:
protected:
private:

   // methods
public:
protected:
private:

   // members
public:
protected:
private:
};

Feel free to come up with your own style, whatever you're comfortable with. There is no right or wrong way of doing it. Just try to be consistent.

Gavrila

Don't you want constructors to be public? – Scanderbeg

@user129393192: not always, a private constructor would only be accessible from within the class so could be used in a static member function which can be useful if you need to do any preamble work before creating the object. Yes, you could do it in the constuctor but you'd have to handle exceptions as there's no other way to signal an error/invalid state. So it's a choice between check before constuction or check during construction. As always, there's no right or wrong way, just what makes it easier to understand. – Gavrila

Answer 3

I usually try to arrange the declaration of the class so that it's easy for others to use the said class.

The usual is thus: public/protected/private, in this order, because it simplifies life for the readers.

• People who use the class can stop reading once reaching the protected tag, anything after is none of their concern.
• People who derive from the class can stop reading once reaching the private tag, anything after is implementation detail.

This, coupled with not writing the code of the methods at their point of declarations, makes for an easy to read interface.

There are however a couple of tricks:

• when using metatemplate programming, you may need to declare types first, methods afterward, so you end up with 2 series of public/protected/private
• when using the Key idiom (instead of friend), you have a public section that is in fact dedicated to only a small portion of the users and is best isolated either at the bottom of the normal public section or after the protected section.

Finally, as to comment about the layout issue among the attributes. Encapsulation means that attributes should be private. So, either you have a struct and everything is public or you have a class and everything is private, mixing the two means breaking encapsulation, and that's a bug in the making.

Exscind

Answer 4

Yes its correct however personally I prefer to just have one public section at the top of the class, that's where programmers looks first when examining a new class. It is then easier to see which parts are supposed to be accessible and which are not -- instead of browsing the whole class header.

Herb

Answer 5

The class is correct, public is just a access qualifier and will apply till the next qualifier is seen or the end of class declaration. There is no limit to how many of these access qualifiers(public, private, protected) you can have in a class. As to why this is useful, it helps writing class declarations the way you want. For example I might want all the member functions (public,protected or private) declared before the (say) private data members.

Canonicals

Answer 6

As @Marcelo Cantos's answer explains, this is allowed. When writing code yourself you should avoid this, as it only leads to confusion when others read your code. The only place I have ever seen this in real life is in the code generated by various MFC-wizards. Whenever you add some thing to your class using a wizard, it would just add an extra section to the end of your class.

Otic