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

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.

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.

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.