Почему в С++ язык не принудительно группирует общедоступные, частные и защищенные члены класса/структуры?

Это дает вам гибкость. Например, у вас может быть куча конструкторов, некоторые общедоступные, некоторые защищенные, некоторые частные - разве вы не хотите, чтобы они были сгруппированы?

Зачем заставлять? Это совсем не помогает компилятору, объективно не облегчает чтение человеку. Частью философии C/C++ является то, что язык не устанавливает произвольных правил, которые не позволяют использовать какую-либо функцию/функциональность.

Это НАМНОГО упрощает генерацию кода. Многие стили кодирования используют спецификаторы доступа более одного раза для каждого класса — сначала определяют все локальные типы, затем все конструкторы, затем все методы, затем все переменные экземпляра и т. д.

C++ дает достаточно возможностей, чтобы выстрелить себе в ногу, но именно эта гибкость позволяет создавать элегантные, удобные в сопровождении и хорошо абстрагированные приложения.

Я думаю, вы правы. Если оставить его необязательным, пользователи могут группировать элементы по своему усмотрению для лучшей читабельности кода.

Компилятор может организовать вещи в памяти по-разному.

изменить: согласно спецификации:

§9.2 clause 12 (1998 and 2003 standards):

Nonstatic data members of a (non-union) class declared without an intervening access-specifier are allocated so that later members have higher addresses within a class object. The order of allocation of nonstatic data members separated by an access-specifier is unspecified (11.1). Implementation alignment requirements might cause two adjacent members not to be allocated immediately after each other; so might requirements for space for managing virtual functions (10.3) and virtual base classes (10.1).

Я нашел эту информацию в связанный вопрос SO

Я предполагаю, что это результат философии C, которая предполагает, что вы знаете, что делаете, и дает вам максимальную гибкость. Это похоже на разрешение одного = в операторе if.

На самом деле я использую это немного неприятным образом: идиома кода, которую я часто использую, — это закрытый член с общедоступными функциями доступа.

У меня есть МАКРО (содрогание), который автоматически генерирует их из одной строки.

пример:

PROPERTY(int, MyVal);

... генерирует:...

private:
  int fMyVal;
public:
  void setMyVal(const int f) { fMyVal = f; };
  int getMyVal() { return fMyVal; };

Это прекрасно работает, если вы помните, что макрос PROPERTY переключает текущую видимость, что неприятно....

eg:

protected:
  int v1;
  PROPERTY (int, v2) // fv2 is  private with public accessors
  int v3;  // whoops. f3 is public,

В «Языке программирования C++, 3-е издание» Страуструп говорит, что это должно упростить генерацию кода.

Хотя имеет смысл, что положение каждого поля в фактическом двоичном файле зависит от того, в каком порядке это поле было объявлено в исходном коде, поэтому это позволяет кому-то поддерживать некоторую совместимость макета с C или даже с другими языками/спецификациями.