Класс против Struct только для данных? - PullRequest
10 голосов
/ 10 января 2009

Есть ли какое-либо преимущество перед использованием класса над структурой в таких случаях? (примечание: он будет содержать только переменные, функций никогда не будет)

class Foo { 
private:   
   struct Pos { int x, y, z };
public:    
   Pos Position; 
};

Против:

struct Foo {
   struct Pos { int x, y, z } Pos;
};

Похожие вопросы:

Ответы [ 7 ]

21 голосов
/ 10 января 2009

Нет реального преимущества использования одного над другим, в c ++ единственное различие между структурой и классом заключается в видимости по умолчанию его членов (структуры по умолчанию являются общедоступными, классы по умолчанию - частными).

Лично я предпочитаю структуры для типов POD и использую классы для всего остального.

РЕДАКТИРОВАТЬ: лит сделал хороший комментарий в комментарии, поэтому я собираюсь процитировать его здесь:

Еще одно важное отличие состоит в том, что структуры вытекают из других классы / структура public по умолчанию, в то время как классы происходят из по умолчанию.

7 голосов
/ 12 января 2009

Одной из сторон является то, что структуры часто используются для агрегированных инициализированных структур данных, поскольку все нестатические члены-данные должны быть открытыми (C ++ 03, 8.5.1 / 1).

struct A {  // (valid)
{
   int a;
   int b;
} x = { 1, 2 };

struct A {  // (invalid)
private:
   int a;
   int b;
} x = { 1, 2 };

class A {  // (invalid)
   int a;
   int b;
} x = { 1, 2 };

class A {  // (valid)
public:
   int a;
   int b;
} x = { 1, 2 };

class A {  // (invalid)
public:
   int a;
private:
   int b;
} x = { 1, 2 };
6 голосов
/ 10 января 2009

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

3 голосов
/ 10 января 2009

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

1 голос
/ 11 января 2009

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

  • Если у вас есть только открытые члены в классе / структуре, вы также можете использовать ключевое слово struct. Это избавит вас от необходимости печатать "public:" позже.
  • Другой причиной выбора структуры над классом является неявное документирование намерения объекта. Таким образом, вы должны создавать структуры типов POD (даже если они содержат конструкторы и некоторые статические вспомогательные методы и т. Д.) И использовать класс для всех остальных «обычных» классов.
0 голосов
/ 10 января 2009

Если содержимое типа не имеет проблем с выделением памяти (например, обычное int), тогда использование struct хорошо, если вы хотите идти по этому пути и приняли осознанное решение, которое вы можете оправдать тем, кто использует ваш код. Однако, если какой-либо из членов имеет тип указателя, вам необходимо тщательно продумать проблемы управления памятью. Возможно, все еще можно использовать struct, но вам, скорее всего, понадобится деструктор, некоторые конструкторы и так далее. В этот момент вы хотите class.

0 голосов
/ 10 января 2009

"(примечание: он будет содержать только переменные, функций никогда не будет)"

Никогда не большое слово. Обычно «никогда» означает «в конце концов». Так как это так, я бы посоветовал вам использовать класс. Таким образом, когда все меняется, вам не нужно так много менять.

Люди с Java (и Python) прекрасно ладят со всем, что является классом. Им не помешало не иметь этих специализированных классов без методов, которые C ++ называет «struct».

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...