Who invented to describe the field at the end of class?

When you read examples or real code in C++ often see field descriptions at the end of the class, public or private makes no difference. Why do that? Is it not more logical to first describe the fields which will then work in methods?

of course implementation details are not needed until we have not described
class Foo {
 void doFoo() {
 i = 0; // what happens here? I think everything is OK
 void *i; // it turns out some scoundrel uses 0 instead of nullptr!
July 4th 19 at 23:51
3 answers
July 4th 19 at 23:53
For some reason nobody pointed out that C++ methods most classes (almost all unconventional) are implemented in the. CPP file and the class itself is described in the header file. The reason for this separation:
a) most likely you will not need information about private fields UNTIL, until you begin to work with the implementation; why do you know them, if you do not see the code of the methods (in some sense mere enumeration of private fields in the class description is a problem, see pimpl).
b) when you start working with the implementation, you have ALREADY read the contents of the header, will get acquainted with the interface, with a list of private fields and then will go to the CPP file with the implementation of the methods. So in a sense private fields is transferred TO the code methods.

Your example is only relevant for inline functions and template methods.

And Yes, in other languages, such as C#, since there is no practice of separation of class definition and implementations of the methods, private fields, it is customary to list UP techniques.
July 4th 19 at 23:55
In the beginning usually describes the interface through which will be produced by the interaction (what the user of this class). Interaction directly with variables is a bad practice, so in most cases they are at the end of the class and declared private.
That is just the inertia of consciousness when I write in the same style .cpp file? - charity84 commented on July 4th 19 at 23:58
July 4th 19 at 23:57
Is it not more logical to first describe the fields which will then work in methods?

fields are implementation details, they are not important from the point of view of the interface. So it's logical that shoving private methods below public.

Find more questions by tags C++