В C ++ почему группировка не навязывается языком для открытых, закрытых и защищенных членов класса / структуры?

Question

Разрешено ли только логическое группирование?

Answer 1

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

Answer 2

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

Это намного облегчает генерацию кода. Многие стили кодирования используют спецификаторы доступа более одного раза для каждого класса - сначала определяют все локальные типы, затем все конструкторы, затем все методы, затем все переменные экземпляра и т. Д. *

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

Answer 3

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

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

редактировать : согласно спецификации:

§9.2 пункт 12 (стандарты 1998 и 2003 гг.):

Нестатические члены данных (не объединяющего) класса, объявленные без промежуточного спецификатора доступа, распределяются таким образом, чтобы более поздние члены имели более высокие адреса в классе объект. Порядок распределения нестатических элементов данных, разделенных спецификатором доступа, не определен (11.1). Требования выравнивания реализации могут привести к тому, что два смежных элемента не будут выделяться сразу после друг друга; то же самое касается требований к пространству для управления виртуальными функциями (10.3) и виртуальными базовыми классами (10.1).

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

Answer 4

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

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

Answer 5

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

У меня есть MACRO (дрожь), который автоматически генерирует их из одной строки.

пример:

PROPERTY(int, MyVal);

... производит: ...

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

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

например:

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

Answer 6

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