C++ codestyle: когда использовать `struct`

Чтобы быть ближе к Си. ИМХО.

А чё пишут в rationale для (){ против ()
{ ? Вот то и пиши.

Если ты о способе расстановки фигурных скобок, то единственное рациональное, что я слышал – «греческие» скобки занимают меньше строчек.

void function(T arg)
{
  if (arg.isFoo())
  {
    doFooThing();
  }
  else if (arg.isBar())
  {
    doBarThing();
  }
}

void function(T arg) {
  if (arg.isFoo()) {
    doFooThing();
  } else if (arg.isBar()) {
    doBarThing();
  }
}

struct - для простых олдовых структур данных. п.2 ненужен.

Греческие? Не египетские?

Зачем городить ещё один coding style? Выбери один из популярных типа Google и дополни его особенностями проекта. Надеюсь однажды комитет C++ догадается включить в стандарт рекоммендуемый для всех code style как во всех нормальных языках, а проверка его соблюдения будет встроена в компиляторы.

«Смысл» - это правила сочетания. Эти правила или постулируются, или выводятся из предыдущих постулатов. В роли выводимых правил может быть статистика. Берешь все свои или не свои юношеские произведения искусства, анализируешь старческим закостенелым творческим умом и пишешь талмут из постулирумых догм.

Использую struct для POD.

Греческие? Не египетские?

Да, ‘‘египетские’’, промазал.

Использую struct для POD.

+

Хорошо сказано. Но я хочу не свод правил «потому, что я так хочу». Я хочу минимальный свод правил, выполняя которые получаешь некие полезности соизмеримые с ограничениями, которые такие правила налагают.

По прямому предназначению, объединению родственных данных

struct mouse
{
   int x;
   int y;
   int button;
   size_t timestap;
   void(*callback)(void*data);
};

struct list
{
  void * data;
  struct list * next;
}ж

Зачем городить ещё один coding style? Выбери один из популярных типа Google и дополни его особенностями проекта.

Руководствуюсь собственно правилами Google и Cpp Core Guidelines.

Исключая сильно рестриктивные пункты и пункты типа ‘‘потому, что мы так решили’’

Для реализации всяких своих типов липа list

Для велосипедов, ты хотел сказать? Здесь о С++ беседа, зачем ты сишечку сюда притащил?

https://google.github.io/styleguide/cppguide.html#Structs_vs._Classes

А почему создал данную тему – я не уверен что написать в ‘‘rationale’’ для данных правил. Т.е. выгдядит, как вкусовщина.

Если использовать struct только для чистых данных, то экономишь на одном слове «public:» и подсказываешь читателю что обьект пассивен - не имеет поведения и предназначен только для чтения и записи полей

и пункты типа ‘‘потому, что мы так решили’’

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

{ на отдельной строке для функций визуально отделает их от их содержимого.

А использую struct для чего-то простого, что само почти ничего не делает, а обрабатывается чем-то другим. Может содержать какие-нибудь утилитарные функции, но по сути такие объекты нужны лишь ради хранения данных.

Отдельно эти 3 пункта не имеют (выводимого) смысла. Нужны основные постулаты: что есть так называемый struct, class. Желательно непротиворечивый набор постулатов. Иначе этими правилами можно будет объяснить все что угодно юношеской незакостенвшей творческой душе.
Взгляд со стороны, не стоит оно того, если занимаешься творческой деятельностью. Разве что, если ты занимаешься техподдержкой, багфиксингом уже достаточно стабильно работающего продукта. Вопрос: зачем ломать, то что уже работает?

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

Надеюсь никогда, т.к. не хочу парашный снаке_казе.

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

А может и правда. Само придет (если все же). Просто стараюсь организовывать вещи. Причем не стараюсь давать перфекционизму переходить в прокрастинацию (что сложнее).

А может и правда. Само придет.

Вроде у физиков есть «принцип минимального действия». Зачем тебе придумывать и да еще соблюдать эти правила. Пользуйся тем, что есть (или насильно навязывают, как во всяких разных гуглах с отступами в питоне).

Я про структуры как таковые, а не язык,структуры везде есть.

Определение POD зависит от версии стандарта

Если вдаваться в подробности стандарта C++, то работать будет некогда.

А чтобы работать, стандарт знать не нужно, ага

для POCO без аксессоров

inb4 не используй С++

Чтобы работать — достаточно знать основы, остальное можно изучить по ходу или при необходимости.

Девиз быдлокодеров

Для junior только так. А senior сразу не станешь. Чтобы изучить С++, библиотеки и инструменты, набраться опыта — нужно время.

Я не знаю. УМВР =)

любые кодестаил для дебилов
struct наше все, в R&D не заменим

Текст стандарта может помочь (а может и не помочь), когда тебя посадят портировать тонну кода на какой-нибудь косой msvc. И балансируя на грани не компилируется/не работает ты будешь очень рад любой ясности. А для того чтобы пилить новый код на фреймворке (культи), где плюсы по сути вообще не требуются, это разумеется не нужно, там каждый первый такой умвр-щик.

struct и class отличаются только тем что публично, а что приватно, ну и особенности наследования. Следовательно, юзать надо то, что требуется в конкретном случае. Больше разницы нет.

Моё ИМХО примерно такое - если у тебя сущность только хранит данные, не имеет внутреннего состояния и методов - тогда struct. Во всех остальных случаях - class.

Из C++ Core Guidelines от Страуструпа:

C.1: Organize related data into structures (structs or classes)
C.2: Use class if the class has an invariant; use struct if the data members can vary independently
C.8: Use class rather than struct if any member is non-public

Короче говоря, struct для POD

Вопрос: если в процессе развития проекта я захочу добавить функции или приватные поля в структуру, то что делать? Переименовывать в класс?

На мой взгляд структуры это что-то из мира Си, и в плюсах им места не должно быть

если у тебя сущность только хранит данные, не имеет внутреннего состояния и методов - тогда struct.

Почему и зачем, если можно класс и в этом случае, для единообразия? Вкусовщина.

struct в данном случае только способ быстро понять что за сущность перед тобой. если struct, то как сказали выше, это POD, если class - то всё по взрослому.

Вкусовщина, да.

Если ты решишь это добавить, то у тебя проблемы с проектированием. Переименовывать в класс в таком случае - борьба с последствиями. Нет необходимости добавлять метод, если нет закрытых данных, можно обойтись свободной вспомогательной функцией. Класс используют для связанных, то есть закрытых данных. Причем работают с такими данными с помощью интерфейса, а не обращаются к ним напрямую. Это позволяет добавлять поля в процессе развития проекта без необходимости пересматривать весь код.

Это я был, если что.

Вот смотри, случай из реального проекта, - есть структура для кривых Безье. Я захотел для удобства добавить в структуру функцию float length() const, которая вычисляет длину кривой. Делать ее свободной float bezierLength(const bezierCurve &bc) не хочу - это будет лишнее засорение глобального неймспейса. Потом подумал, что в общем-то хорошо бы кэшировать ее, так как какая-то кривая один раз создается, а потом length используется много раз для отрисовки, и добавил приватное поле mutable float m_cachedLength для ленивой инициализации. Понимаю, что получается уродство - структура с приватным полем, но как исправить не знаю.

На каком этапе я пошел не туда? Твои идеи как сделать лучше?

Ну и забыл добавить - т.к. появляется кэш, то вводятся сеттеры-геттеры, чтобы кэшированное значение сбрасывалось в случае изменения кривой. Соответсвенно struct меняется на class. Для меня это выглядит как эволюцией кода, а не говнокодом