This could've been a very scary topic.. Or maybe it is already???

You mean if you prefer your privates on the top or bottom?

Bottom for classes (first divided in public, protected and private, each of one in "bottom style" ie ctors, functions, inner classes/datastructures, consts, variables... static things before non static things)

Top for data structures (yes, sometimes I add some little functions to structures)

I like placing the private stuff first in classes, since that is the one thing that makes sense. Putting the public interface (or anything public) first is nonsensical.

A class is a struct where the members default to being private rather than public (in layman's wording, the standard's wording is slightly more elegant).

Therefore, if you write class and immediately follow with public: you are being nonsensical. You're the madman who puts salt on his bananas and throws them away because he doesn't like salted banana. I try not to write nonsensical code, if I can help it.

If one wants the public members first, one should write struct and declare the non-public members private. Of course nobody does that... so it's private stuff first

In C++ private as default class access modifier was a style choice with a solid reason, and not salt on banana:

Before starting work on C with Classes, I worked with operating systems. The notions of protection from the Cambridge CAP computer and similar systems – rather than any work in programming languages – inspired the C++ protection mechanisms. The class is the unit of protection and the fundamental rule is that you cannot grant yourself access to a class; only the declarations placed in the class declaration (supposedly by its owner) can grant access. By default, all information is private.

p14 http://www.stroustrup.com/hopl2.pdf

I do top because of the class being private by default. My method is to do private members on top, protected if I have any, public methods, followed by any operator overloading I'm doing and the constructors/destructors.

I generally put the interface at the top and private members and classes at the bottom because users of the class(including myself) shouldn't be bothered by the implementation so why make them wade through it before they get to what they need? Even when it comes to the interface, I put methods that will be used the most at the top.

That the default access in classes is private has never been a concern to me. I've always thought of it more as a reminder that member variables in classes should be private.

My head doesn't explode when others do the opposite way though.

Reading his most recent version of his The C++ Programming Language book makes it look like Bjarne does top too. His first code from 16.2.3 Access Control:

class Date{
      int d, m, y;
public:
      void init(int dd, int mm, int yy);     // initialize

      void add_year(int n);                  // add n years
      void add_month(int n);                 // add n months
      void add_day(int n);                   // add n days
};

I don't know his reasoning behind it, but I do know mine. My reasoning is, since the default is private why change it to public just to turn around and make it private again.

In C++ private as default class access modifier was a style choice with a solid reason, and not salt on banana:

Well yes, exactly. that is what I'm saying. Hence the pittoresque example

When you write class foo, you are implicitly requesting from the compiler:

class foo
{
private:

The private: is implied, since that is what class is about (in contrast to struct).

If, on the other hand, you put the private members first, you are requesting from the compiler:

class foo
{
private:
public:

It's legal, but absurd. Nonsensical, like putting salt on a banana and throwing it away. Or, like producing a 24k gold zippo and painting it black because you don't like gold (no kidding, one well-known designer actually did that in the 1980s...). You ask for private and immediately throw it away.

The logically correct thing (leaving protected out of consideration for simplicity) would be to either:

struct foo
{
    // here be public stuff
private:
    // blah
};

or

class foo
{
    // here be private stuff
public:
    // blah
};

Of course, "struct" does not sound nearly as cool as "class", so nobody uses struct (other than to bundle together 2-3 PODs without methods, maybe). But actually it would be the correct thing to do, if that is the behavior you want.

I don't know Samoth, I see your point but I would imagine most people don't use class or struct based on implicit accessibility (and go for the more traditional class = complex container with logic, struct = POD approach), so from that point of view it's not nonsensical at all, as the default accessibility doesn't factor into the decision either way, i.e. the programmer did not "ask for private/public", but for a struct or for a class. The fact that the language has some rules about what the default accessibility is is just irrelevant from that perspective.

To me this appears like a style decision, depending on how you interpret the more subtle parts of the language. In your case (the pedantic view, if you will) you prefer to honor the default accessibility settings. In the other case, the programmer prefers not to rely on them (or even know they exist at all) and to explicitly define his own accessibility fields, rearranging them to his liking. The final code is the same, and each style is equally correct "philosophically" from the corresponding perspective.

Well, it sure isn't wrong to do one or the other.

Clearly, this is pretty much an opinion-based (or preference-based) decision. And yes, I certainly agree that the common understanding is that a class is rather the complex thing with built-in logic, and a struct is a few PODs tied together in one lump. Which is likely the reason (apart from the fact that "class" sounds more classy) why everybody writes class for classes (regardless of layout or accessibility).

Still, for some reason, Mr. Stroustrup decided that struct is public by default, and class is private by default. I wouldn't know his personal reasons for that decision, but it's apparently something that made sense in some context. Maybe he wanted to make everything private by default, but finally decided to leave struct as it was because C++ was just C with classes then. Or, something else, who knows.

Either way, as it stands, there's the way that I personally find "the correct way" due to these defaults, and there's the way that I personally find "nonsensical", since it does the exact opposite. That doesn't have to mean that my opinion is the only correct one, but it's how I feel about it.

In the end, like all languages, programming languages, too, are for expressing an intent, and as long as the compiler (and the people around you) understands what you want, it's fine.

structs are public by default because that was most likely how they were in C and he just kept it in C++ since C is a subset of C++. He made classes private by default because they were designed with data hiding in mind.That is what I was told in my programming class years ago.